- 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
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. Comments? Paul
Received on Thursday, 15 February 1996 15:09:17 UTC