MVC5 申请表在提交时产生多个 post 请求
MVC5 application form results in multiple post requests on submit
我们有一个 MVC5/Razor 应用程序上周突然开始表现得很奇怪。它托管在 Windows Server 2008 R2(带有 IIS 7.5)上,问题是在上周安装 Windows 更新后开始的。到那时应用程序运行正常。
问题是,当用户提交一个由 10 个文本字段、4 个文本区域和一个 drop-down 列表组成的简单表单时,服务器没有正确响应,导致 "Error_Connection_Reset"(在Chrome) / "Page Unavailable"(在 IE11 中)。
我们在控制器的接收操作中使用 POST-Redirect-GET 模式和 RedirectToAction
,这通常会导致 302 响应和重定向。
表单呈现如下:
@using (Html.BeginForm("Create", "Controller"))
{
@Html.AntiForgeryToken()
<div class="editor-fields">
@Html.EditorFor(m => m.Model)
</div>
<div class="clear-fix"></div>
<div class="submit-area">
<input type="submit" value="Submit" />
</div>
}
该操作具有以下属性:
[HttpPost]
[ValidateAntiForgeryToken]
[AllowAnonymous]
[ValidateInput(false)]
我们还使用 Google 分析和 jQuery、jQuery 验证,不显眼 ajax 优化(缩小)。大多数 JS 脚本都包含在 Scripts.Render
.
中
当我们从我们自己的域内部访问该应用程序时,该应用程序工作正常,但由于我们所有的用户都需要从外部访问,因此我们需要修复此错误。这可能表明存在 DNS 问题,但我们的 IT 支持人员表示 DNS 看起来很好并且最近没有更改。
这是我们到目前为止所做的和发现的:
inetpub\logs\LogFiles
中的日志文件显示 多个(在 3 到 10 之间)POST 请求所有状态代码为 302,但没有后续 GET 请求。而且真的应该只有一个 POST 请求,然后是一个 GET 请求!
%windir%\System32\LogFiles\HTTPERR
中的日志文件没有显示任何有趣的内容,只是一堆 Timer_ConnectionIdle
"errors" 每当网站达到其空闲超时值(默认为 20 分钟)时。
- 在 Chrome 和 IE11 中使用 Fiddler 和开发工具检查请求,所有请求都显示相同的请求 headers。使用 fiddler,我们得到
[Fiddler] ReadResponse() failed: The server did not return a complete response for this request. Server returned 0 bytes
。在 Chrome Dev Tools 中,状态列中显示 (failed)
。
- 在 IIS 中禁用缓存和压缩。
- 关闭了 web.config 文件中的 CustomErrors
- 在 web.config
中添加了 <modules runAllManagedModulesForAllRequests="true">
- 搜索 Google 和 SO 寻找答案,但到目前为止无济于事
- 检查最近安装的更新 Windows 关于 .NET 4.5.2 的更新和相关的知识库文章,但没有提到与此问题真正相关的内容
- 编辑: 此外,我们启用了失败请求跟踪,但我们只获得
inetpub\logs\FailedReqLogFiles
文件夹中缺少 favicon.ico 的失败请求日志
有趣的是,如果我在 Chrome Dev Tools 中勾选 "Disable cache",应用程序也能正常工作。这可能表明这是一个缓存问题,这也是我们尝试在 IIS 中打开输出缓存的原因。
我们的下一步是启动新服务器(Windows 2012 和更新版本的 IIS)并在那里安装应用程序 或 安装 WireShark在我们当前的服务器上进一步调查请求。但是,如果有人经历过这种行为并知道解决方法,我们宁愿暂时修复它。所以,请,如果有人可以帮助,请指教。
由于问题似乎只发生在我们域外的用户身上,我们开始认为这个问题可能与我们的防火墙有关,所以我们联系了我们的防火墙提供商,他们确认最新版本的防火墙存在问题防火墙软件。碰巧的是,防火墙软件在 Windows 更新的同一天更新到我们的服务器上,这可能引起了一些混乱。恢复到以前版本的防火墙软件后,问题就消失了,一切都再次按预期运行。呸!
我们有一个 MVC5/Razor 应用程序上周突然开始表现得很奇怪。它托管在 Windows Server 2008 R2(带有 IIS 7.5)上,问题是在上周安装 Windows 更新后开始的。到那时应用程序运行正常。
问题是,当用户提交一个由 10 个文本字段、4 个文本区域和一个 drop-down 列表组成的简单表单时,服务器没有正确响应,导致 "Error_Connection_Reset"(在Chrome) / "Page Unavailable"(在 IE11 中)。
我们在控制器的接收操作中使用 POST-Redirect-GET 模式和 RedirectToAction
,这通常会导致 302 响应和重定向。
表单呈现如下:
@using (Html.BeginForm("Create", "Controller"))
{
@Html.AntiForgeryToken()
<div class="editor-fields">
@Html.EditorFor(m => m.Model)
</div>
<div class="clear-fix"></div>
<div class="submit-area">
<input type="submit" value="Submit" />
</div>
}
该操作具有以下属性:
[HttpPost]
[ValidateAntiForgeryToken]
[AllowAnonymous]
[ValidateInput(false)]
我们还使用 Google 分析和 jQuery、jQuery 验证,不显眼 ajax 优化(缩小)。大多数 JS 脚本都包含在 Scripts.Render
.
当我们从我们自己的域内部访问该应用程序时,该应用程序工作正常,但由于我们所有的用户都需要从外部访问,因此我们需要修复此错误。这可能表明存在 DNS 问题,但我们的 IT 支持人员表示 DNS 看起来很好并且最近没有更改。
这是我们到目前为止所做的和发现的:
inetpub\logs\LogFiles
中的日志文件显示 多个(在 3 到 10 之间)POST 请求所有状态代码为 302,但没有后续 GET 请求。而且真的应该只有一个 POST 请求,然后是一个 GET 请求!%windir%\System32\LogFiles\HTTPERR
中的日志文件没有显示任何有趣的内容,只是一堆Timer_ConnectionIdle
"errors" 每当网站达到其空闲超时值(默认为 20 分钟)时。- 在 Chrome 和 IE11 中使用 Fiddler 和开发工具检查请求,所有请求都显示相同的请求 headers。使用 fiddler,我们得到
[Fiddler] ReadResponse() failed: The server did not return a complete response for this request. Server returned 0 bytes
。在 Chrome Dev Tools 中,状态列中显示(failed)
。 - 在 IIS 中禁用缓存和压缩。
- 关闭了 web.config 文件中的 CustomErrors
- 在 web.config 中添加了
- 搜索 Google 和 SO 寻找答案,但到目前为止无济于事
- 检查最近安装的更新 Windows 关于 .NET 4.5.2 的更新和相关的知识库文章,但没有提到与此问题真正相关的内容
- 编辑: 此外,我们启用了失败请求跟踪,但我们只获得
inetpub\logs\FailedReqLogFiles
文件夹中缺少 favicon.ico 的失败请求日志
<modules runAllManagedModulesForAllRequests="true">
有趣的是,如果我在 Chrome Dev Tools 中勾选 "Disable cache",应用程序也能正常工作。这可能表明这是一个缓存问题,这也是我们尝试在 IIS 中打开输出缓存的原因。
我们的下一步是启动新服务器(Windows 2012 和更新版本的 IIS)并在那里安装应用程序 或 安装 WireShark在我们当前的服务器上进一步调查请求。但是,如果有人经历过这种行为并知道解决方法,我们宁愿暂时修复它。所以,请,如果有人可以帮助,请指教。
由于问题似乎只发生在我们域外的用户身上,我们开始认为这个问题可能与我们的防火墙有关,所以我们联系了我们的防火墙提供商,他们确认最新版本的防火墙存在问题防火墙软件。碰巧的是,防火墙软件在 Windows 更新的同一天更新到我们的服务器上,这可能引起了一些混乱。恢复到以前版本的防火墙软件后,问题就消失了,一切都再次按预期运行。呸!