-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 15/01/2014 16:58, Jeremy Boynes wrote: > 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:
OK. No rush. Better we get everything sorted before we start coding. > 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. This could be problematic. We have had explicit requests for name only cookie support. > 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)? Remind me why aren't those allowable. Looking at the Javadoc, the default is RFC2109 but we can optionally support Netscape. >> 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. Browsers might not be but browsers are not the only user agents used with Tomcat. Generally, I'd like to avoid anything that will break existing functionality unless a configuration option is available to provide backwards compatibility. > 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. I'm not a fan of that either. Mark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJS1tVlAAoJEBDAHFovYFnnhAQP/3CljClDnU8uP25lHM6b3EuV jTPdQda0gFMKIfYCi6WEOwl+r1XOOwGW3ZYrc0WuohyEUuZUViv6pPxRJXJofVbu EosOJ+nEry77fgRoNDzKND+R+/mgaEMOYMZKOL74XC6BKNnu5fq2NOI+ddRwsvvJ CZScia/oLi+ZDogngCZV1dk5iTI+v0pif0ad2FSIQsYsBFwMXCwtUvfM5DMo6dOn a/m3ND4ia1PGxrdeAUsUlYkRoydP7AS1wkF5BPcpXP7pSyldgF4MFdKVtlNknOmA t3Y0EE2S31ZSRjrrHOoUJdRhCuQDBJ7Xx7iQuMYA2LPSbsb5GvAnbyauFCO909nT 43jaCC+qMfGi9ZTlfnL6FpfCftGrJeYATD5N8l3WRVma0Ff6Rb5Nq9qX/XsZq6ea Hl/gNvl17Bsli7VRIOOCDlj3M92j4obyw21gGCUBVzOruHRuAYm/M7wpy7YoCwDA U7T4WYSortvfZNz3dHQ2UbewNvJall4YGBC2NXCUEiQw1zaiWbv8tZV8wFs/MXnV TuzgDPPP20m4QZbxgkxpyYxY6rytmzg+KEdGulpgaAAdVPejl2M1dIeJtiwYI3TH 91/CpDR0w8DBkLpytECKXu5+SOLb+TrepieCSwwwXnRUcXJ2ywEIagJu/l4I9l6Z hffjNkZxg6pE/hcdtK9j =0o2e -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
