流大文件上传到ASP.NET MVC [英] Streaming large file uploads to ASP.NET MVC

问题描述

有关我工作的一个应用程序，我需要让用户上传非常大的文件 - 即，许多潜在的千兆字节 - 通过我们的网站。不幸的是，ASP.NET MVC似乎整个请求加载到RAM开始服务之前 - 不完全理想的这样的应用。值得注意的是，试图绕过通过code中的问题，如下列：

For an application I'm working on, I need to allow the user to upload very large files--i.e., potentially many gigabytes--via our website. Unfortunately, ASP.NET MVC appears to load the entire request into RAM before beginning to service it--not exactly ideal for such an application. Notably, trying to circumvent the issue via code such as the following:

if (request.Method == "POST")
{
    request.ContentLength = clientRequest.InputStream.Length;
    var rgbBody = new byte[32768];

    using (var requestStream = request.GetRequestStream())
    {
        int cbRead;
        while ((cbRead = clientRequest.InputStream.Read(rgbBody, 0, rgbBody.Length)) > 0)
        {
            fileStream.Write(rgbBody, 0, cbRead);
        }
    }
}

失败规避缓冲器的非请求到-RAM的心态。有没有一种简单的方法来解决此问题？

fails to circumvent the buffer-the-request-into-RAM mentality. Is there an easy way to work around this behavior?

推荐答案

原来，我最初的code是基本正确;唯一需要改变的是改变

It turns out that my initial code was basically correct; the only change required was to change

request.ContentLength = clientRequest.InputStream.Length;

到

request.ContentLength = clientRequest.ContentLength;

在确定内容长度整个请求前者流;后者仅仅是检查的Content-Length 头，只需要头已全部发送。这使得IIS能够几乎立即开始流的请求，这将完全取消原来的问题。

The former streams in the entire request to determine the content length; the latter merely checks the Content-Length header, which only requires that the headers have been sent in full. This allows IIS to begin streaming the request almost immediately, which completely eliminates the original problem.

这篇关于流大文件上传到ASP.NET MVC的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！