Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

In .NET 9 preview 5 blazor WASM with chromium browsers, when using request streaming, HttpRequestException is thrown unexpectedly if a response is sent before the stream is fully sent to the server #104612

Closed
Gabriel123N opened this issue Jul 9, 2024 · 2 comments · Fixed by #105709
Assignees
Labels
arch-wasm WebAssembly architecture area-System.Net.Http in-pr There is an active PR which will close this issue when it is merged os-browser Browser variant of arch-wasm
Milestone

Comments

@Gabriel123N
Copy link

Gabriel123N commented Jul 9, 2024

Description

While trying the new SetBrowserRequestStreamingEnabled feature for ``HttpRequestMessage` in .NET9 Blazor WASM, I have noticed a blocking behaviour when returning non-success status code from my API calls while streaming something during the request.

Instead of returning a HttpResponseMessage that I can manipulate when returning non 2xx codes, the SendAsync method simply triggers a HttpRequestException.

After more tests, I have found that it is happening with any status code as long as the response is sent before the body is fully streamed to the server. I also believe this issue is only happening on Chromium browsers as Firefox is following the expected behaviour below.

Reproduction Steps

  • Pull the following repositoy: https://github.com/Gabriel123N/BlazorStreamingException
  • Start the server project and open the blazor app in your browser
  • Click on the input file element and choose a file smaller than 128 000Kb
  • Open the console. You should see the following line printed there Error message is "Bad request message returned"
  • Check-in the checkbox next to the input element
  • Click on the input element and choose a file again
  • A stack trace of the exception should be printed inside the console

Expected behavior

Like when request streaming is disabled, no exception is thrown and I can manipulate the response as wanted.

Actual behavior

An exception is thrown on the SendAsync method call.

Regression?

No response

Known Workarounds

The server must read the entirety of the body

Configuration

  • Microsoft.NETCore.App 9.0.0-preview.5.24306.7
  • Windows
  • x64
  • Chrome and Edge.

Other information

Most likely linked to a missing exception handling there #91699

If I change the post endpoint to the following code to make sure that the request stream is fully read, no exception is thrown.

app.MapPost("/api/test",async (HttpRequest request) =>
        {
            var ms = new MemoryStream();
            await request.Body.CopyToAsync(ms);
            await Task.Delay(1000);
            return Results.BadRequest("Bad request message returned");
        });

Stack trace:

Error: System.Net.Http.HttpRequestException: Error
 ---> Error
   --- End of inner exception stack trace ---
   at System.Net.Http.BrowserHttpInterop.CancellationHelper(Task promise, CancellationToken cancellationToken, JSObject jsController)
   at System.IO.Stream.<CopyToAsync>g__Core|27_0(Stream source, Stream destination, Int32 bufferSize, CancellationToken cancellationToken)
   at System.Net.Http.StreamToStreamCopy.<CopyAsync>g__DisposeSourceAsync|1_0(Task copyTask, Stream source)
   at System.Net.Http.HttpContent.<CopyToAsync>g__WaitAsync|56_0(ValueTask copyTask)
   at System.Net.Http.BrowserHttpController.CallFetch(upload)
   at Microsoft.Extensions.Http.Logging.LoggingHttpMessageHandler.<SendCoreAsync>g__Core|5_0(HttpRequestMessage request, Boolean useAsync, CancellationToken cancellationToken)
   at Microsoft.Extensions.Http.Logging.LoggingScopeHttpMessageHandler.<SendCoreAsync>g__Core|5_0(HttpRequestMessage request, Boolean useAsync, CancellationToken cancellationToken)
   at System.Net.Http.HttpClient.<SendAsync>g__Core|83_0(HttpRequestMessage request, HttpCompletionOption completionOption, CancellationTokenSource cts, Boolean disposeCts, CancellationTokenSource pendingRequestsCts, CancellationToken originalCancellationToken)
@dotnet-policy-service dotnet-policy-service bot added the untriaged New issue has not been triaged by the area owner label Jul 9, 2024
Copy link
Contributor

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

@rzikm rzikm added the arch-wasm WebAssembly architecture label Jul 10, 2024
@maraf
Copy link
Member

maraf commented Jul 10, 2024

cc @pavelsavara

@pavelsavara pavelsavara self-assigned this Jul 10, 2024
@pavelsavara pavelsavara added this to the 9.0.0 milestone Jul 10, 2024
@pavelsavara pavelsavara added os-browser Browser variant of arch-wasm and removed untriaged New issue has not been triaged by the area owner labels Jul 10, 2024
@dotnet-policy-service dotnet-policy-service bot added the in-pr There is an active PR which will close this issue when it is merged label Jul 31, 2024
@github-actions github-actions bot locked and limited conversation to collaborators Sep 7, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
arch-wasm WebAssembly architecture area-System.Net.Http in-pr There is an active PR which will close this issue when it is merged os-browser Browser variant of arch-wasm
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants