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

What you say is true, but you are only focusing on the *second half* of 
the Content-Range value, ignoring the *first half*.  Here is the full 
definition:

Content-Range = byte-content-range / other-content-range

byte-content-range = bytes-unit SP ( byte-range-resp / unsatisfied-range )

byte-range-resp = byte-range "/" ( complete-length / "*" )

byte-range = first-byte-pos "-" last-byte-pos

unsatisfied-range = "*/" complete-length

complete-length = 1*DIGIT

other-content-range = other-range-unit SP other-range-resp

other-range-resp = *CHAR

If the range is satisfied, the *complete-length* can be "*", but the 
*byte-range-resp* cannot be "*".

If the range is unsatisfied, the *byte-range-resp* must be "*", and the 
*complete-length* cannot be "*".

Remy Lebeau
Lebeau Software

On 4/15/2016 1:24 PM, Roy T. Fielding wrote:
> 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/*
>
> There is no need for another range unit.
>
> ....Roy
>