Welcome! Log In Create A New Profile

Advanced

Re: Nginx cache-control headers issue

Francis Daly
July 20, 2019 03:40AM
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@daoine.org
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Subject Author Posted

Nginx cache-control headers issue

andregr-jp July 18, 2019 06:38PM

Re: Nginx cache-control headers issue

Francis Daly July 19, 2019 06:48PM

Re: Nginx cache-control headers issue

andregr-jp July 19, 2019 08:34PM

Re: Nginx cache-control headers issue

andregr-jp July 19, 2019 09:48PM

Re: Nginx cache-control headers issue

Francis Daly July 20, 2019 03:40AM

Re: Nginx cache-control headers issue

andregr-jp July 20, 2019 06:12AM

Re: Nginx cache-control headers issue

Francis Daly July 21, 2019 08:28AM

Re: Nginx cache-control headers issue

andregr-jp July 25, 2019 08:04AM

Re: Nginx cache-control headers issue

Francis Daly August 01, 2019 01:28PM



Sorry, only registered users may post in this forum.

Click here to login

Online Users

Guests: 174
Record Number of Users: 8 on April 13, 2023
Record Number of Guests: 421 on December 02, 2018
Powered by nginx      Powered by FreeBSD      PHP Powered      Powered by MariaDB      ipv6 ready