Hi Chris, On 04.09.2009 16:29, Christopher Schultz wrote: > Rainer, > > On 9/4/2009 12:52 AM, Rainer Jung wrote: >> On 03.09.2009 23:31, Christopher Schultz wrote: >>> Whenever a client browses to webapps found on / and /foo, the requests >>> to /foo will get TWO cookies, and confusion may occur (I'm not sure what >>> mod_jk will do in this situation... Rainer?). > >> Not sure either :( > >> Even if I looked at the code now, I wouldn't take it for granted, that >> the behaviour can't change. > > Agreed. I don't have a cluster handy to test, but it would be good to > know what mod_jk actually does in the case where multiple JSESSIONID > cookies exist and have different jvmRoute suffixes. > >> Actually I'm not even sure what the browser is supposed to send (the >> same cookie multiple times, or only the one with the longest path >> match). > > My experience was that /both/ cookies were sent (which makes sense, > since there's no prohibition against the same cookie name being used > more than one time when a different path is used).
OK, I did some (very little) work: RFC 2109 and 2965 both state: 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. (sections 4.3.4 resp. 3.3.4). The code of mod_jk (1.2.28) looks for a URL encoded session id (and uses that one if it finds one) and otherwise it takes all cookie session ids it can find in the order of Cookie headers in the request. It then uses all the session ids in this order and searches for a usable worker (e.g. existing and not being in error or stopped) until it finds one or runs out of session ids. Regards, Rainer --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
