Proposal: 100-Continue optional under Client control

A number of participants in the HTTP-WG have expressed concern about
the requirement a 100 CONTINUE be sent by origin servers in response
to every request which included  a Content-length or Transfer-encoding
header.

This proposal is intended to describe a specific set of changes
to the current specification which make sending the 100 CONTINUE
optional based on the client request including a new header which
indicates that the client is actually waiting for the 100 CONTINUE
header.

This proposal alters the wording in section 8.2 of RFC 2068 and
defines a new request header ("Expected:") with which the client
indicates that it is waiting for a 100 CONTINUE response prior to
completing the request.

Dave Morris


.... The proposal:

Add a new --new-- bullet item in following the --old-- bullet in
section 8.2 (lines 2566-2567) to result in the --new--:

--old--
o  An HTTP/1.1 (or later) client MUST be prepared to accept a 100
   (Continue) status followed by a regular response.

--new--
o  An HTTP/1.1 (or later) client MUST be prepared to accept a 100
   (Continue) status followed by a regular response.

o  An HTTP/1.1 (or later) client MUST send the new "Expected:"
   request header with "100-Continue" specified if the client will
   wait after sending the request headers before sending the
   request body.

The following --old-- paragraph in section 8.2 (lines 2583-2589)
should be replaced with the --new-- wording:

--old--
   Upon receiving a method subject to these requirements from an
   HTTP/1.1 (or later) client, an HTTP/1.1 (or later) server MUST either
   respond with 100 (Continue) status and continue to read from the
   input stream, or respond with an error status. If it responds with an
   error status, it MAY close the transport (TCP) connection or it MAY
   continue to read and discard the rest of the request. It MUST NOT
   perform the requested method if it returns an error status.

--new--
   Upon receiving a request which includes a content body and the
   "Expected: 100-Continue" request header, an HTTP/1.1 (or later)
   server must either respond with
   100 (Continue) status and continue to read from the
   input stream, or respond with an error status. If it responds with an
   error status, it MAY close the transport (TCP) connection or it MAY
   continue to read and discard the rest of the request. It MUST NOT
   perform the requested method if it returns an error status.

   For compatibility with RFC 2068, an HTTP/1.1 (or later) server
   MAY send an intermediate 100 (Continue) status as described above
   to an HTTP/1.1 (but NOT later) client which didn't include the
   "Expected: 100-Continue" request header with 100 (Continue) status
   to minimize any client processing delays associated with an
   undeclared wait for 100 (Continue) status.

   (Possible implementation note:  It is never necessary to send
   the 100-Continue status if the server has already received some
   portion of the request body.)

The new "Expected:" header description should be included
as section 14.21 by renumbering the current 14.21 and beyond.
Insert proposed wording following line 6525:

 14.21 Expected

    The Expected request-header field is used to indicate that
    particular conditional behaviors are required by the client.
    An origin server which does not understand or is unable to
    comply with an Expected field value stipulation MUST
    respond with appropriate error status.

      Expected              =  "Expected" ":" 1#expected-stipulation

      expected-stipulation  =  "100-continue" | extension-stipulation
      extension-stipulation =  token [ "=" ( token | quoted-string )
                                       *stip-params ]
      stip-params           =  ";" token [ = ( token | quoted-string ) ]

    When the 100-continue stipulation is present on a request which
    includes a body, the requesting client is waiting after sending
    the request headers prior to sending the content-body. Thus, the
    server MUST conform to the requirements of section 8.2 and
    either send 100 (Continue) status or error status after receiving
    the "Expected: 100-continue" request header.

    This header field is defined with extensible syntax to allow for
    future extensions.

Received on Sunday, 29 June 1997 23:31:28 UTC