new issue: 206-CONTENT-LENGTH[Was: comments on HTTP/1.1 Rev02 20Feb98]

Dave Kristol writes:
    2) 10.2.7, 206 Partial Content
    "... the Content-Length header field in the response MUST match..."

    Is there some reason why the entity couldn't be sent with chunked
    transfer coding instead and *without* a Content-Length?

    It wasn't clear to me, until sect. 19.6.3, that a server could
    *limit* itself to sending these headers in response to If-Range.
    Could we make that clearer?

I probably should have caught this when I was cleaning up the other
stuff related to Content-Length.

Proposed resolution:

Change this:

  .  Either a Content-Range header field (section 14.16) indicating the
     range included with this response, or a multipart/byteranges
     Content-Type including Content-Range fields for each part. If
     multipart/byteranges is not used, the Content-Length header field
     in the response MUST match the actual number of OCTETs transmitted
     in the message-body.

to this:

  .  Either a Content-Range header field (section 14.16) indicating the
     range included with this response, or a multipart/byteranges
     Content-Type including Content-Range fields for each part. If
|    a Content-Length header field is present in the response, its value
|    MUST match the actual number of OCTETs transmitted
     in the message-body.

-Jeff

P.S.: it's not clear to me why this says "OCTETs" instead of "octets".
"OCTET" is a non-terminal in the BNF, but both forms are used in
non-BNF contexts in the current draft.