Re: FW: Number of connections

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 UTC