Hi Francis,
Thank you for the suggestion, I will start removing the config and try to find which one is the source of the problem. Also, I want to ask you, I saw that the last-modified header with token is always: Last-Modified: Sun, 19 Nov 2000 08:52:00 GMT, but there isn't line in the config forcing this date/time. Can you suggest which code forcing this modified time? Thanks Andrew ________________________________ From: nginx <nginx-boun...@nginx.org> on behalf of Francis Daly <fran...@daoine.org> Sent: Saturday, July 20, 2019 7:38 AM To: nginx@nginx.org <nginx@nginx.org> Subject: Re: Nginx cache-control headers issue On Sat, Jul 20, 2019 at 12:33:24AM +0000, Andrew Andonopoulos wrote: Hi there, > I checked multiple scenarios and when I removed the token I got the correct > header. Looks like when the token is active, I am getting wrong headers. There is lots going on in your config. I suggest it may be useful to have a test system, where you can easily remove most of the config, in order to identify which directive leads to the problem being observed. That "tokens make a difference" is useful information. You config mentions tokens in more than one place. What code handles the tokens? Does it affect the headers that you see are wrong? Is the request made to "upstream" different, when a token is or is not included in the request to nginx? > Also "upstream" you mean the Origin for nginx? which is in my case is S3 Yes, by "upstream" I mean "whatever nginx does proxy_pass to". > For example, this is a token-based request: > > Request URL: > https://example.com/hls/nickelback/Nickelback-Lullaby_960_540_9000000011.ts?token=st=1563581722~exp=1563668122~acl=/hls/nickelback/*~hmac=88ebce1fa4cca0a30b5cb5395bf3c04cde1018cbbfaa1c23506ebbf70e920e3a > > Response header: > Cache-Control: > public, max-age=8640000, max-stale=0, public max-age=31536000 That is not "exactly what you had in your add_header directive". And - it is also not the "private, max-age=3600, max-stale=0" that you reported initially. Is your upstream changing things? Or are you making different request each time, so you do not know what the response will be? Note that the first max-age=8640000 corresponds to 100 days. And your config has "secure_token_expires_time 100d;" which looks like it might be a candidate for where it comes from. And your config has "secure_token_query_token_expires_time 1h;", which might correspond to your original "max-age=3600". > and this is a request without token and all headers are correct: > > Request URL: > https://example.com/hls/nickelback/Nickelback-Lullaby_960_540_9000000000.ts > Cache-Control: > public max-age=31536000 That is also not "exactly what you had in your add_header directive". So I'd call it "not correct". I suggest - for testing purposes, remove as many lines of nginx config as you can. For example -- most of the add_header lines are not needed when testing with "curl", so get rid of them to make the response smaller and easier to analyse. But also -- the configuration that you have for the third-party modules that you use appears to be the source of the response headers that you don't expect. So it probably is not "upstream changed something". Cheers, f -- Francis Daly fran...@daoine.org _______________________________________________ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
_______________________________________________ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
