tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject DO NOT REPLY [Bug 44679] Cookies are treated differently between 6.0.16 and 6.0.14
Date Fri, 23 Jan 2009 16:34:18 GMT

Peter Pichler <> changed:

           What    |Removed                     |Added
                 CC|                            |
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |

--- Comment #29 from Peter Pichler <>  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

The abstract term "token" is used for the definition of possible values for
some HTTP headers defined in HTTP 1.1

Connection = "Connection" ":" 1#(connection-token)
connection-token  = token

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

       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;

        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.


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

    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.


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

>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

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

   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.
    …By default, cookies are created using Version 0 to ensure the best
* 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:
------- You are receiving this mail because: -------
You are the assignee for the bug.
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message