https://issues.apache.org/bugzilla/show_bug.cgi?id=44679
Peter Pichler <peter.pich...@csd.at> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |peter.pich...@csd.at
Status|RESOLVED |REOPENED
Resolution|FIXED |
--- Comment #29 from Peter Pichler <peter.pich...@csd.at> 2009-01-23 08:34:14
PST ---
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)
Why:
The abstract term "token" is used for the definition of possible values for
some HTTP headers defined in HTTP 1.1
e.g.
Connection = "Connection" ":" 1#(connection-token)
connection-token = token
(http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14)
The cookie and the Set-Cookie HTTP header is not defined in Http/1.1.
So from the point of view of Http/1.1 Cookie and Set-Cookie are so called
"extension headers" (see
http://www.w3.org/Protocols/rfc2616/rfc2616-sec7.html#sec7.1)
entity-header = Allow ; Section 14.7
| Content-Encoding ; Section 14.11
| Content-Language ; Section 14.12
| Content-Length ; Section 14.13
| Content-Location ; Section 14.14
| Content-MD5 ; Section 14.15
| Content-Range ; Section 14.16
| Content-Type ; Section 14.17
| Expires ; Section 14.21
| Last-Modified ; Section 14.29
| extension-header
extension-header = message-header
Section 4.2 defines the syntax for the abstract term "message-header"
message-header = field-name ":" [ field-value ]
field-name = token
field-value = *( field-content | LWS )
field-content = <the OCTETs making up the field-value
and consisting of either *TEXT or combinations
of token, separators, and quoted-string>
The term "TEXT" is defined in Section 2.2 (Basic Rules;
http://www.w3.org/Protocols/rfc2616/rfc2616-sec2.html#sec2)
TEXT = <any OCTET except CTLs,
but including LWS>
OCTET = <any 8-bit sequence of data>
CTL = <any US-ASCII control character
(octets 0 - 31) and DEL (127)>
LWS = [CRLF] 1*( SP | HT )
*********
Conclusion: HTTP/1.1 restricts possible values for cookies. Using CRT
characters is not allowed.
!!!!! It is definitely allowed to use separator characters !!!!!!
**********
2.) Servlet Spec does not allow separator chars as value for a cookie
=====================================================================
The Servlet Specification is indifferent.
The description of the Cookie Constructor says
public Cookie(java.lang.String name, java.lang.String value)
Constructs a cookie with a specified name and value.
The name must conform to RFC 2109. That means it can contain only ASCII
alphanumeric characters and cannot contain commas, semicolons, or white
space or begin with a $ character. The cookie's name cannot be changed
after creation.
The value can be anything the server chooses to send. Its value is probably
of interest only to the server. The cookie's value can be changed after
creation with the setValue method.
By default, cookies are created according to the Netscape cookie
specification. The version can be changed with the setVersion method.
(see
http://java.sun.com/products/servlet/2.3/javadoc/javax/servlet/http/Cookie.html#Cookie(java.lang.String,%20java.lang.String)
You can read it? "The value can be anything the server chooses to send"
You are right, the comment of the Cookie.setValue(String) Method sounds
different...
public void setValue(java.lang.String newValue)
Assigns a new value to a cookie after the cookie is created. If you use a
binary value, you may want to use BASE64 encoding.
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.
(see
http://java.sun.com/products/servlet/2.3/javadoc/javax/servlet/http/Cookie.html#setValue(java.lang.String)
)
It seems that the writers of the setValue - Comment made the same mistake when
interpreting HTTP/1.1. (see Top 1). But they say "should",... The proposal to
use the BASE64 encoding for binary information is funny, cause a BASE64 encoded
binary information can contain slash and the equal character, ... characters
which should not be used for a cookie 0 value....
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...
Read what the Servlet Spec says in the setVersion() Comment...
public void setVersion(int v)
Sets the version of the cookie protocol this cookie complies with. Version
0 complies with the original Netscape cookie specification. Version 1
complies with RFC 2109.
Since RFC 2109 is still somewhat new, consider version 1 as experimental;
do not use it yet on production sites.
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")
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...
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....
4.) Conclusion
* The Migration to version 1 is definitely a bug.
See http://java.sun.com/webservices/docs/1.6/api/javax/servlet/http/Cookie.html
…By default, cookies are created using Version 0 to ensure the best
interoperability.
* The newly implemented restriction concerning possible values for cookie0 can
be argued with the second comments in the Cookie.setValue() method… You may
say some parts of the Java-Servlet-Spec advise against the usage of separator
characters…. But these characters are definitely allowed for cookie0 values
in HTTP/1.1. In previous versions it was no problem to use e.g. a Base64
encoded binary information as cookie value. (as recommended in the Servlet
spec!). From my point of view it is still a bug, that this is not possible any
more. (tomcat 6.18 fixes also some security issues… The update makes troubles
in existing applications… )
- So I will reopen the bug…
(I can live with it… I implemented my own Cookie0 Parser and our software
does not use the Cookie-API any more… (we are implementing a security reverse
proxy… and I have to handle cookies as they are defined… an even as they
are used in widespread system… e.g. WebSphere uses “:” in its session
cookie; a lot of applications are using BASE64 encoded strings).
If you need a fast Cookie0 parser I can contribute one….
--
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
