是否有必要在我的响应标头中设置 Content-Length？答案

【问题标题】：Is it necessary to set the Content-Length in my response header?是否有必要在我的响应标头中设置 Content-Length？
【发布时间】：2009-09-11 18:41:11
【问题描述】：

我正在查看一些遗留代码，我发现了一个导致响应无限期停留的错误。

这是基本的想法：

Response.Content-Type = "application/octet-stream"
Response.AddHeader("Content-Disposition", "attachment; filename" & someFileName)
Response.AddHeader("Content-Length", someStoredLength)
Response.BinaryWrite(someByteArray)
Response.Flush()
Response.End()

问题是 someStoredLength 比 someByteArray 的实际大小大得多，所以客户端只是坐在那里等待文件下载，而浏览器只是旋转。

我正在考虑只删除指定内容长度的 AddHeader，因为当我这样做时，一切似乎都正常，但我担心我不理解某些东西。

我可以删除这个 AddHeader 还是我应该想出一个更好的方法来处理这个问题？

【问题讨论】：

这是什么语言？上面代码中的Response对象是什么类？
@RichAmberale：这与问题无关。由于 HTTP 标头，问题发生在浏览器上。
代码在 VB.NET 中，但我可能会在 ASP 经典中完成遗留的其他地方找到这个

标签： vb.net http download response

【解决方案1】：

将 Content-Length 行更改为以下内容：

Response.AddHeader("Content-Length", someByteArray.Length.ToString())

【讨论】：

我也在考虑这样做。我想知道这是否是一个不错的选择。如果我有一个字节数组，Length 属性是否总是给我正确的大小？
是的。 content-length 标头指示内容中的字节数。你的内容是一个字节数组，所以你很好。

【解决方案2】：

您的应用程序 SHOULD（向下滚动到 Content-Length）定义它，但不是严格要求。

这是decent discussion 的可能选项。

【讨论】：

链接文章中建议的解决方案（“只需将长度设置为可能太大的任意值”）似乎是一个非常糟糕的主意。即使它不会破坏当前用户代理的任何内容，它也会破坏“内容长度”标头的整个概念，并且可能会破坏不常见但完全符合标准的 HTTP 客户端库。如果事先不知道文件的大小，则在所有情况下都应使用分块传输编码（如果要重用连接（保持活动状态），则必须使用）。
直接链接到Content-Length，另见HttpBis