Closed
Bug 242539
Opened 20 years ago
Closed 20 years ago
HTTP/1.1 keep-alive interaction
Categories
(Core :: Networking: HTTP, defect)
Tracking
()
RESOLVED
INVALID
People
(Reporter: wolfiR, Assigned: darin.moz)
Details
Attachments
(2 files)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040503 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040503 the keep-alive implementation behaves strange. I captured a network-connection between mozilla 1.7rc1 retreiving a file from a web-application. (will be appended soon) I do not know for sure if it is a mozilla problem or an application problem. But it only occurs if keep-alive is used. I will also add the resulting downloaded file. Reproducible: Always Steps to Reproduce: .
Reporter | ||
Comment 1•20 years ago
|
||
Reporter | ||
Comment 2•20 years ago
|
||
Comment 3•20 years ago
|
||
Reporter, please define 'strange'. I don't see what's happening here, just 2 downloads of the same file, 4 seconds apart. The first one is send as a response on a HEAD (with no-cache set), the second one as a response on the GET. I though that sending a response on a HEAD wasn't allowed (RFC2616, para 9.4) ? But it has nothing to do with the keep-alive mechanism.
Comment 4•20 years ago
|
||
(In reply to comment #3) > I though that sending a response on a HEAD wasn't allowed (RFC2616, para 9.4) ? > But it has nothing to do with the keep-alive mechanism. hm? why not? when sent as keep-alive, that body may well be interpreted as the http header block of the next GET request... an http log as described on http://www.mozilla.org/projects/netlib/http/http-debugging.html would be helpful
Reporter | ||
Comment 5•20 years ago
|
||
I will provide a log tomorrow. What you can see in the attachments is ONE "Save link as file" request. And it doesn't behave like this if keep-alive is disabled in preferences. So I would say it has definitely to do with the keep-alive thing.
Assignee | ||
Comment 6•20 years ago
|
||
From RFC 2616, Section 9.4: "The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response." The server in this bug is sending a message body in response to a HEAD request. Therefore, it is at fault. By sending a message body in response to a HEAD request, the server makes it impossible for HTTP/1.1 keep-alive to be supported. Moreover, wolf.abc.de does not appear to be a valid domain name, so there is no site to evangelize. This bug report is INVALID.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → INVALID
Reporter | ||
Comment 7•20 years ago
|
||
the original hostname was masqueraded because it's an internal server. But thanks for the clarification. But I feel that's an apache default behaviour. I will try to to check it out on server side.
Comment 8•20 years ago
|
||
eh, that's absolutely _not_ apache default behaviour. probably your perl script is buggy. (note that this would alternatively be fixed by making mozilla not send HEAD requests for "save link as"; but the script is broken nonetheless)
Reporter | ||
Comment 9•20 years ago
|
||
you are perfectly right. The perl application is to blame here. I don't know if the HEAD request is needed in that case or not.
You need to log in
before you can comment on or make changes to this bug.
Description
•