views:

529

answers:

2

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.

+2  A: 

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.)

RichieHindle
Cool, thanks, I've been looking for something like Fiddler.
McGuireV10
The headers look completely normal. Fiddler shows:Set-Cookie: authkey=; expires=Sat, 01-May-1999 04:00:00 GMT; path=/That's using this line of script in ASP:Response.Cookies("authkey").Expires = #May 1, 1999#
McGuireV10
(Hmm... no blank lines in replies, I guess?)
McGuireV10
@MV10: How does that `Set-Cookie` header compare with the HTTP header produced by the PHP side when it creates the cookie?
RichieHindle
Other than a different expiration, they're identical. I was looking domain-level cookies in the RFC and it says writing to it requires matching the FQDN so I suspect it really is a side effect of using the hosts file.
McGuireV10
A: 

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.

McGuireV10
The domain line should just be "localtest.com" - no leading dot. I'd guess PHP was fixing it for you - but Fiddler will tell you for sure.
Mark Brackett
PHP does not remove it, and it is valid syntax. A leading dot creates a cookie which is accessible across all sub-domains. Per the RFC (http://www.ietf.org/rfc/rfc2109.txt), "An explicitly specified domain must always start with a dot."
McGuireV10
@MV10 - You're correct - that is what the RFC says. I missed that, since no browser cares. http://blogs.msdn.com/ieinternals/archive/2009/08/20/WinINET-IE-Cookie-Internals-FAQ.aspx
Mark Brackett