SSI URI path decoding/encoding issue
mdounin at mdounin.ru
Mon Dec 28 16:25:03 UTC 2015
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):
> 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.
More information about the nginx