Hello! On Thu, Dec 24, 2015 at 11:20:04PM +0100, Martin Grotzke wrote:
> we experienced an issue with SSIs (include virtual): nginx at first decodes > the URI path and encodes it before passing the request to the upstream. If > an URI path segment contains %2F (encoded slash), the decoded slash is not > encoded again so that the request sent to the upstream differs from the > original request. Other characters are not encoded as expected as well (at > least the backtick, I've not checked it for others). > > I've described this issue more detailed here (also with debug logs): > https://inoio.de/blog/2015/12/22/integrating-SCSs-be-careful-with-SSIs/ > > Does it make sense to submit an issue for this, or is there an explanation > for this behavior / is it intentional? This behaviour is somewhat intentional. Internal handling of URIs in nginx is in an unencoded form, and more or less the only sensible handling of %2F when you need it unencoded (e.g., to to properly check location prefix or to map to a file) is to decode it to "/". And after it's unencoded there is no way to encode it back properly if you'll need to send it somewhere else with proxy_pass. As a result, when you modify an URI whith %2F within nginx by using rewrite (or construct such an URI with SSI), the special meaning of %2F is lost. It's only preserved if you pass original client URI unmodified - without any rewrites and using proxy_pass without an URI component. -- Maxim Dounin http://nginx.org/ _______________________________________________ nginx mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx
