Link: http://trac.tools.ietf.org/wg/httpbis/trac/ticket/133
Origin: http://lists.w3.org/Archives/Public/ietf-http-wg/2008JulSep/0511.html
Component: p5-range
Reported by A. Rothman:
The spec contradicts itself regarding the minimum number of parts in a multipart/byteranges response: On the one hand, "A response to a request for multiple ranges, whose result is a single range, MAY be sent as a multipart/byteranges media type with one part", while on the other hand, "The multipart/byteranges media type includes two or more parts". If a multipart/byteranges media type indeed must include two or more parts, the first statement makes for an illegal response. And if a one-part response is valid, then the second statement is incorrect.
Since the spec also mandates that a client requesting a single range must never receive a multipart/byteranges response, it seems like the intention was to make it possible for a client to support partial retrieval without having to implement multipart support at all, in which case it would have been more straightforward if the spec simply required all single-range responses to use Content-Range and not multipart/byteranges. For backwards compatibility, it can encourage/require multipart/byteranges recipients to properly handle single-part messages as well, which is very likely the case in existing implementations.
In any case, this contradiction should be fixed and the use cases clarified.
Proposed patch,
Fixed in [332]:
Resolve #133: multipart/byteranges can consist of a single part (closes #133).