242539 - HTTP/1.1 keep-alive interaction

Status: RESOLVED INVALID

(Core :: Networking: HTTP, defect)

Description

[Wolfgang Rosenauer [:wolfiR]]

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

Comment 1

[Wolfgang Rosenauer [:wolfiR]]

Attachment: captured tcp stream

Comment 2

[Wolfgang Rosenauer [:wolfiR]]

Attachment: downloaded file

Comment 3

[Jo Hermans]

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

[Christian :Biesinger (don't email me, ping me on IRC)]

(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

Comment 5

[Wolfgang Rosenauer [:wolfiR]]

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.

Comment 6

[Darin Fisher]

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.

Comment 7

[Wolfgang Rosenauer [:wolfiR]]

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

[Christian :Biesinger (don't email me, ping me on IRC)]

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)

Comment 9

[Wolfgang Rosenauer [:wolfiR]]

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.