@pavelsavara ... Do you know if dotnet/runtime#91699 has made it into the latest SDK that I think I can get, which is 9.0.100-rc.2.24474.4?

I'm still hitting the out of memory error with large file uploads using our published example code under the public RC1 release (9.0.0-rc.1.24431.7), which I think will work (in Edge) if I get the SDK that has dotnet/runtime#91699 in it.

It should be there. Which sample code ?

This ...

https://learn.microsoft.com/en-us/aspnet/core/blazor/file-uploads?view=aspnetcore-8.0#upload-files-to-a-server-with-client-side-rendering-csr

There are two spots that we'll need coverage ...

• In the File Uploads article, which is on the PR in draft form. The question is if request streaming will ✨ Just Work!™ ✨ without code changes to the FileUpload2 component IF they're using a Chromium browser? If request streaming isn't available (Safari/FF), doesn't request streaming gracefully fall back? ... noting that we never maintained content on Javier's suggestion to developers looking for client-side large file uploads to create a custom HTTP Ranges-based file upload component. We say that's what to do, but we never showed an example of it. I wonder if we need to show how to use HTTP Ranges in case request streaming isn't available?
• We also need coverage in the Call web API article, which I'm working on now locally (i.e., it isn't on the PR yet). There, I'll be adding a section and describing the SetBrowserRequestStreamingEnabled extension method for HttpRequestMessage.

If the FileUpload2 component IS going to change, then I'll need the updated component to place in versioned content. Can you (or someone) send me the new component to replace it for >=9.0?

UPDATE: Nevermind on that! I have the code generally working, so I'll float what I have on the PR for review.

I also have a side question WRT the LazyBrowserFileStream part that @MackinnonBuck provided ... Mackinnon ... is that to be versioned OUT 🔪 at >=9.0? IIRC, it was a temporary workaround that can go away at 9.0. That's what the comments that I left for myself in the article seem to indicate. It looks like we'll carry the LazyBrowserFileStream approach <9.0 and version it out >=9.0 in favor of just a stream.

Something like below will enable that for Chrome/Edge.

var webAssemblyEnableStreamingRequestKey = new HttpRequestOptionsKey<bool>("WebAssemblyEnableStreamingRequest");
var req = new HttpRequestMessage(HttpMethod.Post, url);
req.Options.Set(webAssemblyEnableStreamingRequestKey, true);

So, you're saying that we'll have to move away from an HttpClient.PostAsync(string, HttpContent) to a HttpClient.SendAsync(HttpRequestMessage) ... that's going to be a firm requirement for it to work?

The reason that I thought the code wouldn't need to change is that I thought the inner workings of HttpClient.PostAsync would perform the checks for HTTP/2 and IsBrowser and automatically set the streaming request key ... that it would do internal magic ✨ to make streaming requests work. I guess you're saying that's not the case.

I have a local test environment here for this. I'll refactor it into an HttpClient.SendAsync(HttpRequestMessage) approach to see if I can get it working. I'll report back in a bit how it went.

Can't I just do it this way? ...

var req = new HttpRequestMessage(HttpMethod.Post, "/Filesave");
req.SetBrowserRequestStreamingEnabled(true);

My point was to use the WebAssemblyEnableStreamingRequest option, not how to set it.

Latest code is ...

var req = new HttpRequestMessage(HttpMethod.Post, "/Filesave");
req.SetBrowserRequestStreamingEnabled(true);
req.Version = HttpVersion.Version20;
req.Content = content;
var response = await Http.SendAsync(req);

Works for small files, but for a 1 GB file, I'm getting a Kestrel(?) exception ...

"type": "https://tools.ietf.org/html/rfc9110#section-15.5.1",
"title": "One or more validation errors occurred.",
"status": 400,
"errors": {
  "": [
    "Failed to read the request form. Request body too large. The max request body size is 30000000 bytes."
  ]

"Failed to read the request form. Request body too large. The max request body size is 30000000 bytes."

That's actually server side error. Try setting MaxRequestBodySize on your server

req.Version = HttpVersion.Version20; is not necessary, doesn't do anything.

I hit another limit on the server ...

"Failed to read the request form. Multipart body length limit 134217728 exceeded."

I'll see about extending that one.

Lick'd IT! 🍻🕺💃🎉

Ok ... I'll get this all into the PR. I'll ping for reviews Wednesday when it's all in place.

@danroth27 @mkArtakMSFT @pavelsavara @maraf ... See the NOTES that I just added to the opening comment ☝️.

This is ready for a look and discussion on next steps.

@danroth27 ... I'll react to your decisions in the morning.

@lewing @pavelsavara @javiercn ... If you need to open an issue, please open it from the bottom of this article ...

https://learn.microsoft.com/en-us/aspnet/core/blazor/file-uploads?view=aspnetcore-9.0#additional-resources

@danroth27 ... Based on your remarks earlier about not cross-linking the PU discussions on this, I simplified the File size read and upload limits section down to just ...

:::moniker range=">= aspnetcore-9.0"

For Chromium-based browsers (for example, Google Chrome and Microsoft Edge) using the HTTP/2 protocol, HTTPS, and [CORS](xref:security/cors), client-side Blazor supports using the [Streams API](https://developer.mozilla.org/docs/Web/API/Streams_API) to permit uploading large files with [request streaming](xref:blazor/call-web-api#client-side-request-streaming).

Without a Chromium browser, HTTP/2 protocol, or HTTPS, client-side Blazor reads the file's bytes into a single JavaScript array buffer when marshaling the data from JavaScript to C#, which is limited to 2 GB or to the device's available memory. Large file uploads may fail for client-side uploads using the <xref:Microsoft.AspNetCore.Components.Forms.InputFile> component.

:::moniker-end

:::moniker range="< aspnetcore-9.0"

Client-side Blazor reads the file's bytes into a single JavaScript array buffer when marshaling the data from JavaScript to C#, which is limited to 2 GB or to the device's available memory. Large file uploads may fail for client-side uploads using the <xref:Microsoft.AspNetCore.Components.Forms.InputFile> component. We recommend adopting [request streaming](xref:blazor/call-web-api?view=aspnetcore-9.0&preserve-view=true#client-side-request-streaming) with ASP.NET Core 9.0 or later.

:::moniker-end

Otherwise, there are no changes for the other two items ...

• 'do nothing outside of just letting readers know that this feature is only supported for Chromium browsers at this time'
• 'trying to document how to deal specifically with the auto render mode'