如何调试损坏的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); 
     } 
    }