Forum Discussion
rjordan
Nimbostratus
Apr 15, 2011cookie persistence problem - IE8 cookie domains
I'm having some issues with session persistence. I'm using the default cookie insert method (only customized the name) and it seems that IE requests are sending cookies for domains that don't really match. If the browser requests domain.com, shouldn't the cookie domain be set to "domain.com", not ".domain.com"? It seems that IE does not follow this practice, but Firefox works properly.
The web application has some chatter between domain.com and sub.domain.com (separate VIPs) and IE is sending the persist cookie for domain.com in the request for sub.domain.com. The load balancer dumps both cookies, makes a new load balancer decision and sends a new cookie in the response. This what it looks like:
Request to domain.com
response: LB-Persist=ABC New persist cookie for domain.com
302 to sub.domain.com/attempt
request: LB-Persist=ABC Why is it sending the cookie for domain.com?
response: LB-Persist=DEF New persist cookie for sub.domain.com
302 to domain.com/?attempted=true
request: LB-Persist=ABC Properly sending domain.com cookie in the request
302 to sub.domain.com/login
request: LB-Persist=ABC Again incorrectly sending the cookie for domain.com
request: LB-Persist=DEF Also sends appropriate cookie for sub.domain.com
response: LB-Persist=GHI The response includes a new persist cookie and the session is lost
Has anyone dealt with this before? I'm hoping the persistence settings can be modified without dealing with iRules. We have several hundred VIPs and it could be a management nightmare if we have to customize each one.
Thanks.
2 Replies
- Joel_Moses
Nimbostratus
According to RFC-2109, the leading period before the domain name field in an HTTP cookie is required:Domain=domain Optional. The Domain attribute specifies the domain for which the cookie is valid. An explicitly specified domain must always start with a dot.
Lots of browsers will accept cookie domains without leading dots, but it's non-standard.
Now then, on to your other issue. The domain .domain.com on a cookie will match host "domain.com" and "sub.domain.com" as well. Firefox will take a cookie without a leading period set and declare it an "exact match" (this is actually called "Netscape cookie compatibility"), which is why this isn't broken on Firefox but is under IE. The trouble here is that Microsoft is reading the standard one way and the Mozilla folks another -- and that's not likely to change.
You're going to have to use a different persistence cookie name on each site. That's the most "compatible" way to handle this. - veer_96014
Nimbostratus
I am facing kind of similar issue. I have two domains (primary and secondary) mapped to 127.0.0.1 in the hosts file. I have web application deployed on weblogic (only one application deployed).
127.0.0.1 mysystem.comp.com
127.0.0.1 sub.mysystem.comp.com
Now I open up IE8 and go to primary domain i.e. http://mysystem.comp.com:7001/ and login successfuly. The session cookie I see in the response is
WLCookie=nYXNQQXRZp7dQdGXLy1dhylQZbtPdJFTjp9f81s5926PQyG04nPb!1416791498
Now I open another tab in the same browser window of IE8 and try to navigate to subdomain (sub.mysystem.comp.com
). Now the subdomain also has the cookie from primary domain. Though I try to clear it by setMaxAge(0), setPath("/"), setdomain, however this cookie does not clean out which causes the weblogic to not accept the session, returns me to the Login page on the second ie tab (subdomain).
This does not happen if instead of a tab I open up a new browser window.
This issue does not occur on firefox, chrome. Please provide a solution to this issue
Help guide the future of your DevCentral Community!
What tools do you use to collaborate? (1min - anonymous)Recent Discussions
Related Content
DevCentral Quicklinks
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com
Discover DevCentral Connects