274382 - loading live bookmarks bypasses cache

Status: RESOLVED FIXED

(Firefox :: Bookmarks & History, defect)

Description

[Radek 'sysKin' Czyz]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

When firefox starts, it loads all live bookmarks. The problem is it completely
ignores its own cache when doing so. Moreover, it sends:
  Pragma: no-cache
  Cache-Control: no-cache
in http headers, thus completely bypassing any proxy that is on the way.
This is a huge waste of bandwidth, both ours and server's.


Reproducible: Always

Steps to Reproduce:
1. Subscribe to a live bookmark, observe that it has (very often) ETag and/or
(often) Last-Modified header and/or (less often) Cache-Control: max-age header.
2. Start firefox, use Live HTPP Headers extension to see what happens

Actual Results:  
All rss feeds are loaded bypassing the cache

Expected Results:  
Firefox sends If-None-Match and If-Modified-Since headers, like explained in
HTTP specs and for obvious reasons.

Comment 1

[Phil Ringnalda (:philor)]

Hrm. Confirmed on 20041209 trunk, with http://philringnalda.com/index.xml which
has a max-age and can be counted on not to have changed the Etag, either ;)

Offhand, that doesn't seem like a good thing to do: there are times when I
restart the browser several times over just a few minutes, plus that's going to
make us more sluggish than we need to be at startup. Is there some reason not to
trust the cache at startup, or is that just an accident?

Comment 2

[Phil Ringnalda (:philor)]

Oh, d'oh. It's not just startup, is it? This bug is actually "back out bug
255458" because we *always* bypass the cache, and are thus *always* a horribly
misbehaved HTTP client: when we have a perfectly good Etag or Last-Modified, we
ignore it and insist on downloading the whole file again instead of getting a
304 Not Modified. For a random example of why I keep saying we need to be very
well-behaved about fetching feeds, see
http://laughingmeme.org/archives/002656.html where the author of the most
widely-used PHP library for parsing RSS says you should just ban anything that
doesn't support conditional GET by user-agent.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a6) Gecko/20041223
Firefox/1.0+

Ouch.

Comment 3

[Phil Ringnalda (:philor)]

Or, rather, if I understand nsIRequest, not back out bug 255458 but use
nsIRequest::VALIDATE_ALWAYS instead of nsIRequest::LOAD_BYPASS_CACHE. Shouldn't
that get us the behavior we want, always getting a new file if it's changed,
without doing aggressive no-cache requests where we ignore the date and ETag we
could be sending?

I got banned from an RSS feed the other day, for using an ill-behaved HTTP
client. Just a friend's weblog, but he banned me anyway.

Comment 4

[Philip Ross]

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

Comment 5

[Mike Connor [:mconnor]]

more "don't do dumb stuff"

vlad, punt this to me if you don't have cycles.

Comment 6

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Attachment: use VALIDATE_ALWAYS instead of LOAD_BYPASS_CACHE

Aiee.. yes, you're right, we should be using VALIDATE_ALWAYS...

Comment 7

[Mike Connor [:mconnor]]

sorry for bugspam, long-overdue mass reassign of ancient QA contact bugs, filter on "beltznerLovesGoats" to get rid of this mass change