merge_slashes and decoding of the path

Jason Barnabe jason.barnabe at gmail.com
Mon Nov 25 16:44:15 UTC 2013


On my site, I accept full URL-encoded URLs as part of the path, for example:

http://www.mysite.com/search/http%3A%2F%2Fexample.com%2F

I recently moved my site to nginx and I found that it was decoding and
collapsing the slashes before passing it on to Passenger. It would pass
along the URL like this: http://www.mysite.com/search/http:/example.com/

I found the merge_slashes setting, and on setting it to off, Passenger now
receives URLs like this: http://www.mysite.com/search/http://example.com/ .
So the slashes are kept, but the path is still decoded. The nginx
documentation [1] says "However, for security considerations, it is better
to avoid turning the compression off."

What are the security considerations here? Why does nginx not allow the
encoded slashes to be passed through (like Apache does[2]), and if it did
so, would that negate the security concerns?

[1] http://nginx.org/en/docs/http/ngx_http_core_module.html#merge_slashes
[2] http://httpd.apache.org/docs/2.2/mod/core.html#allowencodedslashes
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20131125/d493aafe/attachment.html>


More information about the nginx mailing list