What does a cookie expires exactly mean?

[John Dalberg]

What happens when a cookie expires? Does it mean that when the browser or
sessions ends, it doesn't get saved?

I am using Opera and looking at available cookies and I can some cookies
that have expiration dates in the past. Does this mean that they are in
memory and they are still valid cookies which sites can test for their
existance and return true. I thought if a cookie's expiration is set in the
past, it gets removed from memory and is not available anymore for the next
request.

 

[Michael Winter]

What happens when a cookie expires?

It is no longer sent to the origin server when a HTTP request is made.
The cookie could still persist on the client, but it won't be
transmitted so it doesn't matter if it deleted because either way, you
won't be able to access it.

Does it mean that when the browser or sessions ends, it doesn't get saved?

In the case of session cookies - those cookies sent without an expires
(Netscape version) or Max-Age (RFC version) attribute - they are never
saved and only exist for the length of the session. Cookies with an
expires date in the past, or a Max-Age value of zero (0) seconds, must
expire immediately. Any other cookie is stored and transmitted up
until the point of expiration.

I am using Opera and looking at available cookies [...]

In the preferences, or request headers sent to a site?

[...] I thought if a cookie's expiration is set in the past, it
gets removed from memory and is not available anymore for the next
request.

It shouldn't be available. However, it would really be up to the user
agent to decide when to physically delete cookies. It might be
immediately. It might be during a garbage collection cycle. It might
be when it's completely shut down. As long as it doesn't appear in
request headers, it doesn't really matter.

Mike

 

[Dr John Stockton]

JRS: In article <[email protected]>, dated
Thu, 17 Mar 2005 17:26:27, seen in Michael

In the case of session cookies - those cookies sent without an expires
(Netscape version) or Max-Age (RFC version) attribute - they are never
saved and only exist for the length of the session. Cookies with an
expires date in the past, or a Max-Age value of zero (0) seconds, must
expire immediately. Any other cookie is stored and transmitted up
until the point of expiration.

I don't recall Max-Age being mentioned here before; ISTM that a few more
words on the subject might be useful.

 

[Michael Winter]

Dr John Stockton wrote:

[snip]

I don't recall Max-Age being mentioned here before; ISTM that a few
more words on the subject might be useful.

There are two approaches to state management: Netscape's original
proposal[1] and that specified by RFC 2965 - HTTP State Management
Mechanism[2]. The latter has HTTP/1.1 in mind, and differs in some
regards, though I haven't made a detailed comparison.

Perhaps the most notable change in the values sent in the respective
headers is the replacement of expires with Max-Age. Rather than
sending a formatted date, one would send a (optionally quoted) decimal
number which specifies the number of seconds during which the cookie
should be considered valid. Precisely how age and freshness are
determined is specified in sections 13.2.3 - Age Calculations and
13.2.4 - Expiration Calculations of RFC 2616 - Hypertext Transfer
Protocol -- HTTP/1.1[3].

As far as Max-Age and the document.cookie property is concerned, it's
best to avoid it. I can only recall Mozilla accepting it, though
others might if sent in the HTTP response headers - I've never
honestly bothered to check. I mentioned it for completeness.

Mike


[1] <URL:http://www.netscape.com/newsref/std/cookie_spec.html>
[2] <URL:http://www.faqs.org/rfcs/rfc2965.html>
[3] <URL:http://www.faqs.org/rfcs/rfc2616.html>

 

[Dr John Stockton]

JRS: In article <[email protected]>, dated
Fri, 18 Mar 2005 00:03:56, seen in Michael

...

As far as Max-Age and the document.cookie property is concerned, it's
best to avoid it. I can only recall Mozilla accepting it, though
others might if sent in the HTTP response headers - I've never
honestly bothered to check. I mentioned it for completeness.

Thanks - as it happens, I have those RFCs already on this HDD.

Worth knowing of, but not using until known implemented everywhere.

RFC2616 Sec 14.21 Expires has a paragraph
HTTP/1.1 clients and caches MUST treat other invalid date formats,
especially including the value "0", as in the past (i.e., "already
expired").
which seems to me to imply that those who laboriously calculate dates in
the recent past for killing cookies are wasting time - if it is
implemented generally - and could use "Expires: 0".

 

[Michael Winter]

On 18/03/2005 20:44, Dr John Stockton wrote:

^^ I need to correct that format ^^

[snip]

Worth knowing of, but not using until known implemented everywhere.

Well, there is a clear negotiation mechanism specified in RFC 2965.
However, a quick test reveals that of Opera 7.54u1, IE6, and Firefox
1.0, only the former stores the cookie. I must say that I'm quite
surprised that Firefox failed.

Considering the age of RFC 2965, I couldn't imagine a clamour to
implement it unless moving from Proposed to a full Standard means that
much.

RFC2616 Sec 14.21 Expires has a paragraph
HTTP/1.1 clients and caches MUST treat other invalid date formats,
especially including the value "0", as in the past (i.e., "already
expired").
which seems to me to imply that those who laboriously calculate dates in
the recent past for killing cookies are wasting time - if it is
implemented generally - and could use "Expires: 0".

Opera and Firefox are having none of that, though IE is. The
attributes, followed by an equals not a colon, are all lowercase, by
the way. In any event, the Expires header refers to cache control, not
cookies and as cookies aren't officially part of the HTTP protocol, I
don't think that the rules need to apply.

As far as scripting is concerned, a date created

new Date(0)

is simple enough. However, you'd still need to manually construct the
string to comply with Netscape's

Wdy, DD-Mon-YYYY HH:MM:SS GMT

format.

Mike

 

[Dr John Stockton]

JRS: In article <[email protected]>, dated
Sat, 19 Mar 2005 00:38:54, seen in Michael

On 18/03/2005 20:44, Dr John Stockton wrote:

^^ I need to correct that format ^^

Not sure what you intend : but to represent the actual truth, "wrote"
should be "posted", at least in my case and probably in all others. If
you can add the offset (I cannot) that would be good.

As far as scripting is concerned, a date created

new Date(0)

is simple enough.

Though, as far as I've seen here, rarely used to kill cookies.

However, you'd still need to manually construct the
string to comply with Netscape's

Wdy, DD-Mon-YYYY HH:MM:SS GMT

format.

which I believe to be the standard.

"expires=Thu, 01-Jan-1970 00:00:00 GMT"
is insignificantly longer than
"expires="+new Date(0).toGMTString()
and definitely shorter than what is commonly used. <FAQENTRY>?

+ + +

I have code for "all" sorts of Week 1 near Jan 1 week numbering, Y M D
to Y W D and now also back.

 

[Michael Winter]

Not sure what you intend

To change the date format in particular. However, it doesn't seem to
be possible: the format is determined by the client. I can only choose
where to put it.

If you can add the offset (I cannot) that would be good.

Which offset would that be?

[snip]

which I believe to be the standard.

Almost, but not quite. The date fields should be space-separated. See
3.3.1 Full Date in HTTP/1.1.

"expires=Thu, 01-Jan-1970 00:00:00 GMT"

That would certainly be better...

is insignificantly longer than
"expires="+new Date(0).toGMTString()

....than that. The format returned by that method tends to vary. I'm
sure I remember UTC for the timezone abbreviation with one host, which
is strange considering the name of the method. Microsoft's
documentation also suggests a different format, where the leading
weekday and comma parts are missing. Of course, one would hope that a
user agent should be able to properly interpret any date strings it
generates itself.

[snip]

Mike

 

[Dr John Stockton]

JRS: In article <Em4%[email protected]>, dated
Sun, 20 Mar 2005 01:30:12, seen in Michael

To change the date format in particular. However, it doesn't seem to
be possible: the format is determined by the client. I can only choose
where to put it.


Which offset would that be?

The offset from GMT. The information is in the header of the cited
article, but commonly not reproduced. Also, it's not clear whether the
attribution time is in the attributor's zone, the attributee's header's
zone, or in Proper Greenwich Time, or UTC.

I doubt whether you can do it, assuming you didn't write your newsreader
yourself.

Of course, one would hope that a
user agent should be able to properly interpret any date strings it
generates itself.

Some, such as my Web agent, take the HTTP header Last-Modified: line
which is in explicit unambiguous GMT and generate a lastModified string
without zone and which they cannot themselves read correctly (century
error). js-date2.htm.