Dropping Cookies in IE7

I was asked an unusual question yesterday about cookies, Silverlight and WCF. The scenario was that a Silverlight application was being used in a consumer-facing situation. The application itself communicates with the server using WCF. The service which is the target of the communication uses ASP.NET Authentication to authenticate the user. It’s an implementation detail (but critical to this post) that the method of storing the authentication token is a cookie called .ASPXAUTH.

In a normal (that is, working) scenario with Silverlight, the credentials are sent to the server and an .ASPXAUTH cookie is returned. The browser strips off the cookie and stores it. On any subsequent requests, Silverlight creates a request and sends it the the server through the browser’s networking API. The browser is responsible for determining which, if any, cookies should be send with the request and adding them to the outgoing header. In other words, the Silverlight application has no specific knowledge of or interaction with the .ASPXAUTH cookie.

As you would expect, this mechanism works the vast majority of the time. If it didn’t, I think it would have been a significant story long before now. But my questioner was running into a situation where the Silverlight application was unable to communicate with the server even after authentication was performed. What’s worse, this behavior was only happening on IE7. When Silverlight was run through Firefox, it worked exactly as it was supposed to.

The diagnostic step in a situation like this is to use Fiddler (or whatever your favorite TCP trace application is) to view the raw messages. And what was seen is that although the authentication response had the .ASPXAUTH cookie in it, any requests sent back to the server after authentication did not. Given when I’ve already explained about the processing of cookies with Silverlight requests, this eliminates the Silverlight application as the most likely culprit. But it also makes one scratch your head, as we can be pretty certain it’s not a widespread failure of IE7 to process cookies.

The answer likes in a strange bug in IE7. It turns out that if a domain name has a underscore in it, IE7 doesn’t persist the cookies. Let me repeat that, because it’s such a bizarre sounding problem. In IE7, if the domain name has an underscore (‘_’) in it, then any cookies returned from the domain will not be persisted. Which also means that subsequent requests will be ‘cookie-free’.

I’m guessing that most domain names don’t have an underscore, which is why this bug didn’t get widespread notice. In this particular case, the domain was one used for development, which would keep the problem from being a production issue. But I have no reason to believe that the bug would be restricted to a local problem. Deploy a ‘underscored’ domain name to the public internet and no authentication, shopping carts or other state information can be saved.

Fortunately, the solution was a simple one. If the domain name in the endpoint configuration is replaced with the raw IP address, IE7 is more than happy to save the cookie. I wouldn’t be surprise if an entry in your local hosts file would have the same effect. And the final solution would be to have your domain administrator create a DNS Alias entry…one that doesn’t have an underscore, of course.