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
>>>>>
>>>>>
>>>>