为什么“Content-Length：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..

在此期间（半年后仍然没有回答）我很好奇是否有人知道类似的问题a 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月访问它。我猜它们将它用作存档。他们不再创建或更新任何数据，所以这个bug可能不会在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).

这是challange-response情境（NTLM-或Kerberos-安全网站）的功能，IE可以预期第一个POST请求会立即导致 HTTP 401 Authentication Required 响应（包括挑战），实际上只接受第二个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 Blog - Challenge-Response Authentication和零长度帖子

• Definitely related: http://www.websina.com/bugzero/kb/browser-ie.html
• Possibly related: KB923155
• Full Explanation: IEInternals Blog – Challenge-Response Authentication and Zero-Length Posts

这篇关于为什么“Content-Length：0”在POST请求？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！