File uploads file size limitations

[guardrex]

Fixes #27680

Thanks @Kevin-Andrew! 🚀

Internal Review Topic (links to section)

• Remove the existing NOTE and replace it with a dedicated section on this subject.
• Pivot and version the content for Server vs. WASM and >=6.0 and <6.0 (for changes that occurred to lift the limit that only pertained to the InputFile component.
• Because BrowserHttpHandler is internal, it isn't in the API docs. Therefore, I'm going to code-fence it and supply the reference source link so that interested devs can track it down.

❓ ...

• Mackinnon/Pavel ... On one issue (dotnet/aspnetcore #31873), Javier recommended Streaming requests with the fetch API; however, on another issue (dotnet/aspnetcore #35899), he recommended HTTP Ranges. This PR currently only has the HTTP Ranges suggestion. Do you want me to swap that for streaming fetch API or add streaming fetch API as another alternative? I understand that it isn't available for Safari and FF yet, so I'd need to work that in and then have a follow-up issue on hold to revise it later.

• Pavel ... I specifically mention that devs can add a 👍 to the runtime issue (dotnet/runtime #36634) because it's merely marked "Future" at this time and you might have interest in gauging feedback for possibly placing it on the .NET 8 roadmap. Do you want me to strike the 👍 suggestion part of that and just leave the cross-link? I think at least the cross-link should be here because otherwise devs will think that the PU isn't aware of the problem/suggestion. I think we can curtail folks opening more issues on either the ASP.NET Core or runtime repos if we at least mention the issue. However, we can strike the 'you can add a 👍' part if you like.

Cross-references:

• Blazor Support Large File Uploads (dotnet/aspnetcore #33638)
• Net6P7: Blazor WASM can't upload large files (500MB, 1GB, 2GB) (dotnet/aspnetcore #35899)
• [Blazor] [WASM] Large File Upload Via Stream not Work as Expected + Memory Leak (dotnet/aspnetcore #31873)
• [browser][wasm] Request Streaming upload via http handler (dotnet/runtime #36634)

[guardrex]

@Kevin-Andrew ... Look again. On the latest commit, I seek to explain what happened back in 5.0 to help the reader understand what aspect was introducing the limit and when.

... and I'm adding one more NIT update. I may further revise before Monday. What I did this morning was tossed in very quickly (Hey! It's Saturday! 🤣). It's a bit rough in first draft state.

... and one more 😄 ... I must place my reference source NOTE in this. We link to the main branch, which is for the next .NET release. The NOTE explains that the reader can select their version from the GH dropdown when they go look at the ref source.

[guardrex]

@Kevin-Andrew ... I made updates to distinguish between read and upload.

[guardrex]

Do you want to drop the ...

where you can express your interest in the proposal by adding a thumbs-up (👍) to the issue's opening comment.

... suggestion? I actually think that's kind'a obvious these days.

I didn't know if that would be helpful to you in gauging interest or not.

[pavelsavara]

Do you want to drop the ...

where you can express your interest in the proposal by adding a thumbs-up (👍) to the issue's opening comment.

... suggestion? I actually think that's kind'a obvious these days.

I didn't know if that would be helpful to you in gauging interest or not.

Since we could not deliver it on all browsers yet I would not lure people.

[guardrex]

Yes ... I just killed both links. I think I'll keep a tracking item (not issue) on my .NET 8 tracking issue to see how it plays out and what needs to change here, if anything. UPDATE: Done! ... It's tracked now.

[pavelsavara]

LGTM

[guardrex]

Thx @pavelsavara! 🎸 ... I'll see if Mackinnon has any feedback on it before merging.

@danroth27 ... We eliminated the links to both issues. Now, it just says that a future runtime release may address this. I'm tracking via the .NET 8 docs tracking issue to see how it plays out later.

[danroth27]

@javiercn @SteveSandersonMS Is this the right recommendation givent he current level of browser support? Firefox and Safari don't support this yet, right? If you want to support all browsers I believe you need to do some sort of file chunking that you coordinate with the server, correct?

[SteveSandersonMS]

Not sure. Which specific browser support limitation are you referring to?

I see that WritableStream is usable on current Safari/Firefox. Is that sufficient for being able to do an arbitrary-length streaming upload, or is there some other limitation we face?

[pavelsavara]

FF and Safari don't support it yet. See dotnet/runtime#36634 (comment)

[guardrex]

Shall I comment-out the recommendation for now and open a tracking issue on the Safari and FF issues (and the following are just for positions) ...

• Fetch streaming upload WebKit/standards-positions#24
• fetch streaming upload mozilla/standards-positions#663

When I detect that Safari and FF have support, I can surface this sentence.

I have an existing tracking remark on my .NET 8 issue to keep an eye on runtime support. When that happens, I can remove all of the size limitation remarks for future versions of this content.

[guardrex]

I'm commenting-out the line for now and will revisit this line for the .NET 8 release ... and also to keep an 👁️ on Fetch streaming support for FF/Safari. This is tracked by my .NET 8 tracking issue.

[Kevin-Andrew]

@guardrex , thanks. On a side note, out of my own curiosity, when you merged this PR, did you do a Squash Merge? I looked at the main branch and it appears to only have one actual commit, versus the 15 that were done here.

[guardrex]

Squash for this PR, yes ... but for our merges to live, no ... not squashed.

One of things that that helps with you know is keeping the history lighter. It also gives us as doc authors the right amount of "credit" in terms of working here for management's tracking. We get the commit credit for the PR, not for all of the churn on a PR.