Re: [Hls-interest] LL-HLS: status-code expected in the response to the PRELOAD request

[Lucas Pardue <[e-mail]>]

Would RFC 8673 [1] fit the requirement here?

> To accommodate byte-range requests for content that has data appended
over time, this document defines semantics that allow an HTTP client and a
server to perform byte-range GET and HEAD requests that start at an
arbitrary byte offset within the representation and end at an indeterminate
offset.

[1] https://www.rfc-editor.org/rfc/rfc8673.html

On Tue, 18 Aug 2020, 00:30 Law, Will, <wilaw=[e-mail]>
wrote:

> Hello
>
>
>
> I am requesting a clarification on the expected server response status
> code when a client makes an open-ended range request against a media
> segment when playing back LL-HLS.  Consider the following media playlist
> snippet:
>
>
>
> #EXTINF:4.000,
>
> v1_1-7727.m4s
>
> #EXT-X-PROGRAM-DATE-TIME:2020-07-28T17:37:48.771Z
>
> #EXT-X-PART:DURATION=0.500,URI="v1_1-7728.m4s",BYTERANGE="64267@0
> ",INDEPENDENT=YES
>
> #EXT-X-PART:DURATION=0.500,URI="v1_1-7728.m4s",BYTERANGE="63033@64267"
>
> #EXT-X-PART:DURATION=0.500,URI="v1_1-7728.m4s",BYTERANGE="57810@127300"
>
> #EXT-X-PART:DURATION=0.500,URI="v1_1-7728.m4s",BYTERANGE="60558@185110"
>
> #EXT-X-PART:DURATION=0.500,URI="v1_1-7728.m4s",BYTERANGE="68575@245668"
>
> #EXT-X-PART:DURATION=0.500,URI="v1_1-7728.m4s",BYTERANGE="60880@314243"
>
> #EXT-X-PRELOAD-HINT:TYPE=PART,URI="v1_1-7728.m4s",BYTERANGE-START=375123
>
>
>
> To start-up, the client would issue 6 GET range-requests , starting at the
> independent part The server would respond with a 206 response for each and
> a content-range response header indicating the range being returned.
>
>
>
> The next request would be for the PRELOAD-HINT part. This would be a GET
> request with a “range: 375123-“. The client is indicating it wants to
> receive this object starting at offset 375123 and continuing to the end of
> the segment.
>
>
>
> How should the origin (or proxy server) respond to this PRELOAD request?
> Three possible options
>
>    1. It holds back any response until the end of segment, returning at
>    that time a 206 response with a content-range of 375123 – T/T+1 (where
>    represents total size of segment). This would ruin the low latency behavior
>    for the client.
>    2. It starts an immediate response, signaling 206 with content-range:
>    375123 - */*. This is actually forbidden by the RFC’s, which indicate that
>    the last-byte-pos cannot hold a value of “*”.
>    3. It starts an immediate response, signaling a 200 response and if
>    serving H1 to a proxy server which then serves H2 to the client, a
>    "Transfer-Encoding: chunked" response header.
>
>
>
> Option [3] looks to be the most correct however it raises the question of
>  whether a 200 response (chunked-transfer or not) implies to the client
> that is has received the complete object i.e starting at offset 0 instead
> of offset 375123. As a CDN, we need to build a behavior that is robustly
> supported by all HTTP clients and not just a particular class of
> application. The proxy-server cannot tell if is serving a LL-HLS client or
> some other client, therefore we need a consistent behavior when it is asked
> for an open-ended range request against an object of unknown size.
>
>
>
> So the questions are:
>
>    1. Is a 200 status-code expected in the response to the PRELOAD
>    request?
>    2. If so, are there other clients or applications on the internet that
>    would break if we did so for *all open-ended range requests against
>    objects of unknown size* (outside of the application space of LL-HLS)?
>
>
>
> Cheers
>
> Will
>
>
>
>
>
>
> --
> Hls-interest mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hls-interest
>