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

["Law, Will" <[e-mail]>]

@Roger – re “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 is a good point however it still leaves open the question of what content-range header should be returned. Per the H2 spec (snippet below), the requirements of HTTP/1.1 Range Requests are carried forward under HTTP/2. These requirements RFC7233 state that the “the server generating the 206 response MUST generate a Content-Range header field,” and also that the byte-range must contain a last-byte-pos value and that a value of * can be used for an unknown total length of the object but it cannot be used for last-byte-pos. Since the last-byte-pos is not known in this case, we have the same problem with H2 that we have with H1.

The solution proposed by https://tools.ietf.org/html/rfc8673 would seem to work for H2 as well as it would for H1. Per this solution, the client should never make an open ended range request if it is expecting an aggregated response from a fixed offset. It should instead send a request with a very large number (9007199254740991 has been proposed in this thread) as the last-byte-pos in the range request. This would signal the server (or origin) to begin a response that starts at the requested offset and aggregates over time until the object is completely transferred.


https://tools.ietf.org/html/rfc7540#section-8


8. HTTP Message Exchanges

HTTP/2 is intended to be as compatible as possible with current uses
of HTTP. This means that, from the application perspective, the
features of the protocol are largely unchanged. To achieve this, all
request and response semantics are preserved, although the syntax of
conveying those semantics has changed.

Thus, the specification and requirements of HTTP/1.1 Semantics and
Content [RFC7231], Conditional Requests [RFC7232], Range Requests
[RFC7233], Caching [RFC7234], and Authentication [RFC7235] are
applicable to HTTP/2.

-Will

From: Roger Pantos <rpantos=[e-mail]>
Date: Wednesday, August 19, 2020 at 1:17 PM
To: "[e-mail]" <[e-mail]>
Subject: Re: [Hls-interest] LL-HLS: status-code expected in the response to the PRELOAD request




On Aug 17, 2020, at 4:30 PM, Law, Will <wilaw=[e-mail]<mailto: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.


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<https://urldefense.proofpoint.com/v2/url?u=https-3A__httpwg.org_specs_rfc7540.html-23HttpSequence&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=KkevKJerDHRF9WRs8nW8Ew&m=R-IP9-Hj--z3sXAZZX9rokMs5qnnChNcbFO4PLft4_M&s=QsYGd9vU3GGNCIKQjBOnvGSnXVh73OH0Kyi1KcPWpDw&e=>


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:

  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]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/hls-interest<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_hls-2Dinterest&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=KkevKJerDHRF9WRs8nW8Ew&m=R-IP9-Hj--z3sXAZZX9rokMs5qnnChNcbFO4PLft4_M&s=Yv0CtXmSurk_NBFYprpu4mN6giQ1RFARMSK8zxyR6Rg&e=>