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