Re: 7.6 Transfer Codings idea...?

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/