[Webkit-unassigned] [Bug 135379] iOS 8 / OSX 10.10 WebGL - using a video from an other domain fails (CORS bug)

[bugzilla-daemon at webkit.org]

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

--- Comment #19 from Tong Shen <endlessroad at google.com> ---
Hey guys,

Put together a proof of concept patch for this. Verified on OSX 10.11, the demo works in MiniBrowser. Hooray!

Is there any reviewer willing to look at this? I know very little about Webkit (never hacked on Webkit before), so let's evaluate the approach first. If it's OK, then we move on to coding style/webkit details/reusing previous GStreamer code.

Thank you very much :D

=== TL;DR ===

The following is implementation detail of the proof of concept patch.

AVAssetResourceLoader only calls its delegate when the AVURLAsset does not start with http or https. Also, it does not handle CORS check.

So, the situation leaves us 3 possible solutions:

1. do not use AVFoundation APIs. Well that does not seems like the right way to go.

2. wait for AVFoundation to handle CORS check. I personally do not want to wait. Besides, AVFoundation API is for general purpose Internet media resource loading (not limited to web browsers), while CORS checking is a very specific use case in web browsers. For this reason, I think we should handle CORS on Webkit side instead of AVFounation side. We already have mature and well-tested code for CORS, right?

3. hack into AVFoundation API, perform the CORS check somewhere in the progress.

This patch uses approach 3. Implementation is a little hacky.

- We replace http/https URLs with mock protocols mock-http/mock-https, so AVAssetResourceLoader will call our delegate
- In the delegate, use CachedResourceLoader to get response, perform CORS check.
- If CORS check passes, fill response data into the original AVAssetResourceLoadingRequest.

Except for the first step, the latter 2 steps look exactly like what we did for GStreamer backend: http://trac.webkit.org/changeset/167073/ , which is another reason I am happy about it.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20151209/83f0c7f7/attachment-0001.html>