- From: Scott Lawrence <lawrence@agranat.com>
- Date: Wed, 02 Jul 1997 17:02:15 -0400
- To: http-wg@cuckoo.hpl.hp.com
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/
Received on Wednesday, 2 July 1997 14:04:11 UTC