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

Re: FW: Number of connections

From: Carlos Horowicz <carlos@patora.mrec.ar>
Date: Fri, 16 Feb 1996 12:15:01 -0300 (ARG)
Message-Id: <199602161515.PAA18208@patora.mrec.ar>
To: Paul Leach <paulle@microsoft.com>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com

A few comments:

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

How does the client signal, after being continuously pushing requests
into the pipe, that it doesn't want anything else ? I don't see the need
for multiplexing in the client->server direction, if the client can
seat there and bomb the server continously with requests.

The scheme seems really useful for the server->client direction of the
connection. This would allow different programming paradigms for the
server, like spawning a thread for each request that comes from the pipe, or
using overlapped I/O and pushing chunks back into the pipe as the
file I/O operations end, or whatever.

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

I wonder why end-of-data detection wasn't introduced in the protocol
previous to this discussion (for single request/response sequence on
a connection), instead of leaving this detection to
the socket interface.

Carlos
Received on Friday, 16 February 1996 07:12:40 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:31:45 EDT