163806 - Page Info shows expires when no expires header present

Status: RESOLVED WORKSFORME

(Core :: Networking: Cache, defect)

Description

[Jerry Baker]

2002082004 trunk.

1. Load any HTML page that sends Last-Modified headers (URL is but one example).
2. Select View -> Page Info
3. See "Expires: [date]"

If you check the headers of that page, it does not include an expires header.

HTTP/1.1 200 OK
Server: Netscape-Enterprise/3.6 SP2
Date: Wed, 21 Aug 2002 07:42:03 GMT
Content-type: text/html
Etag: "98d8c0-1632-3d60e0fb"
Last-modified: Mon, 19 Aug 2002 12:13:47 GMT
Content-length: 5682
Accept-ranges: bytes

Comment 1

[Jo Hermans]

Confirmed on build 2002072104 on Windows NT.

I've seen this before, but I always though it was caused by proxy-servers (I
can't surf without passing at least 1 invisible cache). 

The first time you go to a page, Mozilla reports an expires that's identical to
the current time (expire immediately). The next time it's always a few hours
later, but the exact duration seems to vary.

Comment 2

[Daniel Brooks [:db48x]]

All page info does is reflect the value the cache has, You'll have to ask a
cache person where it gets the value.

Comment 3

[Jerry Baker]

Adding Networking:cache people to CC:

Comment 4

[gordon]

The value the cache has is set by its client, in this case probably HTTP.  HTTP
needs to generate an expires value if there is no expires header, but perhaps
Page Info should only show the header (if any).  Changing component to HTTP, but
it probably should go to Page Info.

Comment 5

[gordon]

->darin

Comment 6

[Darin Fisher]

-> page info

Comment 7

[Olivier Vit (just a reporter)]

reproduced on win xp build 1.5a 2003071004
http://verts.montreuil.ouvaton.org/mozilla/no-cache/francais.htm

 <-- C04 <-- S05 ==== Response time 0 (Latency 0, Processing 0)
 <-- C04 <-- S05 HTTP/1.1 200 OK
 <-- C04 <-- S05 Date: Tue, 15 Jul 2003 11:35:36 GMT
 <-- C04 <-- S05 Server: Apache/1.3.22 (Unix) Debian/GNU PHP/4.2.2
 <-- C04 <-- S05 Last-Modified: Tue, 08 Apr 2003 21:21:32 GMT
 <-- C04 <-- S05 ETag: "3eeea0-da4-3e933d5c"
 <-- C04 <-- S05 Accept-Ranges: bytes
 <-- C04 <-- S05 Content-Length: 3492
 <-- C04 <-- S05 Content-Type: text/html
 <-- C04 <-- S05 Connection: close
 <-- C04 <-- S05 ==== Body 3492 bytes

page info says : expires on july 25th (we are the 15th) (precisely in 9 days, 18
hours 13seconds)

there are 2 issues:
- page info shouldn't display a fake value for an information which isn't set
- the cache shouldn't build a random expiration date for content without
expiration being defined (at least, this expiration shouldn't many days ahead)

even more critical: the cache seems to really rely on this fake date: if your
cache preference is set to "when the page is out of date", no request is done
anymore to the server, even to check if the content has changed or not

Comment 8

[Olivier Vit (just a reporter)]

reproduced on 1.5b 2003091104 win2k

while http://livehttpheaders.mozdev.org/ propose a valid alternative, I wonder
if the fact that the cache and http modules generate their own expiration date
according to ??? strategy, doesn't represent a source for performance
improvements ??

see also http://bugzilla.mozilla.org/show_bug.cgi?id=200913

Comment 9

[timeless]

=> Darin. do not bounce without a detailed explanation.

Comment 10

[Boris Zbarsky [:bzbarsky]]

> - page info shouldn't display a fake value for an information which isn't set

It has no way to tell that it's not set.

> - the cache shouldn't build a random expiration date for content without
> expiration being defined (at least, this expiration shouldn't many days ahead)

Wrong.  Read the HTTP rfc.

> even more critical: the cache seems to really rely on this fake date:

Read the HTTP rfc a second time.

Comment 11

[Olivier Vit (just a reporter)]

>> - page info shouldn't display a fake value for an information which isn't set
>It has no way to tell that it's not set.
How does liveheaders does ? it is able to say which headers are set and not set ??

Or it should be made explicit that page info doesn't show page header
information, but internal cache values, as they are calculated

>> - the cache shouldn't build a random expiration date for content without
>> expiration being defined (at least, this expiration shouldn't many days ahead)
>Wrong.  Read the HTTP rfc.

however the rfc only suggests a calculation mean, and we have the freedom to
build a calculation algorithm optimized for both performance (manage differently
hhtml content and image content for example) and accuracy of the content being
displayed (have a maximum expiration delay for html content for example)

the benefits will be for our users (who care about the result they experience,
not only about basic standard compliance)

Comment 12

[Michael Lefevre]

Liveheaders does it by capturing the headers separately and displaying them
before the page is loaded.

If the info isn't available to page info, then we either need to make it
available somehow, or we should change page info so it doesn't misrepresent the
info being displayed.

Whether and how the cache calculates expiry times is not what this bug is about
- this bug is only concerned with the page info display. If you want to talk
about changing the cache behaviour, you should file a new bug for that.

Comment 13

[Olivier Vit (just a reporter)]

When I look at page info for the current bugzilla page, I see: 
"Expires: Not Specified" !!?

In summary, this bug is about whether Page Info displays info from headers, or
info from the cache calculation results.

But it needs to be explicit and consistent.

Comment 14

[Boris Zbarsky [:bzbarsky]]

> "Expires: Not Specified" !!?

That's correct.  Since this page sends no last-modified header and no expires
header, there is no way to calculate an expiry date. ;)

Comment 15

[Michael Lefevre]

It does happen to be correct in that case, but then a stopped clock tells the
right time twice a day :)  Page info also says "not specified" if an expiry date
in the past (or something like "Expires: 0") is specified.

Comment 16

[Boris Zbarsky [:bzbarsky]]

What confuses me is why people think page info shows the HTTP header.  It never
makes ANY indication to do that.  What it's showing is a much more useful value
-- when the page _actually_expires_ as far as Mozilla is concerned.  If this
value doesn't match what's expected, then the headers may need to be examined to
determine the reason for the discrepancy.  But it seems to me that all the fuss
is due to people assuming that any field that happens to have the same name as a
(very generically named) HTTP header must be showing the value of that header. 
Unfortunately, adding a big "Leave your HTTP preconceptions behind" sign is bad UI.

Looking at the "General" tab in page info, the only quality that really does
directly map to an HTTP header is "Referring URL" -- it maps to the header we
_sent_ when requesting the page.

Comment 17

[Olivier Vit (just a reporter)]

I would suggest that "Expires: Not Specified" IS misleading : it leads to make
us think that usually we get the value being specified by the server headers

If the info presented there is the result of the cache calculation we should have:
"Expires in cache: not applicable" when no last-modified, etag nor expires
header defined

Actually, the caption should be "Expires in cache:", isn't it ?

Comment 18

[Boris Zbarsky [:bzbarsky]]

> I would suggest that "Expires: Not Specified" IS misleading 

Agreed.  We should just say "Expired" (which it is).

Where else would it expire other than in cache, pray tell me?  "Expires in
cache" is too long to use as a label there.

Comment 19

[Olivier Vit (just a reporter)]

>> I would suggest that "Expires: Not Specified" IS misleading 
>Agreed.  We should just say "Expired" (which it is).

ok for me

>Where else would it expire other than in cache, pray tell me? 
from the server point of view, since he can take control on the expiration delay

couldn't it be absent of the cache (because the client cache si too small for
example and contains objects that claim to expire far later) ?? but the
expiration delay calculated would still be valid

>"Expires in cache" is too long to use as a label there.
too bad

Comment 20

[Olivier Vit (just a reporter)]

still new in build 2004031508

Comment 21

[Olivier Vit (just a reporter)]

Boris,
your suggestion in comment #18 isn't implemented yet :
--------------
> I would suggest that "Expires: Not Specified" IS misleading 

Agreed.  We should just say "Expired" (which it is).

--------------
1.7b 2004041310

regards

Comment 22

[Rick E Clark]

Explain this problem any way you want; Explorer does not have this bug. I cannot
build a web site and upgrade my index page with this fault.

Comment 23

[Darin Fisher]

-> default owner

Comment 24

[Patrick McManus [:mcmanus]]

devtools gets this right