222429 - about:cache?device=memory entries shows incorrect values

Status: VERIFIED INVALID

(Core :: Networking: Cache, defect)

Description

[Olivier Vit (just a reporter)]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007

For example you can have

           Key: http://verts.montreuil.ouvaton.org/mozilla/no-cache/espanol.gif
     Data size: 3444 Bytes
   Fetch count: 1
 Last Modified: 10/16/03 14:46:24
       Expires: 11/04/03 15:18:55

Last Modified is wrong: the response header says Last-Modified: Tue, 08 Apr 2003
21:17:57 GMT

Expiration isn't set in the header, how can it expire 20 days ??

Reproducible: Always

Steps to Reproduce:
see above
Actual Results:  
see above

Expected Results:  
reflect HTTP headers ?
or set at least a reasonable expiration period 

is there a confusion between the last access to the ressource and Last Modified

Expiration is valid for the chrome protocol, but not 'Last Modified'
           Key: chrome://messenger/skin/icons/readcol.gif
     Data size: 832 Bytes
   Fetch count: 1
 Last Modified: 10/16/03 13:21:17
       Expires: No expiration time

Comment 1

[Boris Zbarsky [:bzbarsky]]

> Last Modified is wrong:

No, it's not, you just have a misapprehension as to what about:cache shows. 
That's the time when the cache entry was last modified, not the time when the
resource was last modified.  In other words, this is the value that will be
compared to Last-Modified response headers to determine whether to refetch data.
 Don't assume that just because it's labeled "Last Modified" it reflects some
other thing that also happens to be named "Last Modified"....

Similarly for Expires.  That's the time when Mozilla will expire the cache
entry.  That time may be affected by HTTP headers, but if there is no header,
Mozilla is free to expire the entry whenever it feels right.

Comment 2

[Darin Fisher]

this bug is invalid.  mozilla is working correctly.

we are computing an expiration time based on the value of the Last-modified
header as suggested in RFC 2616 section 13.2.4.  this is only done when no
explicit expiration information is provided by the server.

Comment 3

[Olivier Vit (just a reporter)]

Thanks for your comments (and these good news)

What about having a "Last Updated" label instead of "Last Modified" ? to avoid
any confusion also among the developper community ?

And why is it different (regarding Expires) for GUI elments ? (however it is
relevant that it is different, but is it really the case in the code ?)

Comment 4

[Olivier Vit (just a reporter)]

sorry, 

but about the computation being made to calculate the expiration, shouldn't
there be a sort of maximum (like a week, and possibly depending on the mime-type) ?

see also bug 222430 and bug 221036

Regards

Comment 5

[Boris Zbarsky [:bzbarsky]]

> And why is it different (regarding Expires) for GUI elments ?

Because the expiration algorithm suggested in the HTTP specification only
applies to the HTTP protocol.  ;)

> shouldn't there be a sort of maximum

There is.  10% of the time since the page was last modified or so.  You did read
the spec that darin cited, right?

Comment 6

[Olivier Vit (just a reporter)]

I did read the spec

It does a suggestion
And to a certain extend, when the calculation reaches a certain amount of time
(like a week when modified 10 weeks ago) I really wonder if it is still a good
strategy because there are good chances to show the end user contents which are
obsolete
If Mozilla is one day not only for techies, it should expect users to change
their cache settings twice a day to view something else than an obsolete web

On the other hand, too few web site do use cache-control headers, and relying on
them is good when they exist, but the application should be smart when they don't

don't you think so ?

Comment 7

[Boris Zbarsky [:bzbarsky]]

If a site hasn't changed in 10 weeks, chances are it in fact does not change
much... so checking it less often makes sense.

In any case, that's the subject of the other bugs you filed, not of this one.

Comment 8

[Olivier Vit (just a reporter)]

agreed