Closed Bug 44469 Opened 24 years ago Closed 8 years ago

Strange persistent connection behavior

Categories

(Core :: Networking: HTTP, defect)

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME
Future

People

(Reporter: tenthumbs, Unassigned)

References

Details

Attachments

(1 file)

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?
Assignee: gagan,ruslan → pnunn
very interesting. I'll look into it. I'm working on a 
bug that may be related.
-p
Status: NEW → ASSIGNED
Target Milestone: --- → M17
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
Keywords: nsbeta3
Target Milestone: M17 → M18
Gordon:
Thought this might be of interest per our conversion
yesterday.
-p
per triage team, minus.
Whiteboard: [nsbeta3-]
Target Milestone: M18 → Future
Blocks: 61531
Keywords: nsbeta3nsbeta1
Whiteboard: [nsbeta3-]
Target Milestone: Future → mozilla0.9
All pnunn bugs reassigned to Pav, who is taking over
the imglib.
Assignee: pnunn → pavlov
Status: ASSIGNED → NEW
can someone set this up on a server or something so i can see if it still 
happens with the new imagelib?
Keywords: qawanted
Priority: P3 → --
Target Milestone: mozilla0.9 → ---
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 Contact: tever → benc
(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
Component: Networking → Networking: HTTP
Target Milestone: --- → Future
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.
Depends on: 80922
Blocks: 104166
Keywords: qawanted
QA Contact: benc → httpqa
Assignee: pavlov → nobody
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: