[Webkit-unassigned] [Bug 211323] Videos from certain CDNs not loading

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=211323

--- Comment #6 from riCompro <dev at ricompro.it> ---
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 <julian.reschke at greenbytes.de> 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 <fabian.thobe at ricompro.it> 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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20200503/84ad2691/attachment-0001.htm>