There may be an interaction with imagelib but I'm reasonably sure this is a network problem of some kind. I'm nor sure, though, whether this is just a cache issue or whether more is involved. Feel free to reassign it. I have a simple CGI test script that returns a random JPEG image. It's size is changing all the time. Depending on how it's called, there may be a content-length, or a last-modified, an expires header, or any combination of these headers. For this bug, we will consider the case where it returns a content-length and a last-modified header which is what a static image would return. Because the image is dynamic, the last-modified time is always 30 seconds before the access time. On an initial load, mozilla has no trouble displaying the image. On a reload, mozilla grinds away for a while but nothing changes. On a shift-reload, mozilla grinds away even longer but does display a new image. The server logs show something far more interesting. A reload initiates a network connection, data is actually transferred, but mozilla throws it away. In mozilla's cache, the disk object for the initial image just disappears. A shift reload shows mozilla making _two_ apparently consecutive connections. Data is transferred on both but mozilla only uses the last one. As far as the headers form the server are concerned, the only difference is a ETag header. The script does not return one. All other headers have the same form, although different contents obviously. Using, or not using, a proxy server also makes no difference. The only anomaly I can find is in mozilla's disk cache. If you look at the attached html file from about:cache, you'll see the mozilla expires it metadata 2 seconds before its last modified time. Odd. I tested with an 0514 build but it's been happening for a wile now.

Reporter: could you provide a testcase for this?

A test case is hard because it's a cgi script and the server is not easily available. I'll attach the script itself. If you've got Linux and Apache you can just drop it into Apache's cgi-bin directory and make it executable.

tever : could you test this script out?

-->cache

Neeti, why do you think this is the cache? Isn't this more likely to be an HTTP issue?

Neeti, this is set up internally at http://backwash/cgi-bin/random.jpg if you want to test it. I haven't looked into any details yet but it doesn't seem to work correctly on 6.x. I'll look into it a bit more tomorrow.

Reporter: this is working for me on a linux build pulled on 5/21. Could you try this again with thge latest builds. cc'ing pavlov

In a 05-22-13 nightly it's not fixed although the behavior is different. Now both reload and shift-reload hit the server twice. The first reload throws an error message to the xterm. I suspect that makes mozilla retrieve it again. It looks like its working but it's not.

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

UPDATE: Mozilla 0.9.1, Win98 (commercial) I've used the backwash URL, and it seems to work correctly to me, but I do not have admin access to the server, so I can't speak to the lower level issues. I think we need traction on deciding which component owns this bug.

pav, this is you.

someone should retest this with a recent build.

Stiil there in an 07-10-21 nightly but the behavior is slightly different. On a reload, mozilla retrieves a new image, stores it in the disk cache, displays it, but then retrieves yet another image but apparently throws it away. That's for viewing an image directly in mozilla. This does *not* happen if a dynamic image is embedded (via a <img> tag) in a dynamic html document. In this case, there is only one fetch for each.

is this url what your seeing? testing this in build 2002-2-8-03 w2k. http://www.shacknews.com/screens.x/quake3/Urban+Terror/1/ut24/beta24_shot01.jpg

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

Is this still an issue? None of the links in comments are valid (useful for testing) anymore.

there is a shell script attached which purports to demonstrate the problem. Can't QA check that?

I tested with the script and the doesn't reproduce on Mozilla/5.0 (X11; Linux i686; rv:25.0) Gecko/20130728 Firefox/25.0. At each reload (however it's done), an image gets retrieved very fast. Please only reopen this bug if you can reproduce it.