Re: Cache-Control for INTEGRAL transport guarantee?
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Cache-Control for INTEGRAL transport guarantee?
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Cache-Control for INTEGRAL transport guarantee?
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
Re: Cache-Control for INTEGRAL transport guarantee?
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
