如何調試損壞的zip文件生成？

Question

我們有一個網頁抓取url的一系列字符串，找到與這些字符串相關的一些pdf，使用DotNetZip將它們拉上來，然後將它們返回給用戶。執行此頁面很簡單 - 這裏的Page_Load中：

protected void Page_Load(object sender, EventArgs e) 
{ 
    string[] fileNames = Request.QueryString["requests"].Split(','); 
    Response.Clear(); 
    Response.ClearHeaders(); 
    Response.ContentType = "application/zip"; 
    string archiveName = String.Format("MsdsRequest-{0}.zip", DateTime.Now.ToString("yyyy-mm-dd-HHmmss")); 
    Response.AddHeader("Content-Disposition", "attachment; filename=\"" + archiveName + "\""); 

    using (ZipFile zip = new ZipFile()) 
    { 
     foreach (string fileName in fileNames) 
     { 
      zip.AddFile(String.Format(SiteSettings.PdfPath + "{0}.pdf", msdsFileName), ""); 
     } 
     zip.Save(Response.OutputStream); 
    } 
    Response.Flush(); 
} 

（你問之前，這將是很好，如果有人把其他值在此網址......這些都不是安全的文件。）

這適用於我的開發框。但是，在我們的QA系統上進行測試時，它會下載壓縮文件，但它已損壞。沒有錯誤被引發，並且事件日誌中沒有記錄任何內容。

我可能有可能找到一種在QA環境中交互式調試的方法，但由於沒有任何事情會因拋出錯誤而失敗（比如如果沒有找到dll等），並且它已成功生成一個非空（但損壞）的壓縮文件，我想我不會通過逐步發現很多東西。

是否有可能這是Web服務器通過某種方式「修復」文件「幫助」我的某種問題？

我看了一下http響應標題，它在我的本地盒子上工作，而不是在qa盒子上工作，但是當它們稍微不同時，我沒有看到任何吸菸槍。

作爲我拒絕的其他想法，內容長度發生在我身上的可能性，因爲如果內容長度值太小，我想這會使它損壞......但我不清楚爲什麼會發生這種情況，我不認爲這正是它，因爲如果我嘗試壓縮並下載1個文件，我會得到一個小的壓縮文件...下載多個文件時會給我一個更大的壓縮文件。因此，加上沒有記錄錯誤的事實，使我認爲zip實用程序正在正確查找和壓縮文件，並且問題在別處。

這是標題，要完整。

我的開發機器上的響應報頭（工作）

HTTP/1.1 200 OK 
Date: Wed, 02 Jan 2013 21:59:31 GMT 
Server: Microsoft-IIS/6.0 
X-Powered-By: ASP.NET 
X-AspNet-Version: 2.0.50727 
Content-Disposition: attachment; filename="MsdsRequest-2013-59-02-165931.zip" 
Transfer-Encoding: chunked 
Cache-Control: private 
Content-Type: application/zip 

質量保證機器（不工作）

HTTP/1.1 200 OK 
Date: Wed, 02 Jan 2013 21:54:37 GMT 
Server: Microsoft-IIS/6.0 
P3P: CP="NON DSP LAW CUR TAI HIS OUR LEG" 
SVR: 06 
X-Powered-By: ASP.NET 
X-AspNet-Version: 2.0.50727 
Content-Disposition: attachment; filename="MsdsRequest-2013-54-02-165437.zip" 
Cache-Control: private 
Content-Type: application/zip 
Set-Cookie: (cookie junk removed);expires=Wed, 02-Jan-2013 21:56:37 GMT;path=/;httponly 
Content-Length: 16969 

不知道如何處理這個因爲沒有聲稱一個上的響應頭失敗。我覺得這可能是一個Web服務器配置問題（因爲我沒有更好的想法），但我不確定去哪裏看。有我可以採取的機智嗎？

Answer 1

因爲它是你錯過右後Flush()，以給出End()頁面：

... 
     zip.Save(Response.OutputStream); 
    } 
    Response.Flush(); 
    Response.End(); 
} 

但這不是正確的方法，使用頁面發送一個壓縮文件，可能是IIS也gzip該頁面，這可能會導致問題。 The correct way is to use a handler，並且還避免了對該處理程序的額外gZip壓縮，請通過ether配置IIS，如果您使用gZip壓縮，請避免使用它。

與例如download.ashx名稱的處理程序，你的情況會像：

public void ProcessRequest(HttpContext context) 
    { 
     string[] fileNames = Request.QueryString["requests"].Split(',');   
     context.Response.ContentType = "application/zip";   
     string archiveName = String.Format("MsdsRequest-{0}.zip", DateTime.Now.ToString("yyyy-mm-dd-HHmmss"));   
     context.Response.AddHeader("Content-Disposition", "attachment; filename=\"" + archiveName + "\""); 

     // render direct 
     context.Response.BufferOutput = false; 

     using (ZipFile zip = new ZipFile()) 
     { 
     foreach (string fileName in fileNames) 
     { 
      zip.AddFile(String.Format(SiteSettings.PdfPath + "{0}.pdf", msdsFileName), ""); 
     } 
     zip.Save(context.Response.OutputStream); 
     } 
    }