We have multiple copies of a web-app that is deployed on multiple paths on the same domain.
Example:
Each instance maintains a set of cookies each one defines its path
as "/" + .getWebDirRoot()
- i.e. /abc
, /xyz
, /abc123
When performing the following flow:
- Login to http://mydomain.com/abc
- Perform some activity
- Logout
- Login to http://mydomain.com/abc123
- Perform some activity <-- Failure
The last step fails since IE
sent us the incorrect cookie - it sends the one for http://mydomain.com/abc instead of the one for http://mydomain.com/abc123
This does not happen in FireFox. (And I haven't tried any other browser).
Is this a known behavior of IE
(I tested IE9
and IE8
)?
Is there a way to overcome it (in a programmatic manner)?
Note: Just to clarify, this does not happen when switching from http://mydomain.com/abc to http://mydomain.com/xyz - the behavior is strictly restricted to flows where currentUrl.startswith(urlAssociatedWithCookie) == true
I checked the behavior using Fiddler - I clearly see the HTTP request for abc123
sent with the value of the cookie belonging to abc
.
I also checked the cookies on FireFox and they are as expected - one created per path.
After investigating for more than a day and looking everywhere for specification on IE's behaviour I came up with nothing - apart from the understanding that when
IE
sees a cookie from domainxyz
and pathabc
, it will send it on any request sent to any URL starting with the same domain and path, e.g. `http://xyz/abc123'.So eventually what I did was change my cookie creation, and instead of:
I now create the following:
This solved the problem with no ricochetes - the cookie is saved succesfuly on the client and the correct cookie is always sent to the server.
Note: I checked the RFC for HTTP Cookies and found this:
The scenario that should have applied here is the 3rd, but it looks like
IE
does not comply with the RFC on this case ...