views:

3494

answers:

5

I'm setting the cookie expiration using the following code:


// remove existing cookies.
request.Cookies.Clear();
response.Cookies.Clear();

// ... serialize and encrypt my data ...

// now set the cookie.
HttpCookie cookie = new HttpCookie(AuthCookieName, encrypted);
cookie.Expires = DateTime.Now.Add(TimeSpan.FromHours(CookieTimeOutHours));
cookie.HttpOnly = true;
response.Cookies.Add(cookie);

// redirect to different page


When I read the cookie timeout in the other page I'm getting 1/1/0001 12:00 AM. If someone can help me figure out the problem, I'll appreciate it. I'm using ASP.NET 3.5

ok. after reading the links from Gulzar, it appears that I cannot check cookie.Expires on the HttpRequest at all? Because the links seem to suggest that cookie.Expires is always set to DateTime.MinValue because the server can never know the actual time on the client machine? So this means I have to store the time inside the cookie myself and check it? Is my understanding correct?

thanks Shankar

+4  A: 

Which version of asp.net are you using? This was discussed in asp.net forum.

Gulzar
A: 

The version problem discussed in the link was not helpful. Basically ASP.NET cookie sucks. I had to store the expiration date time inside the cookie myself and check it in every request.

Shankar
But that is not because ASP.NET cookies suck. Http Response Cookies just dont have this information.
Per Hornshøj-Schierbeck
+1  A: 

There should be another solution to this problem. When I see examples online they usually set the DateTime object directly to the Expires property. Could this be a browser side issue ?

When debugging, you can observe that the property is set and that it contains the right value.

Alexandre Brisebois
+5  A: 

The problem here doesn't really lie with ASP.NET but with the amount of information that is provide in the http request by browsers. The expiry date would be unobtainable regardless of the platform you are using on the server side.

As you have summarised yourself in your question the Expires property of the HttpCookie object that is provided by the HttpRequest object is always set to 1/1/0001 12:00 AM. This is because this expiry information, as well as the properties such as domain and path, are not passed by the browser to the server when it sends a request. The only cookie information that is sent is the name and value(s). Therefore cookies in the request will have default values for these 'missing' fields as they are unknown on the server side.

I would guess the reason behind this is that the expiry, domain and path attributes of a cookie are only intended to be used by the browser when it is making a decision as to whether it should pass a cookie in a request or not and that the server is only interested in the name and value(s).

The work around you have suggested of duplicating the expiry time as another value of the cookie is a way to get the behaviour you are looking for.

Andy Rose
+1  A: 

Hi,

At first I also disappointed why Request cookie doesn't have the actual Expires value. After debugging the http by using Fiddler2. I know that .NET was not wrong, instead, http protocol is the answer why Request cookies behaving like that.

If you use Fiddler between your app and the browser. You can see the Response cookie sent correctly to browser with all domain, path, expires, secure and httponly. However next Request cookie in http cookie header doesn't have the expires value, it only cookie name and value. Browser responsible to send this request header and I believe that is because http protocol. The reason why is because to minimize size and web server doesn't need to check it since they actually set all the values. They should notice.

So you no need to check the expires value on web request since you already know the date. Just, if you receive the cookie back that means the cookie is not yet expired. Once you set the expires, browser will handle the expiry. If you want to change the expires, just set the new value on the response.

CallMeLaNN

CallMeLaNN