On Jan 1, 2014, at 8:59 AM, Mark Thomas <ma...@apache.org> wrote: > Signed PGP part > On 26/12/2013 19:23, Jeremy Boynes wrote: > > On Dec 26, 2013, at 2:47 AM, Mark Thomas <ma...@apache.org> wrote: > > > > Focusing on the 8-bit issue address by the patch, leaving the other > > RFC6265 thread for broader discussion ... > > > >>> The change only allows these characters in values if version == > >>> 0 where Netscape’s rather than RFC2109’s syntax applies (per > >>> the Servlet spec). The Netscape spec is vague in that it does > >>> not define “OPAQUE_STRING" at all and defines “VALUE” as > >>> containing equally undefined “characters” although > >>> historically[1] those have been taken to be OCTETs as permitted > >>> by RFC2616’s “*TEXT” variant of “field-content.” The change > >>> will continue to reject these characters in names and in > >>> unquoted values when version != 0 (RFC2109’s “word" rule) > >>> > >>> [1] based on comments by Fielding et al. on http-state and > >>> what I’ve seen in the wild > >> > >> Can you provide references for [1]? > > > > This is the mail in the run up to RFC6265 that triggered the > > discussion: > > http://www.ietf.org/mail-archive/web/http-state/current/msg01232.html > > Thanks > > > for that reference. What a complete mess. RFC6265 really > dropped the ball on this. The grammar for cookie-value is a disaster. > So far the issues include: > - no support for 0x80 to 0xFF > - no support for \" sequences > - no support for using whitespace, comma, semi-colon, backslash > > I was beginning to think that factoring out the cookie generation / > parsing and then providing different implementations (one for Netscape > + RFC2109 - roughly what we have now with a few fixes, one for RFC6265 > and maybe one very relaxed) would be the way to go. Having looked at > the first issue that plan already looks like it needs a re-think. > > I'm still hoping that by documenting all the various issues in one > place we will be able to come up with a solution that both addresses > all the issues you have raised and is better than the handful of > system properties we have currently.
I think they did a reasonable job given the mess cookies are in the wild today. They summarize this in the preamble: > The recommendations for cookie generation provided in Section 4 represent a > preferred subset of current server behavior, and even the more liberal cookie > processing algorithm provided in Section 5 does not recommend all of the > syntactic and semantic variations in use today. Section 4 recommends guidelines for servers generating cookies. I interpret that as being “if you follow these guidelines, you have a good chance of actually getting back the value you tried to set.” The rules above (no 8-bit, no escaping, no Netscape delimiters) reflect that principle. A server application can step outside those guidelines but "thar ther be dragons." — Jeremy
signature.asc
Description: Message signed with OpenPGP using GPGMail
