What exactly does the spec or javadocs say that requires the Cookie
class to reject names that are not tokens?
Rajiv Mordani wrote:
> Adding a flag in the Cookie class will be hard at this point - given
> that we are so close to the finish line. At this point we have one of
> 2 options - not do this at this time, or do it and take the hit on the
> impl side via an implementation specific flag or just fixing things.
> The spec does not allow not being strictly compliant in this area,
> however Tomcat already has a flag that says don't comply strictly to
> servlet spec requirements.
>
> - Rajiv
>
> 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
>>>>>>>
>>>>>>>
>>>>>>
>>