Closed PeterJCLaw closed 4 months ago
Merging to reflect that this is deployed (given the urgency & impact on teams of it being broken), however post-merge review would still be welcome.
Prior to #51 we had literals for our proxy_pass
arguments. In such cases there are different rules for what's passed to the proxy.
My understanding (though may be in correct) is that given:
location /foo/ {
proxy_pass http://internal/bar/
}
then a request to http://proxy/foo/something
would be transformed into a request for http://internal/bar/something
. However with the introduction of variables in #51 we lots that automatic mapping.
One minor gotcha we do now have is that the public-facing root name now must match the underlying one, or we'd need to manually adjust the prefix of the $request_uri
to match. That does seem to be something which is possible, though keeping them the same probably simplifies things.
Summary
It turns out that when proxy_pass is given a value with variables in then it always proxies to exactly that value, without any of the normal appending of the rest of the path or query. This means we need to explicitly pass the request uri through in such cases.
Exactly what this means for processing of the content returned from the proxied host is somewhat unclear, however testing of the code-submitter suggests at least that its redirects work as desired.
Code review
Testing
Links
https://discord.com/channels/1154145712943153252/1154145715518459950/1207444719655849994
Note: given the urgency here and that this is currently broken I've already applied this fix in prod.