Automatic page refresh for "Expires" META tag not working

RESOLVED FIXED in mozilla0.9.9

Status

()

Core
Networking: HTTP
P2
major
RESOLVED FIXED
16 years ago
3 years ago

People

(Reporter: Al, Assigned: Darin Fisher)

Tracking

Trunk
mozilla0.9.9
x86
Windows 98
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

16 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.3+) Gecko/20010907
BuildID:    2001090703

Preferences/Advanced/Cache/"compare page with page on network" is set for
"Automatic"

The page has a META  tag:  "<META http-equiv="Expires" content="Tue, 1 Nov 2000
06:30:00 GMT">"

The page should be automatically refreshed according to W3C HTML  standard.  

Reproducible: Always
Steps to Reproduce:
1.Open any page with an Expires META tag whose "content" is prior to  the
current date.
2.
3.

Actual Results:  Doesn't automatically refresh.

Requires manual refresh.
Um... I think you are confusing the Expires: and Refresh: headers....  Expires:
just tells the browser not to cache the page if the date is before the present
date....

Comment 2

16 years ago
http://www.w3.org/TR/html4/struct/global.html#h-7.4.4.2 says :

The following sample META declaration:

<META http-equiv="Expires" content="Tue, 20 Aug 1996 14:25:27 GMT">

will result in the HTTP header:

Expires: Tue, 20 Aug 1996 14:25:27 GMT

This can be used by caches to determine when to fetch a fresh copy of the
associated document.


Can. Not should.
-> Networking:Cache anyway
Assignee: asa → gordon
Component: Browser-General → Networking: Cache
QA Contact: doronr → tever
(Reporter)

Comment 3

16 years ago
As I understand it, this tag is used should force the browser to fetch a fresh
copy of the document even though it may have a copy in its cache, assuming the
date has expired.  

This is useful if a document is essentially the same [e.g., only minor changes
have been made] and the author wants to force visiting browsers to fetch the
fresh copy and not use the one it may have in its cache.  

Correct me if I'm wrong.  And if so, how would an author force a browser to
fetch a fresh copy.  

Furthermore, Mozilla does not [as best I can tell] refresh the document in its
cache if the date has expired.  

Incidentally, IE5x, NS4x and IE6 all honor the tag as I have described. 

Comment 4

16 years ago
Sending upstream to HTTP.
Assignee: gordon → neeti
Component: Networking: Cache → Networking: HTTP

Comment 5

16 years ago
<q class=ot>so i should be able to create an infinite loop by writing a page 
that says it expired yesterday? this sounds really stupid.</q>
(Reporter)

Comment 6

16 years ago
Timeless:

Using the "expires" tag is common practice for websites that have semi-
permanent pages with links to them.  Authors don't want to have to change 
referring links just because minor changes have been made.

There is no endless loop condition.  If the "expires" date for the cached 
document indicates the doc has expired, the browser simply fetches the one from 
the site, renders it, and replaces the one in its cache.  

If you know of an alternative way to accomplish the same thing, please inform 
me.  

As I said previously, IE6, IE5x, and NS4x all act as I stated.  If in doubt, 
try it yourself.  
That quote from the std just says that it should be treated as an Expires:
header. Theres no reloading involved - see rfc2696 for the expires header
semantics.

darin was working on getting no-cache working - is this now working as well?
(Assignee)

Comment 8

16 years ago
WORKSFORME... clicking on a link to a cached page containing a <meta> expires
tag with an expiration time in the past causes a reload from the server.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 9

16 years ago
build 2001091003 does not work.

I just visited a posted html doc with IE6, NS4x, and Moz 9.4. Then modified a 
few words in the doc and uploaded it to the site. 

IE6 and NS4x both autonmatically refreshed the doc.

MOZ did not.  I had to key the reload button.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
(Reporter)

Comment 10

16 years ago
This bug is erratic. 
 
Based on Darin's report, I ran the test reported earlier today very carefully.

I just reran the test and MOZ did not fail this time.  

(Assignee)

Comment 11

16 years ago
Al: please use about:cache to verify the expiration time of the specified
document, and if possible, use a packet sniffer either locally or on the server
(if possible) to verify that mozilla is indeed making a network request. 
alternatively, if you have a debug mozilla bug, then please enable HTTP logging
(see http://lxr.mozilla.org/seamonkey/source/netwerk/protocol/http/src/nsHttp.h#32)

thanks!

Comment 12

16 years ago
Shouldn't this bug be marked as a duplicate of bug 65892 (The HTML parser
ignores <META HTTP-EQUIV="Expires" ... >)?

these meta bugs (expires/no-cache) are important, alot of webcam sites use these
tags. 

An intresting note: the expires tag (also the no-cache tag) are working in the
sidebar! check out http://cam.xrs.net. watch the site for a minute (picture
refreshes all 30 seconds) it's allways the same picture. then clik on, you
guessed it, "add tab to ns6". see how the picture in the sidebar refreshes,
while the picture on the site is allways the same. 

This is tested with netscape 6.1 not mozilla.....
(Assignee)

Comment 13

16 years ago
meta expires is ignored by NS6.1.. it should however work in mozilla 0.9.4
(Reporter)

Comment 14

16 years ago
Darin, it still does not work in 9.4.  I just tested it again.  NS4x, IE6 work; 
but not MOZ9.4 [2001091303]  Here is the cache data, again.  Appears to me you 
are not recording and handling the META expires tag properly.  

The bottom line is: Web designers use the "expires" tag to force pages to be 
reloaded.[Yes we know it is not a perfect solution, but it's the best we have 
for all browsers]

Here is the doc's tag:   
<meta http-equiv="Expires" content="Tue, 1 Nov 2000 06:30:00 GMT">
IE6 and NS4x have no problem with this, or any other doc, with META expires 
dates.

key: http://www.ridersite.org/JFK50/2001Participants.htm 
fetch count: 11
 
last fetched: 09/18/01 09:36:52
 
last modified: 09/18/01 09:23:17
 
expires: 09/18/01 10:37:15
 
Data size: 19229
 
Security: This document does not have any security info associated with it.
 

--------------------------------------------------------------------------------
Client: HTTP
 
charset: ISO-8859-1
 
request-method: GET
 
response-head: HTTP/1.1 200 OK
Content-Type: text/html
Accept-Ranges: bytes
Last-Modified: Tue, 18 Sep 2001 00:07:19 GMT
Etag: "905fdde1d53fc11:19100d"
Content-Length: 19229
Server: Microsoft-IIS/4.0
Date: Tue, 18 Sep 2001 13:18:10 GMT

 

(Assignee)

Comment 15

16 years ago
just tried with a 2001-09-14 linux nightly build and observed a correct
expiration time, so it looks like this is working with recent nightly builds.

reporter: any chance you could download a nightly build and give it a try?
(Reporter)

Comment 16

16 years ago
Per Darin's request, I tested with 2001091803.

Same bug.  I always confirm the bug exist by making a slight modification to a 
page and then posting it to my web-host.  I then test that IE6 and NS4.78 work 
properly.

I repeat:  If you examine the disk cached files.  IE6 and NS4x both show 
the "expires" date to be as included in the META expires data tag.  MOZ does 
not.
(Assignee)

Comment 17

16 years ago
wierd... i believe you :-)  but it really is wierd that this would only effect
windows and not linux.  i'll investigate this for 0.9.5
Priority: -- → P2
Target Milestone: --- → mozilla0.9.5
(Assignee)

Comment 18

16 years ago
tever: can you try to repro this?
Keywords: qawanted
Darin: So... NEW?
(Assignee)

Comment 20

16 years ago
-> me
Assignee: neeti → darin
(Assignee)

Updated

16 years ago
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
(Assignee)

Comment 21

16 years ago
ok.. after reviewing Al's snapshot from about:cache, i finally understand the
problem here.  Al: the expiration time assigned to a cache entry is a time equal
to now + freshness_lifetime.  for <meta> expires with a time in the past, the
freshness_lifetime is zero.  if you notice, in your example, the last fetched
date is 09/18/01 09:36:52 and the expiration time is 09/18/01 10:37:15.  this
expiration time is actually the time when the page load completed.  the last
fetched time is when the page load started.  both of these times will be in the
past relative to the next page fetch, and hence this bug is INVALID.
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago16 years ago
Resolution: --- → INVALID
(Reporter)

Comment 22

16 years ago
Darin:
 
You are missing the point.  The bug is the fact that you can make a change to 
the html code in a page and repost  it on the sever, same file name.   The file 
has an obsolete META expires tag.
 
IE5.5, IE6, NS4x always reload the page.  Mozilla does not.
 
Web designers can use this technique to encourage [it's not foolproof] browsers 
to reload the page.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
(Assignee)

Comment 23

16 years ago
please supply a sample document which does not work for you.  i have done so
myself and it always works.  that is, the file is always requested again from
the server.
(Assignee)

Comment 24

16 years ago
-> untargeted
Target Milestone: mozilla0.9.5 → ---
(Reporter)

Comment 25

16 years ago
I think I've found the problem.  It's the algorithm used for cache "automatic"
 
I just reran the test with Moz's pref/adv/cache set for "once per session" and 
it worked [as it should of course]!
 
I suggest that you may want to fix the "automatic" mode, since that is the 
default and the one most folks will use.
 
Bottom line is that Moz should reload the page when the "expires" date has 
expired, even if the pref setting is "automatic"  because web designers use 
this feature to "encourage" browsers to reload a page.  
Al: Can you give a url which shows this problem?
(Assignee)

Comment 27

16 years ago
the importance of this features is well understood ;-)

what i don't understand is why this doesn't work for you.  as i have said, i am
unable to reproduce the problem you are seeing.  my cache validation pref is
also set to validate automatically.  this is a bit frustrating... i would really
like to fix this bug, but not being able to reproduce it is getting in the way ;-)
(Reporter)

Comment 28

16 years ago
Here is URL [in the URL box].  Same problem with any of the pages.  

The one thing I haven't tried is to allow more time to elapse between when I 
post the modified page and when I go to it with Moz.  However, I always try IE6 
and NS4x before Moz.  So it's at least a minute or so before I get to Moz.

I'd be happy to send you the files; but I assume you have a way to easily fetch 
them, and their css file.  They all use jfk50.css
(Assignee)

Comment 29

16 years ago
i think i understand the problem now...

Al: are you using view->page_source at all?
(Assignee)

Comment 30

16 years ago
<meta http-equiv> tags are not honored when a page is loaded for viewsource.

do the following:

1) clear your disk cache
2) goto http://www.ridersite.org/JFK50/index.htm
3) goto
about:cache-entry?client=HTTP&sb=1&key=http://www.ridersite.org/JFK50/index.htm
4) notice that the expires time is less than now.
5) goto http://www.ridersite.org/JFK50/index.htm again
6) click view->page_source
7) return to
about:cache-entry?client=HTTP&sb=1&key=http://www.ridersite.org/JFK50/index.htm
8) notice that the expires time is now in the future

Al: does this somehow explain what you are seeing?
(Assignee)

Comment 31

16 years ago
actually, this has nothing to do with viewsource... here's a much simpler way of
reproducing the problem:

1) goto http://www.ridersite.org/JFK50/index.htm
2) press shift reload to completely update the cached copy
3) goto the cache entry for this page
4) goto http://www.ridersite.org/JFK50/index.htm again
5) press reload
6) press the back button and notice that the expiration time is now in the future.

something wierd is happening in the reload case... i'm not sure what.
(Reporter)

Comment 32

16 years ago
Sorry, I inadvertantly answered you via the e-mail message.  So, i don't know if
you received my answer.  Here it is, just in case.

It well could since it made the "expires" date 3 hours in the future. 
 
If I modify a file and don't wait for at least 3 hours, then Moz won't bother to
reload.
 
By George,I believe you got it.  Good work. 
 
However, you might want to consider that, apparently, IE and NS4x don't change
the "expires" date in the cache. They just save whatever is in the META tag. 
This would seem to be a safer approach. 

Also, it appears that Moz saves the expires date from the META tag if it is in
the  future.  If it is obsolete, a modified and incorrect date is saved.  
 
Severity: normal → major
(Assignee)

Updated

16 years ago
Status: REOPENED → ASSIGNED
Target Milestone: --- → mozilla0.9.6
(Assignee)

Comment 33

16 years ago
-> 0.9.6
(Assignee)

Comment 34

16 years ago
Created attachment 56044 [details] [diff] [review]
v1.0 patch
(Assignee)

Comment 35

16 years ago
the problem was that we weren't honoring META tags on 304 Not Modified responses.
(Assignee)

Comment 36

16 years ago
Comment on attachment 56044 [details] [diff] [review]
v1.0 patch

r=gagan
Attachment #56044 - Flags: review+

Comment 37

16 years ago
Comment on attachment 56044 [details] [diff] [review]
v1.0 patch

trusting that FinalizeCacheEntry does not need an active mTransport.
Attachment #56044 - Flags: superreview+
(Assignee)

Comment 38

16 years ago
shouldn't be a problem... fixed-on-trunk
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago16 years ago
Resolution: --- → FIXED
(Assignee)

Comment 39

16 years ago
*** Bug 78551 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 40

16 years ago
It is broken again.

Ignores "When the page is out of date".

Must key refresh, generally several times, to fetch current version from site.

Win 2K
Moz 2002010403
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 41

16 years ago
Al: the fix for this bug went in on 2001-01-18.  that means that only builds
after that date will have the fix.  therefore you should not expect that this
bug would be fixed in the build from 2001-01-04.  marking FIXED.
Status: REOPENED → RESOLVED
Last Resolved: 16 years ago16 years ago
Resolution: --- → FIXED
Darin:
Your comment #38:
>------- Additional Comment #38 From Darin Fisher 2001-11-03 21:37 -------
>
>shouldn't be a problem... fixed-on-trunk

your latest comment :
>Al: the fix for this bug went in on 2001-01-18.

It seems that you checked in this fix at : 2001-11-03 21:37
and the reporters build ID: Moz 2002010403

but maybe I'm only stupid :-)
(Assignee)

Comment 43

16 years ago
doh! my bad... sorry for accusing you of mucking up the dates!

reopening...
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 44

16 years ago
-> 0.9.9
Status: REOPENED → ASSIGNED
Target Milestone: mozilla0.9.6 → mozilla0.9.9
(Assignee)

Comment 45

16 years ago
agreed.. linux build 2002020208 has this bug :-(

the testcase in comment #31 is reproducible.  investigating...
(Assignee)

Comment 46

16 years ago
turns out i accidentally checked in some changes that i had lying around in my
tree along with my patch for bug 83471 that caused this regression.  the check
in was made on 12/7 as version 1.70 of nsHttpChannel.cpp.  the accidental
changes have been backed out.

marking FIXED.
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago16 years ago
Resolution: --- → FIXED
Keywords: qawanted
You need to log in before you can comment on or make changes to this bug.