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

On Apr 15, 2016, at 1:24 PM, Roy T. Fielding <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/*

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).

....Roy