- From: <dillon@hns.com>
- Date: Fri, 27 Apr 2001 13:22:16 -0400
- To: "Carl Kugler" <kugler@us.ibm.com>
- cc: http-wg@cuckoo.hpl.hp.com
Thankyou for digging that up, but does it
mean that by a server SHOULD or MUST use self-defined message
lengths? This doesn't seem to give the browser author any assurance
that his pipelined requests won't be aborted by a premature connection
close due to a no CONTENT-LENGTH response.
Seems to me that you only pipeline after you've gotton one
request through a connection because you don't know whether the
other end supports persistent connections. After that first request, which
handles the negotiation, you'd like to be able to pipeline with worry about the
pipeline being
cut off.
Doug.......................
"Carl Kugler" <kugler@us.ibm.com> on 04/27/2001 11:53:53 AM
To: Doug Dillon/HNS@HNS
cc:
Subject: Re: Whatever happenned to HTTP 1.1 Pipelining
I found this sentence in section 8.1.2.1, Negotation:
In order to remain persistent, all messages on the connection MUST have a
self-defined message length (i.e., one not defined by closure of the
connection), as described in section 4.4.
-Carl
dillon@hns.com
To: Carl Kugler/Boulder/IBM@IBMUS
04/27/2001 cc:
08:36 AM Subject: Re: Whatever happenned to
HTTP 1.1
Pipelining
I naturally thought about that, but is there anything is the RFC
that says that Transfer-Encoding: chunked SHOULD or MUST be used on
persistent
HTTP 1.1 connections instead of sending with no content-length?
I don't recall seeing that.
Doug................
"Carl Kugler" <kugler@us.ibm.com> on 04/27/2001 10:22:42 AM
To: Doug Dillon/HNS@HNS
cc: http-wg@cuckoo.hpl.hp.com
Subject: Re: Whatever happenned to HTTP 1.1 Pipelining
> The biggest one that comes to mind is fact that one
> of the responses in the pipeline may not have a content-length.
> What could be done about that?
Use Transfer-Encoding: chunked.
-Carl
Received on Friday, 27 April 2001 18:26:08 UTC