2015-09-08 22:57 GMT+02:00 Jeffrey Janner <jeffrey.jan...@polydyne.com>: >> -----Original Message----- >> From: Jose María Zaragoza [mailto:demablo...@gmail.com] >> Sent: Tuesday, September 08, 2015 9:08 AM >> To: Tomcat Users List <users@tomcat.apache.org> >> Subject: Re: Multiple JSESSIONID cookies being presented. >> >> 2015-09-08 15:51 GMT+02:00 Jeffrey Janner <jeffrey.jan...@polydyne.com>: >> >> -----Original Message----- >> >> From: Christopher Schultz [mailto:ch...@christopherschultz.net] >> >> Sent: Friday, September 04, 2015 12:46 PM >> >> To: Tomcat Users List <users@tomcat.apache.org> >> >> Subject: Re: Multiple JSESSIONID cookies being presented. >> >> >> >> -----BEGIN PGP SIGNED MESSAGE----- >> >> Hash: SHA256 >> >> >> >> Jeffrey, >> >> >> >> On 9/4/15 12:37 PM, Jeffrey Janner wrote: >> >> > I'm running Tomcat 8.0.24 on Ubuntu 14.04 with Java 8u45, but I'm >> >> > also seeing this on Windows (version doesn't matter), with Tomcat >> >> > 7.0.57 and Java 7u71, and Tomcat 6.0.43 and Java 7U51. >> >> > >> >> > I have 2 contexts installed in Tomcat, one is ROOT, the other >> >> > APP2. Both contexts start off at a login screen unique to the >> >> > context and provided by it (not using container auth). >> >> > >> >> > When I connect to ROOT, no problem, but when I connect to APP2, I >> >> > get 2 JSESSIONID cookies, one with the path "/" and the other with >> >> > the path "/APP2/". >> >> >> >> I would expect this behavior: you have one ROOT app (cookie path=/) >> >> and one APP2 app (cookie path=/APP2). Your browser will send both >> >> cookies to /APP2 because / is a prefix of /APP2. >> >> >> > Chris - >> > I wanted to come back to this case. >> > Why is the above "expected behavior"? >> > The client is connecting directly as "https://hostname/APP2"; and never >> going directly to the ROOT app, yet gets both JSESSIONIDs from Tomcat on >> first connection. To me, this seems like a bug. >> > Only being an admin, I've not fully read the spec, so not sure if the >> above is really expected behavior. >> >> >> http://www.ietf.org/rfc/rfc2109.txt >> >> The following rules apply to choosing applicable cookie-values from >> among all the cookies the user agent has. >> >> Domain Selection >> The origin server's fully-qualified host name must domain-match >> the Domain attribute of the cookie. >> >> Path Selection >> The Path attribute of the cookie must match a prefix of the >> request-URI. >> >> Max-Age Selection >> Cookies that have expired should have been discarded and thus >> are not forwarded to an origin server. >> >> 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. >> >> >> > Thanks for the clarification of what's supposed to happen on receipt, Jose. > However, I am describing what happens on first contact from the client to the > server. > The browser sends https://hostname/APP2, and Tomcat returns: > JSESSIONID=XXXX, path=/ and JSESSIONID=YYYY, path=/APP2/
Sorry, I misunderstood IMHO, that behaviour is strange . Indeed, it doesn't make sense for me to return different id ( XXXX , YYYY ) if you are accesing to only one context (/APP2) Are you sure that your webapp deployed in /APP2 is not accesing to resources ( session-aware resources as JSP, servlet, .. .I mean) stored in ROOT context ? > > My contention is that it shouldn't be sending the first one, since it should > never route the request to the ROOT app, so it should not be generating a > cookie for it. > > However, taking what you say above at face value, are you saying that HaProxy > should only be forwarding the cookie with path=/APP2/ or should it forward > all of them and let Tomcat figure it out. I don't know. In a later email, I talked you about using another cookie ( SRV_ID ) to balance between backend servers. This feature is implemented by HA Proxy ( 1.5 at least ) > > Jeff --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
