Re: STATUS100 Re: Proposed resolution

** Reply to note from Jeffrey Mogul <mogul@pa.dec.com> Thu, 17 Jul 97 14:40:59 MDT
>   
> On the general topic of "is the whole status 100 thing worth having?":
>   
> I've always been neutral on the topic.  However, several members
> of the HTTP/1.1 editorial group are firmly in favor of keeping
> it, as are at least some other members of the full working group.
> As far as I can tell, the consensus of the editorial group is
> "keep it, but fix it."
>   
> I got stuck with the responsibility to fix it.  My interest is
> to try to see that, if we have it, then it is done right.
Understood, just wanted to weigh in on the "I don't really like it" but
if we have to keep it let's fix it right" side.

>   
> Koen writes:
>     > 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.
>   
> I don't believe that it's feasible to add a new method at this point,
> especially since it would not interoperate with existing proxies
> and servers.  Koen's ASK-IF-ALLOWED method might have been a good
> design for the original HTTP protocol, but I don't see how to deploy
> it today, without a lot of complexity.
>   
> Richard Gray added:
>   
>    Why not OPTIONS?
>   
> Using OPTIONS is a possibility, but we are still waiting for
> a formal specification for OPTIONS (everyone seems to agree
> that RFC2068 doesn't explain enough how to use it).  Also,
> can you suggest a way of using OPTIONS that doesn't add round
> trips to every PUT/POST interaction?
I thought Roy explained fairly clearly that OPTIONS is meant to be
extensible.  So, you invent a MIME type for the message you want to
send, and a format for the body:
  http/query-authorization
  METHOD=PUT

True it would add round trips, but you have the same problem with the
"Expect" header, right?

It occurs to me that another workaround would be to issue HEAD against
the resource...

(as an aside, it occured to me while looking at this, that TRACE and
OPTIONS are not listed as idempotent, but I don't see why they are not;
did I miss discussion of this somewhere?)

>   
> Richard continues:
>   
>     o  If an origin server receives a request that does not include an
>        "Expect" request-header field with the "100-continue"
>        expectation, and the request includes a request body, and the
>        server responds with an error status before reading the entire
>        request body from the transport connection, then the server
>        SHOULD NOT close the transport connection until it has read the
>        entire request, or until the client closes the connection.
>        Otherwise, the client may not reliably receive the response
>        message.
>   
>     This is excellent advice, but it does expose the server implementer
>     to attacks where the amount of data is *very* large or the
>     datastream is self-defining (e.g. chunked).
>   
> There are, of course, may other kinds of denial-of-service attack.
> But perhaps it would help to add one more sentence to that rule:
>   
>     o  If an origin server receives a request that does not include an
>        "Expect" request-header field with the "100-continue"
>        expectation, and the request includes a request body, and the
>        server responds with an error status before reading the entire
>        request body from the transport connection, then the server
>        SHOULD NOT close the transport connection until it has read the
>        entire request, or until the client closes the connection.
>        Otherwise, the client may not reliably receive the response
> |      message.  However, this requirement should not be construed
> |      as preventing a server from defending itself against
> |      denial-of-service attacks, or from badly broken client
> |      implementations.
I agree, that is an improvement.

>   
> -Jeff
>   
> 
 

Richard L. Gray
chocolate - the One True food group

Received on Thursday, 17 July 1997 15:30:58 UTC