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

[Göran Eriksson AP <[e-mail]>]

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
>