- From: Jim Gettys <jg@pa.dec.com>
- Date: 1998年11月11日 13:42:44 -0800
- To: Jeffrey Mogul <mogul@pa.dec.com>
- Cc: Jim Gettys <jg@pa.dec.com>, http-wg@hplb.hpl.hp.com
- Message-Id: <9811112142.AA25335@pachyderm.pa.dec.com>
> From: Jeffrey Mogul <mogul> > Date: Wed, 11 Nov 98 13:36:22 PST > To: jg@pa.dec.com (Jim Gettys) > Cc: http-wg@hplb.hpl.hp.com > Subject: 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. > Concrete suggestion gratefully accepted. My light saber is getting limp at this date on this spec... :-) - Jim
Received on Wednesday, 11 November 1998 13:47:02 UTC