URL decode rewrite handling: + vs. %20

SplitIce 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
> 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
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20110903/d5b1a960/attachment.html>

More information about the nginx mailing list