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