Re: 7.6 Transfer Codings idea...?

Alex Hopmann (hopmann@holonet.net)
27 May 96 00:16:35 -0700 

--Cyberdog-AltBoundary-010D9B14
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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/



--Cyberdog-AltBoundary-010D9B14
Content-Type: multipart/mixed; boundary="Cyberdog-MixedBoundary-010D9B15"
Content-Transfer-Encoding: 7bit


--Cyberdog-MixedBoundary-010D9B15
Content-Type: text/enriched; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<SMALLER><X-FONTSIZE><PARAM>10</PARAM><X-FONTNAME><PARAM>Geneva</PARAM>=
Richard Connamacher wrote:

</X-FONTNAME></X-FONTSIZE></SMALLER><X-FONTNAME><PARAM>Geneva</PARAM>>I=
t 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 a=
ppropriate for HTTP/1.1 at this late stage of the
process.</X-FONTNAME><SMALLER><X-FONTSIZE><PARAM>10</PARAM><X-FONTNAME>=
<PARAM>Geneva</PARAM>



Alex Hopmann

ResNova Software, Inc.

hopmann@holonet.net

http://www.resnova.com/

</X-FONTNAME></X-FONTSIZE></SMALLER>
--Cyberdog-MixedBoundary-010D9B15--

--Cyberdog-AltBoundary-010D9B14--