Reputation: 9936
I have a system which generates a cookie in PHP, then needs to delete it from classic ASP. This is a quick-and-dirty dev box, just a spare XP machine running IIS5, PHP5, and ASP3. I used the hosts file to create a fake domain name (www.localtest.com) since other parts of the process wouldn't work with localhost.
The PHP file is in a subdirectory off the site root, but the cookie domain is .localtest.com and the path is root (/). The cookie name is "authkey" and the value is a 32 byte hashcode.
The ASP file is in the site root (for now). It can read the cookie just fine after PHP creates it, but no matter what I try I can't seem to change the cookie at all from ASP -- it won't change the value, let alone change the expiration. Both Firefox 3.5 and IE 8 ignore every attempt I've made (figures that when they finally agree on something, it would be this).
I have tried many, many variations -- setting just the expiration (to a wide variety of values in various formats), setting all parameters to exactly match the cookie except the expiration, using Response.AddHeader to emit a Set-Cookie header with all those variations, setting the value to false, and then finally just an attempt to change the value to some other string, which failed.
What the heck is going on? Is this some ASP side-effect of running with a "fake" domain? I've developed this way for 10+ years without seeing ASP have any trouble with a hosts-specified domain, although I've never had occasion to delete a cookie (oddly enough).
I'm especially surprised that I couldn't even set the value.
Upvotes: 2
Views: 1165
Reputation: 9936
Weird.
The problem was the leading dot in the domain name. Since my site isn't using sub-domains I don't really need it -- but apparently if that dot is there, the browsers won't delete or change the cookie.
I'm wondering if that's new behavior since I know a lot of systems rely on that to make sub-domain-neutral cookies (such as phpBB).
Also, to delete the cookie I had to specify everything -- domain, path, and date, but I think that's actually per the RFC so I'm not too concerned about it.
Upvotes: 0
Reputation: 281675
Use Fiddler or similar to look at the actual HTTP traffic - the server technology shouldn't matter, as long as the right HTTP headers are being sent. Presumably they aren't, but you won't know for sure unless you look at the HTTP stream.
(Normally I'd recommend Wireshark, but that doesn't work when the client and server are on the same machine.)
Upvotes: 2