On Tue, Jul 20, 2021, at 10:04, Mark Thomas wrote:
> Cache headers have been somewhat of a moving target with different 
> browsers behaving in different ways at different times over the years.
> I wanted to review the current state of things before forming an opinion 
> on this suggestion. I found the following the most useful:
> https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control
> https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Expires
> https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Pragma

Thanks for the investigation!

This surely seems a difficult area to find a one-size-fits-all solution.
My hope was that a new default for the no-authorization-constraint and
INTEGRAL-transport-guarantee case would make it unnecessary to set these
headers explicitly for static contexts. But if I anyway want to set
something exotic like "immutable" for static resources, the best I could
hope for from such a new default would be a clean slate, i.e. as few
headers set as possible.

> I'm wondering if an alternative solution would be to move the code that 
> sets "Expires: Thu, 01 Jan 1970 00:00:00 GMT" to the 
> securePagesWithPragma section. If we are sending "Cache-control: 
> private" then I don't, at the moment, see a need to force revalidation 
> of that cached content on every request. That would leave the 
> application free to set its own expires headers (or not) as it saw fit.
> Anyone using an HTTP/1.0 proxy would need to be using 
> securePagesWithPragma anyway so would be unaffected by this.

That would leave the slate cleaner at least. Though I'm not sure why
Expires would still be needed for the securePagesWithPragma branch; if
it's not, I guess it could simply be removed. (Sorry for any confusion
talking about Cache-Control: no-cache in the first post. I hadn't noticed
that securePagesWithPragma was now by default false, so I looked at the
wrong code branch.)


To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to