W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1997

Re: STATUS100 Re: Proposed resolution

From: Jeffrey Mogul <mogul@pa.dec.com>
Date: Thu, 17 Jul 97 14:40:59 MDT
Message-Id: <9707172140.AA15580@acetes.pa.dec.com>
To: HTTP Working Group <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
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.

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?

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.

-Jeff
Received on Thursday, 17 July 1997 14:59:30 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:32:48 EDT