https://issues.apache.org/bugzilla/show_bug.cgi?id=44679
Mark Thomas <ma...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |RESOLVED
Resolution| |FIXED
--- Comment #30 from Mark Thomas <ma...@apache.org> 2009-01-25 01:32:37 PST ---
(In reply to comment #29)
> 1.) HTTP/1.1 allows the usage of separator chars in cookie values
>
> It is not true, that the RFC2616 definition for the term "token" is
> restricting the allowed characters for cookies following the Netscape Cookie
> Definition (cookie 0; see
> http://web.archive.org/web/20070805052634/http://wp.netscape.com/newsref/std/cookie_spec.html)
The cookie 0 spec has a number of ambiguities (eg %XX encoding is suggested but
not supported by many (all?) browsers, the '=' character is not listed as one
that must be quoted if used in a name or value despite the obvious issues this
would cause, etc). The Tomcat treatment of v0 cookies is consistent with the v0
spec and takes a practical view of the various ambiguities that is consistent
with the operation of major browsers.
The v1 spec (RFC2109) does restrict cookie values to token or quoted string.
> 2.) Servlet Spec does not allow separator chars as value for a cookie
> =====================================================================
> The Servlet Specification is indifferent.
The servlet spec defers to the v0 and v1 specs with the additional statement
that:
> With Version 0 cookies, values should not contain white space, brackets,
> parentheses, equals signs, commas, double quotes, slashes, question
> marks,
> at signs, colons, and semicolons. Empty values may not behave the same way
> on all browsers.
The should is enforced as it enables parsing to be unambiguous (see the =
comment above).
> 3.) Your Work Around: Migrating cookies to version 1 Cookies, when they are
> containing special characters
> ==================================================
>
> This is one of the most horrible ways imaginable to handle this problem...
I, and I suspect a number of other committers, strongly disagree.
> There is written "DO NOT USE IT YET (Version 1 Cookies) ON PRODUCTION
> SITES"....
>
> From my point of view the justification ("is still somewhat new") is a little
> bit silly (RFC 2109 has been released Feb. 1997) but the conclusion is right
> in
> every case. ("DO NOT USE ON PRODUCTION SITES")
That statement should have been updated several spec versions ago. v1 cookies
are widely supported and are a lot better than v0 in terms of a well defined
spec.
> If you look outside the servlet spec, you will find there is already a new RFC
> (Cookie 2, RFC 2965). READ the chapter "ABSTRACT" on page 1...
If you read the Tomcat source you will see that the Tomcat developers are well
aware of the various cookie specs.
> Abstract
> ...
> The method described here differs from Netscape's Cookie
> proposal [Netscape], but it can interoperate with HTTP/1.0 user
> agents that use Netscape's method. (See the HISTORICAL section.)
>
> This document reflects implementation experience with RFC 2109 and
> obsoletes it.
>
>
> In plain text.... RFC 2109 is incompatible with the Netscape cookie spec. It
> is
> not possible to support both in one system... So RFC 2109 is not
> experimental... RFC 2109 was an experiment which failed....
Last time I checked browser support for RFC 2965 was patchy. It would also help
if the servlet spec referenced v2 cookies.
> 4.) Conclusion
>
> * The Migration to version 1 is definitely a bug.
We know the auto conversion isn't spec compliant. That is why if you use strict
servlet compliance, the automatic conversion doesn't happen.
The fundamental problem with cookies is a lack of a well defined specification
that is correctly implemented by browsers. This situation is made worse by
ambiguities in the v0 spec.
The changes made to Tomcat's cookie parsing were made to address a number of
security concerns. These changes had to be made. These changes highlighted a
number of browser issues and further changes were made to provide a solution
that is secure and compatible with major browsers.
All the known issues are addressed in 6.0.18. There may interoperability issues
with some systems as a result of Tomcat's stricter parsing. These will almost
certainly need to be addressed on a case by case basis but where there is a
case for adding functionality or a configuration option to Tomcat it will be
considered (please create a separate bugzilla entry for any such proposed
patches).
As has already been noted earlier in this bug, not all of the cookie changes
have been ported to 5.5.x. I will create a new Bugzilla entry for 5.5.x to
track that to make sure all the changes are ported, hopefully in time for the
next 5.5.x release.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
