Help with setting expiration dates on COOKIES

[Rickey Tom]

This has to be a very common question, but my search did not come up with an
answer.

I needed to set an expiration time for a cookie. In .NET, is seems that the
server-side code is used to set the expiration date of the cookie. More
specifically, I've seen several examples (from the Microsoft site) where the
cookie information, including the expiration date is set on the server. I
wonder how this can work. If the client and server do not have the same time
stamp, how can this work. For example, if the expiration time is 20 min and
the client is 12 hours forward in time, as soon as the request returns to
the client, the cookie is expired and no longer "issued".

It seems to me that the server either needs to take into account, the
client's time when the expiry time is set.

I noticed that in some documentation, the expires flag is supposed to use
GMT. But if the user plays with the date
on their machine, the cookie may be prevented from expiring.

What is wrong with my logic?


Thanks
Rick

[Peter O'Reilly]

Since the server is the one issuing the cookie and doing so on their 'clock'
it logically makes sense that the expiration date specified is that of the
server. In other words, the server has no knowledge of what time zone,
date, etc. of the requesting client computer. Why should it? It's not
necessary and having all the cookies issued timed/date stamped under one
clock makes things a whole lot easier for the server to manage state.

The server sends cookie information to the requesting source, the web
browser. From there, expiration and removal of the cookie is the browser's
responsibility. In creating the actual cookie (file) the browser may
translate GMT to local time when creating the cookie.

Hope this helps.
--
Peter O'Reilly

[Rickey Tom]

> Since the server is the one issuing the cookie and doing so on their
'clock'

> it logically makes sense that the expiration date specified is that of the
> server.

Thanks for your response.

(Assuming that the client and server has the same time zone but for what
ever reason, the clocks are out of sync.)

Is this not the problem.
I mean, the server specifies (logically) 3:00 PM July 27 (expiry for 10 min)
The client machine has 9:00 PM July 27. So technically, this cookie has
expired.
As I understand from the description, the Browser will not issue the cookie
any more since it is expired
an it will not get persisted. This is what I observed in some software that
I'm working with. The symptom is
that the Login page keeps re-appearing. If I synchronize the time, then the
problem goes away. However,
on the internet, I have no control over client's time.

Thanks
Rick


"Peter O'Reilly" <Peter_OReilly@timeinc.com!N!O!.S!P!AM!> wrote in message
news:utEsT8TVDHA.3232@tk2msftngp13.phx.gbl...

> Since the server is the one issuing the cookie and doing so on their

'clock'

> it logically makes sense that the expiration date specified is that of the
> server. In other words, the server has no knowledge of what time zone,
> date, etc. of the requesting client computer. Why should it? It's not
> necessary and having all the cookies issued timed/date stamped under one
> clock makes things a whole lot easier for the server to manage state.
>
> The server sends cookie information to the requesting source, the web
> browser. From there, expiration and removal of the cookie is the

browser's

> responsibility. In creating the actual cookie (file) the browser may
> translate GMT to local time when creating the cookie.
>
> Hope this helps.
> --
> Peter O'Reilly
>
>

[Rickey Tom]

> Since the server is the one issuing the cookie and doing so on their
'clock'

> it logically makes sense that the expiration date specified is that of the
> server.

Thanks for your response.

(Assuming that the client and server has the same time zone but for what
ever reason, the clocks are out of sync.)

Is this not the problem.
I mean, the server specifies (logically) 3:00 PM July 27 (expiry for 10 min)
The client machine has 9:00 PM July 27. So technically, this cookie has
expired.
As I understand from the description, the Browser will not issue the cookie
any more since it is expired
an it will not get persisted. This is what I observed in some software that
I'm working with. The symptom is
that the Login page keeps re-appearing. If I synchronize the time, then the
problem goes away. However,
on the internet, I have no control over client's time.

Thanks
Rick


"Peter O'Reilly" <Peter_OReilly@timeinc.com!N!O!.S!P!AM!> wrote in message
news:utEsT8TVDHA.3232@tk2msftngp13.phx.gbl...

> Since the server is the one issuing the cookie and doing so on their

'clock'

> it logically makes sense that the expiration date specified is that of the
> server. In other words, the server has no knowledge of what time zone,
> date, etc. of the requesting client computer. Why should it? It's not
> necessary and having all the cookies issued timed/date stamped under one
> clock makes things a whole lot easier for the server to manage state.
>
> The server sends cookie information to the requesting source, the web
> browser. From there, expiration and removal of the cookie is the

browser's

> responsibility. In creating the actual cookie (file) the browser may
> translate GMT to local time when creating the cookie.
>
> Hope this helps.
> --
> Peter O'Reilly
>
>

[Rickey Tom]

Any Comments?
Thanks
"Rickey Tom" <rickey_tom@hotmail.com> wrote in message
news:%239iSEHUVDHA.2104@TK2MSFTNGP10.phx.gbl...

> > Since the server is the one issuing the cookie and doing so on their

> 'clock'

> > it logically makes sense that the expiration date specified is that of

the

> > server.

>
> Thanks for your response.
>
> (Assuming that the client and server has the same time zone but for what
> ever reason, the clocks are out of sync.)
>
> Is this not the problem.
> I mean, the server specifies (logically) 3:00 PM July 27 (expiry for 10

min)

> The client machine has 9:00 PM July 27. So technically, this cookie has
> expired.
> As I understand from the description, the Browser will not issue the

cookie

> any more since it is expired
> an it will not get persisted. This is what I observed in some software

that

> I'm working with. The symptom is
> that the Login page keeps re-appearing. If I synchronize the time, then

the

> problem goes away. However,
> on the internet, I have no control over client's time.
>
> Thanks
> Rick
>
>
> "Peter O'Reilly" <Peter_OReilly@timeinc.com!N!O!.S!P!AM!> wrote in message
> news:utEsT8TVDHA.3232@tk2msftngp13.phx.gbl...

> > Since the server is the one issuing the cookie and doing so on their

> 'clock'

> > it logically makes sense that the expiration date specified is that of

the

> > server. In other words, the server has no knowledge of what time zone,
> > date, etc. of the requesting client computer. Why should it? It's not
> > necessary and having all the cookies issued timed/date stamped under one
> > clock makes things a whole lot easier for the server to manage state.
> >
> > The server sends cookie information to the requesting source, the web
> > browser. From there, expiration and removal of the cookie is the

> browser's

> > responsibility. In creating the actual cookie (file) the browser may
> > translate GMT to local time when creating the cookie.
> >
> > Hope this helps.
> > --
> > Peter O'Reilly
> >
> >

>
>