Hi Francis,
Thanks for the response,
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.
Also "upstream" you mean the Origin for nginx? which is in my case is S3
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:
1.
Accept-Ranges:
bytes
2.
Access-Control-Allow-Credentials:
true
3.
Access-Control-Allow-Headers:
DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Origin,X-Auth-Token,Authorization,Accept,Client-Security-Token
4.
Access-Control-Allow-Methods:
OPTIONS, GET
5.
Access-Control-Allow-Origin:
*
6.
Cache-Control:
public, max-age=8640000, max-stale=0, public max-age=31536000
7.
Connection:
keep-alive
8.
Content-Length:
2535932
9.
Content-Type:
video/MP2T
10.
Date:
Sat, 20 Jul 2019 00:15:58 GMT
11.
ETag:
"9660239489c3a42342fc2fff979f3658"
12.
Expires:
Mon, 28 Oct 2019 00:15:58 GMT
13.
Last-Modified:
Sun, 19 Nov 2000 08:52:00 GMT
14.
Pragma:
public
15.
Server:
nginx/1.17.0
16.
X-Cache-Status:
MISS
17.
X-Proxy-Cache:
MISS
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
Response header:
1.
Accept-Ranges:
bytes
2.
Access-Control-Allow-Credentials:
true
3.
Access-Control-Allow-Headers:
DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Origin,X-Auth-Token,Authorization,Accept,Client-Security-Token
4.
Access-Control-Allow-Methods:
OPTIONS, GET
5.
Access-Control-Allow-Origin:
*
6.
Cache-Control:
public max-age=31536000
7.
Connection:
keep-alive
8.
Content-Length:
3275712
9.
Content-Type:
video/MP2T
10.
Date:
Sat, 20 Jul 2019 00:24:48 GMT
11.
ETag:
"cb86d50c9544c5382d854420c807aa86"
12.
Last-Modified:
Fri, 19 Jul 2019 20:15:31 GMT
13.
Pragma:
public
14.
Server:
nginx/1.17.0
15.
X-Cache-Status:
HIT
16.
X-Proxy-Cache:
HIT
Thanks
Andrew
________________________________
From: nginx <nginx-bounces@nginx.org> on behalf of Francis Daly <francis@daoine.org>
Sent: Friday, July 19, 2019 10:47 PM
To: nginx@nginx.org <nginx@nginx.org>
Subject: Re: Nginx cache-control headers issue
On Thu, Jul 18, 2019 at 06:44:13PM -0400, andregr-jp wrote:
Hi there,
> I have an nginx proxy which suddenly adding 2 cache-control headers and the
> last modified time is always the current time:
I suspect that whatever is being reverse-proxied changed recently to
send these headers.
> #Add Headers
> add_header Cache-Control 'public max-age=31536000
> s-maxage=31536000';
add_header is "please send this in the nginx response, as well as
everything else".
> proxy_hide_header x-amz-id-2;
proxy_hide_header is "please do not send this, from upstream to the
client".
> proxy_ignore_headers Cache-Control;
proxy_ignore_headers is "don't use these special headers".
> I don't know why is adding this control header: Cache-Control: private,
> max-age=3600, max-stale=0
You probably want to add "proxy_hide_header Cache-Control"; or to change
back whatever changed on your upstream which made it claim that things
are public.
You can look at the response from upstream (e.g.,
$upstream_http_cache_control) to confirm whether the header is set there.
f
--
Francis Daly francis@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
