http expires header with date-in-past causes miscalculation

VERIFIED FIXED in mozilla1.4alpha

Status

()

Core
Networking: HTTP
P2
major
VERIFIED FIXED
15 years ago
15 years ago

People

(Reporter: Tom Everingham, Assigned: Suresh)

Tracking

({topembed+})

Trunk
mozilla1.4alpha
x86
All
topembed+
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [http/1.1] [adt2], URL)

Attachments

(2 attachments)

(Reporter)

Description

15 years ago
Overview Description:  An http expires header with a date in the past sometimes
causes browser to miscalculate the expiration time of a page.  In this case, I
send out an expires of 'Thu, 01 Dec 1969 16:00:00 GMT' which the browser
interprets as a future date of '01/06/06 14:28:15'.   This causes the stale
version of the page to be pulled from cache when it should be coming from the
network.

Steps to Reproduce:
1.)  click on the url to send out the expires: '1969' header to the browser
(sorry, internal only)
2.)  type about:cache to check the expires date

Actual Results:  date is miscalculated to the year 2006

Build Date & Platform Bug Found:  2002101015 winNT

Additional Builds and Platforms Tested On:
works on mac osX
linux rh6 and rh7.1 gives me expires: can't get timezone
(Reporter)

Comment 1

15 years ago
Created attachment 102535 [details]
packet trace and what is displayed in about:cache

Comment 2

15 years ago
tever: HTTP/1.1 requires a Date header.  can you try adding a Date header to see
if that fixes the problem?  we may be having this problem only when there is no
Date header.
(Reporter)

Comment 3

15 years ago
darin:  I added the header "Date: Friday, 11-Oct-02 12:12:12 GMT" and I am still
seeing the same thing.  The expires is still ending up as year 06.

Comment 4

15 years ago
ok, thanks for trying that tom.  i'll take it from here.
Severity: normal → major
Status: NEW → ASSIGNED
Keywords: nsbeta1, topembed
Priority: -- → P2
Whiteboard: [http/1.1]
Target Milestone: --- → mozilla1.2beta
(Reporter)

Updated

15 years ago
QA Contact: httpqa → tever

Comment 5

15 years ago
-> moz 1.3
Target Milestone: mozilla1.2beta → mozilla1.3alpha

Comment 6

15 years ago
This does not seem specific to embeddors. Topembed-/nsbeta1+.
Keywords: nsbeta1, topembed → nsbeta1+, topembed-
Whiteboard: [http/1.1] → [http/1.1] [adt2]

Comment 7

15 years ago
no, but it may cause site compatibility issues, and it is a standards violation.
 i would think embedders would care about such things.

re-nominating.
Keywords: topembed- → topembed

Comment 8

15 years ago
Marking topembed+ as result of Topembed triage
Keywords: topembed → topembed+

Updated

15 years ago
Target Milestone: mozilla1.3alpha → mozilla1.3beta

Comment 9

15 years ago
-> suresh
Assignee: darin → suresh
Status: ASSIGNED → NEW
Target Milestone: mozilla1.3beta → ---
(Assignee)

Updated

15 years ago
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.4alpha
(Assignee)

Comment 10

15 years ago
Created attachment 113139 [details] [diff] [review]
patch attached.

The problem is PR_ParseTimeString returns negative number for this case.
(Assignee)

Updated

15 years ago
Attachment #113139 - Flags: superreview?(darin)
Attachment #113139 - Flags: review?(dougt)

Comment 11

15 years ago
Comment on attachment 113139 [details] [diff] [review]
patch attached.

suresh: looks good, but please keep the indentation consistent with the rest of
the file. thx!

sr=darin
Attachment #113139 - Flags: superreview?(darin) → superreview+

Updated

15 years ago
Attachment #113139 - Flags: review?(dougt) → review+
(Assignee)

Comment 12

15 years ago
fixed in trunk.
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED
(Reporter)

Comment 13

15 years ago
verified:  2003040708 win NT trunk
You need to log in before you can comment on or make changes to this bug.