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 <francis at daoine.org> 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?


-- 
http://dropsafe.crypticide.com/aboutalecm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20171219/f5d9f6f6/attachment.html>