First of all, other bugs prevent you from seeing any changes so you really need access to server logs to see what is going on. I have a cgi script on my localhost Apache server and the script will, among other things, emit "Refresh: 10" headers along with a constantly changing HTML document. Since Mozilla talks HTTP/1.1 and Apache has a 15 second timeout on persistent connections, it is easy to see from the server logs and Mozilla's output that Mozilla reuses the initial connection and receives a new page every 10 seconds. That's perfectly normal. If I change the script to return an image (GIF or PNG, it doesn't matter) then things get more interesting. Mozilla reports a successful initial load but the first time it tries to reuse the connection it thinks an error has occurred. It reports this error and appears to close the connection. From this point on, it opens a new connection every 10 seconds and receives new data from the server but it still reports an error on every reload. If you turn off persistent connections in the prefs, this does not happen. Mozilla thinks every reload is successful. What is really interesting is turning off persistent connections in the server. If you let Mozilla get into its error mode described above, turn off persistent connections in the server and restart it gracefully so the changes take effect starting with new connections then Mozilla stops reporting errors and reports successes. If you turn persistent connections back on then Mozilla thinks the next connection works but, as above, all subsequent ones fail. I have no idea why content type should make a difference. but it does. Very odd.

Sounds like imagelib does smth. Is it a multipart gif?

No, it's just a single image. It also happens with PNG's. I lengthened the server's keep-alive time and that made no difference either. You're welcome to the test scripts if you want them.

Any clues from the imagelib corner?

very interesting. I'll look into it. I'm working on a bug that may be related. -p

10thumbs: When you are viewing the images, are you viewing only the image, or is the image accessed through an html page? I ask because each is a slightly different code path. For view-images, layout creates a 'synthetic document' to issue the request. The image remains the top level document, so any change to it would indicate any netlib cache items should be 'old'. Another oddity occurs in that layout requests an initial read of the image to get its dimensions and it releases the data stream. To actually decode the image requires another a request for another data stream. And I'm working on other bugs that result from this second request. I hope this isn't more info than you'd like to hear. Any other info you can pass on would be welcomed. When I view the test url with a tree built from 07-11-00 on NT, I can see all image viewed in the target frame. I'll test again with a linux build and see what's up. -p

> When you are viewing the images, are you viewing only the > image, or is the image accessed through an html page? Just the image; I've never been able to get Mozilla to refresh an image embedded in a document. I am going to attach the test scripts I've been using. Maybe it will be easier to see what's happening using them. You are going to need a HTTP server, but almost any Linux system will have what's needed.

Make that attachment a tar.gz file. Sorry about the spam.

cool. thanks much. I'm currently looking at several symptoms of reload problems. -p

Gordon: Thought this might be of interest per our conversion yesterday. -p

per triage team, minus.

All pnunn bugs reassigned to Pav, who is taking over the imglib.

can someone set this up on a server or something so i can see if it still happens with the new imagelib?

I suspect that the current netlib state prevents really testing this. I could not get a 04-10 Linux nightly build to do persistent connections no matter what I tried. Still, there is definitely something odd. A constantly refreshing HTML document works as expected and mozilla spits out success messages to stderr. With a GIF inage instead, mozilla renders it correctly and gets the refresh right but it also spits out error messages to stderr. You really need simultaneous access to the server logs as well as mozilla to properly see what's happening.

Sorry, but I missed some stuff when I cut and pasted. "It's much easier to run the scripts on localhost."

qa to me. Can someone put a priority and milestone to this? I think the problem is well described enough for us to make that decision. If this becomes important enough, I can move it to the top of my todo list.

(qa to me should have been as "benc@netscape.com"...)

the error printed out is due to me canceling a load in progress (the one trying to figure out what the thing you asked it to load is) since I have a cache entry.. basically the error comes from the fact that I can't cancel a channel with a successful status. if you can file a bug on HTTP, and mark this dependant on it, that would be helpful

pavlov: with the http branch landing, one of the things you can now do is cancel a load with a successful status. but, canceling a load will always cause the connection to be dropped.

reporter: can you reproduce this bug using a recent nightly build?

The good news is that the test scripts work much better now. Mozilla appears to reuse persistent connections. The bad news is that mozilla still throws the occasional error; not every time though. Looking at the server logs I see that it's make two calls on each refresh which is bug 80922. I would like to say this bug is fixed but I can't be sure until 80922 is dealt with.