W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1996

FW: Number of connections

From: Paul Leach <paulle@microsoft.com>
Date: Thu, 15 Feb 96 15:11:34 PST
To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: red-16-msg960215230428MTP[01.52.00]000000b1-95857
I'm really sorry -- today, our mailer doesn't like addresses of the 
form foo%x.y.z@host...
From: Paul Leach
To: mogul@pa.dec.com; ses@tipper.oit.unc.edu
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Subject: Re: Number of connections
Date: Thursday, February 15, 1996 3:05PM

(resend due to mail problem...)

I was looking at the description of chunking, and realized that a 
slight extension of chunking would allow for multiplexing the 
connection between more than one pipelined request/response. This would 
really reduce the incentive for browsers to open more than one connection.

To recall what chunking does: each chunk starts will the length encoded 
as an ASCII hex number, followed by CRLF followed by the next chunk of 
data as 8 bit raw octets, followed by CRLF.  The last chunk has length 
0, and after it can optionally come entity header fields (other than 
Content-Length or Transfer-Encoding).  The idea is that the receiver 
can reliably detect end-of-data, without having to know in advance what 
the content length is, so that the server can dynamically generate it 
and send early parts of it while the later parts are being generated.

This definition of chunked transfer encoding makes it easy to define a 
multiplexed transfer encoding:  each chunk starts with the length in 
hex, a ':', then a "stream number".  Streams are used for the 
interleaved sending of entity bodies.

To initiate this we unfortunately need a new header: the client sends
	Request-ID: xxx, stream=n
which says that this request has ID "xxx" and the entity-body requested 
is requested to be returned on stream "n". The client must assign a 
unique ID and stream number to each outstanding request.

Clients may send multiple requests without waiting for a response. The 
server may respond to requests containing Request-ID headers in any 
order it chooses if it includes
	Request-ID: xxx
in the response to identify the matching request; otherwise it must 
respond in the order requests were received.

The server, if it chooses to honor the request for multiplexed transfer 
encoding, will reply with
	Transfer-Encoding: multiplexed
and send the entity-body using multiplexed transfer encoding.

When using multiplexed transfer encoding, response elements other than 
entity-bodies are sent "in between" chunks. A response can be 
differentiated from a chunk because chunks start with a hex number, 
while responses start with "HTTP/n.m".  Good thing "H" is not a hex digit :-)

Conveniently, the presence of Request-IDs forms a nice basis for the 
ability of the client to cancel outstanding requests without having to 
close the connection. An new method, CANCEL, is required. To cancel a 
request, the client sends
	CANCEL /x/y/z.gif HTTP/1.1
	Request-ID: xxx
to the server, asking it to cancel the request with ID "xxx". The URI 
is really only needed when talking to a proxy, which will use it to 
determine the correct origin server to talk to; if the client knows it 
is talking directly to an origin server, it could send '*'.

This seems like a really small protocol change, in order to reduce the 
number of connections to a bare minimum, and it gets the ability for 
clients to cancel a request without closing the connection as well -- 
and if I recall, some significant fraction of requests are cancelled.


Received on Thursday, 15 February 1996 15:09:17 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:16 UTC