为什么“内容长度:0"在 POST 请求中? [英] Why "Content-Length: 0" in POST requests?

问题描述

客户有时会在提交表单(10 到 40 多个字段)时发送带有 Content-Length: 0 的 POST 请求.

A customer sometimes sends POST requests with Content-Length: 0 when submitting a form (10 to over 40 fields).

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

We tested it with different browsers and from different locations but couldn't reproduce the error. The customer is using Internet Explorer 7 and a proxy.

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

We asked them to let their system administrator see into the problem from their side. Running some tests without the proxy, etc..

与此同时(半年后仍然没有答案)我很好奇是否有人知道 Content-Length: 0 请求的类似问题.可能来自某些 Windows 网络内部，为大公司提供特殊代理.

In the meantime (half a year later and still no answer) I'm curious if somebody else knows of similar problems with a Content-Length: 0 request. Maybe from inside some Windows network with a special proxy for big companies.

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

Is there a known problem with Internet Explorer 7? With a proxy system? The Windows network itself?

Google 仅在 NTLM(以及此类)身份验证的上下文中显示了一些内容，但我们并未在 Web 应用程序中使用它.也许是代理在使用 Windows 登录的客户网络中运行的方式?(我不是 Windows 专家.只是猜测.)

Google only showed something in the context of NTLM (and such) authentication, but we aren't using this in the web application. Maybe it's in the way the proxy operates in the customer's network with Windows logins? (I'm no Windows expert. Just guessing.)

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

I have no further information about the infrastructure.

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

UPDATE: In December 2010 it was possible to inform one administrator about this, incl. links from the answers here. Contact was because of another problem which was caused by the proxy, too. No feedback since then. And the error messages are still there. I'm laughing to prevent me from crying.

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

UPDATE 2: This problem exists since mid 2008. Every few months the customer is annoyed and wants it to be fixed ASAP. We send them all the old e-mails again and ask them to contact their administrators to either fix it or run some further tests. In December 2010 we were able to send some information to 1 administrator. No feedback. Problem isn't fixed and we don't know if they even tried. And in May 2011 the customer writes again and wants this to be fixed. The same person who has all the information since 2008.

谢谢大家的回答.你帮助了很多人，正如我从这里的一些评论中看到的那样.太糟糕了，现实世界对我来说太奇怪了.

Thanks for all the answers. You helped a lot of people, as I can see from some comments here. Too bad the real world is this grotesque for me.

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

UPDATE 3: May 2012 and I was wondering why we hadn't received another demand to fix this (see UPDATE 2). Looked into the error protocol, which only reports this single error every time it happened (about 15 a day). It stopped end of January 2012. Nobody said anything. They must have done something with their network. Everything is OK now. From summer 2008 to January 2012. Too bad I can't tell you what they have done.

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

UPDATE 4: September 2015. The website had to collect some data and deliver it to the main website of the customer. There was an API with an account. Whenever there was a problem they contacted us, even if the problem was clearly on the other side. For a few weeks now we can't send them the data. The account isn't available anymore. They had a relaunch and I can't find the pages anymore that used the data of our site. The bug report isn't answered and nobody complaint. I guess they just ended this project.

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

UPDATE 5: March 2017. The API stopped working in the summer of 2015. The customer seems to continue paying for the site and is still accessing it in February 2017. I'm guessing they use it as an archive. They don't create or update any data anymore so this bug probably won't reemerge after the mysterious fix of January 2012. But this would be someone else's problem. I'm leaving.

推荐答案

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

Internet Explorer does not send form fields if they are posted from an authenticated site (NTLM) to a non-authenticated site (anonymous).

这是针对挑战响应情况(NTLM 或 Kerberos 保护的网站)的功能，在这种情况下，IE 可以预期第一个 POST 请求会立即导致 HTTP 401 需要身份验证响应(其中包括一个挑战)，并且只有第二个 POST 请求(包括对挑战的响应)才会被实际接受.在这些情况下，出于性能原因，IE 不会在第一个请求中上传可能很大的请求正文.感谢 EricLaw 发布该内容评论中的一些信息.

This is feature for challange-response situations (NTLM- or Kerberos- secured web sites) where IE can expect that the first POST request immediately leads to an HTTP 401 Authentication Required response (which includes a challenge), and only the second POST request (which includes the response to the challange) will actually be accepted. In these situations IE does not upload the possibly large request body with the first request for performance reasons. Thanks to EricLaw for posting that bit of information in the comments.

每次从 NTLM 身份验证(即 Intranet)页面到非身份验证(即 Internet)页面进行 HTTP POST 时，或者如果非身份验证页面是框架集的一部分，其中框架集页面已通过身份验证.

This behavior occurs every time an HTTP POST is made from a NTLM authenticated (i.e. Intranet) page to a non-authenticated (i.e. Internet) page, or if the non-authenticated page is part of a frameset, where the frameset page is authenticated.

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

The work-around is either to use a GET request as the form method, or to make sure the non-authenticated page is opened in a fresh tab/window (favorite/link target) without a partly authenticated frameset. As soon as the authentication model for the whole window is consistent, IE will start to send form contents again.

• 绝对相关:http://www.websina.com/bugzero/kb/browser-ie.html
• 可能相关:KB923155
• 完整说明:IEInternals 博客 – 挑战-响应身份验证和零长度帖子

这篇关于为什么“内容长度:0"在 POST 请求中?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！