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

[Remy Lebeau <[e-mail]>]

 > You mean response must contain content length?

Not a Content-Length header, no.  A "Transfer-Encoding: chunked" header 
can be used to represent an open-ended response.  But apparently the 
Content-Range response header can't be open-ended for a requested 
open-ended range.  It provides the requested first-byte-pos and the 
current last-byte-pos.  However, it can report an instance length of * 
to indicate the server does not know the full length of the entity being 
requested.

Remy Lebeau
Lebeau Software

On 4/15/2016 12:03 PM, Göran Eriksson AP wrote:
> Hi,
>
> Have a similar use case in a slightly different context. I find the draft
> and discussion useful.
>
> A few questions inline.
>
>
>
>> AFAICT, the existing ABNF for byte ranges *does* already support what you
>> are looking for, without having to introduce a new unit type:
>>
>>     byte-range-spec = first-byte-pos "-" [ last-byte-pos ]
>>
>> Simply omit the * and leave the second value empty:
>>     Range: bytes=1234567-
>>
>>
>>
>> RFC 2616 Section 14.35.1 says:
>>
>> "If the last-byte-pos value is absent, or if the value is greater than or
>> equal to the current length of the entity-body, last-byte-pos is taken to
>> be equal to one less than the current length of the entity- body in
>> bytes."
>>
>> <bhs> Yes the client can make an open-ended request. The problem is the
>> server has no means of providing an open-ended response.
>
> You mean response must contain content length?
>
>> RFC 7233 Section 2.1 says:
>>
>> "If the last-byte-pos value is absent, or if the value is greater than or
>> equal to the current length of the representation data, the byte range is
>> interpreted as the remainder of the representation (i.e., the server
>> replaces the value of last-byte-pos with
>> a value that is one less than the current length of the selected
>> representation)."
>>
>> <bhs> Correct. The server is required to provide an actual value for
>> last-byte-pos. And that value is based on the current length. If the
>> server is recording
>> the content from a live stream, whatever value the server provides will
>> no longer be the last byte almost as soon as the value is sent. The
>> actual endpoint is constantly increasing.
>>
>> Since the media is being recorded while streaming, the client can
>> randomly jump around within the recorded portion of the media all it
>> wants. Once jumped, it would simply be receiving media from the
>> recording, not the live feed.  To jump back to the live feed,
>> simply omit the "Range" header.
>>
>> <bhs> The use case is not one of the client recording the stream. It is
>> of the server recording the stream. Let me see if I can explain the use
>> case better.
>> The user is watching content on a client that is being streamed from a
>> server. The server is recording the content from a live stream.
>> The client has limited
>> memory and can only buffer about 15 seconds worth of content.
>> The user pauses watching the content and comes back after 1 minute to
>> resume. The client sends the server a request to provide content from the
>> paused byte position
>> to “-“.
>> The server is required to provide a response that has an actual last byte
>> value. The only last byte value the server has is the one for the precise
>> moment of
>> the request. After a minute, the server has a minute more of content but
>> has provided the client with the content up to that responded last byte.
> Isn’t the server providing the client with a new manifest with the latest
> ‘last byte’ every 15 seconds or so? Or are you after a solution where this
> approach is not used, instead with an “open request” in the request
> template?
>
> Would be good to know what kind of media player behaviour is assumed here,
> especially the manifest part of it.
>
>> Shouldn’t the server stop sending bytes once it gets to the value of its
>> responded last-byte-pos? Even though
>> it has now a whole lot more bytes and we know that the user just wants
>> to keep watching? Should the client be expected to make continual
>> requests to keep up with the ever-increasing endpoint?
>> The purpose of this proposal is to allow the server to provide an
>> open-ended response, so the server can send bytes that it didn’t have at
>> the time of the original
>> request.
>>
>> Barbara
>>