Hi folks, 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/". On the Windows implementations, we are not seeing a problem, at least not one being reported. On the Linux implementation, the end user will occasionally get immediately kicked out with an invalid session immediately after providing credentials. The access logs show a single jsessionid=xxx being provided on the POST URL. Amazingly, sometimes that goes through and lets the user login, so my theory is that the browser is sometimes picking the wrong path. (Also, theory, the "/" cookie is being generated by a request for "/favicon.ico" just before the request for the login page.)
So my question is: Is there anything I can do from a configuration perspective to get it to NOT send the "/" cookie for APP2? Deployment details: Linux is being fronted by an HaProxy server, but the traffic appears to be staying on one host. Server.xml is essentially the basic one provided with install. Port # and access log information is modified and has RemoteIpValve setup so we can log the end user's IP. Apps are deployed as war files with static context.xml files in Catalina/localhost. Those files all look like: <Context> <Manager pathname="" /> <Resource ...jdbc connection info.... /> </Context> War files do get exploded. I can't find anything in the web.xml files that have anything to do with cookies. Any help here would be appreciated. Jeffrey Janner
