URL decode rewrite handling: + vs. %20
mat999 at gmail.com
Sat Sep 3 10:22:06 UTC 2011
edit the php script to do something like this before the rest of the script
$_GET['g2_path'] = urldecode($_GET['g2_path'])
On Sat, Sep 3, 2011 at 11:21 AM, signe <nginx-forum at nginx.us> wrote:
> Ubuntu Natty
> PHP 5.3.5 / FPM / FastCGI
> I'm just beginning to work with nginx for the first time. Converting my
> home server (very few hits) as an experiment for possible broader-scale
> testing and implementation on work servers (billions of hits per
> Everything has gone beautifully... up until I begin working on an older
> app: Gallery 2. Some of the photos in my Gallery contain spaces, so
> they're being encoded in the old-but-still-accepted + format. However,
> when I make the requests in nginx, it's passing the pathinfo through to
> fastcgi as an escaped + (%2b) instead of a space (+ or %20).
> The path is something like this:
> which gets rewritten to
> In a path, + should be handled literally per RFC. In a query string,
> it's supposed to be interpreted as a space per x-www-form-urlencoded.
> This is the disparity - what once was path is now query string. Because
> of the conversion, Apache translates the + from literal string to
> encoded space during rewrite. nginx simply encodes the literal string.
> I don't know if there's a solid answer as to which one is strictly
> "correct"... but what I do need to know is if there's a way to achieve
> the same behavior in nginx?
> This is an interesting edge case...
> Posted at Nginx Forum:
> nginx mailing list
> nginx at nginx.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the nginx