Re: Proposal: 100-Continue optional under Client control
Scott Lawrence (lawrence@agranat.com)
Wed, 02 Jul 1997 17:02:15 -0400
Without agreeing with the premise that the client should control
whether or not it will wait (that is I actually think it should just
always wait)...
>>>>> "JM" == Jeffrey Mogul <mogul@pa.dec.com> writes:
JM> The Expected request-header field is used to indicate that
JM> particular server behaviors are required by the client. A
JM> server that does not understand or is unable to comply with any of
JM> the expectation values in the Expected field of a request MUST
JM> respond with appropriate error status.
JM> Expected = "Expected" ":" 1#expectation
JM> expectation = "100-continue" | expectation-extension
JM> expectation-extension = token [ "=" ( token | quoted-string )
JM> *expect-params ]
JM> expect-params = ";" token [ = ( token | quoted-string ) ]
JM> The server SHOULD respond with a 412 (Precondition Failed) status
JM> if any of the expectations cannot be met.
I think that it might be better to allocate a new 4xx code (416
Expectation Failed?) for this so that the client can tell whether
the problem was the Expected header or one of the other headers that
make the request conditional (If-Unmodified-Since or If-None-Match).
JM> When the "100-continue" expectation is present on a request that
JM> includes a body, the requesting client will wait after sending the
JM> request headers before sending the content-body. In this case, the
JM> server MUST conform to the requirements of section 8.2: it MUST
JM> either send a 100 (Continue) status, or an error status, after
JM> receiving the "Expected: 100-continue" request header.
I suppose that I could accept this approach as a compromise, but
only if someone can explain the basis on which the client can know
when it is appropriate or important to invoke this mechanism.
--
Scott Lawrence EmWeb Embedded Server <lawrence@agranat.com>
Agranat Systems, Inc. Engineering http://www.agranat.com/