HttpWorkerRequest實現大檔案上傳asp.net

HttpWorkerRequest可以實現大檔案上傳
以前也做過檔案上傳，但都是些小檔案，不超過2M。這次要求上傳100M以上的東西。沒辦 法找來資料研究了一下。基於WEB的檔案上傳可以使用FTP和HTTP兩種協議，用FTP的話雖然傳輸穩定，但安全性是個嚴重的問題，而且FTP伺服器讀 使用者庫擷取許可權，這樣對於使用者使用來說還是不太方便。剩下只有HTTP。在HTTP中有3種方式，PUT、 WEBDAV、RFC1867，前2種方法不適合大檔案上傳，目前我們使用的web上傳都是基於 RFC1867標準的HTML中基於表單的檔案上傳。
一、先簡要介紹一下RFC1867（Form-based File Upload in HTML）標準：
1．帶有檔案提交功能的HTML表單
現 有的HTML規範為INPUT元素的TYPE屬性定義了八種可能的值，分別是：CHECKBOX, HIDDEN, IMAGE, PASSWORD, RADIO, RESET, SUBMIT, TEXT. 另外，當表單採用POST方式的時候，表單預設的具有"application/x-www-form-urlencoded" 的ENCTYPE屬性。
RFC1867標準對HTML做出了兩處修改：.....
.....
ASP.NET大檔案上傳解決方案
解 決的方法是利用隱含的HttpWorkerRequest，用它的 GetPreloadedEntityBody 和 ReadEntityBody方法從IIS為ASP.NET建立的pipe裡分塊讀取資料。Chris Hynes為我們提供了這樣的一個方案(用HttpModule)，該方案除了允許你上傳大檔案外，還能即時顯示上傳進度。
Lion.Web.UpLoadModule和AspnetUpload 兩個.NET組件都是利用的這個方案。
方案原理：
利用HttpHandler實現了類似於ISAPI Extention的功能，處理請求(Request)的資訊和發送響應(Response)。
方案要點：
1． httpHandler or HttpModule
a.在asp.net進程處理request請求之前截獲request對象
b.分塊讀取和寫入資料
c.即時跟蹤上傳進度更新meta資訊
2． 利用隱含的HttpWorkerRequest用它的GetPreloadedEntityBody 和 ReadEntityBody方法處理檔案流
IServiceProvider provider = (IServiceProvider) HttpContext.Current;
HttpWorkerRequest wr = (HttpWorkerRequest) provider.GetService(typeof(HttpWorkerRequest));
byte[] bs = wr.GetPreloadedEntityBody();
....
if (!wr.IsEntireEntityBodyIsPreloaded())
{
int n = 1024;
byte[] bs2 = new byte;
while (wr.ReadEntityBody(bs2,n) >0)
{
.....
}
}
3． 自訂Multipart MIME 解析器
自動截獲MIME分割符
將檔案分塊寫如臨時檔案
即時更新Appliaction 狀態（ReceivingData, Error, Complete）
/例子
HttpApplication application1 = sender as HttpApplication;
HttpWorkerRequest request1 = (HttpWorkerRequest) ((IServiceProvider) HttpContext.Current).GetService(typeof(HttpWorkerRequest));
try
{
if (application1.Context.Request.ContentType.IndexOf("multipart/form-data") <= -1)
{
return;
}
//Check The HasEntityBody
if (!request1.HasEntityBody())
{
return;
}
int num1 = 0;
TimeSpan span1 = DateTime.Now.Subtract(this.beginTime);
string text1 = application1.Context.Request.ContentType.ToLower();
byte[] buffer1 = Encoding.ASCII.GetBytes(("\r\n--" + text1.Substring(text1.IndexOf("boundary=") + 9)).ToCharArray());
int num2 = Convert.ToInt32(request1.GetKnownRequestHeader(11));
Progress progress1 = new Progress();
application1.Context.Items.Add("FileList", new Hashtable());
byte[] buffer2 = request1.GetPreloadedEntityBody();
num1 += buffer2.Length;
string text2 = this.AnalysePreloadedEntityBody(buffer2, "UploadGUID");
if (text2 != string.Empty)
{
application1.Context.Items.Add("LionSky_UpLoadModule_UploadGUID", text2);
}
bool flag1 = true;
if ((num2 > this.UpLoadFileLength()) && ((0 > span1.TotalHours) || (span1.TotalHours > 3)))
{
flag1 = false;
}
if ((0 > span1.TotalHours) || (span1.TotalHours > 3))
{
flag1 = false;
}
string text3 = this.AnalysePreloadedEntityBody(buffer2, "UploadFolder");
ArrayList list1 = new ArrayList();
RequestStream stream1 = new RequestStream(buffer2, buffer1, null, RequestStream.FileStatus.Close, RequestStream.ReadStatus.NoRead, text3, flag1, application1.Context, string.Empty);
list1.AddRange(stream1.ReadBody);
if (text2 != string.Empty)
{
progress1.FileLength = num2;
progress1.ReceivedLength = num1;
progress1.FileName = stream1.OriginalFileName;
progress1.FileCount = ((Hashtable) application1.Context.Items["FileList"]).Count;
application1.Application["_UploadGUID_" + text2] = progress1;
}

if (!request1.IsEntireEntityBodyIsPreloaded())
{
byte[] buffer4;
ArrayList list2;
int num3 = 204800;
byte[] buffer3 = new byte[num3];
while ((num2 - num1) >= num3)
{
if (!application1.Context.Response.IsClientConnected)
{
this.ClearApplication(application1);
}
num3 = request1.ReadEntityBody(buffer3, buffer3.Length);
num1 += num3;
list2 = stream1.ContentBody;
if (list2.Count > 0)
{
buffer4 = new byte[list2.Count + buffer3.Length];
list2.CopyTo(buffer4, 0);
buffer3.CopyTo(buffer4, list2.Count);
stream1 = new RequestStream(buffer4, buffer1, stream1.FileStream, stream1.FStatus, stream1.RStatus, text3, flag1, application1.Context, stream1.OriginalFileName);
}
else
{
stream1 = new RequestStream(buffer3, buffer1, stream1.FileStream, stream1.FStatus, stream1.RStatus, text3, flag1, application1.Context, stream1.OriginalFileName);
}
list1.AddRange(stream1.ReadBody);
if (text2 != string.Empty)
{
progress1.ReceivedLength = num1;
progress1.FileName = stream1.OriginalFileName;
progress1.FileCount = ((Hashtable) application1.Context.Items["FileList"]).Count;
application1.Application["_UploadGUID_" + text2] = progress1;
}
}
buffer3 = new byte[num2 - num1];
if (!application1.Context.Response.IsClientConnected && (stream1.FStatus == RequestStream.FileStatus.Open))
{
this.ClearApplication(application1);
}
num3 = request1.ReadEntityBody(buffer3, buffer3.Length);
list2 = stream1.ContentBody;
if (list2.Count > 0)
{
buffer4 = new byte[list2.Count + buffer3.Length];
list2.CopyTo(buffer4, 0);
buffer3.CopyTo(buffer4, list2.Count);
stream1 = new RequestStream(buffer4, buffer1, stream1.FileStream, stream1.FStatus, stream1.RStatus, text3, flag1, application1.Context, stream1.OriginalFileName);
}
else
{
stream1 = new RequestStream(buffer3, buffer1, stream1.FileStream, stream1.FStatus, stream1.RStatus, text3, flag1, application1.Context, stream1.OriginalFileName);
}
list1.AddRange(stream1.ReadBody);
if (text2 != string.Empty)
{
progress1.ReceivedLength = num1 + buffer3.Length;
progress1.FileName = stream1.OriginalFileName;
progress1.FileCount = ((Hashtable) application1.Context.Items["FileList"]).Count;
if (flag1)
{
progress1.UploadStatus = Progress.UploadStatusEnum.Uploaded;
}
else
{
application1.Application.Remove("_UploadGUID_" + text2);
}
}
}
byte[] buffer5 = new byte[list1.Count];
list1.CopyTo(buffer5);
this.PopulateRequestData(request1, buffer5);
}
catch (Exception exception1)
{
this.ClearApplication(application1);
throw exception1;

}

傳統方式上傳缺陷用戶端差異    用戶端只提交資料及檔案流， 看似應該沒有差別；可是IE和firefox有一個最大的不同點，就是IE上傳檔案不會增加用戶端記憶體佔用， 而firefox則要將檔案內容不斷地讀入記憶體中再發送，比如你使用firefox上傳100MB的檔案用戶端記憶體就會增加100MB的消耗， 很詫異firefox怎會有如此缺陷！
IIS伺服器處理檔案上傳  很顯然IIS處理檔案上傳時還是很謹慎的，在上傳過程中不會因為提交資料是大檔案而引起伺服器的記憶體消耗；所以，猜測IIS是在建立的Pipe讀取資料後 直接存到臨時檔案中。但是，很致命的一個問題那就是我們程式員要對上傳的檔案進行處理，及需要asp.net把真箇檔案流交給您來處理，最終結果就是 ASP.Net進程還是會把整個檔案內容載入記憶體交給你處理，例如Bitaec架構中就是此種情況。
  另外值得一提的就是ASP.NET中的FileUpload控制項，正如我上面分析的情況FileUpload上傳檔案時IIS不斷的從Pipe中讀取資料 並存入臨時檔案中，從而不會造成伺服器內容增加；當上傳完畢時，你直接調用FileUpload裡的SaveAs方法將檔案直接存入你需要的位置，實際上 所做的操作是將收到的臨時檔案移動你需要的位置，所以是不會增加消耗伺服器記憶體資源。但是，如果你需要對上傳的檔案流操作的話則會增加記憶體消耗，因為它需 要把臨時檔案重新載入到記憶體中。
大檔案上傳解決方案利用RFC1867標準處理檔案上傳的兩種方式：
1．一次性得到上傳的資料，然後分析處理。
看了N多代碼之後發現，目前無組件程式和一些COM組件都是使用Request.BinaryRead方法。一次性得到上傳的資料，然後分析處理。這就是為什麼上傳大檔案很慢的原因了，IIS逾時不說，就算幾百M檔案上去了，分析處理也得一陣子。
2．一邊接收檔案，一邊寫硬碟。

了 解了一下國外的商業組件，比較流行的有Power-Web，AspUpload,ActiveFile,ABCUpload, aspSmartUpload,SA-FileUp。其中比較優秀的是ASPUPLOAD和SA-FILE，他們號稱可以處理2G的檔案(SA-FILE EE版甚至沒有檔案大小的限制)，而且效率也是非常棒，難道程式設計語言的效率差這麼多?查了一些資料,覺得他們都是直接操作檔案流。這樣就不受檔案大小的制 約。但老外的東西也不是絕對完美，ASPUPLOAD處理大檔案後,記憶體佔用情況驚人。1G左右都是稀鬆平常。至於SA-FILE雖然是好東西但是破解難 尋。然後發現2款.NET上傳組件，Lion.Web.UpLoadModule和AspnetUpload也是操作檔案流。但是上傳速度和CPU佔用率 都不如老外的商業組件。
做了個測試，LAN內傳1G的檔案。ASPUPLOAD上傳速度平均是4.4M/s，CPU佔用10-15，記憶體佔用 700M。SA-FILE也差不多這樣。而AspnetUpload最快也只有1.5M/s，平均是700K/s，CPU佔用15-39，測試環境: PIII800,256M記憶體,100M LAN。我想AspnetUpload速度慢是可能因為一邊接收檔案，一邊寫硬碟。資源佔用低的代價就是降低傳輸速度。但也不得不佩服老外的程式，CPU 佔用如此之低.....

三、ASP.NET上傳檔案遇到的問題
我們在用ASP.NET上傳大檔案時都遇到過這樣或那樣的問題。 設定很大的maxRequestLength值並不能完全解決問題，因為ASP.NET會block直到把整個檔案載入記憶體後，再加以處理。實際上，如果 檔案很大的話，我們經常會見到Internet Explorer顯示 "The page cannot be displayed - Cannot find server or DNS Error"，好像是怎麼也catch不了這個錯誤。為什嗎？因為這是個client side錯誤，server side端的Application_Error是處理不到的。
四、ASP.NET大檔案上傳解決方案
解決 的方法是利用隱含的HttpWorkerRequest，用它的GetPreloadedEntityBody 和 ReadEntityBody方法從IIS為ASP.NET建立的pipe裡分塊讀取資料。Chris Hynes為我們提供了這樣的一個方案(用HttpModule)，該方案除了允許你上傳大檔案外，還能即時顯示上傳進度。
Lion.Web.UpLoadModule和AspnetUpload 兩個.NET組件都是利用的這個方案。

解決的方法是利用隱含的HttpWorkerRequest，用它的GetPreloadedEntityBody 和 ReadEntityBody方法從IIS為ASP.NET建立的pipe裡分塊讀取資料
  IServiceProvider provider = (IServiceProvider) HttpContext.Current;
  HttpWorkerRequest wr = (HttpWorkerRequest) provider.GetService(typeof(HttpWorkerRequest));
  byte[] bs = wr.GetPreloadedEntityBody();
  ....
  if (!wr.IsEntireEntityBodyIsPreloaded())
  {
        int n = 1024;
        byte[] bs2 = new byte[n];
        while (wr.ReadEntityBody(bs2,n) >0)
      {
            .....
        }
  }

  上傳大檔案，有好幾種方法：
  1、HttpWorkerRequest方法
  2、利用第三方的控制項 AspNetUpload 要錢！！算了，咱還是喜歡免費的。
  3、修改web.config檔案，但是不能捕獲錯誤。
  4、通過ftp的方式上傳。伺服器需要提供ftp服務。
 

第三種方： 
  修改Webcong檔案:
  <system.web>
  <httpRuntime maxRequestLength="40690"
  useFullyQualifiedRedirectUrl="true"
  executi
  useFullyQualifiedRedirectUrl="false"
  minFreeThreads="8"
  minLocalRequestFreeThreads="4"
  appRequestQueueLimit="100"
  enableVersi
  />
  </system.web>
 
  其中與上傳有密切關係的是：
  maxRequestLength
  指示 ASP.NET 支援的最大檔案上傳大小。
  該限制可用於防止因使用者將大量檔案傳遞到該伺服器而導致的拒絕服務的攻擊。
  指定的大小以 KB 為單位。
  預設值為 4096 KB (4 MB)。
 
  executionTimeout
  指示在被 ASP.NET 自動關閉前，允許執行請求的最大秒數。
  單位為秒，在上傳大的檔案時把這個設的大一些。
 
 
  如果伺服器記憶體512M,已可上傳大小160M的檔案。(沒試過，csdn上眾文章的一致意見。)
  'www.knowsky.com
  到這裡web.config的設定就已經結束。
  可是一旦上傳檔案的大小超過了這個設定的檔案大小範圍就會發生如下錯誤：
  該頁無法顯示
  您要查看的頁當前不可用。網站可能遇到技術問題，或者您需要調整瀏覽器設定。
 
  雖然解決不了，那也要捕獲這個錯誤啊！怎麼辦呢？
  最近吃了幾條魚，想了想，由於這個錯誤是由file控制項引發的前台錯誤，所以在後台想利用try...catch來捕獲是行不通的。
  於是想到了利用.NET的錯誤捕獲頁面的機制來處理。可行哦。
 
  1、先設定web.config
  <customErrors mode="On"/>
  2、建立一個error.aspx 檔案，專門用來捕獲錯誤的。
  3、在上傳檔案的aspx頁面的前台頁面裡添加page指令。ErrorPage="UploadError.aspx"
  4、在error.aspx中添加一些代碼來判斷錯誤資訊是否是file引起的前台錯誤。
  public class UploadError : System.Web.UI.Page
  {
  private void Page_Load(object sender, System.EventArgs e)
  {
  Exception ex = Server.GetLastError();
  if (ex != null)
  {
  Response.Redirect("../error.aspx");
  }
  else //前台錯誤ex為空白值
  {
  Response.Redirect("uploadexcel.aspx?err=1"); //重新跳轉到上傳頁面，加上err參數是為了顯示錯誤資訊
  }
  }
 
  5、顯示錯誤提示。
  public class uploadexcel : System.Web.UI.Page
  {
  private void Page_Load(object sender, System.EventArgs e)
  {
  if (Request["err"] == "1")
  {
  Page.RegisterStartupScript("budget","<script language = javascript>alert('Upload file has failed ! File size is too large !')</script>");
  }
  }
  }