Problem using `proxy_redirect` to rewrite the same Location 2-or-more times?
Alec Muffett
alec.muffett at gmail.com
Fri Dec 8 20:48:55 UTC 2017
Hi! I am using Nginx 1.12.2 in a large and complex reverse-proxy
configuration, with lots of content-rewriting (subs_filter, lua, ...).
Problem:
- the client connects to my proxy
- my proxy forwards the request to the origin
- the origin responds with a 302:
"Location: http://www.foo.com/" ...or
"Location: http://www.bar.com/" ...or
"Location: http://www.baz.com/"
...and I have the following dynamic rewriting that I want to perform:
* foo.com -> ding.org
* bar.com -> dong.org
* baz.com -> dell.org
* ...more?
So I have the following three (or more) rules:
http {
# ...etc
proxy_redirect ~*^(.*?)\\b{foo\\.com}\\b(.*)$ $1ding.org$2;
proxy_redirect ~*^(.*?)\\b{bar\\.com}\\b(.*)$ $1dong.org$2;
proxy_redirect ~*^(.*?)\\b{baz\\.com}\\b(.*)$ $1dell.org$2;
# ...more?
...and these work well most of the time.
However: these do not function as-desired when the origin produces a 302
which mentions two or more *different* rewritable site names:
"Location: http://www.foo.com/?next=%2F%2Fcdn.baz.com%2F" <-- INPUT
...which I *want* to be rewritten as:
"Location: http://www.ding.org/?next=%2F%2Fcdn.dell.org%2F" <-- WANTED
...but instead I get:
"Location: http://www.ding.org/?next=%2F%2Fcdn.baz.com%2F" <-- ACTUAL
i.e. the location is converted from `foo.com` to `ding.org`, but no further
processing happens to convert `baz.com` in this example.
The issue seems to be that `proxy_redirect` stops after executing the first
rule that succeeds?
Is this intended behaviour, please? And is there a way to achieve what I
want, e.g. via options-flags or Lua? I am making heavy use of subs_filter,
proxy_cookie_domain, etc.
I've put one of my Nginx configuration files at
https://gist.github.com/alecmuffett/f5cd8abcf161dbdaffd7a81ed8a088b9 if
you'd like to see the issue in context.
Thanks!
- alec
--
http://dropsafe.crypticide.com/aboutalecm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20171208/3c38d13a/attachment.html>
More information about the nginx
mailing list