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

Hi Will,

Not sure it's exactly applicable to your use case, but does this help?
  https://tools.ietf.org/html/rfc8673#section-2.2

Cheers,

> On 18 Aug 2020, at 9:30 am, Law, Will <wilaw=40akamai.com@dmarc.ietf.org> 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. 
>  
> 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
> Hls-interest@ietf.org
> https://www.ietf.org/mailman/listinfo/hls-interest

--
Mark Nottingham   https://www.mnot.net/