On 19/07/2021 20:46, Mikael Sterner wrote:
I can understand the motivation for adding a Cache-Control header for
CONFIDENTIAL transport guarantees, as discussed in
But if the transport guarantee is only INTEGRAL (and there are no
authorization constraints), wouldn't it make more sense to let the
resource be fully cached?
One use case would be a single-page app where some static resources never
change (e.g. due to content hashes in their names). These resources would
require data integrity, since it's important that the app logic and
content cannot be modified in transit. But if the resources don't require
authorization they aren't secret, so they don't require confidentiality.
And since they never change, it's wasteful for the client to check with
the server to validate its cache on every request.
What I'm proposing, if the above makes sense, would be to add an
additional criteria to the disableProxyCaching logic in AuthenticatorBase,
that goes through the constraints array and checks if there are any
authorization constraints or user data constraint with CONFIDENTIAL
transport guarantee. If not, no cache control headers should be added.
Static resources could then be configured with a transport guarantee of
INTEGRAL and still redirect to a secure connector if needed, but retain
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:
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.
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org