On Jan 15, 2014, at 10:37 AM, Mark Thomas <ma...@apache.org> wrote: > On 15/01/2014 16:58, Jeremy Boynes wrote: > > 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.
RFC2109 syntax allows names starting with “$” but there’s a semantic constraint in 4.2.2 that says they are reserved so rejecting those seems right. The JavaDoc refers to "matches a token reserved for use by the cookie protocol” which we’ve taken to include the attributes names but strictly they are a different part of the protocol and there is no ambiguity. I think we are being over restrictive here in excluding them; IMO it may be confusing but it is valid. Strictly Netscape does not preclude an empty name either so perhaps turning that mode on should also allow that by suppressing the "null or empty” clause in the JavaDoc. This would also address the value-only cookie problem and allow them to be round-tripped. We could make STRICT_NAMING multi-valued: - if it’s “false” or “netscape” allow anything per Netscape’s spec including empty - if it’s “true” or “rfc2109” allow anything per RFC2109 (i.e. token and not starting with ‘$’) - if it’s unset or “rfc6265” allow anything per RFC6265 (i.e. token and may start with ‘$’) with STRICT_SERVLET_COMPLIANCE implying "rfc2109"
signature.asc
Description: Message signed with OpenPGP using GPGMail
