Open
Bug 157963
Opened 22 years ago
Updated 6 months ago
Should ignore malformed max-age directives [was: Page info in NS 4 and mozilla show different expiration dates]
Categories
(Core :: Networking, defect, P3)
Core
Networking
Tracking
()
NEW
People
(Reporter: jpmelko, Unassigned)
References
()
Details
(Whiteboard: [necko-backlog])
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:1.1b) Gecko/20020716 BuildID: 20002071608 After noticed that every day mozilla was not showing me the last versiontracker page, i looked at page info (i have to do a force reload to see the correct page) NS show (now): Expires: Mer 17 juil 2002 20:34:17 Mozilla Show: Expires: Sat, Sep 4, 1926 7:28:15 AM Note that NS4 is localized Reproducible: Always Steps to Reproduce: 1.Browse http://www.versiontracker.com/macos/index.shtml with Netscape (4.x) 2. show info 3.Browse http://www.versiontracker.com/macos/index.shtml with Mozilla 4 Show info Actual Results: Different expiration time. Expected Results: Same expiration Dates Tried many force reload in NS4 and Mozilla Changed also my prefs (HTTP 1.0, keep alive) no effect an other page http://www.ibm.com/planetwide/us/index.html NS 4: Expires: No date given Mozilla : Expires: Sat, Jul 20, 2002 11:27:20 AM I have also tried with interarchy, that is a Mac ftp client, that can also manipulate http protocol. (i did that Some minutes Later) It's log window: GET /macos/index.shtml HTTP/1.0 Accept: */* Host: www.versiontracker.com User-Agent: Interarchy/5.0.1 HTTP/1.0 200 OK Age: 292 Date: Wed, 17 Jul 2002 19:01:12 GMT Content-Type: text/html Expires: Wed, 17 Jul 2002 19:01:12 GMT Cache-Control: max-age=-1296868 X-Pad: work around browser bug Server: Apache/1.3.24 (Unix) mod_fastcgi/2.2.12 Via: 1.1 becquerel (NetCache NetApp/5.1R2) GET /planetwide/us/index.html HTTP/1.0 Accept: */* Host: www.ibm.com User-Agent: Interarchy/5.0.1 HTTP/1.0 200 OK Age: 0 Date: Wed, 17 Jul 2002 19:08:51 GMT Content-Length: 21808 Content-Type: text/html Server: IBM_HTTP_SERVER/1.3.19.1 Apache/1.3.20 (Unix) Last-Modified: Fri, 21 Jun 2002 17:22:12 GMT ETag: "2141013d-5530-3d1360c4" Via: 1.1 curie (NetCache NetApp/5.1R2) ---------------------------------------------- Netscape seems to be right. No expiration date for IBM I don't see year 1926 for version tracker. Note also that my provider use transparent proxies as you can see in the log. To avoid proxy effects, i tried the download many times (with force reload), in NS4 and Mozilla, first in NS4, then in Mozilla or the reverse etc... no effect
Comment 1•22 years ago
|
||
-> Http
Assignee: Matti → darin
Status: UNCONFIRMED → NEW
Component: Browser-General → Networking: HTTP
Ever confirmed: true
QA Contact: asa → tever
Comment 2•22 years ago
|
||
the negative sign is unexpected... i'm not sure what moz should do with this line... maybe it should be ignored... or maybe moz should just ignore the negative sign?! hmm... Cache-Control: max-age=-1296868
Reporter | ||
Comment 3•22 years ago
|
||
Ok for versiontracker, But what about the IBM page ? Mozilla create an expiration date from nothing ?
Comment 4•22 years ago
|
||
versiontracker.com sends these headers (today): HTTP/1.1 200 OK Date: Tue, 23 Jul 2002 17:55:10 GMT Server: Apache/1.3.24 (Unix) mod_fastcgi/2.2.12 Cache-Control: max-age=-1811324 Expires: Tue, 02 Jul 2002 18:46:26 GMT Keep-Alive: timeout=300 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/html however mozilla is unable to determine an expiration time... presumably because it is given higher precidence to the max-age directive over the expires header, which is what the RFC says to do. however, since the max-age directive is malformed, mozilla should really fallback to using the expires header value instead. 4.x probably ignores the Cache-control header since that is not a HTTP/1.0 header. ibm.com sends these headers (today): HTTP/1.1 200 OK Date: Tue, 23 Jul 2002 18:04:09 GMT Server: IBM_HTTP_SERVER/1.3.19.1 Apache/1.3.20 (Unix) Last-Modified: Tue, 23 Jul 2002 00:59:20 GMT ETag: "1fd00110-5892-3d3caa68" Accept-Ranges: bytes Content-Length: 22674 Keep-Alive: timeout=10, max=100 Connection: Keep-Alive Content-Type: text/html mozilla determines that the expiration time is 07/23/2002 12:46:12 PM, which is roughly 100 minutes from now. this comes from the fact that we take the difference between the Date header and the Last-modified header and divide by 10 to determine when the document might be stale. this algorithm is described in RFC2616 as well. on this page 4.x reports no expiration time, though in reality it does use the same Last-modified based expiration algorithm to determine when the document should be validated. so, i think the only issue with mozilla is that it should ignore badly formated max-age directives and fallback on looking at the other headers to determine the expiration time.
Severity: normal → minor
Status: NEW → ASSIGNED
Priority: -- → P4
Summary: Page info in NS 4 and mozilla show different expiration dates → Should ignore malformed max-age directives [was: Page info in NS 4 and mozilla show different expiration dates]
Target Milestone: --- → mozilla1.2alpha
Comment 5•22 years ago
|
||
i missed something about the versiontracker site in my initial analysis... turns out that they are sending an expires header with a date in the past. that causes mozilla to treat the document as if it were sent with a 'Cache-control: no-cache' directive. so, even if moz ignores the max-age directive, it'll still result in identical behavior. it's important to note that page info under 4.x shows the expiration header value as sent from the server whereas page info under mozilla shows the calculated or effective expiration time. there does seem to be a bug in the page info display however. instead of saying "no expiration time" it should say something like "expires immediately" or "already expired" or something to that effect.
Reporter | ||
Comment 6•22 years ago
|
||
another difference between Mozilla and NS4, this time for the modification Date (And also for the expiration Date) http://www.mactech.com/macintosh-c/classic-download.html Mozilla: Modification Date: Wed, Jul 24, 2002 7:18:14 PM Expiration Date: Thu, Mar 3, 2016 11:14:41 AM NS4: Modification Date: Unknown Expiration Date: No date given Interarchy Says: GET /macintosh-c/classic-download.html HTTP/1.0 Accept: */* Host: www.mactech.com User-Agent: Interarchy/5.0.1 HTTP/1.0 200 OK Age: 25224 Date: Wed, 24 Jul 2002 11:09:39 GMT Content-Length: 19958 Content-Type: text/html Server: WebSTAR/4.5 Beta/1(SSL) ID/77129 / MGI Server 2.1.10 Last-Modified: Wed, 24 Jul 2002 11:09:39 -0700 MIME-Version: 1.0 Via: 1.0 ampere (NetCache NetApp/5.1R2) Note that the three programs give different modification Dates and expirations Dates. No Expiration date With interarchy
Updated•22 years ago
|
Target Milestone: mozilla1.2alpha → mozilla1.2beta
Comment 7•22 years ago
|
||
-> future (not going to make it for moz 1.2)
Target Milestone: mozilla1.2beta → Future
Comment 8•21 years ago
|
||
This bug is targeted at a Mac classic platform/OS, which is no longer supported by mozilla.org. Please re-target it to another platform/OS if this bug applies there as well or resolve this bug. I will resolve this bug as WONTFIX in four weeks if no action has been taken. To filter this and similar messages out, please filter for "mac_cla_reorg".
Updated•21 years ago
|
OS: Mac System 9.x → All
Hardware: Macintosh → All
Comment 9•18 years ago
|
||
-> default owner
Assignee: darin → nobody
Status: ASSIGNED → NEW
Component: Networking: HTTP → Networking
QA Contact: tever → networking
Target Milestone: Future → ---
Updated•8 years ago
|
Whiteboard: [necko-backlog][good first bug]
Comment 10•7 years ago
|
||
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: P4 → P1
Comment 11•7 years ago
|
||
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: P1 → P3
Comment 12•5 years ago
|
||
Hi, is this bug still relevant? I am not sure how to replicate this bug.
Updated•4 years ago
|
Keywords: good-first-bug
Whiteboard: [necko-backlog][good first bug] → [necko-backlog]
Updated•2 years ago
|
Severity: minor → S4
Updated•6 months ago
|
Keywords: good-first-bug
You need to log in
before you can comment on or make changes to this bug.
Description
•