Thanks everyone for your help on this. I have noticed 2 categories of
cookie names in Woodstock that are impacted by this. One with '/' chars
in the name (JSF viewId) and another with ':' chars (JSF clientId). I
am not yet sure how much code is impacted if I fix it. Any changes to
Woodstock will most likely need to be done by me, I don't know of any
other available resources that are familiar with the code. I'll
evaluate the impact tomorrow morning.
A flag as Bill suggested would help a great deal in meeting the
GlassFish code freeze and minimizing risk. It would also give our users
options. I like the flag idea as well.
Thanks again everyone!
Ken
Bill Shannon wrote:
> I agree, we should fix Woodstock.
>
> Still, this is a tough one. Following the internet philosophy of
> "be conservative in what you send and liberal in what you accept",
> unfortunately I think we're on the accepting side of this one because
> it's the applications controlling what cookie is used and the container
> chooses to accept it.
>
> I would recommend a property or flag or config element to control this.
> I wouldn't complain if the default was "strict". It's also probably fine
> if the control over this in product-specific, assuming the spec allows
> that.
>
>
> Rajiv Mordani wrote:
>> Ken,
>> We hadn't required this in the past I agree. However we are
>> tightening the spec in this release. If a framework / application is
>> using the special characters, it is probably broken as per the
>> specification and the clients that are working off of this might
>> itself be rejecting these cookies because it does not confirm to the
>> specification. Am including Bill and Roberto for their opinion as
>> well. We have reverted the change for now, but I would really want to
>> put this change in else we will have to wait till the next revision.
>> Also Tomcat already has this change in their version of the spec, so
>> if anyone were to use woodstock with Tomcat today, they would be
>> broken just as an FYI. We really should fix woodstock.
>>
>> - Rajiv
>>
>> 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
>>>>>>
>>>>>>
>>>>>
>