157963 - Should ignore malformed max-age directives [was: Page info in NS 4 and mozilla show different expiration dates]

Status: RESOLVED DUPLICATE of bug 1872460

(Core :: Networking, defect, P3)

Description

[Jean-Pierre Melkonian]

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

[Matthias Versen [:Matti]]

-> Http

Comment 2

[Darin Fisher]

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

Comment 3

[Jean-Pierre Melkonian]

Ok for versiontracker, But what about the IBM page ? Mozilla create an expiration 
date from nothing ?

Comment 4

[Darin Fisher]

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.

Comment 5

[Darin Fisher]

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.

Comment 6

[Jean-Pierre Melkonian]

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

Comment 7

[Darin Fisher]

-> future (not going to make it for moz 1.2)

Comment 8

[Simon Paquet [:sipaq]]

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".

Comment 9

[Darin Fisher]

-> default owner

Comment 10

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 11

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 12

[Tan Yee Jian]

Hi, is this bug still relevant? I am not sure how to replicate this bug.

Comment 13

[Valentin Gosu [:valentin] (he/him)]

This is already fixed https://searchfox.org/mozilla-central/rev/99f02d7a9456d4cfe2abd9c2a4a1eb8f3f41e22a/netwerk/test/gtest/TestCacheControlParser.cpp#15,29