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

Re: 7.6 Transfer Codings idea...?

From: Alex Hopmann <hopmann@holonet.net>
Date: 27 May 96 00:16:35 -0700
To: Richard Connamacher <phantom@baymoo.sfsu.edu>, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <ADCEA51F-10DA92F@206.15.78.175>
Richard Connamacher wrote:
>It would be very useful to extend the chunked Transfer Coding to
allow
>the
>processing of a second request in a pipe-lined connection between or
>before
>sending the chunks for the first request.  An example would be if the
>first
>request sent would require some time to respond to, but the second
>request
>could be fulfilled immediately, or if the response to the first
request
>used a Netscapism like server push.

While I agree strongly with the objectives of this proposal (The
importance of a mechanism for returning multiple requests out of
order), I think this is entirely the wrong approach to achive that
goal- It makes alot more sense to pursue a multiplexing layer
underneath HTTP such as the various multiplexing/SCP proposals that
are variously being worked on by Simon Spero, Jim Gettes, and myself.
I believe I would not be inaccurate in saying that many members of
this group consider this one of our most important tasks to tackle
_after_ the completion of the HTTP/1.1 proposal.

Furthermore, allow me to put forth a more direct critque of the
suggestion:
Chunked encoding takes place in the entity-body. HTTP responses are
useless without their response-headers, and response-headers which are
further down the pipeline cannot be conveyed easily within chunked
encoding. Furthermore use of chunked encoding in this would could add
quite a bit of additional complexity to client (and to some degree
server) implementations as they will have to be able to simultaneously
receive multiple responses from a single HTTP entity-body. By placing
a multiplexing layer _under_ HTTP, each HTTP protocol element can act
as if it has its own virtual channel, with a different multiplexing
layer dealing with the multiplexed transport.

In any case I believe that an addition of this magnitude would not be
appropriate for HTTP/1.1 at this late stage of the process.


Alex Hopmann
ResNova Software, Inc.
hopmann@holonet.net
http://www.resnova.com/
Received on Monday, 27 May 1996 00:23:40 EDT

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