Re: Summary of STATUS100 issue

Jeffrey Mogul:
>
> 
>During the editorial group teleconference on Friday, we discussed
>the STATUS100 issue (i.e., when/whether to send or wait for
>"100 (Continue)").

Urgl.  I get the feeling that 100 is taking far too much of our scarce
time, given that it is in no way central to basic HTTP operation.  I
also have the feeling that is taking so much time because it had loads
of *unnecessary complexity* from the start.

I think we are trying to untangle a knot which should be cut instead.

I move that we either simplify the thing, or remove it from the spec
entirely.  We already know that 100 processing is a pain to implement
in servers and clients, and I think it is time to question whether we
cannot achieve the same goals in a much simpler way.

[...]

>Our understanding is that the two-phase mechanism solves two
>potential problems:
> 
>        (1) A client sending a request message with a request body
>        may wish to determine if the server is willing to accept
>        the request (based on the request headers) before it
>        transmits the body.  In some cases, it may either be
>        inappropriate, or highly inefficient, for the client to
>        send the body if the server will reject the message without
>        looking at the body.

Yes, this is one of the requirements.

>        (2) There are race conditions that arise when pipelining
>        several non-idempotent requests, due to the ambiguity that
>        arises when the connection is terminated before the client
>        has received responses to all of the requests it has sent.
>        The use of the two-phase mechanism can reduce the exposure
>        to such ambiguities, although it cannot entirely eliminate
>        them.

This pipelining stuff is new for me, I thought the race conditions
could also happen without pipelining.  The race condition is in the
TCP stack if the server aborts the connection.  AFAIK, the background
was that http MUST allow servers to abort the connection after having
sent an error response if they do not want to read and throw away all
request body data.  The binary exponential backoff is basically a
method by which a client will eventually get the error response even
though the server aborts the connection, which may cause the TCP stack
to delete the error response before the client can read it.

I did some thinking about simplifying stuff, and I have concluded that
a binary exponential backoff algorithm would work *just as fine* at
eventually avoiding a race condition if all the 100 response stuff was
removed.

I concluded that to meet (2) above, one could spec that:

 1) if a user agent sees a reset without getting a full status, or a
502 response, when doing a request-with-a-body, the agent
must wait a time X between sending the request header and the body if
it retries, where X should be doubled on every retry.
 2) if it has returned an error response, a server (any server) must
_never_ abort the connection _before_ seeing any request data.
 3) a proxy or gateway should not wait indefinitely for request body data
before forwarding the request header
 4) a proxy which sees an abort from the upstream server must either
abort the downstream connection too or send a 502 response.

This gives exactly the same degree of protection in a pure 1.1 chain
as far as I can see, while having a greater chance of still offering
protection over a chain which is partly 1.0.

Note the absence of differences depending on whether the server is 1.0
or 1.1, and the absence of 100 responses.

After simplifying 8.2 in this way, and removing the 100 response, we
could either cut the 1xx class response codes entirely, or keep them
without specifying any timing requirements for forwarding/processing
by proxies.

To meet (1) above, we could define a new method by which the client
can ask the server if an X request with the following headers would be
allowed.  Such a request could look like:

ASK-IF-ALLOWED /a/page HTTP/1.1
Is-method-allowed: PUT
Authorization: ......
 etc. 


I don't think things need to be more complicated than that.

Koen.

Received on Thursday, 10 July 1997 12:49:55 UTC