- From: Jeffrey Mogul <mogul@pa.dec.com>
- Date: Fri, 18 Jul 97 14:42:25 MDT
- To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Roy Fielding writes:
o An origin server SHOULD NOT send a 100 (Continue) response if
the request message does not include an "Expect" request-header
field with the "100-continue" expectation, and MUST NOT send a
100 (Continue) response if such a request comes from an HTTP/1.0
(or earlier) client.
No, this is not an appropriate use of SHOULD NOT. If we reference
the Bradner RFC, then we follow its rules, and one of them is that
we MUST NOT use the capitalized forms for things which are not
interoperability requirements.
If you are referring to RFC2119, it says:
6. Guidance in the use of these Imperatives
Imperatives of the type defined in this memo must be used with care
and sparingly. In particular, they MUST only be used where it is
actually required for interoperation or to limit behavior which has
potential for causing harm (e.g., limiting retransmisssions) For
example, they must not be used to try to impose a particular method
on implementors where the method is not required for
interoperability.
I suppose one could start a pointless argument about whether the
intention behind "potential for causing harm (e.g., limiting
retransmissions)" applies to "limiting the transmission of
unnecessary bytes over the network." I'll leave this decision
to the working group chair. Larry, if you ask me to remove this
SHOULD NOT, please say so.
o An origin server SHOULD NOT send a 100 (Continue) response if
has already received some or all of the request body for the
corresponding request.
Likewise, inappropriate. Recommendations should be presented as
recommendations, not as requirements.
I've rephrased this as:
o An origin server MAY omit a 100 (Continue) response if
has already received some or all of the request body for the
corresponding request.
-Jeff
Received on Friday, 18 July 1997 14:53:28 UTC