Request Streaming upload

[guardrex]

Fixes #33692

Notes ...

• Tested working 🎉🍻 with ...
  • BWA (Interactive WebAssembly rendered component to server project)
  • Standalone Blazor WebAssembly app to a web API.
• Eventually, a fully working demo for both BWA and WASM/web API will be be placed into sample apps for easy demo by users. I've made a tracking note to address it later.

BIG ❓❓❓...

My understanding is that request streaming gracefully degrades when any of the following conditions fail:

• Chromium-based browser
• HTTP/2
• CORS (preflight must succeed)
• HTTPS

However ...

For a Safari/FF user and a large file upload, this current guidance is going to 💥. There are two obvious scenarios to consider if the user agent were detected as non-Chromium browser:

1. Stop or warn the user on trying to upload a large file.
2. Don't post with multipart body. Take Javier's advice and set up the component to use HTTP Ranges. We've said to do that in large file upload scenarios but never actually showed how to do it.

Adopting either approach, tell me if checking the user agent via JS interop is the right way to go. I mean there's nothing else available via API that I can check to determine if it's a non-Chromium browser, correct?

Then, tell me which of those you prefer ... merely warning a user (or stopping them from uploading a large file) or upgrade this guidance to use HTTP Ranges?

If we're going with HTTP Ranges, do you want me 🦖 to try and hack it up 🙈 ... or do you want a real programmer to do it (i.e., Mackinnon/Javier/Steve)?

... and one more related ❓ ...

This is CSR right now for the BWA side ... Interactive WASM ... no IsBrowser check and no alternative processing required in this section/demo. Up to this point, I was just trying to get it working in the CSR case for the CSR section. I haven't delved into Auto rendering yet. Do you want me to get into that scenario? If so, 🤔 I suppose the component could take a services-based approach for server vs. client uploading ... is that the right direction?

---

Internal previews

📄 File	🔗 Preview link
aspnetcore/blazor/file-uploads.md	ASP.NET Core Blazor file uploads

[guardrex]

@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.

[pavelsavara]

It should be there. Which sample code ?

[guardrex]

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.

[guardrex]

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.

[pavelsavara]

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);

[guardrex]

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.

[guardrex]

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

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

[pavelsavara]

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

[guardrex]

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."
  ]

[pavelsavara]

"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

[pavelsavara]

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

[guardrex]

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.

[guardrex]

Lick'd IT! 🍻🕺💃🎉

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

[guardrex]

@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.