5

请看最后，因为我会不断更新最新的调查数据。目前，我需要有关服务器端 WireShark 日志的帮助。

我在使用 ASP.NET MVC Web 应用程序时遇到了奇怪的问题。很少有用户会遇到表单发布超时和挂起的情况，因此单击提交后它只会永远持续并且不会前进到下一页。奇怪的是，这是通过清除浏览器的缓存来解决的。我不明白这两件事如何相关。此外，一位用户报告说它发生在 FireFox 3+ 中，但不会发生在 FireFox 1.5 和 2.0 中。我和许多用户无法在 IE、任何 FireFox 和 Linux/Windows 上重现这一点。

浏览器缓存如何以及为什么会影响表单 POST 处理？

好的，我检查了用户和 FireBug。我看到了 POST 请求，但在长时间超时后它失败了。服务器没有收到请求 - 至少，在我进行日志记录的基本控制器的 OnBeforeExecuting 中，也没有在 IIS 日志文件中。响应为空。此外，一旦请求花费了很长时间但最终执行 - 在服务器上，我发现执行时间非常短。

据我所知，这发生在使用 jQuery Form 插件完成的 AJAX 请求上。我尝试在参数中设置 cache: false ，没有成功。

实际上，我尝试不使用 AJAX，直接提交 - 一样。我还可以看到 jQuery 表单插件确实调用 $.ajax() 并返回。我看到它启动了 POST 请求。但我没有在 IIS 日志中看到服务器上的这个请求，直到有时，在一分钟后 - 有时它在 FireBug .Net 窗格中被中止。

有趣的是，清除 FireFox 缓存/cookies/form&post 数据会有所帮助——一次尝试，下一篇文章也会挂起。

此外，请求以 GUID 的形式发送有关所选组件的信息。当未选择组件时，它似乎可以正常工作。组件实际上是由 JavaScript 检查的隐藏复选框（不是在提交时，更早）。这是 POST 数据中的“selected”参数。好像没有选择组件时，它不会挂起，虽然我只尝试过一次，也许以后会调查更多。

对此附加信息有任何想法吗？

Request info:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8 ( .NET CLR 3.5.30729; .NET4.0C)
Accept: */*
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
X-Requested-With: XMLHttpRequest
Content-Length: 1288
Pragma: no-cache
Cache-Control: no-cache

发布数据

为了= 842f2988-abff-413C-a092-9dde00a8b9a8＆选定= f98c9ad8-49e0-4a9f-9966-9d3d01203aa5_a1d659c0-b8ec-4f91-ba2f-9d3d01203a4c＆选定= f98c9ad8-49e0-4a9f-9966-9d3d01203aa5_d6e1984e-227D-4bd0-b8d2-9d3d01203a4d＆选定= f98c9ad8- 49e0-4a9f-9966-9d3d01203aa5_0b7cbc1a-35f1-4db8-856b-9d3d01203a4c＆选定= f98c9ad8-49e0-4a9f-9966-9d3d01203aa5_0cc7ef9b-085f-4b50-ACDB-9d3d01203a4c＆选定= f98c9ad8-49e0-4a9f-9966-9d3d01203aa5_ad273397-ed5d-49bb-b181- 9d3d01203a4c＆选定= f98c9ad8-49e0-4a9f-9966-9d3d01203aa5_b5fbf67f-202f中-464B-a9e4-9d3d01203a4c＆选定= f98c9ad8-49e0-4a9f-9966-9d3d01203aa5_ae275579-8163-4f6b-9d36-9d3d01203a4c＆选定= f98c9ad8-49e0-4a9f-9966-9d3d01203aa5_73fa066c-0467- 4bc6-aa91-9d3d01203a4c&selected=f98c9ad8-49e0-4a9f-9966-9d3d01203aa5_5020b52f-baa2-4aea-be10-9d3d01203a4d&selected=f98c9ad8-49e0-4a9f-9966-9d3d01203aa5_8b2cd95a-c014-4c83-9ec6-9d3d01203a4d&selected=f98c9ad8-49e0-4a9f-9966-9d3d01203aa5&submit=Add+To+Suite

安装了 WireShark。没有直接控制就很难使用（远程用户遵循我的命令），但我可以看到在单击提交后立即向服务器 IP 地址发送了一个 TCP 请求。所以浏览器发出请求。

要求远程用户与 IT/网络支持合作，检查请求是否从客户端/到达服务器。

这是一个非常相似的问题，不幸的是没有任何答案：https ://stackoverflow.com/questions/3355000/my-iis-server-wont-serve-ssl-sites-to-some-browsers

这是来自服务器的 WireShark 日志。提交开始，然后发生一些 SSL 更改密码/握手（在 90 秒内！），然后经过长时间的请求最终失败。

No.     Time        Source                Destination           Protocol Info

  1 0.000000    11.22.33.44         192.168.1.9           TCP      [TCP segment of a reassembled PDU]

  2 0.000114    11.22.33.44         192.168.1.9           TLSv1    Application Data

  3 0.000394    192.168.1.9           11.22.33.44         TCP      https > 50950 [ACK] Seq=1 Ack=2305 Win=64690 Len=0

  4 97.611245   192.168.1.9           11.22.33.44         TCP      https > 50950 [RST, ACK] Seq=1 Ack=2305 Win=0 Len=0

  5 97.752530   11.22.33.44         192.168.1.9           TCP      50958 > https [SYN] Seq=0 Win=8192 Len=0 MSS=1459 WS=2 SACK_PERM=1

  6 97.752612   192.168.1.9           11.22.33.44         TCP      https > 50958 [SYN, ACK] Seq=0 Ack=1 Win=16384 Len=0 MSS=1460 WS=0 SACK_PERM=1

  7 97.778024   11.22.33.44         192.168.1.9           TCP      50958 > https [ACK] Seq=1 Ack=1 Win=17508 Len=0

  8 97.784462   11.22.33.44         192.168.1.9           TLSv1    Client Hello

  9 97.785107   192.168.1.9           11.22.33.44         TLSv1    Server Hello, Change Cipher Spec, Encrypted Handshake Message

 10 97.813970   11.22.33.44         192.168.1.9           TLSv1    Change Cipher Spec, Encrypted Handshake Message

 11 97.814082   11.22.33.44         192.168.1.9           TLSv1    Application Data

 12 97.814208   192.168.1.9           11.22.33.44         TCP      https > 50958 [ACK] Seq=123 Ack=2555 Win=64647 Len=0

 13 227.535270  192.168.1.9           11.22.33.44         TCP      https > 50958 [RST, ACK] Seq=123 Ack=2555 Win=0 Len=0
4

4 回答 4

3

我强烈建议在服务器端和客户端都使用wireshark，看看实际发送了什么数据。我遇到过类似的奇怪错误，看到每个客户端和服务器之间的实际通信总是很有启发性的。我将从服务器端开始。捕获数据包，然后在 POST 上使用“follow tcp stream”。使用
Wireshark 下载Wireshark

于 2010-08-26T17:36:59.863 回答
1

我有一个非常相似的问题（但即使在清除浏览器缓存后也没有解决）。即使重新安装Windows也没有解决它。最终发现是我信任的 Sygate 防火墙将一些数据附加到每个发布请求（根据我有限的理解阻止弹出窗口等）导致问题。我关闭了 Sygate，目前在准系统 Windows 防火墙上，问题就消失了。

于 2010-12-18T11:11:04.537 回答
0

根据我的发现，它看起来像 AVG 问题。当我关闭其 LinkScanner 和 Online Shield（两者）功能时，来自 Chrome 和 Safari（根本不起作用）的 POST 请求开始起作用。

于 2010-11-18T19:53:25.813 回答
0

我有一个类似的问题，Mac 浏览器没有从运行 IIS 6.0 的 Win2k3 服务器加载 SSL 页面。更新 .net 框架修复了 Firefox 和 Camino 问题，但没有修复 Safari 问题。禁用 AVG Online Scanner 解决了我的 Safari 问题，但未安装链接扫描器。找到这篇文章，它解决了我的问题。

谢谢

于 2010-12-20T19:10:26.317 回答