HTTP/1.1 keep-alive interaction

RESOLVED INVALID

Status

()

Core
Networking: HTTP
RESOLVED INVALID
14 years ago
14 years ago

People

(Reporter: wolfiR, Assigned: Darin Fisher)

Tracking

Trunk
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

14 years ago
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

14 years ago
Created attachment 147622 [details]
captured tcp stream
(Reporter)

Comment 2

14 years ago
Created attachment 147624 [details]
downloaded file

Comment 3

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

14 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

14 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
Last Resolved: 14 years ago
Resolution: --- → INVALID
(Reporter)

Comment 7

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

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