-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Nick,

On 3/1/13 2:58 PM, Nick Williams wrote:
> 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.

There is one caveat that you should be aware of: if Tomcat does not
recognize any of the session ids as valid,
HttpServletRequest.getRequestedSessionId may not return the session id
you expect (that is, the first one).

I know this because of a pathological environment we had a few years back:

1. Two contexts with nested URL patterns (/ and /foo)
2. Two contexts sharing a path prefix (/foo and /foo)
3. One of the two "shared-url" contexts did *not* use sessions, but
contacted the other "shared-url" webapp with the requested session id
form the request (you could think of it as "session forwarding")

Under this configuration, we could get ourselves into a situation
where the session id for the / webapp would be picked up by the
session-less webapp and forwarded to the third webapp. In that case
(and not every time, IIRC), the situation was only recoverable by
expiring all of the cookies and starting over again.

Bug reports were fantastically well-documented like "I was using your
site and it stopped working." Tough to investigate.

The moral of the story is that nested URL spaces is a bad idea where
sessions are concerned. We easily fixed that problem by moving the
/-mounted webapp to a unique URL prefix (which wasn't trivial, since
we had inter-webapp links, etc.) but it solved all of those weird
problems.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEAREIAAYFAlEyBZcACgkQ9CaO5/Lv0PDNYACePkVvMrqjm4BJqhjQjN78tILd
s1wAoLwrlcaVvpE9LzaGn8xYRMj2QMlW
=fQzr
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to