[Webkit-unassigned] [Bug 184447] mp4 video element broken with service worker

[bugzilla-daemon at webkit.org]

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

Jun Kokatsu <s.h.h.n.j.k at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |s.h.h.n.j.k at gmail.com

--- Comment #4 from Jun Kokatsu <s.h.h.n.j.k at gmail.com> ---
(In reply to youenn fablet from comment #2)
> Thanks for the report.
> Here is some info that currently explains the behavior:
> 
> Video loading usually happens as follow in Mac/iOS:
> - WebKit will do a 0-1 byte range request and expect a 206 with 2 bytes as a
> response
> - Based on the response, it will do loading or not with additional range
> requests.
> 
> When going through the service worker, the service worker needs to handle
> range request properly. The sw.js script is not doing that so cache API will
> probably not provide the expected results.
> 
> When service worker intercepts video loads, we have the following behavior:
> - MediaResourceLoader sends a request with various headers, include
> byte-range and several other headers
> - Service Worker receives a fetch event
> - self.fetch() is used on the request of the fetch event
> At that point, the fetch event request has all headers and self.fetch will
> create a new request based on it.
> Since the load is in no-cors mode, we use RequestNoCors header filtering
> mode, which then filters out all MediaResourceLoader specific headers.
> We then do the load, get a 200 response and not a 206 due to the filtered
> out headers.
> We send it to MediaResourceLoader which actually decides it will not play
> the video.
> 
> In the short term, the best approach would be to make the script not
> intercept cross-origin byte-range/video requests.
> Or handle all range requests in scripts and not rely on fetch/servers to do
> it.
> 
> Even if we would somehow all fetch to use all headers (might be ok since the
> script did not touch any of them),
> we would probably need to beef up the Cache API to cache range requests, or
> the script would need to do the handling by itself, probably using synthetic
> responses, which is basically back to let the script handle every range
> request.
> 
> Another approach would be to change the way we handle response checking in
> our media resource loading code path.

This doesn't work with Same-Origin audio/video file.

PoC
https://test.shhnjk.com/media_test.html

-- 
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/20180416/357b2183/attachment.html>