Additional issues
It won't be possible to address one of the issues in the updates for https://github.com/aspnet/AspNetCore.Docs/issues/10214.
The following opportunities remain:
using statements as comments in the in-text code examples and at the tops of methods/classes shown from the sample app.QueueBackgroundWorkItem is on the backlog :point_right: https://github.com/aspnet/Extensions/issues/805KEEP AN :eye: ON https://github.com/aspnet/AspNetCore/issues/2711
⚠Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.
I am trying to make File Upload For Large Files work in my ASP.NET Core 3.0 Preview project. I followed the tutorial and I am running my project on localhost at the moment. After clicking on Upload button on the razor page, I get:
The SPA default page middleware could not return the default page '/index.html' because it was not found, and no other middleware handled the request.
Maybe the default VS template doesn't have all the necessary configuration in Startup.cs.
I saw that many developers reported this error before:
https://github.com/aspnet/JavaScriptServices/issues/1514
https://github.com/aspnet/AspNetCore/issues/5223
https://github.com/dotnet/core/issues/1803
It would be great if we the examples from github were updated, to have views with .razor extension and ASP.NET Core 3.0 structure:
WebApp.Client
WebApp.Server
WebApp.Shared
I saw the example https://github.com/aspnet/AspNetCore.Docs/blob/ad16f5e1da6c04fa4996ee67b513f2a90fa0d712/aspnetcore/mvc/models/file-uploads/sample/FileUploadSample/Views/Home/Index.cshtml
but I still don't know what is causing the above mentioned default page error.
Hello @nemtajo ... We don't have the staffing to work with projects. We only maintain documentation here. However, there are a _large number of updates_ on a PR that's in review now. You could take a look at the updates on the PR to see if they would help you. https://github.com/aspnet/AspNetCore.Docs/pull/12344
Otherwise, we recommend talking to devs on a support forum, such as Stack Overflow, or a support chat, such as Slack or Gitter. If you find a real bug in the framework, then open an issue with engineering to report it.
Just noticed the "Master issue" that originally referenced the issue this came from got closed, glad that these are still being looked at/considered though. I haven't forgotten about it, and look forward to documentation enhancements covering uploads!
@nickalbrecht The last round of the prior updates went in today on https://github.com/aspnet/AspNetCore.Docs/pull/14770, and those updates are live now, which include a 3.0 sample.
~Additional possible updates are being collected on ... https://github.com/aspnet/AspNetCore.Docs/issues/12285~ :smile: lol ... this issue duh ... it's been a long day. We'll use this issue to collect up a new set of possible enhancements. WRT to ETA on looking at this, I'm feeling that it will be for 2020. We're going to be working on 3.1 soon, and I think that's going to take precedence over this.
Good to know. I do think it's important to get some sort of documentation for theses items, some more than others. So I just want to make sure they are not dropped as things not having a high enough ROI for time spent getting them going, or something like that.
Actually, most of theses were carried over multiple times from comment you'd put on https://github.com/aspnet/AspNetCore.Docs/issues/4777#issuecomment-357405456 after a conversation we had on Slack. Few more months, and by Jan 2020 we'll hit 2 years for this one ;-)
I saw an tweet by Fowler the other day about playing with HTTP/3, no idea what potential topics that would bring beyond the original question of chunking and HTTP/2. 😅 But it's obviously still early days for HTTP/3 anyway.
@pranavkm Would you help me prioritize the following (High, Medium, Low, or Hold)?
[FileExtensions] attribute, which can be used to restrict what files can be uploaded. #139051) Sounds really useful. I'd put this at the top
2) @Tratcher, is this useful information for users to understand?
3) I'd put this at number 3
4) Pri 2.This would make sense to cover as part of the file uploads topic.
2. HTTP/2 apparently doesn't support chunked transfer encoding ... it goes to DATA frames. Should DATA frames coverage be explained/demoed?
Is there an existing chunked transfer encoding sample/explanation you're comparing this to? Chunked encoding and HTTP/2 data frames are wire level framing details, they end up having the same behavior. Any existing description could be generalized to cover both.
@Tratcher No, I'm merely asking about these at this point. Just need to know which items are candidates for enhancing the topic and what priority to apply to them. I understand your remark, so dropping that entry. Should a chunking approach/sample not ever be part of this topic (i.e., let blogs/forum post resources cover it)?
File chunking across multiple requests is a useful technique. Chunked encoding on a single request/response is a formatting detail unrelated the prior scenario. A sentence or two about using or excluding the Content-length header would be sufficient. E.g. Using a content-length header can make the message easier to inspect. When not using a content-length header the message format automatically falls back to transfer-encoding: chunked (or HTTP/2 data frames).
So based off of what you've mentioned regarding the difference between chunked uploads (just split into multiple upload operations), and chunked encoding, Which one is used in the StreamController for demonstrating streamed uploads in
https://github.com/aspnet/AspNetCore.Docs/blob/master/aspnetcore/mvc/models/file-uploads/samples/3.x/SampleApp/Controllers/StreamingController.cs
Is the behaviour of streaming an upload like that the same regardless of the protocol being HTTP/2 or 1.1? I only ask because at first glance it seems to be closer to the underlying details of the protocol than most file upload examples I've seen, and I want to make sure if HTTP/2 implementation details are truly irrelevant regardless of how someone tries to implement file uploading, or if at worst it becomes an edge case that is beyond the intended scope of the documentation and gets mentioned as a foot note saying as such. Or maybe that the reader may need to be aware of it if they are looking at going down that path.
Which one is used in the StreamController for demonstrating streamed uploads in
That shows a file upload on a single request. The request in that example could use Content-Length or Transfer-Encoding: chunked and the sample would behave the same.
Is the behaviour of streaming an upload like that the same regardless of the protocol being HTTP/2 or 1.1?
Yes. The wire formatting and some headers vary but the application visible behavior does not. E.g. the Transfer-Encoding: chunked header is not used in HTTP/2 but the sample continues to work the same because it doesn't need to check that header.
FYI the default nginx upload limit is 1 MB.
To change this for every site in a nginx configuration, edit the nginx.conf and add a 'client_max_body_size' entry to the http section. To edit it per-site, put the entry in the appropriate location section.
http://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size
Most helpful comment
That shows a file upload on a single request. The request in that example could use Content-Length or Transfer-Encoding: chunked and the sample would behave the same.
Yes. The wire formatting and some headers vary but the application visible behavior does not. E.g. the
Transfer-Encoding: chunkedheader is not used in HTTP/2 but the sample continues to work the same because it doesn't need to check that header.