Opened 10 years ago

Closed 10 years ago

#133 closed design (fixed)

multipart/byteranges minimum number of parts

Reported by: julian.reschke@… Owned by:
Priority: Milestone: unassigned
Component: p5-range Severity: Active WG Document
Keywords: Cc:

Description

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.

Attachments (1)

133.diff (1.3 KB) - added by julian.reschke@… 10 years ago.
Proposed patch,

Download all attachments as: .zip

Change History (2)

Changed 10 years ago by julian.reschke@…

Proposed patch,

comment:1 Changed 10 years ago by julian.reschke@…

  • Resolution set to fixed
  • Status changed from new to closed

Fixed in [332]:

Resolve #133: multipart/byteranges can consist of a single part (closes #133).

Note: See TracTickets for help on using tickets.