Nginx cache-control headers issue

[Andrew Andonopoulos]

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-bounces at nginx.org> on behalf of Francis Daly <francis at daoine.org>
Sent: Saturday, July 20, 2019 7:38 AM
To: nginx at nginx.org <nginx at 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        francis at daoine.org
_______________________________________________
nginx mailing list
nginx at nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20190720/d95da7f0/attachment.html>