Bug 211323 – 200 (OK) response not accepted for range requests

• Component: Media
• Status: REOPENED

[riCompro]

Created attachment 398242 [details]
Example showing the issue of the video loading on Chrome but not on Safari

When using certain CDNs to serve content, videos are not displayed on Safari without throwing any console error but successfully rendered on Chrome. Nevertheless, a right click shows the option to download the video. 

Example: 
https://www.intexcorp.com/video-test/

<div class="container">
        <p>Through CDN</p>
        <video playsinline="" autoplay="" loop="" muted="">
            <source src="https://cdn11.bigcommerce.com/s-u7yn5f7nmq/content/videos/cover.mp4" type="video/mp4">
        </video>
        <p>Direct Path</p>
        <video playsinline="" autoplay="" loop="" muted="">
            <source src="https://www.intexcorp.com/content/videos/cover.mp4" type="video/mp4">
        </video>
</div>

[riCompro]

Created attachment 398243 [details]
HTML Example

[Radar WebKit Bug Importer]

<rdar://problem/62753586>

[Jer Noble]

This CDN does not support the Range: header:

```
> curl -r 0-1 -I 'https://cdn11.bigcommerce.com/s-u7yn5f7nmq/content/videos/cover.mp4'
HTTP/2 200 
server: openresty
content-type: video/mp4
etag: f3034a50b64f126cb4047022e00d71f7
last-modified: Mon, 16 Sep 2019 18:57:06 UTC
x-request-id: 69046b9547c909e4713d36f9056598d8
x-bc-is-ha: 1
date: Sat, 02 May 2020 04:55:06 GMT
x-ak-prop: stencil-store
x-is-akamai: 1
```

A server which supports range requests would return a 206 response with a Content-Range: response header.

Safari's media frameworks will do not support servers which themselves do not support range requests.

[riCompro]

Hi Jer & Simon, 

thank you so much for taking a look at this, even if I don't like the response :)

Please find below a comment on why I'd like to reopen this (even if I understand that perception on this issue varies): 

TL;DR
Accepting a 200 response is not uncommon across clients and I understand that the current method of handling such a response by not loading the media file has bandwidth and resource optimisation in mind and is designed to avoid unwanted consumption of traffic and client resources. Nevertheless it became best practice across clients to accept a 200 response given that in can pose a significant challenge in many environments to implement partial 206 responses server side. When writing the standard for range requests IETF saw that issue as RFC-7233 (see below) states clearly that servers are free to ignore Range requests therefor as a consequence the client should be prepared to render alternative responses. Given that in 2020 the negative user impact by not rending the content is in most cases much bigger than a graceful fallback by accepting a 200 response, you might consider making the appropriate changes. Please find below a reference of the web standard and some comments. 

Detailed Explanation

RFC-7233 states in a note in 4.4:

[...]
Because servers are free to ignore Range, many
implementations will simply respond with the entire selected
representation in a 200 (OK) response.  That is partly because
most clients are prepared to receive a 200 (OK) to complete the
task (albeit less efficiently) and partly because clients might
not stop making an invalid partial request until they have
received a complete representation.  Thus, clients cannot depend
on receiving a 416 (Range Not Satisfiable) response even when it
is most appropriate.
[...]

This note represents the entire problem and makes three assumptions: 
1) not all servers can provide a content range response
2) servers frequently fall back to 200 responses given the lack compatibility to a range request
3) clients usually gracefully fall back to accepting this response
4) the content provider determines if to honor a range request

Webkit, to my knowledge, is the only engine not accepting a 200 response and as much I agree that a partial delivery of the file would be the most efficient delivery, in times of external hosting via CDNs / cloud infrastructure, it is rather difficult to enforce such delivery on external hosting infrastructure.

Also it's worth assuming that some media is simply not heavy enough to warrant a partial response given that today's infrastructure has much more issues with latency than with bandwidth given that 3G / 4G is widely available. In case of video backgrounds for example the time needed to request multiple partials of a video is often more than the time needed to deliver the video itself. 

I am looking forward to your feedback. 

Thanks, 

Fabian

[riCompro]

Section of RFC-7233 mentioning client behavior if server does not support range requests: https://tools.ietf.org/html/rfc7233#section-4.4

[riCompro]

I mailed Julian Reschke, one of the three authors of RFC-7233: 

TL;DR
Correct behaviour would be to accept a 200 response as server side support of range requests is optional.

Please find the full reply below.  

On 3 May 2020, at 18:20, Julian Reschke <[e-mail]> wrote:

On 02.05.2020 15:14, Fabian Thobe wrote:
Hi Julian, Roy and Yves,
I hope this email finds you well and healthy in this strange times!
...

Yup.

First of all, I recommend to send questions like these to the HTTP WG's mailing list. That way it will be seen by all WG members, publicly archived, etc. (-> <https://lists.w3.org/Archives/Public/ietf-http-wg/>).

Regarding your question:

RFC 7233 clearly says that support for Range requests is optional. Thus, clients need to deal with this case (if they do not, I would consider that a bug). In particular, there's the important property of HTTP response messages being self-descriptive: the combination of status code (200 vs 206) and the Content-Range response header field gives the client all the information it needs.

Hope that helps,

Julian




On 2 May 2020, at 15:14, Fabian Thobe <[e-mail]> wrote:

Hi Julian, Roy and Yves,

I hope this email finds you well and healthy in this strange times!

First I want to thank you for your various IETF contributions, after I stumbled on the issue below I digged deeper and found a lot of your work. I think you, Roy and Yves did great work on RFC 7233 and plenty of other contributions. 

As an issue with Safari regarding Range requests came up I had some questions to you and your colleagues and I wanted to hear your opinion before trying to contribute anything, please keep in mind that what I write below is not the work of a software engineer so I am happy about any feedback I receive ;)

TL;DR
RFC-7233 currently offers only one possible response: HTTP status code 206 indicating a partially served content. Nevertheless plenty of CDNs do not serve partial responses but a response with Status Code 200 serving the content fully instead of partially. This response results in different outcomes across browsers: 

Behaviour 1: Rendering the File
the majority (Chrome, Firefox, Edge and Opera) digest the non standard response and render the response provided with status code 200

Behaviour 2: Not rendering the file and not throwing any error
Safari (iOS / mobile & desktop) do not render the file

To my understanding, range requests have been created to optimise usage of bandwidth of heavy files such as Videos or other large media files, but given that the implementation of partial file servings might pose a challenge on some web servers there should be a consideration of allowing a fallback to a status code 200 and fully serve the file.  

A note in RFC-7233 mentions this issue: 
[...]That is partly because most clients are prepared to receive a 200 (OK) to complete the
task (albeit less efficiently) and partly because clients might
not stop making an invalid partial request until they have
received a complete representation.[...]

Given that the industry moves more and more towards CDNs and externally managed hosting it, it has become much more difficult to enforce RFC compliant policies regarding the serving of files. RFC-7233 does cover this issue in the note, but does not live up to real life scenarios. A possibility would be to allow a 200 response as a fall back to cover all three scenarios: 

Content can be served Partially
206 Partial Content

Content can not be served at all
- 416 Content not Satisfiable

Content can be served at different conditions
- 200 OK

While I agree that this is not a great solution and not in the spirit of a range request, it seems a more desirable solution than fractioning the implementation of Range as currently done by Chromium based browsers and Webkit based browsers. 

I am looking forward to your thoughts. 

Best, 

Fabian 

Suggested Modifications

4.5 The 200 (OK) status code indicates that the server is not able to successfully fulfil a range request for the target resource but offers the full representation that includes the satisfiable ranges found in the request's Range header field (Section 3.1). In this case, the client shall stop requesting a partial representation and accept the full representation.

[riCompro]

Created attachment 398324 [details]
Email conversation with RFC-7233 Authors regarding 200 (OK) responses

Email conversation confirming assumption that a 200 (OK) response should be digested and rendered by a client if a partial response is not given.

[Noam Rosenthal]

See HTML PR: https://github.com/whatwg/html/pull/7782
and WPT: https://github.com/web-platform-tests/wpt/pull/33491

[Ahmad Saleem]

Added WPT test link mentioned in Comment 08 (also 'WPTImpact' tag) and added 'BrowserCompat' tag since only Safari is failing test.