Re: Proposal: 100-Continue optional under Client control

David W. Morris:
>
[...]
>
>.... The proposal:

Overall, this looks good to me.  Some nitpicks included below.

>
>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)
                                          ^^^
Add: `from an HTTP/1.1 client'.  A 1.0 proxy will not strip off this
header when relaying a request.

>   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
        ^^^^^^
Delete origin.

>    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.

As the 100 mechanism is hop-to-hop, it looks like Expected must be a
hop-to-hop header, so it must be added to the list in section 13.5.1,
and the following text should be added to the header definition:

  The Expected header field is a hop-by-hop header field, and MUST be
  listed in a Connection header field, as described in section 14.10,
  when included in the request.

As there are no 1.1 proxy implementations yet (I believe), we _could_
get away with not requiring the Connection header.  This is an issue
which needs to be discussed.

Koen.

Received on Monday, 30 June 1997 11:28:58 UTC