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.

Received on Friday, 16 February 1996 07:12:40 UTC

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