Re: Rev81: byte range inconsistencies

    1) 10.2.7 206 Partial Request
    is worded to apply only to responses that contain a *single* byte
    range, and a Content-Range header.  ("The response MUST include a
    Content-Range header....")  Does that mean I should use 200 (OK) for
    responses with multiple byte ranges?
    
No, I think the description of 206 needs adjusting.  Instead of
    The server has fulfilled the partial GET request for the resource. The
    request must have included a Range header field (section 14.36)
    indicating the desired range. The response MUST include a Content-Range
    header field (section 14.17) indicating the range included with this
    response. The Content-Length header field in the response MUST match the
    actual number of OCTETs transmitted in the message-body.
it should say
    The server has fulfilled the partial GET request for the resource. The
    request must have included a Range header field (section 14.36)
    indicating the desired range. The response MUST include either a
    Content-Range
    header field (section 14.17) 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.

I think this was the intent of the byte-range draft all along.

    2) 19.2 MIME multipart/byteranges Content-type
    b) The words ("...includes two or more parts...") imply that
    multipart/byteranges cannot be used to send just a single byterange.

This is a little trickier.  If the client is not able to part
the multipart/byteranges Content-type, it can avoid receiving such
a response simply by never requesting multiple ranges (under the
current wording).  If we make your suggested change:
    2) multipart/byteranges can be used to send just a single range.
then we have to insist that any client using Range has to implement
multipart/byteranges.

Note that Netscape's current practice, according to Lou Montulli,
is to use multipart/byteranges *only* for multiple-part responses.
    
    3) 14.17 Content-Range
    The words here (and in 19.2) say "... multiple non-overlapping ranges...".
    That implies that a server
	    a) will detect and coalesce overlapping ranges in Range.
	    b) will use multipart/byteranges only when it sends more than
		    one distinct range.
    
Actually, that term is used only in sentences that begin "for example"
and is not normative.  I think there is nothing in the spec that
requires or prevents coalescing, and I think it should stay that
way.  I would certainly expect coalescing to be a slightly
more efficient use of network resources, but perhaps not of server
resources.

-Jeff

Received on Monday, 3 June 1996 14:31:42 UTC