Re: Is 100-Continue hop-by-hop?

Jeffrey Mogul:
>
>Yaron Goland:
>    >On 100 being hop by hop, I would also throw in the following scenario
>    >from DAV land:
>    >A client executes a COPY on a container with a large number of members.
>    >The user agent will want to be able to provide update information on how
>    >the copy is progressing rather than just sitting there for a few minutes
>    >while the procedure is underway. 100 continue responses are perfect for
>    >this scenario.
>    
>Koen:
>    Sorry, but 100 continue is _not_ perfect for this scenario.  There
>    is a message by Jeff in the archives which explains why.
>    Basically, a proxy which is multiplexing requests from multiple
>    clients over a single upstream connection would have no idea to
>    which client a 100 continue would have to be forwarded.
>    
>You're presumably referring to my mail on "head of line blocking",
>which is a separate issue.

No, think I was referring to
http://www.ics.uci.edu/pub/ietf/http/hypermail/1997q2/0134.html (Re:
1xx Clarification, which was written a few weeks ago).

Anyway, I think I interpreted Yaron's message wrong.  I thought he was
arguing the case

  <copy request> <200 OK response to copy request> <100 response about
  progress=50%> <100 response about progress=100%>

in which the progress events are sent *after* the OK response which
ends the transaction.

But I guess that what he actually had in mind was 

  <copy request> <100 response about progress=50%> <100 response about
  progress=100%> <200 OK response to copy request>

And this latter case would indeed work through a multiplexing proxy
(though the code would have to be 101 or something, with semantics
slightly different from 100). 

So I believe I was wrong, and that Yaron has a valid case for keeping
the 1xx codes.

Sorry for all the confusion.

>-Jeff

Koen.

Received on Friday, 11 July 1997 00:53:46 UTC