- 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