You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Mikael Sterner <ms...@tomcat.mxy.se> on 2021/07/19 19:46:34 UTC
Cache-Control for INTEGRAL transport guarantee?
Hi!
I can understand the motivation for adding a Cache-Control header for
CONFIDENTIAL transport guarantees, as discussed in
http://tomcat.10.x6.nabble.com/tomcat-8-0-jre8-user-data-constraint-CONFIDENTIAL-user-data-constraint-adds-Cache-Control-private-tp5077170p5077201.html
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
full caching.
Yours,
Mikael
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Cache-Control for INTEGRAL transport guarantee?
Posted by Mikael Sterner <ms...@tomcat.mxy.se>.
On Wed, Jul 21, 2021, at 16:35, Mark Thomas wrote:
> I'm reluctant to remove the Expires header from the the
> securePagesWithPragma branch because that branch is for older HTTP/1.0
> proxies and I'm not confident that it isn't required for some proxies.
> I'm not confident it is required either so my default position is to
> effectively leave it as it is. If someone reports a problem with it with
> an HTTP/1.0 proxy we can look at it then.
Makes sense.
> For the other branch, I am confident that Cache-Control header will be
> honoured which means that the Expires header is unnecessary. Since the
> Expires header is also triggering unnecessary cache validations then I
> can see a benefit to effectively removing it for that branch.
Sounds good. I guess it's also better the fewer headers Tomcat sets, since
there doesn't seem to be a portable way to remove a single header from a
response, only to replace it.
Yours,
Mikael
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Cache-Control for INTEGRAL transport guarantee?
Posted by Mark Thomas <ma...@apache.org>.
On 21/07/2021 08:06, Mikael Sterner wrote:
> 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.)
I'm reluctant to remove the Expires header from the the
securePagesWithPragma branch because that branch is for older HTTP/1.0
proxies and I'm not confident that it isn't required for some proxies.
I'm not confident it is required either so my default position is to
effectively leave it as it is. If someone reports a problem with it with
an HTTP/1.0 proxy we can look at it then.
For the other branch, I am confident that Cache-Control header will be
honoured which means that the Expires header is unnecessary. Since the
Expires header is also triggering unnecessary cache validations then I
can see a benefit to effectively removing it for that branch.
If I don't see any objections, I'll aim to do that in a couple of days.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Cache-Control for INTEGRAL transport guarantee?
Posted by Mikael Sterner <ms...@tomcat.mxy.se>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Cache-Control for INTEGRAL transport guarantee?
Posted by Mark Thomas <ma...@apache.org>.
On 19/07/2021 20:46, Mikael Sterner wrote:
> Hi!
>
> I can understand the motivation for adding a Cache-Control header for
> CONFIDENTIAL transport guarantees, as discussed in
> http://tomcat.10.x6.nabble.com/tomcat-8-0-jre8-user-data-constraint-CONFIDENTIAL-user-data-constraint-adds-Cache-Control-private-tp5077170p5077201.html
>
> 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?
Probably.
> 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
> full caching.
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
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.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org