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

STATUS100 Re: Proposed resolution

From: Scott Lawrence <lawrence@agranat.com>
Date: Thu, 17 Jul 1997 10:33:32 -0400
Message-Id: <199707171433.KAA08872@devnix.agranat.com>
To: http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/3776

  An observation: I find it interesting that the set of rules to limit
  use of 100 Continue seems to require such a long specification,
  given that the original mechanism was so simple...

>>>>> "JM" == Jeffrey Mogul <mogul@pa.dec.com> writes:

JM> 8.2 Message Transmission Requirements
JM>    Requirements for HTTP/1.1 or later clients:
JM>    o  A client MUST be prepared to accept a 100 (Continue) status
JM>       message followed by a regular response, even if the client does
JM>       not expect a 100 (Continue) status message.
JM>    Requirements for HTTP/1.1 or later origin servers:
JM>    o  Upon receiving a request which includes an "Expect" request-header
JM>       field with the "100-continue" expectation, an origin server must
JM>       either respond with 100 (Continue) status and continue to read
JM>       from the input stream, or respond with an error status. If it
JM>       responds with an error status, it MAY close the transport (TCP)
JM>       connection or it MAY continue to read and discard the rest of the
JM>       request. It MUST NOT perform the requested method if it returns
JM>       an error status.

  I would reword this to reflect that the 100 Continue response MUST
  be sent after the request _headers_ have been recieved, since the
  'request' includes the body.

JM>    o  An origin server SHOULD NOT send a 100 (Continue) response if
JM>       the request message does not include an "Expect" request-header
JM>       field with the "100-continue" expectation, and MUST NOT send a
JM>       100 (Continue) response if such a request comes from an HTTP/1.0
JM>       (or earlier) client.

JM>    o  An origin server SHOULD NOT send a 100 (Continue) response if
JM>       has already received some or all of the request body for the
JM>       corresponding request.

  I don't see the point of these two SHOULD NOTs, since the client
  MUST be prepared to accept an unexpected 100 response anyway.
  Arguing against these rules:

    - As noted elsewhere, existing 1.1 servers (yes, there are some)
      won't have been coded to include these restrictions (since the
      Expect header was only suggested a couple of weeks ago).

    - I think that it is poor design to encourage look-ahead in the
      data stream to determine whether or not body has been received.

JM>    o  If an origin server receives a request that does not include an
JM>       "Expect" request-header field with the "100-continue"
JM>       expectation, and the request includes a request body, and the
JM>       server responds with an error status before reading the entire
JM>       request body from the transport connection, then the server
JM>       SHOULD NOT close the transport connection until it has read the
JM>       entire request, or until the client closes the connection.
JM>       Otherwise, the client may not reliably receive the response
JM>       message.

  Does this amount to a rule for the purpose of avoiding bugs in some
  TCP implementations?  I can live with this rule since it is not a

JM>    For compatibility with RFC 2068, a server MAY send a 100 (Continue)
JM>    status in response to an HTTP/1.1 PUT or POST request that does not
JM>    include an "Expect" request-header field with the "100-continue"
JM>    expectation.  This exception, the purpose of which is to minimize
JM>    any client processing delays associated with an undeclared wait for
JM>    100 (Continue) status, applies only to HTTP/1.1 requests, and not to
JM>    requests with any other HTTP-version value.

  I think that making this a special case allowed _only_ for HTTP/1.1
  is going too far.  We already have the requirement that 100 Continue
  must be accepted by the client anyway.  We're talking about as few
  as 'HTTP/1.1 100CRLF" - 14 bytes - 23 if you send the ' Continue'.
  What justification is there for the complexity of this restriction?

  Furthermore, I think that the above rule, which is stated using
  'MAY', is really a 'MUST NOT':

    A server using any revision of HTTP later than HTTP/1.1 MUST NOT
    send a 100 (Continue) status in response to an HTTP/1.1 PUT or
    POST request that does not include an "Expect" request-header
    field with the "100-continue" expectation.

  Referring to the use of the imperitive 'key word's, RFC 2119 says

    Imperatives of the type defined in this memo must be used with
    care and sparingly.  In particular, they MUST only be used where
    it is actually required for interoperation or to limit behavior
    which has potential for causing harm (e.g., limiting

  I don't believe that this rule on future versions of the protocol
  meets that test.

JM>    Requirements for HTTP/1.1 or later proxies:
JM> ...
JM>    o  If the proxy knows that the version of the next-hop server is
JM>       HTTP/1.0 or lower, it MUST NOT forward the request, and it MUST
JM>       respond with a 419 (Expectation Failed) status.

  How is the client to know that repeating the request using HTTP/1.0 could
  resolve this situation?  Should clients always back off to 1.0 if
  they receive a 419?

Scott Lawrence           EmWeb Embedded Server       <lawrence@agranat.com>
Agranat Systems, Inc.        Engineering            http://www.agranat.com/
Received on Thursday, 17 July 1997 07:36:25 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:20 UTC