- From: Jeffrey Mogul <mogul@pa.dec.com>
- Date: Wed, 11 Nov 98 13:36:22 PST
- To: Jim Gettys <jg@pa.dec.com>
- Cc: http-wg@hplb.hpl.hp.com
> In section 4.4 "Message Length", does the statement
> "If a Content-Length header field (section 14.13) is present, its
> decimal value in OCTETs represents both the entity-length and the
> transfer-length. The Content-Length header field MUST NOT be used
> if these two lengths are different (i.e., if a Transfer-Encoding
> header field is present)."
> mean that a receiver should ignore Content-Length, or a sender should
> not send it?
It means that the sender should not send it in the case of a
transfer encoded message, since the transfer-length is otherwise
encoded and would result in a contradiction in the lenth.
I don't see an obvious rewrite to make this more obvious. Unless
there is some concrete suggestion, I plan to leave this one alone.
"Use the Robustness Principle, Luke!"
It means both: it means that the sender MUST NOT send it
and that (in the event of a non-compliant sender) the receiver
MUST ignore it. I agree that the verb here ("be used") is
fuzzy.
So how about:
If a Content-Length header field (section 14.13) is present, its
decimal value in OCTETs represents both the entity-length and the
transfer-length. The Content-Length header field MUST NOT be sent
if these two lengths are different (i.e., if a Transfer-Encoding
header field is present). If a message is received with both a
Transfer-Encoding header field and a Content-Length header field,
the latter MUST be ignored.
Maybe a little more rigid than formally necessary, but I think
we need to take a strong stand against non-compliance in this
area (as we did with the Host header), or else we could end up
in a bad mess.
-Jeff
Received on Wednesday, 11 November 1998 13:39:15 UTC