Closed
Bug 781369
Opened 13 years ago
Closed 13 years ago
userContent images are cached, ignoring Cache-Control headers
Categories
(Core :: General, defect)
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: marcus.ball, Unassigned)
Details
User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:14.0) Gecko/20120722 Firefox/14.0.1
Build ID: 20120722203403
Steps to reproduce:
I have set the background-image property of an element in the userContent.css file of Firefox (version 14). The background image file is sent from a server which sends a new image each time the file is requested; with the image, this header is sent: "Cache-Control:max-age=0, private, must-revalidate". (Note: both "public" and "private" were tested, with no difference in results).
userContent.css:
body.test_body{
background-image: url("http://res.apps.pseudofailure.com/random_img.php") !important;
}
test page (http://res.apps.pseudofailure.com/test_page.html):
<!DOCTYPE html>
<html>
<head>
<title>Test page</title>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<style type="text/css">
html, body{
width: 100%;
height: 100%;
}
</style>
</head>
<body class="test_body">
</body>
</html>
Headers sent/received: http://i.imgur.com/3pMDZ.png
Actual results:
After initially loading the image from the server, the image remains cached and no further connections are made to the server. Clearing the cache, and refreshing (both via F5 and CTRL+F5), have no effect. The same image is always displayed and no requests occur following the initial request, even though headers clearly show that the image should not be cached.
The image, however, is refreshed after a browser restart.
Expected results:
The image should be re-requested upon refresh, as specified by the Cache-control headers.
|
||
Comment 1•13 years ago
|
||
Stylesheets request images at stylesheet parse time (basically; it's not quite that simple) and hold on to the resulting image object. After that, there is no more HTTP traffic of any sort, ever. Which makes sense when you think about it: you wouldn't want to do an HTTP fetch on every paint or every selector matching operation.
This is why your cache-clearing and refreshing have no effect: those affect the HTTP cache, but there is no HTTP involved here: there's just an image object that is applied as needed.
I don't think we want to change behavior here. Especially because I'm not aware of any sane use cases for the "expected results" above...
Status: UNCONFIRMED → RESOLVED
Closed: 13 years ago
Resolution: --- → WONTFIX
|
Reporter | |
Comment 2•13 years ago
|
||
I unde(In reply to Boris Zbarsky (:bz) [In and out Aug 1 - 10, out Aug 11-20] from comment #1)
> Stylesheets request images at stylesheet parse time (basically; it's not
> quite that simple) and hold on to the resulting image object. After that,
> there is no more HTTP traffic of any sort, ever. Which makes sense when you
> think about it: you wouldn't want to do an HTTP fetch on every paint or
> every selector matching operation.
>
> This is why your cache-clearing and refreshing have no effect: those affect
> the HTTP cache, but there is no HTTP involved here: there's just an image
> object that is applied as needed.
>
> I don't think we want to change behavior here. Especially because I'm not
> aware of any sane use cases for the "expected results" above...
I understand what you're saying, but only for most default cases. However, if the server explicitly states that the image shouldn't be cached, or specifically asks the browser to refresh after a certain period, I don't see why I shouldn't do so.
|
|
||
Comment 3•13 years ago
|
||
Because this isn't a "cache". It's just an in-memory object. Just like when you switch away from tab and then back to it we don't reload the page even if it was marked as no-cache.
You need to log in
before you can comment on or make changes to this bug.
Description
•