admin@glassfish.java.net

Re: Broken Cookie Issue #10850

From: Jan Luehe <Jan.Luehe_at_Sun.COM>
Date: Thu, 05 Nov 2009 18:46:02 -0800

Ken,

I just sent a heads-up to the Servlet EG (bcc'ing you and Anissa)
mentioning that this particular change will most likely have to be
reverted.

Rajiv and I don't anticipate any objections from the EG.

Therefore, I am going to revert it in time for tomorrow's promoted
build.

Thanks,

Jan

On 11/05/09 18:38, Ken Paulsen wrote:
>
> I read RFC2965 and RFC2616... I agree a "token" is not supposed to
> have those characters. This was specified in October 2000 and June
> 1999 respectively.
>
> However, we've never been compliant and our application and
> undoubtedly thousands of others have relied on cookies with illegal
> names. If we change this now, we will break frameworks and
> applications making it more difficult to move to JavaEE 6. At a
> minimum I would ask that we provide a compatibility flag so older
> applications can continue to run.
>
> Question: besides conforming to a spec which we've never followed in
> the past, is there a motivation for this change? Any customers asking
> for it? Any technical reason for making this? What is the benefit?
>
> I also believe in following standards as close as possible (to the
> letter)... but that ship sailed in 2000. We need further discussion
> on this topic.
>
> Thanks,
>
> Ken
>
>
> Rajiv Mordani wrote:
>> I would like to make this change as this is the only time we can make
>> this change until the next release of the spec. It makes the API
>> compliant with the underlying HTTP specs.
>>
>> - Rajiv
>>
>> Jan Luehe wrote:
>>> Hi Ken,
>>>
>>> On 11/05/09 17:37, Ken Paulsen wrote:
>>>>
>>>> Hi Jan,
>>>>
>>>> You made a change to Cookie.java which restricted certain
>>>> characters from a cookie name:
>>>>
>>>> svn diff -r26092:33813 Cookie.java
>>>> - // Note -- disabled for now to allow full Netscape
>>>> compatibility
>>>> - // from RFC 2068, token special case characters
>>>> - //
>>>> - // private static final String tspecials =
>>>> "()<>@,;:\\\"/[]?={} \t";
>>>> + private static final String tspecials =
>>>> "/()<>@,;:\\\"[]?={} \t";
>>>>
>>>> - private static final String tspecials = ",; ";
>>>>
>>>> Woodstock uses "/" in one of the cookie they set. This is
>>>> resulting in our UI not functioning correctly (P2 issue filed:
>>>> #10850 which is blocking testing).
>>>>
>>>> Is this change necessary? If so we're going to have to release a
>>>> new version of Woodstock to fix this, which I would really prefer
>>>> to avoid.
>>>>
>>>> Let me know!
>>>
>>> In javax.servlet.http.Cookie, we've expanded the list of "special"
>>> cookie
>>> chars from
>>>
>>> private static final String tspecials = ",; ";
>>>
>>> to
>>>
>>> private static final String tspecials = "/()<>@,;:\\\"[]?={} \t";
>>>
>>> This was requested by the Servlet EG in order to become compliant with
>>> the HTTP 1.1 spec, see Section 2.2 ("Basic Rules") of RFC 2616, which
>>> has the following:
>>>
>>> Many HTTP/1.1 header field values consist of words separated by LWS
>>> or special characters. These special characters MUST be in a quoted
>>> string to be used within a parameter value (as defined in section
>>> 3.6).
>>>
>>> token = 1*<any CHAR except CTLs or separators>
>>> separators = "(" | ")" | "<" | ">" | "@"
>>> | "," | ";" | ":" | "\" | <">
>>> | "/" | "[" | "]" | "?" | "="
>>> | "{" | "}" | SP | HT
>>>
>>> See how the new definition of "tspecials" in Cookie.java matches the
>>> definition of "separators" in the HTTP 1.1 spec.
>>>
>>> Not sure how to handle this regression ...
>>>
>>> Jan
>>>
>>>>
>>>> Thanks,
>>>>
>>>> Ken
>>>>
>>>>
>>>