SSI URI path decoding/encoding issue

[Maxim Dounin]

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/