Opened 14 years ago
Closed 14 years ago
#17 closed enhancement (fixed)
Photon: Allow Query Strings for Whitelisted Domains
| Reported by: | mdawaffe | Owned by: | barry |
|---|---|---|---|
| Priority: | major | Component: | photon |
| Keywords: | Cc: |
Description
Attached:
- Defines
PHOTON__ALLOW_ANY_EXTENSIONandPHOTON__ALLOW_QUERY_STRINGSconstants. - Redefines the
$origin_domain_exceptionsto be an associative array where the keys are domains and the values are bitmasks of the above constants. - For domains where query strings are allowed, pass them via the 'q' query string (rather than attempting to encode them in the path).
For example, an image URL like:
http://image.example.com/image?foo=bar
is Photoned as:
http://photon.example.com/image.example.com/image?q=foo%3Dbar&resize=100,100
Attachments (2)
Change History (5)
Changed 14 years ago by
| Attachment: | photon-17.diff added |
|---|
comment:2 Changed 14 years ago by
Replying to barry:
Why did you decide to support query strings via a separate query arg rather than attempting to encode them in the path?
Because I originally thought it would be difficult to determine if the path was encoded or not. It turns out, with minor, ignorable edge cases, it should be easy to determine if a path is encoded: look for a "/".
As we discussed elsewhere, encoding the path makes things more opaque (a more objective sounding way of saying "ugly").
Instead, Photon should output an error if q is passed for a non-whitelisted domain.
comment:3 Changed 14 years ago by
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
Why did you decide to support query strings via a separate query arg rather than attempting to encode them in the path? It makes caching support more complicated because we either have to maintain the whitelist also in the caches or add the "q" arg to the cache key which defeats one reason for not supporting query args in the first place which is to prevent random requests from bypassing the cache.