56

客户有时会在提交表单时发送 POST 请求Content-Length: 0（10 到 40 多个字段）。

我们使用不同的浏览器和不同的位置对其进行了测试，但无法重现该错误。客户正在使用 Internet Explorer 7 和代理。

我们要求他们让他们的系统管理员从他们的角度看待问题。在没有代理的情况下运行一些测试等。

与此同时（半年后仍然没有答案）我很好奇其他人是否知道类似的Content-Length: 0请求问题。也许来自一些 Windows 网络内部，为大公司提供了特殊代理。

Internet Explorer 7 是否存在已知问题？使用代理系统？Windows 网络本身？

Google 仅在 NTLM（和此类）身份验证的上下文中显示了一些内容，但我们没有在 Web 应用程序中使用它。可能是代理在使用 Windows 登录的客户网络中运行的方式？（我不是 Windows 专家。只是猜测。）

我没有关于基础设施的更多信息。

更新：在 2010 年 12 月，可以将此通知一位管理员，包括。来自这里的答案的链接。联系也是因为代理引起的另一个问题。从那以后没有任何反馈。并且错误消息仍然存在。我笑是为了不让我哭。

更新 2：这个问题自 2008 年中期以来就存在。每隔几个月，客户就会感到恼火，并希望尽快修复它。我们再次向他们发送所有旧电子邮件，并要求他们联系他们的管理员来修复它或运行一些进一步的测试。2010 年 12 月，我们能够向 1 位管理员发送一些信息。没有反馈。问题没有解决，我们不知道他们是否尝试过。并且在 2011 年 5 月，客户再次写信并希望解决此问题。自 2008 年以来拥有所有信息的同一个人。

感谢所有的答案。正如我从这里的一些评论中看到的那样，你帮助了很多人。太糟糕了，现实世界对我来说是这样的怪诞。

更新 3： 2012 年 5 月，我想知道为什么我们没有收到另一个解决此问题的要求（请参阅更新 2）。调查了错误协议，它每次发生时只报告这个单一的错误（大约每天 15 次）。它于 2012 年 1 月结束。没有人说什么。他们一定对他们的网络做了什么。现在一切正常。从 2008 年夏天到 2012 年 1 月。太糟糕了，我不能告诉你他们做了什么。

更新 4： 2015 年 9 月。网站必须收集一些数据并将其传送到客户的主网站。有一个带有帐户的 API。每当出现问题时，他们都会联系我们，即使问题显然在另一边。几个星期以来，我们无法向他们发送数据。该帐户不再可用。他们重新启动了，我再也找不到使用我们网站数据的页面了。错误报告没有得到答复，也没有人抱怨。我猜他们刚刚结束了这个项目。

更新 5： 2017 年 3 月。API 在 2015 年夏天停止工作。客户似乎继续为该网站付费，并且仍在 2017 年 2 月访问它。我猜他们将其用作存档。他们不再创建或更新任何数据，因此这个错误可能不会在 2012 年 1 月的神秘修复之后重新出现。但这将是其他人的问题。我走了。

4

13 回答 13

43

如果表单字段从经过身份验证的站点 (NTLM) 发布到未经过身份验证的站点（匿名），Internet Explorer 不会发送它们。

这是挑战响应情况（NTLM 或 Kerberos 安全网站）的功能，其中 IE 可以预期第一个 POST 请求立即导致HTTP 401 Authentication Required响应（包括质询），并且只有第二个 POST 请求（其中包括对挑战的回应）实际上将被接受。在这些情况下，出于性能原因，IE 不会将可能较大的请求正文与第一个请求一起上传。感谢EricLaw在评论中发布这些信息。

每次从 NTLM 已验证（即 Intranet）页面到未验证（即 Internet）页面的 HTTP POST 时，或者如果未验证页面是框架集的一部分，框架集页面已在其中验证，则会发生此行为。

解决方法是使用 GET 请求作为表单方法，或者确保未经过身份验证的页面在没有部分经过身份验证的框架集的情况下在新的选项卡/窗口（收藏夹/链接目标）中打开。一旦整个窗口的认证模型一致，IE就会重新开始发送表单内容。

于 2009-03-10T13:04:49.613 回答
15

这很容易通过 MS-IE 和服务器端的 NTLM 身份验证过滤器重现。我对 XP-SP2 上的 JCIFS (1.2. )、struts 1.和 MS-IE 6/7 有同样的问题。终于修好了。有几种解决方法可以弥补。

  1. 将表单方法从 POST（struts 默认设置）更改为 GET。对于大多数具有小尺寸表单的页面，它运行良好。不幸的是，我可能有超过 50 条记录要在 HTTP 流中发送回服务器端。IE 的 GET URL 限制为 2038 字节（不是参数长度，而是整个 URL 长度）。所以这是一个快速的解决方法，但不适用于我。

  2. 在执行 POST 操作之前发送 GET。这是在 MS-KB 中推荐的。我的项目有许多遗留程序，我不会在正确的时间冒险。我从未尝试过，因为根据我对 MS-KB 的理解，当过滤层接收到 GET 时，它仍然需要一些额外的身份验证处理，而且我不想改变其他浏览器的行为，例如 Firefox、Opera。

  3. 检测是否以零内容长度发送 POST（您可以使用框架从标头属性哈希结构中获取它）。如果是这样，请通过从 DC 或缓存中获取质询代码来触发 NTLM 身份验证周期，并期待 NTLM 响应。当收到 NTLM type2 msg 并且会话仍然有效时，您实际上不需要对用户进行身份验证，只需将其转发到预期的操作（如果 POST 内容长度不为零）。顺便说一句，这会增加网络流量。因此，请在应用更改之前检查您的缓存寿命设置和 SMB 会话 soTimeOut 配置。或者，更简单，您可以只向 MS-IE 发送 401 未授权状态，然后浏览器将发送回 POST 请求和数据作为回复。

  4. MS-KB 提供了一个带有 KB-923155 的热修复程序（我不能发布多个链接，因为信誉数低 :{ ），但它似乎不起作用。有人会在这里发布一个可行的热修复吗？谢谢 :) 这是一个参考链接，http://www.websina.com/bugzero/kb/browser-ie.html

于 2010-04-13T06:49:39.187 回答
6

我们的系统上有一个客户遇到了完全相同的问题。我们已将其指向代理/防火墙。微软的 IAS。它正在剥离 POST 正文并发送 content-length: 0。然而，我们无法解决很多问题，并且想要使用 GET 请求，因为这会在 URL 字符串上暴露用户名/密码等。我们的系统上有近 7,000 个用户，只有一个有问题……也只有一个使用 Microsoft IAS，所以它必须是这个。

于 2009-07-01T09:23:13.990 回答
5

问题很可能是中间的代理服务器实现了 HTTP 1.0。

在 HTTP 1.0 中，您必须使用 Content-Length 标头字段：（请参阅此处的第 10.4 节）

所有 HTTP/1.0 POST 请求都需要有效的 Content-Length。如果 HTTP/1.0 服务器无法确定请求消息内容的长度，它应该以 400（错误请求）消息进行响应。

进入代理的请求是 HTTP 1.1，因此不需要使用 Content-Length 标头字段。通常使用 Content-Length 标头，但并非总是如此。请参阅HTTP 1.1 RFC S. 14.13的以下摘录。

应用程序应该使用这个字段来指示消息体的传输长度，除非这被第 4.4 节中的规则禁止。任何大于或等于零的 Content-Length 都是有效值。

第4.4节描述了在没有给出 Content-Length 的情况下如何确定消息体的长度。

因此，代理服务器看不到 Content-Length 标头，它假设在 HTTP 1.0 中如果有正文则绝对需要该标头。因此它假定为 0，以便请求最终到达服务器。请记住，代理不知道 HTTP 1.1 规范的规则，因此它不知道如何处理没有 Content-Length 标头的情况。

您是否 100% 确定您的请求指定了 Content-Length 标头？如果它使用第 4.4 节中定义的另一种方式，因为它认为服务器是 1.1（因为它不知道中间的 1.0 代理），那么您将遇到您所描述的问题。

也许您可以改用 HTTP GET 来绕过这个问题。

于 2009-03-11T21:05:06.970 回答
3

这是 Internet Explorer 6 的已知问题，但不是我所知道的 7。您可以为 IE6 KB831167修复安装此修复。

你可以在这里阅读更多关于它的信息。

给你一些问题：

  • 你知道代理的类型吗？
  • 您知道请求中是否发送了实际的正文？
  • 每次都持续发生吗？还是只是有时？
  • 请求中是否发送了任何二进制数据？也许数据以 \0 开头，并且代理有二进制数据的错误。
于 2009-03-11T19:49:18.090 回答
2

如果用户正在通过使用 NTLM 身份验证的 ISA 代理，那么听起来像这个问题，它提供了一个解决方案（ISA 代理的补丁）

http://support.microsoft.com/kb/942638
没有 POST 正文的 POST 请求可能会发送到在 ISA Server 2006 中发布的 Web 服务器

于 2010-06-30T15:32:15.157 回答
2

我还遇到了一个问题，即来自客户的 IE 11 浏览器的请求Content-Length: 0包含但不包含预期的 POST 内容。当客户使用 Firefox 或 Chrome 时，请求中包含预期的内容。

我发现原因是客户使用的是 HTTP URL 而不是 HTTPS URL（例如http://...，not https://...），而我们的应用程序使用 HSTS。似乎 IE 11 中可能存在一个错误，即当请求由于 HSTS 升级到 HTTPS 时，请求内容会丢失。

让客户更正 URL 以https://...使内容包含在 POST 请求中并解决问题。

在这个阶段，我还没有进一步调查它是否真的是 IE 11 中的一个错误。

于 2017-06-30T18:08:18.177 回答
1

您确定这些请求来自“客户”吗？

我以前遇到过机器人的问题；他们有时会根据他们在抓取过程中发现的 FORM 标记中的操作 URI 发送空白 POST 请求来探测站点以查找“联系我们”表单。

于 2008-11-30T01:28:03.510 回答
1

HTTP 中 ContentLength 标头的存在和可能值在 HTTP（我假设 1/1）RFC 中进行了描述：

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.13

在 HTTP 中，只要可以在传输之前确定消息的长度，就应该发送它

也可以看看：

如果接收到的消息同时带有 Transfer-Encoding 头字段和 Content-Length 头字段，则必须忽略后者。 http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4

也许您的消息带有 Transfer-Encoding 标头？

稍后编辑：还请注意 RFC 中使用的“应该”非常重要，不等同于“必须”：

3. 应该 这个词，或形容词“推荐”，意味着在特定情况下可能存在忽略特定项目的正当理由，但在选择不同的课程之前必须理解并仔细权衡全部含义。 参考：http ://www.ietf.org/rfc/rfc2119.txt

于 2008-11-30T09:03:03.390 回答
1

我们有一位客户以匿名和 NTLM 模式（在不同端口上）使用同一网站。我们发现，在我们的案例中，401 与用于 http 优化的 Riverbed Steelhead 应用程序有关。将我们指向该方向的第一个信号是 X-RBT-Optimized-By 标头。问题是免费的 401 功能：

此功能可与按请求和按连接身份验证一起使用，但在与按请求身份验证一起使用时最有效。使用按请求身份验证，必须先针对服务器对每个请求进行身份验证，然后服务器才能将对象提供给客户端。但是，大多数浏览器不会缓存需要身份验证的服务器响应，因此每个 GET 请求都会浪费一次往返。使用 Gratuitous 401，客户端 Steelhead 设备将缓存服务器响应，当客户端发送没有任何身份验证标头的 GET 请求时，它将在本地响应“401 Unauthorized”消息，从而节省往返行程。请注意，HTTP 模块本身并不参与实际的身份验证。

于 2014-09-15T06:25:17.730 回答
0

Microsoft 的KB821814修补程序可以将 Content-Length 设置为 0：

本文介绍的修补程序将 Wininet.dll 中的代码更改为：

  • 检测 POST 请求的 RESET 条件。
  • 保存要发布的数据。
  • 重试 POST 请求并将内容长度设置为 0。这可以防止发生重置并允许完成身份验证过程。
  • 重试原始 POST 请求。
于 2009-11-17T23:38:48.740 回答
0

在 https 连接达到 keepalive 超时并重新连接到服务器后，Google 还将其显示为 IE（无论如何都是某些版本）错误。该解决方案似乎将服务器配置为在 https 下不对 IE 使用 keepalive。

于 2008-11-30T07:43:17.450 回答
0

curl在配置为使用 HTTP 代理时发送PUT/POST请求。在第一次未经授权的代理请求Content-Length: 0的情况下克服所需的缓冲是一个技巧。PUT/POST在GET/HEAD请求curl的情况下，只需重复查询。的方案PUT/POST是这样的：

  1. 发送设置为 0 的第一个PUT/POST请求。Content-Length

  2. 得到答案。HTTP 状态码 407 意味着我们必须使用代理授权。为发送请求准备代理身份验证的标头。

  3. 再次发送请求，并使用填充的标头进行代理身份验证，并将真实数据发送到 POST/PUT。

于 2017-03-04T09:22:49.330 回答