MicrosoftEdge / WebView2Feedback

Feedback and discussions about Microsoft Edge WebView2
https://aka.ms/webview2
449 stars 55 forks source link

Get response streams for all urls/GetContentAsync issue #2091

Open doskabouter opened 2 years ago

doskabouter commented 2 years ago

When setting the source to an url ending with .json I correctly get a get a CoreWebView2_WebResourceResponseReceived event, and awaiting e.Response.GetContentAsync() I can read the stream and get the json contents. However, when setting the source to an url ending with .m3u8 the resulting stream of GetContentAsync() is null and I'm greeted with a downloadbox (which apparently already downloaded the contents to my downloadfolder, so after my experiments I ended up with quite a lot of m3u8 files in it). Is there some setting so that all urls are treated equally, and neatly return a stream which I can read?

sample urls:

https://filesamples.com/samples/code/json/sample2.json https://multiplatform-f.akamaihd.net/i/multi/will/bunny/big_buck_bunny_,640x360_400,640x360_700,640x360_1000,950x540_1500,.f4v.csmil/master.m3u8;

AB#37968068

champnic commented 2 years ago

Hey @doskabouter - What's the behavior you get when you navigate to the .m3u8 sites in Chrome or the Microsoft Edge browser?

doskabouter commented 2 years ago

Don't have chrome overhere but in edge, the json is shown correctly, and the m3u8 is downloaded.

champnic commented 2 years ago

So the behavior is the same, but you'd just like to intercept the downloading and instead read the stream through the WebResourceRequested event, right?

We have a DownloadStarting event for intercepting downloads, but it only allows for changing the download location, and not reading the stream directly: https://docs.microsoft.com/en-us/dotnet/api/microsoft.web.webview2.core.corewebview2downloadstartingeventargs?view=webview2-dotnet-1.0.1072.54

As a workaround, could you detect .m3u8 files in the DownloadStarting event, save them to a temp location, and then read and open the file?

doskabouter commented 2 years ago

That is correct. I also know of the DownloadStarting event but that is quite a workaround. Especially since I have to use webview as a workaround already for the utter lack of support for modern tls/cipher combinations in the regular .Net HttpWebRequest.

And another thing: I don't know if the decision for webview to download it instead of having it accessible in the stream only depends on extension in the url, it might also depend on the returned mime-type which isn't available in the DownloadStarting event. Is there some list inside of the webview2 component which specifies which urls to stream and which to download? Perhaps it is also a solution if that list be made publicly available and modifiable

champnic commented 2 years ago

I don't think we currently support your scenario. I'm opening it as a feature request on our backlog. Thanks!