What exact headers are sent with the response in this case for the 304 response? The 200 response sends a Last-Modified that's 2 hours ago and no Expires or max-age, so we compute an expiration time of 12 minutes for it. After 12 minutes pass, we will make another GET instead of hitting the cache, and get the 304 response... and update the expiration information with whatever information that 304 returns. What does it return?
Assignee: general → nobody
QA Contact: general → imagelib
Many thanks for your response. As part of debugging this problem I tried configuring the apache expires module so that the images that are normally animated in operational use of my website have the following headers set: Cache-Control: max-age=86400 Expires: Tue, 21 Sep 2010 02:01:43 GMT (ie expires 24 hours from now) However this made no difference to the fault. I didn't think to configure the cache-control header for the simple test case I put together for the bug report because it is incidental to the actual problem. The get request happens every time the animation changes to a new images, ie five times per seond for the demonstration I put together. Not every 12 minutes. I can see in the server logs that you only loaded the page once. Please try loading it in two different tabs and then hit reload in one of them in order to trigger the bug.
Here is an abbreviated excerpt from my server logs. It actually seems a new get request is issued every time the animation frame is updated in either tab. Ie for the bugdemo.html page I put together, there is 10 (ten) get requests to the server every second if you have two tabs open. [20/Sep/2010:11:27:14 +1000] "GET /temp/white.jpg HTTP/1.1" 304 [20/Sep/2010:11:27:14 +1000] "GET /temp/black.jpg HTTP/1.1" 304 [20/Sep/2010:11:27:14 +1000] "GET /temp/black.jpg HTTP/1.1" 304 [20/Sep/2010:11:27:14 +1000] "GET /temp/white.jpg HTTP/1.1" 304 [20/Sep/2010:11:27:14 +1000] "GET /temp/white.jpg HTTP/1.1" 304 [20/Sep/2010:11:27:14 +1000] "GET /temp/black.jpg HTTP/1.1" 304 [20/Sep/2010:11:27:14 +1000] "GET /temp/black.jpg HTTP/1.1" 304 [20/Sep/2010:11:27:14 +1000] "GET /temp/white.jpg HTTP/1.1" 304 [20/Sep/2010:11:27:14 +1000] "GET /temp/white.jpg HTTP/1.1" 304 [20/Sep/2010:11:27:14 +1000] "GET /temp/black.jpg HTTP/1.1" 304 I hope to convince you that there is a real problem and this is not just the normal cache behaviour.
I loaded the page once, then got each of the images via wget, actually. And again, what happens after the first 304 depends on the headers sent with the 304 response; it may not take 12 minutes to redo a GET at that point. But this is still an imagelib issue, not a JS engine one; don't move it back there. If the above cache-control header was also sent with the 304, then chances are this is the imagelib cache per-document pinning suddenly missing for some reason after a reload. I believe you there's a real problem; I'm just trying to diagnose what might trigger it, and all the data I can get is helpful. If you have the exact headers you send with your 304 available offhand, that would save Joe or Bobby the time needed to do an HTTP log to get those headers...
Below is the full 304 response headers obtained with the LiveHTTPHeaders plugin while the browser was in the broken state constantly polling the server: HTTP/1.1 304 Not Modified Date: Mon, 20 Sep 2010 02:31:26 GMT Server: Apache/2.2.9 (Debian) PHP/5.2.6-1+lenny9 with Suhosin-Patch Connection: Keep-Alive Keep-Alive: timeout=15, max=92 Etag: "144023-1ce3-490a5852a7b40" Thanks.
That doesn't update the expiration time, right? So once the original 200 response expires it will stay expired.... That said, it sounds like the two documents thing is still pointing out a separate issue, since the problem there starts as soon as you reload, not when the image actually expires... but the reload likely causes us to revalidate and get that 304 response, which says that the image should be considered expired thereafter. It's worth testing whether sending a useful Expires or max-age with the 304 helps, since that will narrow down the set of possibly subsystems involved here (http cache vs image cache).
Okay now I see what you are looking for. I should have been more exhaustive: The 304 response above is for the testcase images. Below is the 304 header for the actual image directory my website normally uses. In this case the expiration and max-age headers do get updated each time: HTTP/1.1 304 Not Modified Date: Mon, 20 Sep 2010 03:59:01 GMT Server: Apache/2.2.9 (Debian) PHP/5.2.6-1+lenny9 with Suhosin-Patch Connection: Keep-Alive Keep-Alive: timeout=15, max=85 Etag: "ded094-2cea-490a853762600" Expires: Tue, 21 Sep 2010 03:59:01 GMT Cache-Control: max-age=86400 So having the 304 header update the expiration time does not change the behaviour of the browser (given that I see the problem I am reporting in normal operation use using the image directory that posts the additional headers).
Great. If you can make the testcase send headers like that too, just so the debugging doesn't run into that issue, that would be awesome. Joe, Bobby, Alon can one of you look at this?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Done. The testcase now includes the Expires and Cache-Control: max-age headers in the 304 response.
Hi Folks, Do you still need me to keep the testcase files in that temp directory on my site? Thanks, David
David, if you can keep them up for now, that would be great. I think the imagelib folks have been swamped with 4.0 blocker bugs so far. :(
Hi, I note this bug is still present in Firefox 23.0. I am sure if would be an easy fix for somebody familiar with the relevant code. Regards, Dave
You need to log in before you can comment on or make changes to this bug.