# SSI URI path decoding/encoding issue

**URL:** <https://www.ruby-forum.com/t/ssi-uri-path-decoding-encoding-issue/243714>\
**Category:** NGINX\
**Created:** [December 24, 2015, 11:20pm UTC](https://www.ruby-forum.com/t/ssi-uri-path-decoding-encoding-issue/243714 "2015-12-24T23:20:51Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Rafa\_F](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/958977/32.png) [@Rafa\_F](https://www.ruby-forum.com/u/Rafa_F)\
**Post date:** [December 24, 2015, 11:20pm UTC](https://www.ruby-forum.com/t/ssi-uri-path-decoding-encoding-issue/243714/1 "2015-12-24T23:20:51Z")

</div>

Hi,

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):

> **[inoio gmbh | Integrating Self-Contained Systems - be careful with your SSIs!](https://inoio.de/blog/2015/12/22/integrating-SCSs-be-careful-with-SSIs/)**
>
> 22. Dezember 2015 Integrating Self-Contained Systems - be careful with your SSIs! In this post I’m g...

Does it make sense to submit an issue for this, or is there an  
explanation  
for this behavior / is it intentional?

Thanks && cheers,  
Martin

---

<div class="post-metadata">

**Author:** ![Martin\_Grotzke](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/c68b51/32.png) [@Martin\_Grotzke](https://www.ruby-forum.com/u/Martin_Grotzke)\
**Post date:** [December 28, 2015, 5:25pm UTC](https://www.ruby-forum.com/t/ssi-uri-path-decoding-encoding-issue/243714/2 "2015-12-28T17:25:28Z")

</div>

Hello!

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.

–  
Maxim D.

> **[nginx](http://nginx.org/)**