[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 #24 from Jer Noble <jer.noble at apple.com> ---
(In reply to comment #23)
> (In reply to comment #20)
> 
> Hi Jer, thanks a lot for the reply! Clarify things a lot. A few questions
> though, still hoping we can find a way to fix this:
> 
> > This will only work for initial requests.  Subsequent requests (for
> > additional byte ranges, for sub-resources, or due to HTTP redirects) will
> > not come through this path, and will thus we will not get a chance to do a
> > CORS check on those requests.  
> 
> Do you mean subsequent requests will not reach code in
> MediaPlayerPrivateAVFoundationObjC, or CachedResourceLoader does not give us
> a chance to handle subsequent requests?

Well, there's a related problem I haven't mentioned: if you simply do the CORS check, and notify AVFoundation of the final URL (provided CORS passes), then AVFoundation will proceed to use that final URL for all new requests, and thus you won't get a chance to handle subsequent requests due to redirects, additional sub-resources, etc.  If you provide the data directly, you fall into a separate performance category:

The AVAssetResourceLoaderDelegate API was designed for on-disk resources which were not stored as files which AVFoundation could parse directly. E.g., database entries, UUEncoded e-mail attachments, etc.  So AVFoundation makes a lot of decisions about buffering, enqueueing load requests, etc. based on the assumption that the file is entirely available and exists locally (on disk). So doing the "bait-and-switch" with "mock-http://" breaks a lot of features, such as when the "canplaythrough" event fires, how much pre-buffering occurs, and more.

Looking more carefully at the patch, I see that is exactly the trap this approach falls into.

> Either way, if so, how did we handle this situation in other backends
> (namely GStreamer backend, as in
> https://bugs.webkit.org/show_bug.cgi?id=99037 )? Did we leave a loophole
> there?...

No I think this is a problem specific to AVFoundation.

> > Additionally, this path is only triggered for the HLS manifest load, but
> > requests for HLS media segments does not come through this API.
> 
> Is this caused by AVFoundation API? If so, that would be a blocker.

Yes it is.

> Thanks again for your time!

No problem. Rest assured we care very much about making this work in Safari.

-- 
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/20151210/45fa7f96/attachment.html>