Re: Is 100-Continue hop-by-hop?
Koen Holtman (koen@win.tue.nl)
Fri, 11 Jul 1997 09:50:37 +0200 (MET DST)
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.