Changes between Initial Version and Version 1 of Ticket #803


Ignore:
Timestamp:
10/02/15 13:32:38 (9 years ago)
Author:
Maxim Dounin
Comment:

Docs say (see ​http://nginx.org/r/proxy_pass):

A server name, its port and the passed URI can also be specified using variables ...

That is, if you use variables, the passed URI is expected to be specified, not a replacement URI part. This behaviour is required for original use case variables support in proxy_pass was added - to allow requests to any resource explicitly specified using variables.

While this may not be very natural behaviour for some other use cases like the one you describe, it's how it's expected to work and documented. Improving docs to be more explicit may make sense though.

Note well that in this particular case, when you don't need to change anything in the URI, it should be better to just use a server name, without an URI part. In this case nginx is smart enough to use original request URI regardless of whether you use variable or not: 

location /test/ {
    set $upstream_var upstream;
    proxy_pass ​http://$upstream_var;
}

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #803

    • Property Keywords docs added
    • Property Component nginx-core → other
    • Property Type defect → enhancement

  • Ticket #803 – Description

    initial v1  
    22
    33if using no-variables the uri is implicitly and transparently appended to the proxy_pass, i.e. a static definition:
    4 
     4{{{
    55location /test/ {
    66    proxy_pass http://upstream/test/;
    77}
     8}}}
    89
    910Called with a URI of /test/this, will call the upstream URL: http://upstream/test/this.  However, if a variable definition is used:
    1011
     12{{{
    1113location /test/ {
    1214    set $upstream_var upstream;
    1315    proxy_pass http://$upstream_var/test/;
    1416}
     17}}}
    1518
    1619The same URL will ignore the URI, and only ever call http://upstream/test/
    … …  
    1821Changing the definition as follows resolves the problem, but is very counter-intuitive as the same command behaves differently which is not expected:
    1922
     23{{{
    2024location /test/ {
    2125    set $upstream_var upstream;
    2226    proxy_pass http://$upstream_var$request_uri;
    2327}
     28}}}
    2429
    2530I don't know if there is a code fix to this--but it wasn't easy to figure out so perhaps the docs could somehow be more clear?