Nginx cache-control headers issue
Andrew Andonopoulos
andre8525 at hotmail.com
Thu Jul 25 12:02:27 UTC 2019
Hi Francis,
Nginx decide which content to cache based on the configuration under "Location" + the cache key? For example I have proxy_cache which means will cache everything which match the specific location?
I don't yet why I am getting cache miss for all the token based requests (m3u8 & ts), but I am wondering if is related to cache key and if will need to instruct neginx to check the token first and then cache it? Can this be done?
Thanks
Andrew
________________________________
From: nginx <nginx-bounces at nginx.org> on behalf of Francis Daly <francis at daoine.org>
Sent: Sunday, July 21, 2019 12:26 PM
To: nginx at nginx.org <nginx at nginx.org>
Subject: Re: Nginx cache-control headers issue
On Sat, Jul 20, 2019 at 10:10:39AM +0000, Andrew Andonopoulos wrote:
Hi there,
> 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?
You appear to be using the third-party module documented at
https://github.com/kaltura/nginx-secure-token-module
That page says:
==
secure_token_last_modified
syntax: secure_token_last_modified time
default: Sun, 19 Nov 2000 08:52:00 GMT
context: http, server, location
Sets the value of the last-modified header of responses that are not tokenized. An empty string leaves the value of last-modified unaltered, while the string "now" sets the header to the server current time.
secure_token_token_last_modified
syntax: secure_token_token_last_modified time
default: now
context: http, server, location
Sets the value of the last-modified header of responses that are tokenized (query / cookie) An empty string leaves the value of last-modified unaltered, while the string "now" sets the header to the server current time.
==
which seems to explain both the "that old timestamp" and the "always
the current time" that you reported in the first mail.
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/20190725/9c9c7703/attachment.html>
More information about the nginx
mailing list