On Jan 15, 2014, at 2:38 AM, Mark Thomas <ma...@apache.org> wrote: > Does any one have anything else to add to > http://wiki.apache.org/tomcat/Cookies ? It feels like we should be > looking to make some decisions on where to go with this.
There are two things on my mind I’ve not had a chance to write up yet: 1) Clearer distinction between name-only and value-only cookies. Existing code treats a name-value pair of «X» as being name-only but the browsers treat that as being the value of a cookie-with-no-name. 2) How to handle cookies whose name might be valid RF6265 but won’t be allowed by Cookie’s constructor e.g. «Expires», «$Foo» or the «» name from above. If an application sub-classes Cookie so getName() returns such a value, will we still generate the header as we currently do? If the browser sends such a header should we just drop it (meaning the app would need to parse the Cookie header itself and it’s not round-trippable), or should we allow it (which would mean we would need a sub-class, see C1a)? > My $0.02 to start this discussion is that we should adopt the all of the > proposed changes with the following notes: > - C1 rather C1a > - G1a rather than G1 > (we need to keep an option to switch for backwards compatibility) > - G3a rather than G3 > (Tomcat currently handles quoting / escaping for RFC2109 cookies so > it needs to continue to do so for backwards compatibility) The concern I have with G1a and G3a is that the browsers are not round-tripping the cookies in RFC2109 format. So although we can add quotes to make it a valid RFC2109 value when we send it, when we get it back we will see a RFC6265 format header with no indicator on whether the quotes were there originally or if we added them. The best I’ve come up with, which seems lame, is to have individual flags controlling this behaviour: * escape-on-write, when enabled would escape any non-cookie-octet values, implies quote-on-write * quote-on-write, when enabled would add dquotes to anything with a non-cookie-octet value * unquote-on-read, when enabled would remove leading and trailing quotes * unescape-on-read, when enabled would also replace any ‘\’ escaped characters, implies unquote-on-read This would allow an application owner to run in one of three modes: * new, where client and server views of the value are the same * compatible, where client sees quoted and server sees unquoted * transitional, where quotes are stripped on read and no longer added on write In “transitional" mode, the browser would send a quoted value previously set, we would strip the quotes when returning the value to the application, the application would re-set the cookie, we would send that without quotes, and any client-side code working with that response would always see the new unquoted value. An application could transition by switching directly to “new” mode where we would pass it the quoted value and it would handle removing the quotes. That would give it more control but would require code changes.
signature.asc
Description: Message signed with OpenPGP using GPGMail
