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.) Yours, Mikael --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
