Re: Issue with "bytes" Range Unit and live streaming

[Darshak Thakore <[e-mail]>]

Oops, my earlier email got criss-crossed with this one.

On Apr 15, 2016, at 1:00 PM, Craig Pratt <[e-mail]<mailto:[e-mail]>> wrote:

[cp] Remy answered this: Content-Length is not expressly required (since that would prevent chunked and other transfer encodings). But the Content-Range header can only communicate a fixed response.

That is incorrect.  See RFC7233, Sec 4.2:


   For byte ranges, a sender SHOULD indicate the complete length of the
   representation from which the range has been extracted, unless the
   complete length is unknown or difficult to determine.  An asterisk
   character ("*") in place of the complete-length indicates that the
   representation length was unknown when the header field was
   generated.

   The following example illustrates when the complete length of the
   selected representation is known by the sender to be 1234 bytes:

     Content-Range: bytes 42-1233/1234

   and this second example illustrates when the complete length is
   unknown:

     Content-Range: bytes 42-1233/*


Oh, never mind, now I see that you are referring to the second number being fixed.

I think I would prefer that be solved by allowing last-byte-pos to be empty, just like
it is for the Range request.  I think such a fix is just as likely to be interoperable as
introducing a special range type (same failure cases).

DT>> We would be ok with that approach too. Our initial thought was that it would be more invasive (less acceptable) so we opted for suggesting an alternate unit. That way we don’t break existing clients and any client that desires the “open-ended last-byte-pos” feature could support the new unit.



....Roy