279452 - cannot browse www online due to cache problems

Status: RESOLVED EXPIRED

(Firefox :: General, defect)

Description

[yoshi watanabe]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041213 Firefox/1.0
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041213 Firefox/1.0

i'm using firefox 1.0 for linux and windows
-------------------------------------------
ok, my ISP had an server maintenance and i could not access the web. when i
tried to open any page the information page from my ISP would appear in my browser. 

but when the problem got fixed i still could not browse any site that i recently
visited  - i always ended up watching that info page from my ISP. i could only
access new websites, i've never been to (or at least recently). everything
worked fine on other browsers, though. [i tried opera and links]

i had this problem on windows xp [pre-compiled firefox from installer] and
gentoo linux [firefox compiled from source]

the only solution was to flush the www cache in firefox. (both in windows and linux)

my ISP does not provide me with a proxy server, if that matters. and i'm not
using any.

Reproducible: Always

Steps to Reproduce:
1.try to browse the net when your ISP is down :/
2.keep trying 
3.when your connection finally works, try to browse again some sites you tried
in step 1

Actual Results:  
firefox refuses to load the web pages, instead it supplies me with pages from
its cache. 

Expected Results:  
open the actual web pages

windows - i used standard firefox installer from mozilla site
linux -
--------------------------------------------------------------
about:buildconfig

Build platform
target
i686-pc-linux-gnu

Build tools
Compiler 	Version 	Compiler flags
gcc 	gcc version 3.4.3 (Gentoo Linux 3.4.3, ssp-3.4.3-0, pie-8.7.6.6) 	-Wall -W
-Wno-unused -Wpointer-arith -Wcast-align -Wno-long-long -march=pentium4 -pipe
-pthread -pipe
c++ 	gcc version 3.4.3 (Gentoo Linux 3.4.3, ssp-3.4.3-0, pie-8.7.6.6) 	-fno-rtti
-fno-exceptions -Wall -Wconversion -Wpointer-arith -Wcast-align
-Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor
-Wno-long-long -march=pentium4 -pipe -Wno-deprecated -fshort-wchar -pthread
-pipe -I/usr/X11R6/include

Configure arguments
--disable-ldap --disable-mailnews --enable-crypto --disable-composer
--enable-single-profile --disable-profilesharing --enable-optimize=-O2
--enable-old-abi-compat-wrappers --disable-installer --disable-pedantic
--enable-crypto --with-system-jpeg --with-system-png --with-system-zlib
--without-system-nspr --enable-default-toolkit=gtk2 --disable-ipv6
--disable-xinerama --disable-xprint --enable-freetype2 --enable-freetypetest
--disable-debug --disable-tests --enable-reorder --enable-strip
--enable-strip-libs --enable-elf-dynstr-gc --enable-xft --enable-oji
--enable-mathml --disable-jsd --disable-xpctools --enable-gnomevfs --disable-svg
--disable-svg-renderer-cairo
--with-default-mozilla-five-home=/usr/lib/MozillaFirefox
--enable-extensions=cookie,xml-rpc,xmlextras,pref,transformiix,universalchardet,webservices,inspector,gnomevfs,negotiateauth,-venkman,gnomevfs
--prefix=/usr --host=i686-pc-linux-gnu --mandir=/usr/share/man
--infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc
--localstatedir=/var/lib 
--------------------------------------------

Comment 1

[Ben Fowler]

How did your ISP provide Firefox with the same page for each web request?

It is possible that this is some sort of DNS issue - either Firefox or your
system thinks that the IP address of the origin server of each your 
'recently visited' pages is that of your ISP's info page's server.

This does sound like a defect in Firefox unless Firefox has reason to believe
that the dummy pages in its cache meet its freshness rules, and I doubt that
it should do so if the IP address for the server has changed. Do you happen
to know whether the meta data for the 'info page' had a short expiration
date? There is, in fact, a 'must revalidate' directive, which would appear
to match this purpose exactly
http://www.w3.org/Protocols/rfc2616/rfc2616-sec13 . It is very definitely
surprising that a shift-Reload didn't solve the problem as even if the 
dates were wonky, the etags couldn't have matched!

It is possible that Firefox's behaviour is correct, and you are seeing the
aftermath of what would be a cache poisoning attack, if malicious. We really
need to know why Firefox thought that the dummy pages were still fresh. It
looks to me that a simple DNS lookup followed by an IMS request would have
solved the problem - assuming that ther info page had a dummy date well in
the past.

Perhaps Firefox should have a preference for a more aggressive cache
revalidation policy, but the HCI ramifications of that would need a lot
of thought. IIRC iCAB has a setting for verifying pages on each view/once
per session/never . Trying to browse the web with the setting 'never' is
surprisingly uncomfortable as news pages do not update themselves.

(Having said that, as HTTP is a distributed system, providing that upstream
caches to adhere to the rules, a less aggressive policy is usually preferred:
I would rather see my cached pages than nothing).

Comment 2

[yoshi watanabe]

(In reply to comment #1)
> How did your ISP provide Firefox with the same page for each web request?
> 
> It is possible that this is some sort of DNS issue - either Firefox or your
> system thinks that the IP address of the origin server of each your 
> 'recently visited' pages is that of your ISP's info page's server.
> 
yeah, that might be true. i even though that was an issue with some extensions
[i actually only tried adblock] but turning them off didn't help.

> This does sound like a defect in Firefox unless Firefox has reason to believe
> that the dummy pages in its cache meet its freshness rules, and I doubt that
> it should do so if the IP address for the server has changed. Do you happen
> to know whether the meta data for the 'info page' had a short expiration
> date? There is, in fact, a 'must revalidate' directive, which would appear
> to match this purpose exactly
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec13 . It is very definitely
> surprising that a shift-Reload didn't solve the problem as even if the 
> dates were wonky, the etags couldn't have matched!

well soon after they fixed the server, i was able to access some information
portals. the most frequently visited one loaded OK, but the page was from the
day before [it's updated at least 3 times a day]
the weird thing was that i couldn't go to google, but when i searched directly
from firefox search bar via google the google DID open. but i couldn't visit any
of the links it found.
> 
> It is possible that Firefox's behaviour is correct, and you are seeing the
> aftermath of what would be a cache poisoning attack, if malicious. We really
> need to know why Firefox thought that the dummy pages were still fresh. It
> looks to me that a simple DNS lookup followed by an IMS request would have
> solved the problem - assuming that ther info page had a dummy date well in
> the past.
> 
there was another weird thing - some images did not load at all, even from that
info page from my ISP after a while. they propably were thrown out of the cache,
but why didn't firefox download them again?

> Perhaps Firefox should have a preference for a more aggressive cache
> revalidation policy, but the HCI ramifications of that would need a lot
> of thought. IIRC iCAB has a setting for verifying pages on each view/once
> per session/never . Trying to browse the web with the setting 'never' is
> surprisingly uncomfortable as news pages do not update themselves.
> 
> (Having said that, as HTTP is a distributed system, providing that upstream
> caches to adhere to the rules, a less aggressive policy is usually preferred:
> I would rather see my cached pages than nothing).
> 
i thought at frst that the server was working incorrectly, so i asked my isp a
couple of times.  but they said everything was fine. and it actually was,
junding from the behavior of other browsers. 

oh, and one more thing. i don't use windows too often recently, so that part
with cache attack is unlikely to have happened for two separate systems in a
longer timespan. but the problem did happen under windows as well.

Comment 3

[Ben Fowler]

(In reply to comment #2)
> (In reply to comment #1)
> [snip]
> there was another weird thing - some images did not load at all, even 
> from that info page from my ISP after a while. they propably were thrown out 
> of the cache, but why didn't firefox download them again?

My first thought would be that Firefox was requesting the images correctly,
but upstream a request for (say) /content/images/picture.jpg was being 
diverted to a wrong server which knew nothing about that URL path. You can 
check Firefox's network requests using instructions at
http://www.mozilla.org/projects/netlib/http/http-debugging.html

It maybe that the problem is outside your control, particularly if you
do not have a proxy server running. 

Comment 4

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 5

[Gervase Markham [:gerv]]

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.