Nginx pass_proxy subdirectory without url decoding

[Rinat Silnov]

Hello guys,

First of all thank you for this amazing server!

Here's an issue I'm trying to solve: I need to write an nginx location directive to proxy requests for subdirectory to another server preserving urlencoding and removing subdirectory prefix.

Here's an artificial example — request like this:

http://1.2.3.4/api/save/http%3A%2F%2Fexample.com

should pass as

http://abcd.com/save/http%3A%2F%2Fexample.com

I tried several different ways. Here're couple of them:

        location /api/ {
            rewrite ^/api(/.*) $1 break;
            proxy_set_header   X-Real-IP        $remote_addr;
            proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
            proxy_set_header   Host             $host;
            proxy_pass http://abcd.com;
        }

But it decodes the string, so http://abcd.com gets /save/http://example.com

        location /api/ {
            proxy_set_header   X-Real-IP        $remote_addr;
            proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
            proxy_set_header   Host             $host;
            proxy_pass http://abcd.com;
        }

But it keeps subdirectory, so http://abcd.com gets /api/save/http%3A%2F%2Fexample.com.

Here's the ​question on SO

Is it correct to keep special characters such as ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" | "$" | "," decoded after processing? Is there some workaround for this issue? I would prefer to use subdirectory instead of subdomain since this way you don't have to worry about CORS etc

Thanks a lot!

[Maxim Dounin]

Characters which are not allowed to be passed unescaped are escaped after URI transformation. The ":" and "/" characters are allowed within URI (though may have special meaning in some cases).

If you want nginx to do something custom, you can do so using ​proxy_pass with variables (and the $request_uri variable, which contains original unescaped request URI as sent by a client). In this case it will be your responsibility to do correct URI transformations. Note though that this can easily cause security issues and should be done with care.

[Rinat Silnov]

Hello Maxim,

I guess RFC 2616 ​https://www.ietf.org/rfc/rfc2616.txt section 3.2.3 and RFC 2396 ​https://www.ietf.org/rfc/rfc2396.txt section 2.2 says that special characters like / are not the same as %2F, so they probably shouldn't be decoded at all by proxy, is it my misunderstanding? What kind of "Characters which are not allowed to be passed unescaped" do you mean in this case?

Thank you