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.