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.
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.