121696 - Expired cookies are being stored with wrong (future) dates.

Status: RESOLVED WORKSFORME

(Core :: Networking: Cookies, defect)

Description

[Indraneel Sarkar]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7+) Gecko/20020117
BuildID:    20020117

When a server sends a "Set-Cookie" with an expires clause set to a date/time in
the past (i.e., deletes a cookie), the Mozilla is storing it with expiry set to
a future date and sending it back to the server. Here is a part of the LAN
trace, and the associated cookie manager display.

-- LAN trace (partial) --
HTTP/1.1 401 Authentication Required
Server: Apache/1.2.20a (NETWARE) mod_jk
Set-Cookie: test=abcd; expires=Wed, 23 Jan 2002 22:36:02 GMT; path=/
WWW-Authenticate: Basic realm="Test"
-- End LAN trace ---

-- Cookie manager --
Name: test
Information: abcd
Host:
Path: /
Secure Server: no
Expires: Fri Jan 25 15:58:55 2002 15:58:55

Reproducible: Always
Steps to Reproduce:
1. Create a site that sends back a "Set-Cookie" with expired date. Better still,
set the date on the server back by more than the expiry time.
2. Point the browser to it.
3. Compare the data on the wire with the stored cookie.

Actual Results:  Mozilla accepted the cookie, stored it, and kept forwarding the
expired cookie to the server. This violates the "Set-Cookie:" definition.

Expected Results:  Mozilla should have deleted the cookie.

Comment 1

[Stephen P. Morse]

Can you provide some more details here.  Specifically, the expiry date/time 
specified in the set-cookie header as well as the date/time that the server is 
set for.

There is a time-zone correction that the browser makes, and I suspect that this 
might be what you are observing and thinking it is a problem.  Specifically, the 
browser takes the difference of the cookie expiry time and the server time, and 
then addes that difference to the browser's current time to determine the expiry 
time in the browser's time zone.

Comment 2

[Indraneel Sarkar]

Yes, the date on the server itself is back by more than the expiry time.
However, this is still a problem, as I understand from the specs
(http://home.netscape.com/newsref/std/cookie_spec.html & rfc2109). The expiry
date/time is specified in GMT. The browser is not expected to make any
adjustments for the current date-time on the server. It should take the expiry
date-time at its face value and act accordingly, adjusting only for timezones.
This is how earlier Netscape browsers (4.7x) and even IE behave.

Comment 3

[Stephen P. Morse]

The code for procesing the expiry time is the exactly the same code that was 
used in 4.x.  Do you have a concrete example that shows that the two browsers 
behave differently?

Comment 4

[Indraneel Sarkar]

Sorry, my mistake. Double checked after you said that Netscape 4.x browsers
exhibit the same behaviour. IE is the only one that takes expiry date/time at
face value.

Comment 5

[benc]

REOPEN: no fix in this bug.

Comment 6

[benc]

RESOLVED/wfm.

The cookie manager does behave the way stephen described, however, it could not
be valid for the example given.

I don't know of any system that could receive a GMT time on the Wed, 23, and
then convert it to Fri, 25.

it would be something like GMT -16 -24 -1 = GMT -41 hours.