Problem using `proxy_redirect` to rewrite the same Location 2-or-more times?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Problem using `proxy_redirect` to rewrite the same Location 2-or-more times?

Alec Muffett

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:

* ...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:


...which I *want* to be rewritten as:


...but instead I get:


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

-- 


_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|

Re: Problem using `proxy_redirect` to rewrite the same Location 2-or-more times?

Francis Daly
On Fri, Dec 08, 2017 at 08:48:55PM +0000, Alec Muffett wrote:

Hi there,

I have not tested this, but it looks like you might already have the
answer...

> - 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?

> 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 do not know if that stop-on-first-match is the intended behaviour. (But
I suspect that proxy_redirect expects to be called in a much simpler
scenario than yours.)

You do currently have a header_filter_by_lua_block{} section, where you
appear to rewrite three specific content-security-related headers based
on multiple regex matches.

Could you not do exactly the same with the "Location" header, since it
is just another header from upstream that will be sent to the client?

It seems so obvious that I guess you must have tried it; but you didn't
explicitly say that you did, so maybe it is worth a shot.

Cheers,

        f
--
Francis Daly        [hidden email]
_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|

Re: Problem using `proxy_redirect` to rewrite the same Location 2-or-more times?

Alec Muffett
Hi Francis!

On 18 December 2017 at 22:26, Francis Daly <[hidden email]> wrote:
You do currently have a header_filter_by_lua_block{} section, where you
appear to rewrite three specific content-security-related headers based
on multiple regex matches.

Could you not do exactly the same with the "Location" header, since it
is just another header from upstream that will be sent to the client?

It seems so obvious that I guess you must have tried it; but you didn't
explicitly say that you did, so maybe it is worth a shot.

Eventually it struck me that this was indeed a solution, but only after I worked out that the proxy_cookie_domain command was similarly operating on a first-match-wins principle.

Then I just dove into it, and coded it.

I am now using Lua to global-search-and-replace upon "Access-Control-Allow-Origin", "Content-Security-Policy", "Content-Security-Policy-Report-Only", "Link", "Location" and "Set-Cookie", and I am getting the behaviour that I wanted, and I am keeping an eye open for other headers to fix.

I believe that I will be able to use the same/similar mechanism to obviate use of `more_clear_headers`, and possibly I can find somewhere convenient to replace the inbound `proxy_set_header` and `proxy_hide_header` with Lua, too.

Perhaps the best thing to do would be (to get someone?) to document this behaviour in the `proxy_redirect` (etc) manuals; I feel that I was led astray because (by comparison) multiple invocations of `subs_filter` work exactly as expected.

What do you think?


--

_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx