On Jan 15, 2014, at 10:37 AM, Mark Thomas <ma...@apache.org> wrote: > On 15/01/2014 16:58, Jeremy Boynes wrote: > > > 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.
Sorry, I was rushing so perhaps wasn’t clear. Based on where things end up being stored client-side, browsers seem to treat: «X» as unnamed with just a value, same as «=X» although they do not actually send that «X=» as named with no value «X=“”» as named with a value comprising 2 dquotes On write, although Cookie will not allow the first form, it can be sub-classed so getName() could return null or an empty String. As an application actually had to create and use a sub-class to do that, there’s an argument we should respect their intent by writing the anonymous cookie (i.e. «value»), at least if version == 0; I’m not sure I buy that argument, just calling it out as we allow it now (addCookie() does not recheck the name). If getValue() returns null or an empty String, then the application is setting a name-only cookie and: * for V0, we emit «name=» * for V1, we either emit «name=“”» if auto-quoting is enabled or throw an IAE if not (as it is not a valid VALUE). On read, if there is a ‘=‘ present then everything before it is the name and everything after is the value. The change would be that «value» would now be treated as a value-only cookie rather than a name-only one. However, Cookie’s constructor won’t allow an empty name so if we are going to return it to the application we would need to use a sub-class to bypass the checks. My proposal would be to drop the cookie by default, potentially with a property to enable a value-only cookie.
signature.asc
Description: Message signed with OpenPGP using GPGMail
