1
votes

I'm seeing some very strange behaviour here:

I'm using HttpWebRequest / HttpWebResponse with a fixed CookieContainer object. .NET 4, Windows Server 2008 R2.

On one machine (my dev machine) I am seeing the expected behaviour:

a response containing the following:

Set-Cookie: m-aid=rm=false&un=systestseller&uid=68818c42-cb63-4d37-8daf-9e6e0130f72c&hp=true; expires=Fri, 31-Dec-9999 23:59:59 GMT; path=/; HttpOnly
Set-Cookie: m-pc=sim=Normal; expires=Fri, 31-Dec-9999 23:59:59 GMT; path=/; HttpOnly
Set-Cookie: m-f-auth=D8EC2D07743011DCC62EE52C968A649E419CDC3F476CC9EF04AE7D096E36CEE51DF2289E69C1D990809156CDD5DC6483DDFAAD101ED41E5890D4E6B7467E6F4F8705ED9BA7D358C9C878F5437CE9FC3FE47F8EB878E5CC8219B8767BD001AF7A; path=/; secure; HttpOnly

results in the following request containing

Cookie: arr=2ce1b36a3ef29aa4c45128f8c08ac603debf2063c752e843291a90fb8936899d; m-aid=rm=false&un=systestseller&uid=68818c42-cb63-4d37-8daf-9e6e0130f72c&hp=true; m-pc=sim=Normal; m-f-auth=D8EC2D07743011DCC62EE52C968A649E419CDC3F476CC9EF04AE7D096E36CEE51DF2289E69C1D990809156CDD5DC6483DDFAAD101ED41E5890D4E6B7467E6F4F8705ED9BA7D358C9C878F5437CE9FC3FE47F8EB878E5CC8219B8767BD001AF7A

however on another machine, I am seeing the next request contain only

Cookie: arr=2ce1b36a3ef29aa4c45128f8c08ac603debf2063c752e843291a90fb8936899d; 

In other words, only the arr cookie and not the others get created.

Debugging the code, the HttpWebResponse in fact only has the arr cookie in its Cookies collection.

Anyone got any ideas? It's driving me mad.

2
Do you know if the other machine is using a different browser?Julius A
All the client calls are programmatic. There is no browser involved. For the record, using IE on the problematic machine exhibits the expected behaviour (i.e. the cookies are sent after being set).Gaz

2 Answers

2
votes

This is actually related to timezones.

Cookie-expiry is assumed to be in UTC, this means that .NET adjusts the expiry-parameter for your current local settings. Since the missing cookies all have an expiry of DateTime.MaxValue, and your production server most likely is living in a +1 or greater timezone, .NET adds the local time offset, arrives at an invalid date, and discards the cookie as "not relevant".

While this did not seem to be an issue with .net 2.0 (discovered this issue after upgrading framework), It is apparently here to stay, since downgrading the code does not remove the problem.

0
votes

My guess is that the problem has something to do with variation of URLs between your dev server and your production server. If the hostname of request #1 differs from the hostname of request #2 (even a redirect from www.foo.com to foo.com) then cookies obtained in a call from request #1 won't be sent to request #2.

Could you list the specific URLs (for both requests) used successfully on your dev server and the URLs which fail in production?

Note that one of your cookies is marked secure, meaning that it won't be sent to any non-HTTPS requests. This won't cause the problem you're seeing (because in your case none of the cookies are being retained) but would cause a problem where two of the cookies are sent to an HTTP request but the third one is not.

Also, I'm intrigued that one cookie, arr, is being sent to the server, presumably from an even-earlier request. What is that previous request doing differently from your subsequent request that is failing?

BTW, if you're unable to solve the problem, you can always manually fetch and set cookies from HTTP headers. Take a look at my answer to this question for sample code to do this.