Question

I’m trying to have nginx proxy various applications on subpaths of the same domain.

My problem is that the links generated by the application use / as their root instead of their subdir.

My configuration is :

location /wiki/ {
    proxy_pass http://localhost:4567/;
    proxy_set_header SCRIPT_NAME /wiki;
}

I believe proxy_set_header SCRIPT_NAME /wiki; should set the header SCRIPT_NAME, which is use by the application to generate links, but instead HTTP_SCRIPT_NAME is set, which is ignore by the application.

How can I set SCRIPT_NAME so that my links are generated correctly ?

Answer 1

As per CGI specification, http headers are availabe with the HTTP_ prefix:

Meta-variables with names beginning with "HTTP_" contain values read
from the client request header fields, if the protocol used is HTTP.
The HTTP header field name is converted to upper case, has all
occurrences of "-" replaced with "_" and has "HTTP_" prepended to
give the meta-variable name.

That is, header Some-Header will be seen as HTTP_SOME_HEADER in your application. That is, everything works is expected – you added http header, and got it available with HTTP_ prefix.

The SCRIPT_NAME variable is special and isn’t set by any header, but instead it’s constructed from URI by the code which runs your application. To change it, you have to actually change URI seen by your backend, i.e. you need

proxy_pass http://localhost:4567/wiki/;

Or just no /wiki/ in proxy_pass, as long as it’s in location /wiki/ anyway, i.e.

location /wiki/ {
    proxy http://localhost:4567;
}

The bad thing here is that you probably did URI change from /wiki/ to / for some reason, i.e. your backend application expects /. There are several possible solutions to this problem:

1. Actually move the application to /wiki/. Usually this is simple to do.
2. Change your app to accept it’s base url used for generating links etc. by some out-of-bands method. Many application already support this via some configuration option.
3. Try to replace what your application returns by nginx itself. There are several nginx directives to do it, in particular proxy_redirect, proxy_cookie_path, and the sub filter. It’s most fragile method though, and not recommended unless you know what your application returns and what exactly have to be replaced.