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

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.  In particular, there I said "proxies
should not multiplex requests from multiple clients" because of
the H-O-L blocking problem, which can greatly limit performance.

But in any case, your concern is misplaced; a 100 response is
no different from any other kind of response.  I.e., if a
proxy *were* multiplexing requests from multiple clients (which
it shouldn't, but suppose it did), then it would certainly
have to match up responses with requests.  This is just as
true for 200 responses as it is for 100 responses.

The rule for HTTP persistent connections is that responses cannot be
reordered.  That is, until the server sends the response for request N,
it cannot send the response for request N+1 (or any request N+x, for x
>= 1).  Another way of looking at this is that for a given transport
connection, although more than one request or response may be
pipelined, they cannot be parallelized.

The "100" status code complicates this, because it allows the
sender to send more than one response for a request.  Fine; just
change the rule to say
	until the server sends the LAST response for request N, it
	cannot send ANY response for request N+1 (or any request N+x,
	for x >= 1).

Simple, foolproof, and not in any way a change from current practice
(given that some people have apparently implement 100 already).

    1.1 does not offer an end-to-end event notification service, nor
    can 100 be easily `fixed' to produce such a service.  Adding such a
    service is out of scope for this WG I think.  IF DAV needs
    something, I suggest that you either document Netscape server push
    and use that, or spec a mechanism in which the client makes
    occasional status requests.

HTTP/1.1 already includes "100 (Continue)", and (as our "Summary of
STATUS100 issue" makes clear) there is exactly one problem that this
status code actually solves: allowing the client to defer transmission
of the request body until the server has indicated a willingness to
accept it.

The working group consensus seems to be that this is a useful
feature (and I'm on the "reluctantly agree" side of this myself).
On the other hand, I think everyone agrees that the current text
in RFC2068 is misleading and perhaps wrong.  The scope of our
current effort is to "fix the bugs in RFC2068", not to re-argue
the basic design features.

-Jeff

Received on Thursday, 10 July 1997 16:58:21 UTC