HTML 表单数据在 POST 时丢失
我们有一个非常奇怪的问题，我们尚未能够诊断。我们的应用程序有许多特定的 ASP.NET MVC 操作，这些操作因缺少必需的参数而失败：
The parameters dictionary contains a null entry for parameter 'myVariable' of non-nullable type... etc
每个操作都是某种 HTTP POST，因此我们希望看到表单数据。在某些情况下，应该有十几个变量。
我们使用 ELMAH 收集 Web 应用程序中的错误，通过此工具，您通常可以看到在请求失败期间发布的实际表单数据。然而在这些特定的 errpr 中，应该有几个变量整个表单丢失了！
我们根本无法按需重现此内容。然而，随着我们应用程序的流量增加，我们每天都会看到这些错误数十次。用户也无法重现该错误，并且在网络浏览器中尝试相同的操作第二次会起作用。
我们也不能 100% 确定数据丢失的位置。是在网络浏览器中吗？在 IIS 管道内部？或者是 ASP.NET MVC 转储了它？完全不确定。
如果有人可以帮助我们解决和/或诊断这个问题，我们将不胜感激。
更新 1：我们发现 HTTP 标头中指定的内容长度的大小表明请求中存在某些内容。然而，请求中的表单集合是空的（根据 ELMAH）。因此，我们添加了一些额外的日志记录来跟踪收到的内容的实际长度以及内容本身。
更新 2：我们发现，虽然 CONTENT_LENGTH HTTP 标头的大小正确（对于类似的请求），但内容本身丢失了。该流包含 0 字节。
我们还能够将问题范围缩小到 Internet Explorer，但其他浏览器似乎无法解决此问题。
有时，我们可以通过在浏览器中引发多个重叠的 AJAX 请求，然后刷新或重定向来重现问题。这几乎就像 Internet Explorer 在完全写出流缓冲区之前关闭连接一样。
我们无法用 Fiddler 追踪这一点。使用 Fiddler 似乎无法重现特定情况。
更新 3：我们所看到的一切都可以这样解释：为什么 Internet Explorer 在 Ajax 调用失败后不发送 HTTP post 正文？
We have a very strange problem which we have yet to be able to diagnose. Our application has a number of specific ASP.NET MVC actions which fail because a required parameter is missing:
The parameters dictionary contains a null entry for parameter 'myVariable' of non-nullable type... etc
Each of these is some sort of HTTP POST, and thus we expect to see form data. In some cases there should be over a dozen variables.
We use ELMAH to collect errors in the web application, and via this tool you can typically see the actual form data which is posted during a request which fails. However in these specific errpr when there should be several variables the entire form is missing!
We simply cannot reproduce this on-demand. However with the volume of traffic in our application we see these errors several dozen times a day. Users cannot reproduce the error either, and trying the same action in the web browser works a second time.
We're also not 100% sure where the data is lost. Is it in the web browser? Inside the IIS pipeline? Or is it ASP.NET MVC which dumps it? Totally unsure.
If anyone can help us troubleshoot and/or diagnose this problem it would be greatly appreciated.
Update 1: We've discovered that the content length as specified in the HTTP Headers is of a size that suggests that there is some content in the request. However the forms collection on the request is empty (as per ELMAH). So we've added some additional logging to trace the actual length of the content received and the content itself.
Update 2: We have discovered that while the CONTENT_LENGTH HTTP Header is of the correct size (for a similar requests), the content itself is missing. The stream contains 0 bytes.
We've also be able to narrow down the problem to Internet Explorer, we can't seem to get it to happen with other browsers.
We've been able to sometimes recreate the problem by causing several overlapping AJAX requests in the browser, and then either refreshing or redirecting. It's almost as if Internet Explorer is closing the connection before completely writing out the stream buffer.
We have not been able to trace this with Fiddler. Using Fiddler, it appears it is impossible to recreate the specific situation.
Update 3: Everything we've seen can be explained by this: Why does Internet Explorer not send HTTP post body on Ajax call after failure?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
这可能有点猜测，但您的操作是否有可能没有 [HttpPost] 限制，因此用户以某种方式通过 GET 而不是 POST 来访问它？
我的应用程序中也发生过类似的情况，用户尝试 POST 到 URL，但他们的 FormsAuthentication 票证已过期，因此他们被重定向到登录页面。但由于登录页面已传递“ReturnUrl”参数，一旦他们登录，他们就会被重定向回原本要 POST 的页面，但这次是使用 GET。这会导致您描述的错误，因为显然 POST 数据不再存在。正如我所说，有点猜测......
This might be a bit of a guess, but is it possible that your action does not have the [HttpPost] restriction on it, so that somehow users are getting to it via a GET rather than a POST?
I've had something similar happen in my app where users try POST to a URL, but their FormsAuthentication ticket has expired, so they get redirected to the login page. But because the login page has the "ReturnUrl" parameter passed to it, once they login they are redirected back to the page they are meant to be POSTing to originally, but this time with a GET. This would cause the error you describe, as obviously none of the POST data is present any more. As I say, bit of a guess...
您发布的错误消息看起来表单没有任何问题。对我来说，这看起来像是一个路由问题，所以我想问的是：
The error message you posted doesn't seem like there's anything wrong with the form. To me it looks like a routing issue so here's what I would ask:
问题的根源可以这样解释： 为什么 Internet Explorer 在 Ajax 调用失败后不发送 HTTP post 正文？
更新：事实证明，我们的具体症状似乎与 jQuery 的使用有关。升级后，问题最终消失。
The source of the problem can be explained by this: Why does Internet Explorer not send HTTP post body on Ajax call after failure?
Update: It turns out that our specific symptoms seemed to be tied to use of jQuery. After upgrading, the problem has eventually gone away.