Nginx cache-control headers issue
francis at daoine.org
Sat Jul 20 07:38:55 UTC 2019
On Sat, Jul 20, 2019 at 12:33:24AM +0000, Andrew Andonopoulos wrote:
> 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
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:
> Response header:
> 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:
> 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".
Francis Daly francis at daoine.org
More information about the nginx