309839 - home page does not refresh, but it you click on date, it takes you to the correct date

Status: RESOLVED WORKSFORME

(Firefox :: General, defect)

Description

[Michael Cornelius]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6 (ax)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6 (ax)

i use msn.com as home page, it is frozen on September 21, with all the boxes
that were there on that date, however if you select the date of September 21, it
takes you to a page of what happened on this date, and shows the correct date,
ie Sept 23 etc.  I have also tried the same home page on IE and it works fine
there.  This just happened on the 21 of Sept 2005

Reproducible: Always

Steps to Reproduce:
1.go to the home page of msn.com
2.
3.

Actual Results:  
it says it is a different date and will not refresh

Expected Results:  
switched to the correct date everynight at 12:01 am

Comment 1

[Ria Klaassen (not reading all bugmail)]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050923
Firefox/1.6a1 ID:2005092321

Has browser.cache.check_doc_frequency the value 3?
Does the behaviour change when you press Shift while reloading?

Comment 2

[Ryan Flint [:rflint] (ping via IRC for reviews)]

*** Bug 310469 has been marked as a duplicate of this bug. ***

Comment 3

[Ryan Flint [:rflint] (ping via IRC for reviews)]

*** Bug 310160 has been marked as a duplicate of this bug. ***

Comment 4

[Ryan Flint [:rflint] (ping via IRC for reviews)]

*** Bug 310830 has been marked as a duplicate of this bug. ***

Comment 5

[Jo Hermans]

*** Bug 311342 has been marked as a duplicate of this bug. ***

Comment 6

[Phil Ringnalda (:philor)]

*** Bug 311353 has been marked as a duplicate of this bug. ***

Comment 7

[Nan Winchell]

Same problem still exists on ontober 7th- my MSN homepage is stil showing the
Oct 5th page.
When I access msn homepage using IE the correct (today's new page) shows

Comment 8

[Phil Ringnalda (:philor)]

*** Bug 311945 has been marked as a duplicate of this bug. ***

Comment 9

[Timothy B. Anderson (Tails)]

Setting this bug as WORKSFORME.  It works fine in Mozilla/5.0 (Windows; U;
Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051010 Firefox/1.6a1.

Comment 10

[Phil Ringnalda (:philor)]

[e-mail]: Feel free to re-resolve this WFM when it has been more
than five minutes since I told you the bug existed, so that you might reasonably
have actually tested it, and when you can explain why all these people are
seeing a bug for which you claim, from
https://bugzilla.mozilla.org/page.cgi?id=fields.html#resolution "reading the
code produces no clues as to why the described behavior would occur"

Comment 11

[Phil Ringnalda (:philor)]

*** Bug 317590 has been marked as a duplicate of this bug. ***

Comment 12

[Daniel Veditz [:dveditz]]

I'd say we can confirm this based on the sheer number of dupes. Might be an MSN problem (wrong TTL values?) but then it would still be a valid tech evangelism bug.

Comment 13

[Daniel Veditz [:dveditz]]

According to Page Info msn.com doesn't set an expires, so our default browser.cache.check_doc_frequency of 3 ("as appropriate") probably assumes such a page never expires. You could argue that a missing expires on an ever-changing news page is wrong. But how common is it? What does IE do with it?

Maybe pages missing an expires should be checked once a session? Or at least pages that appear to be dynamic (mod date == last load date?) could ignore the missing expires.

Comment 14

[Phil Ringnalda (:philor)]

Not so simple, I'd guess. Fragment from a not-yet-useful HTTP log:

4076[16f7a98]: http response [
4076[16f7a98]:   HTTP/1.1 200 OK
4076[16f7a98]:   Date: Thu, 24 Nov 2005 04:00:30 GMT
4076[16f7a98]:   Server: Microsoft-IIS/6.0
4076[16f7a98]:   P3P: CP="BUS CUR CONo FIN IVDo ONL OUR PHY SAMo TELo"
4076[16f7a98]:   S: A10
4076[16f7a98]:   X-AspNet-Version: 1.1.4322
4076[16f7a98]:   Pragma: no-cache
4076[16f7a98]:   Cache-Control: no-cache, private
4076[16f7a98]:   Content-Type: text/html; charset=utf-8
4076[16f7a98]:   Content-Encoding: gzip
4076[16f7a98]:   Content-Length: 8834
4076[16f7a98]: ]
...
0[aa4260]: nsHttpHandler::NotifyObservers [chan=2548944 event="http-on-examine-response"]
0[aa4260]: nsHttpChannel::ProcessNormal [this=2548918]
0[aa4260]: nsHttpChannel::InitCacheEntry [this=2548918 entry=2557208]
0[aa4260]: nsHttpResponseHead::MustValidate ??
0[aa4260]: Must validate since response contains 'no-cache' header

Comment 15

[Darin Fisher]

If there is no information with which to deduce an expiration time, then the document must be validated before each use.  That's at least what we try to implement.  In this case, it looks like the site is explicitly saying that the document should be validated before each use.

Can someone produce a HTTP log that shows Firefox not refreshing the page?

Comment 16

[Ria Klaassen (not reading all bugmail)]

Tried making a log, but was not able to reproduce.
At eleven o'clock in the evening I loaded www.msn.com, the next day at eight o'clock I started the computer and the site had still the same date. But that was probably due to the fact that all times are different around the globe and msn is an American site.
At nine o'clock the date changed. Seemingly because it was midnight in the US.

Comment 17

[Ria Klaassen (not reading all bugmail)]

But I have still the log, in case someone is interested.

Comment 18

[Matthias Versen [:Matti]]

Is this still an issue ?