tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: HtttServletRequest.getSession()
Date Tue, 14 Sep 2010 22:17:14 GMT
Mark Thomas wrote:
> On 14/09/2010 15:16, Christopher Schultz wrote:
> I'm in the middle of some major re-factoring so I don;t have time to
> actually test this...
>> 0. [Browser has two JSESSIONID cookies: one secure=true and one
>> secure=false]
> This I doubt. When testing load-balancing on a single machine, I have
> seen browsers send the same cookie to two Tomcat instances that only
> differ by port number. I suspect https and http will be treated the same
> way and one cookie will just overwrite the other. You should test that
> to be sure though.
>> 1. Browser makes an HTTPS connection to the server and sends both cookies
>> 2. Application code calls request.getSession()
> Assuming browsers behave the way I think they will, this should be a
> non-issue. If they don't it will get 'interesting'. Either way you'll
> need to experiment to be sure.

RFC 2965            HTTP State Management Mechanism         October 2000

       OPTIONAL.  The Secure attribute (with no value) directs the user
       agent to use only (unspecified) secure means to contact the origin
       server whenever it sends back this cookie, to protect the
       confidentially and authenticity of the information in the cookie.

       The user agent (possibly with user interaction) MAY determine what
       level of security it considers appropriate for "secure" cookies.
       The Secure attribute should be considered security advice from the
       server to the user agent, indicating that it is in the session's
       interest to protect the cookie contents.  When it sends a "secure"
       cookie back to a server, the user agent SHOULD use no less than
       the same level of security as was used when it received the cookie
       from the server.

Personal interpretation : if the browser receives a cookie marked "secure", it should only

send it back with requests happening over an HTTPS connection.
(No matter if it was received over HTTP or HTTPS).

Page 8 :
Port    The default behavior is that a cookie MAY be returned to any

Personal interpretation : if the "Port" attribute is not specified, the browser may return

this cookie on any port; if the port attribute is specified, then it may only return this

cookie with requests made over a connection to one of the listed ports.

on page 9 :

  3.3.3  Cookie Management  If a user agent receives a Set-Cookie2
    response header whose NAME is the same as that of a cookie it has
    previously stored, the new cookie supersedes the old when: the old
    and new Domain attribute values compare equal, using a case-
    insensitive string-compare; and, the old and new Path attribute
    values string-compare equal (case-sensitive).

Personal interpretation, inasmuch as necessary :

Neither the "Port" nor the "Secure" attributes are "identifiers" of the cookie; 2 cookies

which have the same name and domain and path, but different "Port" and/or "Secure" 
attributes, are the same cookie, and one overwrites the other.

So a browser should never return 2 cookies with the same name and path, with a request to

the same host.

It is even clearer on page 11 :

  The user agent applies the following rules to choose applicable
    cookie-values to send in Cookie request headers from among all the
    cookies it has received.

    Domain Selection
       The origin server's effective host name MUST domain-match the
       Domain attribute of the cookie.

    Port Selection
       There are three possible behaviors, depending on the Port
       attribute in the Set-Cookie2 response header:

       1. By default (no Port attribute), the cookie MAY be sent to any

       2. If the attribute is present but has no value (e.g., Port), the
          cookie MUST only be sent to the request-port it was received

       3. If the attribute has a port-list, the cookie MUST only be
          returned if the new request-port is one of those listed in

    Path Selection
       The request-URI MUST path-match the Path attribute of the cookie.

An interesting question is still this :
if a server sends 2 cookies to a browser, with the same name and path, but a diffrent 
domain : cookie 1 has a domain "", and cookie 2 a domain of 
According to what I understand, the browser should cache both cookie separately, as they 
differ by the domain attribute.
But should the browser return both cookies with the next request to the same host ?

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message