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?
On Thu, Dec 24, 2015 at 11:20:04PM +0100, Martin Grotzke wrote:
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.