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, 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.
(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
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.
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
Last Resolved: 15 years ago
Resolution: --- → INVALID
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.
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)
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.