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

[bugzilla-daemon at webkit.org]

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

riCompro <dev at ricompro.it> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WONTFIX                     |---

--- Comment #4 from riCompro <dev at ricompro.it> ---
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

-- 
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/20200502/32416b0d/attachment-0001.htm>