ср, 14 авг. 2024 г. в 17:29, Mark Thomas <ma...@apache.org>: > > Hi all, > > The IETF HTTP working group is working on RFC 6265bis (the RFC that will > replace RFC 6265). I have been reviewing the changes to see what impact > they might have on Tomcat and our users.
Links: https://datatracker.ietf.org/doc/html/rfc6265 https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-rfc6265bis/ Generally, I think we can do nothing at our end until that paper is approved. Though now is a good time to file comments (complaints, concerns) to IETF. > There are a few changes (e.g. SameSite) we have already implemented. > > There are quite a few changes that I think don't impact us. > > And then there is this: > > Cookie: apple > > Current Tomcat interprets that as name="apple" value="" > > RFC 6265 says any name-value-pair from a Set-Cookie string without an > "=" should be ignored and the Cookie headers should always use = between > the name and the value. Interesting, if I read 5.2 (That section is about processing Set-Cookie by a User-Agent. I was looking at what browsers do at their end.) it first parses that as empty name and value=apple, and then they have "5. If the name string is empty, ignore the set-cookie-string entirely." In RFC 6265bis this step is removed. I think the following: 1) Generally, when encountering an invalid "apple" string there are the following options: a) error out, e.g. throw IAE, or in some other way resulting in sendError(400) b) ignore / drop it The option of a) in case of cookies would be wrong, as cookies may creep in into user's storage and it makes a site inaccessible. 2) Interpreting that case as name="" value="apple" leaves a place for programmatic processing. It decouples parsing and error handling. E.g. if the HttpServletRequest had a getCookie(name) method (in addition to the existing getCookies()), some "security hardening Filter" could do if (getCookie("") != null) { request.sendError(400); } Using an empty name clearly groups those cookies as some "oddity", and allows one to retrieve them at once. There are places where the spec takes advantage of this to define steps in its algorithms. E.g. the step that I cited above from the current RFC6265 <quote> 5. If the name string is empty, ignore the set-cookie-string entirely. </quote> E.g. in RFC6265bis section "5.7. Storage Model" step 22: https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-rfc6265bis/#section-5.7 <quote> 22. If the cookie-name is empty and either of the following conditions are true, abort these steps and ignore the cookie entirely: * the cookie-value begins with a case-insensitive match for the string "__Secure-" * the cookie-value begins with a case-insensitive match for the string "__Host-" </quote> 3) Interpreting that case as name="apple" value="" lacks the advantage of such grouping. (btw That is how cookie attributes are parsed. E.g. "Secure".) 4) I cannot think of a valid use case of handling such cookies. An abstract "Security hardening filter"? Will it block access to the site? Or will it use this feature to "finger-print" users' browsers? Anyway, I think it is a waste of time to support such use cases. (Though we cannot block them, as the same data are available via getHeaders, and parsed manually). I think that 1) We would better switch to "ignore" mode right now, in all supported versions. 2) The "empty name" option seems to be the correct behaviour, But as the majority of web applications would not need this feature, I think that\ "ignore" would better remain the default behaviour. Best regards, Konstantin Kolinko --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
