Re: HTTP 1.1 issue 07: 4.4 Message Length

    > 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