Here’s a fun one for FireFox regarding cookies. I was running through some test scenarios of my West Wind Web Store and while running in FireFox I noticed that I was unable to log on to my store profile with FireFox. Working fine in IE. So how do you debug this?

The thing to do when there are problems with Cookies is to track HTTP headers and see what’s getting sent and then coming back from the client on the next request. These days I mostly use the awesome FireBug tool for my HTTP header debugging (and many other things), but in this case it didn’t work because it only keeps track of the current headers of the current request. If you log in you’ll want to see the headers for potential redirect/reroute URls.

So I used Fiddler instead. Fiddler works automatically with IE, but you can also set up Fiddler to handle Http Headers by setting up a proxy in the FF proxy settings and pointing it at the Fiddler debugging proxy which is by default 127.0.0.1.

So after checking this out I found that for reasons unknown FireFox was generating multiple copies of the same cookie (which in theory should NEVER happen). Here’s the headers I send out when I log in and reconnect to my profile:

HTTP/1.1 200 OK

Cache-Control: private

Content-Length: 6856

Content-Type: text/html; charset=utf-8

Server: Microsoft-IIS/7.0

X-AspNet-Version: 2.0.50727

Set-Cookie: WebStoreUser=344b5786 ; expires=Fri, 28-Jan-2011 08:49:42 GMT; path=/

X-Powered-By: ASP.NET

Date: Sun, 28 Jan 2007 08:49:42 GMT

My login process then displays a confirmation page and then immediately redirects to the original page they came from. The second page now should have the cookie set on it. It does but:

GET /wwstore/Profile.aspx HTTP/1.1

Host: rasvista

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1

Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5

Accept-Language: en-us,en;q=0.5

Accept-Encoding: gzip,deflate

Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7

Keep-Alive: 300

Proxy-Connection: keep-alive

Cookie: WebLogUser=10127252; WebStoreUser=79fd8a7a; ASP.NET_SessionId=hx5wgvm24qmpec45z5zcu245; WebStoreUser=344b5786

As you can see it turns out there are actually two WebStoreUser cookies and when requesting the cookie only the first one (the wrong one) is returned by ASP.NET, which is why the login process is failing.

Now this should never happen in HTTP. Cookies should apply uniquely to a given URL and cookie name, but this is apparently a bug in FireFox. To follow up I checked in FireFox’s Cookie viewer and sure enough I found the problem there:

Apparently I made a typo at somepoint while browsing the site and used .localhost and FireFox stored the cookie as a new domain, but still filed it under localhost causing this conflict. The Cookie entires are otherwise the same – same name, same path (different values for the cookie of course though).

This is a subtle bug, but this has actually bitten me a few times although I can’t  be 100% sure that it’s the same issue exactly. I’m not even sure whether it’s my typo that caused the .localhost to get in there or whether this is an issue with FireFox natively with a formatting problem somewhere, since I've seen this on a few ocassions.

Luckily it's easy to remove the cookie in FireFox - problem solved.