Browsers send all of the cookies because that's the compliant thing to do. 
RFC-2109 [1] says:

> If multiple cookies satisfy the criteria above, they are ordered in
> the Cookie header such that those with more specific Path attributes
> precede those with less specific.  Ordering with respect to other
> attributes (e.g., Domain) is unspecified.


Based on that, assuming Tomcat follows the rules Christopher says it does, you 
should be okay. The /app/myapplication cookie should always come first, and 
assuming it is valid Tomcat should always prefer it.

Nick

[1] http://www.ietf.org/rfc/rfc2109.txt

On Mar 1, 2013, at 1:46 PM, Jose María Zaragoza wrote:

> Thanks for your answers.
> 
> I wonder why browsers don't send only one JSESSIONID
> If I request an URL as www.mydomain.com/app/myapplication/action.do
> and it has got 2 cookies with the same name, one for www.mydomain.com/
> and another for www.mydomain.com/app/myapplication/  , IMHO, that a
> browser should send the most restrictive
> 
> Indeed, I don't know if there is some browser working like that.
> 
> 
> Christopher,
> if the browser sends a JSESSIONID to Tomcat and this JSESSIONID is not
> tracked by the server , does any error happen ?  or is it created a
> new session with a new identifier ?
> 
> Thanks and regards
> 
> 
> 
> 2013/2/28 Caldarale, Charles R <chuck.caldar...@unisys.com>:
>>> From: Nick Williams [mailto:nicho...@nicholaswilliams.net]
>>> Subject: Re: Multiple JSESSIONID
>> 
>>>> That's interesting. I would recommend a servlet filter that captures
>>>> addCookie and friends to see where that "extra" one is being added.
>> 
>>> The two JSESSIONIDs immediately above are in the request, so they're added
>>> by the browser, not the server
>> 
>> Unless the browser is part of a hacking attack, the JSESSIONID cookies 
>> originally came from the server.  The filter would have to be applied to 
>> both the ROOT and /app/myapplication contexts, so it might best be placed in 
>> conf/web.xml to cover all webapps.
>> 
>> - Chuck
>> 
>> 
>> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
>> MATERIAL and is thus for use only by the intended recipient. If you received 
>> this in error, please contact the sender and delete the e-mail and its 
>> attachments from all computers.
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to