URL decode rewrite handling: + vs. %20
signe
nginx-forum at nginx.us
Sat Sep 3 01:21:33 UTC 2011
Ubuntu Natty
nginx/0.8.54
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
month).
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:
http://www.example.com/gallery/foo+bar.jpg.html
which gets rewritten to
http://www.example.com/gallery/main.php?g2_path=foo+bar.jpg.html
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: http://forum.nginx.org/read.php?2,214668,214668#msg-214668
More information about the nginx
mailing list