Wrong logic for NONE as certificateKeystoreFile?
It seems like the logic implemented for NONE as certificateKeystoreFile deviates from the documentation. Currently NONE is always interpreted as a file path, even for PKCS11. Looks like the comparison with NONE should be inside the parentheses for the negation? A workaround is to use "" instead of NONE. https://github.com/apache/tomcat/blob/main/java/org/apache/tomcat/util/net/SSLUtilBase.java#L196 Yours, Mikael - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Minor doc bug, DSS should be DSA for certificate type?
In tomcat/webapps/docs/config/http.xml, it seems like the valid values for the type attribute of the Certificate element should include DSA instead of DSS, to match the enum used in the code? https://github.com/apache/tomcat/blob/main/java/org/apache/tomcat/util/net/SSLHostConfigCertificate.java#L276 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 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 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
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
