I'm currently building a web-app for a client who would like to utilise cookies to better shape their traffic, etc, etc, you know the drill.
So at the end of last week I added a simple cookie write (basically set cookie="helloworld") and a cookie read with a counter to the app, which is effectively just a single page so every request to the service goes through this read/write for sure.
A few million requests after deployment cookie read rates were at ~25% of total requests, and now after the weekend they've only crept up to ~33%.
For reference: no path is set, the domain is fixed, the expiry is a month from creation. The number of repeat visits is relatively high. I am 100% confident in the technology for setting/getting and counting.
Update: further investigation reveals that the acceptance rates are 90% for browsers which (surprise, surprise) aren't IE. Requests which identify themselves as IE (which no doubt includes a number of bots) have a 10% acceptance rate. Based on a fiddler session (confirmed by firebug), the response headers look like this:
HTTP/1.1 200 OK
Content-Encoding: gzip
Expires: Wed, 09 Jun 1993 00:00:00 GMT
Vary: Accept-Encoding
Set-Cookie: foo; domain=bar.com; expires=Sat, 11-Jul-2009 11:10:19 GMT; path=/; HttpOnly
Cache-Control: no-cache
Cache-Control: private
Cache-Control: no-store
Cache-Control: must-revalidate
Cache-Control: max-stale=0
Cache-Control: post-check=0
Cache-Control: pre-check=0
Date: Thu, 11 Jun 2009 11:10:19 GMT
Transfer-Encoding: chunked
X-AspNet-Version: 2.0.50727
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
Content-Type: text/html
Pragma: no-cache
So I have two theories:
1). IE sees a conflict in the headers which causes it to ignore the cookie - possibly this is related to the cache-control fields?
2). Something is missing or malformed which IE requires. I can find no evidence of this googling for it.
Can anyone find fault with the headers above or have similar experience?