Re: 7.6 Transfer Codings idea...?

> 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.

Agreed, I realized that it most likely wouldn't be integrated in HTTP 
1.1, since it's much more than a clairity-based change.  Perhaps I should 
have waited until after HTTP 1.1 is finished to post this, so I apologize 
for my timing.  I considered my approach to be a very simple one that 
would be very easy to impliment, although not optimal.

> 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.

Agreed, a layer beneath HTTP would probably be a better approach.  I 
suggested this because something like this would take only a minimal 
reprogramming of our server to fully support (and probably most others), and 
clients would require less.   Just to clarify, though, I'll show what I 
meant by mixing up headers and entities, since they're not really mixed 
up.

Since this is a little off the subject of the list right now, feel free 
to toss it in the back of your mail folder and worry about it later.

Client: GET /foo HTTP/1.1
Client: <header blab>
Client:
Client: GET /bar HTTP/1.1
Client: <header blab>
Client:
Server: HTTP/1.1 200 OK  <-- Answer to first request.
Server: <header blab>
Server: Content-type: text/plain
Server: Transfer-encoding: chunked id=0
Server:
Server: 17
Server: This is a line.
Server: This is another.
Server: !              <-- transfer paused, client now ready for either the 
                           next response or a resumed transfer.
Server: HTTP/1.1 200 OK  <-- It was the next response...
Server: <header blab>
Server: Context-type: image/gif
Server: Transfer-encoding: chunked id=1
Server:
Server: !              <-- Whoa, this'll take a while, better pause it 
                           and send something else in the meantime...
Server: [id=0]         <-- Okay, it's a resumed transfer of response id 0 
                           (the first one)
Server: E
Server: The end.  Bye.
Server: 0              <-- Ended, the client waits for what's next...
Server: [id=1]         <-- Okay, the server wants to send that gif now.
Server: 1AF
Server: <a 432 byte gif>
Server: 0
[server closes connection]

Richard Connamacher

Received on Monday, 27 May 1996 01:41:00 UTC