659273 - http-equiv refreshs should not refresh all linked in content

Status: NEW

(Core :: Networking: HTTP, defect, P3)

Description

[bjoern]

User-Agent:       Mozilla/5.0 (X11; Linux i686; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
Build Identifier: Mozilla/5.0 (X11; Linux i686; rv:2.0.1) Gecko/20100101 Firefox/4.0.1

a site with a meta http-equiv="refresh" should be refreshed but all the linked in files like images should not be refreshed if they haven't expired in the cache.

See http://wiki.samba.org/test.html for a simple test.

Firefox will send request containing "if-modified-since" and "chache-control: max-age=0" for the site itself AND for all the linked content like css files and images.

Google Chrome for example only sends just a request containing "if-modified-since" and ONLY for the main site not for linked in content which is found in the cache with valid cache expiration time.

This issue slows down sites using http-equiv refresh in Firefox quite noticably, especially if latency is high and many linked in content is contained on the site. 

Reproducible: Always

Comment 1

[:aceman]

I can confirm on FF5. Firefox is sending requests also for the images, but in the testcase the server replies they were not modified, so they are not redownloaded. Anyway, even the requests may be expensive.

Comment 2

[Boris Zbarsky [:bzbarsky]]

If the main page forces validation, which is the case for http-equiv refresh, then all subresources also force validation.  This is because VALIDATE_ALWAYS is one of the flags propagated through the loadgroup.  This is needed for the reload button case (and in fact, http-equiv and reload button just do the same thing in Gecko).

If you really want refreshes that don't have reload semantics, you probably don't want to be using http-equiv refresh...

Comment 3

[Boris Zbarsky [:bzbarsky]]

And to be clear, the way to fix this would be to add a new load flag that forces validation for the toplevel page only but not for everything in the loadgroup.

Comment 4

[bjoern]

I don't think that any w3 standard or RFC mandates that http-equiv refresh behaves exactly like the reload button, does it? As mentioned other browsers (tested Epiphany, Chrome and IE7) also behave differently, resulting in noticably faster site refreshs on high latency or lossy links. To me it seems like a absolutely valid asumption that a server explicitly marking resources as cacheable that they should be cached and not be reloaded (not even with if-modified-since) because the html site contains a http-equiv refresh. If you want to keep up that performance penalty against Chrome, IE and other browsers, this is up to you, but I don't think it makes any sense.

Comment 5

[Boris Zbarsky [:bzbarsky]]

There is no standard or RFC covering this <meta> tag at all; it was a unilateral Netscape extension to HTML.

So the "right" behavior is basically whatever Netscape 3 did with it....

Comment 6

[bjoern]

still the same with firefox 33. This is a mayor performance penalty against most other browsers.

As the other mayor browsers don't reload the cachable linked in content if the main site asks for refresh, it should really be save for you to change to that behaviour also. It would also be nice to see those sites be loaded much quicker with Firefox when you change this habit.

Comment 7

[bjoern]

the javascript location.reload() function has the same issue. It reloads all of the linked in content, not just the main site.

Comment 8

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 9

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258