unosquare / embedio

A tiny, cross-platform, module based web server for .NET
http://unosquare.github.io/embedio
Other
1.46k stars 176 forks source link

Intermittant empty responses #527

Closed captainjono closed 2 years ago

captainjono commented 3 years ago

Describe the bug

Im using this library across platform. I am getting this weird issue that occours on systems with many cores, from what i guess due to a multithread issue and maybe buffer corruption? It is causing intermittent but regular 404s.

i initally started out with a ZipFileProvider and had issues with current bugs MS Zip compression (hit known issues causing bad state type exceptions). Switched to DotNetZipLib and that improved the situation 1000%. But I still experienced this intermittent failure, and so i switched to extracting webcontent at runtime and use a FileProvider instead... Same issue. To reduce variables, manually override all response compression to always be none. Same issue..

The response is always EMPTY, NO EXCEPTIONS are generated, and no headers are set - happens on any type of request, not just files. Im at the stage of debugging into the lib internals and thought i would reach out for help. I fully expect im missing something simple (like a config flag) to cause this... Sorry in advance but i search around to no luck.

To Reproduce Here is the response corruption happening on Windows (ChromeEdge WebView2 latest), repoed by pressing Reload (each flash in the gif, is a reload, about ~6 in the animation). This page has ~150 assets of varying content-types. The more assets, the more likely a failure i found.

empty_response

   var server = new EmbedIO.WebServer(
                        opt => opt
                            .WithUrlPrefix(url)
                            .WithMode(HttpListenerMode.EmbedIO))
                    .WithModule(new CorsModule("/", "*", "*", "*"))
                    .WithModule(webApiModule)
                    .WithModule(new ActionModule("/common/error/logjavascripterror", HttpVerb.Any,
                        c =>
                        {
                            c.Response.Headers.Add("Access-Control-Allow-Origin", "*");
                            return new StreamReader(c.Request.InputStream).ReadToEndAsync().ContinueWith(_ => _.Result.LogDebug($"ERROR - {c.RequestedPath} {c.RemoteEndPoint}"));
                        }))
                    .HandleHttpException((context, exception) =>
                    {
                        "trace".LogError(exception);
                        return Task.CompletedTask;
                    })
                    .WithModule(indexhtmlFileModule)
    <PackageReference Include="EmbedIO" Version="3.4.3" />
    <PackageReference Include="Microsoft.Web.WebView2" Version="1.0.864.35" />
    <PackageReference Include="Zlib.Portable.Core" Version="1.0.0" />

Expected behavior The same response each time a request is made

Screenshots

Desktop (please complete the following information): -Win10 - NET5 + webview -macOS - Xamarin + wkebview

Smartphone (please complete the following information): -Android 9+ Xamarin + webview -iOS 14.0+ Xamarin + wkwebview

captainjono commented 3 years ago

Ok i think ive just realised im using 4.0-pre as its connected to master after i forked to update another unrelated aspect of the http pipeline to cator for my specific use-case. maybe this is a known issue and im just an early beta tester. Retesting now with 3.4.3 ...

captainjono commented 3 years ago

Ok so switching back to 3.4.3 has fixed the issue.

Im happy to help debug this on 4.0-pre if u wanted?

rdeago commented 3 years ago

Hello @captainjono, thanks for using EmbedIO and for taking the time to investigate this issue.

Some help in testing v4.0-pre would be great! Unfortunately, a bunch of unfinished (and rather complicated) changes has been sitting uncommitted on my PC for... much too long. As soon as I'm able to make the master branch somewhat stable, it will be my pleasure to contact you, hoping you'll still have some time to spare. Please join our Slack workspace so we can exchange messages without cluttering issues.

stale[bot] commented 2 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.