- From: Scott Lawrence <lawrence@agranat.com>
- Date: Tue, 17 Feb 1998 16:58:51 -0500
- To: HTTP Working Group <http-wg@cuckoo.hpl.hp.com>
- Cc: Jim Gettys <jg@w3.org>
I noticed this in the course of trying to work through documenting what features we implement (I guess that means that it's working :-). I think this is just an editorial issue - there is a SHOULD here that may leave implementors with the idea that the Expect header can be ignored. draft-ietf-http-v11-spec-rev-01.txt says: 14.47 Expect The Expect request-header field is used to indicate that particular server behaviors are required by the client. A server that does not understand or is unable to comply with any of the expectation values in the Expect field of a request MUST respond with appropriate error status. [...ABNF...] The server SHOULD respond with a 417 (Expectation Failed) status if any of the expectations cannot be met. This header field is defined with extensible syntax to allow for future extensions. If a server receives a request containing an Expect field that includes an expectation-extension that it does not support, it MUST respond with a 417 (Expectation Failed) status. I'm not sure why the SHOULD in the second paragraph above is not a MUST other than to allow for the possibility of responding with some other 4xx status because of another problem with the request. If so, this should be clarified, perhaps by rewording it as something like: The server MUST respond with 417 (Expectation Failed) if any of the expectations cannot be met or, if there are other problems with the request, some other 4xx status. If the thinking was/is that the SHOULD is to allow for 2068-compliant implementations then it should be changed - a 2068-complaint implementation may not be compliant with the Draft Standard, and that is OK. -- Scott Lawrence EmWeb Embedded Server <lawrence@agranat.com> Agranat Systems, Inc. Engineering http://www.agranat.com/
Received on Tuesday, 17 February 1998 14:01:53 UTC