regex generated variable loses character encoding when used in proxypass rule

[excudo@…]

I had exactly the same problem as is described in this stackoverflow post:

​https://stackoverflow.com/questions/8838905/how-to-avoid-nginx-to-replace-20-by-whitespace-when-using-as-a-proxy-proxy-pas/31440150#31440150

The proxypass was towards tomcat and in those logs I could see that everything after the (originally encoded) space went missing. Even the HTTP/1.1 part, which caused it to throw a 505.

I can confirm the workaround mentioned in the answers (to assign it to a new variable) works. But this should be fixed structurally, without the need for a workaround.

[Maxim Dounin]

The stackoveflow post uses a part of the unencoded URI as used in ​location matching. Quoting docs:

The matching is performed against a normalized URI, after decoding the text encoded in the “%XX” form, resolving references to relative path components “.” and “..”, and possible compression of two or more adjacent slashes into a single slash.

That is, a configuration like:

location ~ /api/search(/.*) {
    proxy_pass http://127.0.0.1:3003$1;
}

is expected to produce incorrect requests to proxied server. One is expected to use properly encoded variables when using variables in proxy_pass, and this might not be trivial to do. In this particular case, a better solution might be to use a much simpler configuration without variables:

location ~ /api/search/ {
    proxy_pass http://127.0.0.1:3003/;
}

In more complex cases using rewrite ... break; followed by a proxy_pass without an URI component is usually the simplest solution.

Note well that the "workaround" with using set mentioned on the stackoverflow is actually a misuse of a bug (#348). Avoid using it.

[JoshMcCullough@…]

I commented on this other ticket, which is for the same issue. IMO the NGINX team should really consider at least / only encoding spaces in the request-line which proxy_pass generates.

Alternatively, provide us with a built-in directive, e.g. encode_uri:

location ~ /api/search/(?<path>.*) {
    encode_uri $path $encoded_path 
    proxy_pass http://127.0.0.1:3003/$encoded_path;
}

[Maxim Dounin]

Replying to JoshMcCullough@…:

I commented on this other ticket, which is for the same issue. IMO the NGINX team should really consider at least / only encoding spaces in the request-line which proxy_pass generates.

As already replied in #1930, only encoding spaces is certainly wrong thing to do.

Alternatively, provide us with a built-in directive, e.g. encode_uri:

location ~ /api/search/(?<path>.*) {
    encode_uri $path $encoded_path 
    proxy_pass http://127.0.0.1:3003/$encoded_path;
}

See ticket #52.