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