19

When I browse to this URL: http://localhost:8080/foo/%5B-%5D server (nc -l 8080) receives it as-is:

GET /foo/%5B-%5D HTTP/1.1

However when I proxy this application via nginx (1.1.19):

location /foo {
        proxy_pass    http://localhost:8080/foo;
}

The same request routed through nginx port is forwarded with path decoded:

GET /foo/[-] HTTP/1.1

Decoded square brackets in the GET path are causing the errors in the target server (HTTP Status 400 - Illegal character in path...) as they arrive un-escaped.

Is there a way to disable URL decoding or encode it back so that the target server gets the exact same path when routed through nginx? Some clever URL rewrite rule?

17

Quoting Valentin V. Bartenev (who should get the full credit for this answer):

A quote from documentation:

  • If proxy_pass is specified with URI, when passing a request to the server, part of a normalized request URI matching the location is replaced by a URI specified in the directive

  • If proxy_pass is specified without URI, a request URI is passed to the server in the same form as sent by a client when processing an original request

The correct configuration in your case would be:

location /foo {
   proxy_pass http://localhost:8080;
}
  • 7
    I had to change http://localhost:8080/ to http://localhost:8080 in case anyone has the same situation as I did. – herrtim Aug 22 '13 at 20:23
  • 3
    Why does Nginx decode the URI before passing it to the backend server? Wouldn't it make more sense if it kept the URI untouched? – platypus Jan 7 '14 at 7:46
  • @platypus, it is kept untouched, until you explicitly start performing the substitutions – cnst Apr 6 '18 at 21:30
0

Note that URL decoding, commonly known as $uri "normalisation" within the documentation of nginx, happens before the backend IFF:

  • either any URI is specified within proxy_pass itself, even if just the trailing slash all by itself,

  • or, URI is changed during the processing, e.g., through rewrite.


Both conditions are explicitly documented at http://nginx.org/r/proxy_pass (emphasis mine):

  • If the proxy_pass directive is specified with a URI, then when a request is passed to the server, the part of a normalized request URI matching the location is replaced by a URI specified in the directive

  • If proxy_pass is specified without a URI, the request URI is passed to the server in the same form as sent by a client when the original request is processed, or the full normalized request URI is passed when processing the changed URI


The solution is to either omit the URI as in OPs case, or, indeed, use a clever rewrite rule:

# map `/foo` to `/foo`:
location /foo {
    proxy_pass  http://localhost:8080;  # no URI -- not even just a slash
}

# map `/foo` to `/bar`:
location /foo {
    rewrite  ^  $request_uri;            # get original URI
    rewrite  ^/foo(/.*)  /bar$1  break;  # drop /foo, put /bar
    return 400;   # if the second rewrite won't match
    proxy_pass    http://localhost:8080$uri;
}

You can see it live in a related Stack Overflow answer, including control group.

  • The documentation is confusing here. Both forms contain a URI. It is the path component that is present in one and missing in the other. – Michael Hampton Apr 7 '18 at 16:36
  • @MichaelHampton, I disagree — the PATH is generally called the URI, so, the one without the path, doesn't contain the URI. – cnst Apr 7 '18 at 18:39
  • A relative path alone can also be a valid URL, of course. The point is, the remainder is also a valid URI (e.g. http://localhost:8080). If you disagree, you can take it up with the authors of RFC 3986. – Michael Hampton Apr 7 '18 at 18:46
  • @MichaelHampton Unforturnately, it seems scheme and path are mandatory to be an URI, authority, arguments, fragment are optional – Norman Xu Dec 4 '18 at 14:58

Your Answer

By clicking "Post Your Answer", you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.