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

[Roger Pantos <[e-mail]>]

> On Aug 17, 2020, at 4:30 PM, 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
> 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.
> 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 “*”. 
> 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. 
>  

Note that when using H2 (or H3) that there is a fourth option, which is to return 206 and not supply any Content-Length header at all. This (I believe) became the expected behavior when HTTP/2 removed support for chunked transfer encoding: https://httpwg.org/specs/rfc7540.html#HttpSequence


Roger Pantos
Apple Inc. 

> 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:
> Is a 200 status-code expected in the response to the PRELOAD request?
> 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] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/hls-interest <https://www.ietf.org/mailman/listinfo/hls-interest>