Ticket #133 (closed design: fixed)
multipart/byteranges minimum number of parts
|Reported by:||firstname.lastname@example.org||Owned by:|
|Component:||p5-range||Severity:||Active WG Document|
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.