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

On 4/15/16, 2:24 PM, "Roy T. Fielding" <fielding@gbiv.com<mailto:fielding@gbiv.com>> wrote:

On Apr 15, 2016, at 1:00 PM, Craig Pratt <craig@ecaspia.com<mailto:craig@ecaspia.com>> 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/*

DT>> The issue we have is with specifying 1233 as the last-byte-pos since that will change as soon as it is set.






There is no need for another range unit.

....Roy