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

我在ASP.NET MVC Web应用程序中遇到奇怪的问题。很少有用户会遇到表单发布超时和挂起的情况,因此,单击“提交”后,它将永久存在,并且不会前进到下一页。奇怪的是,这可以通过清除浏览器的缓存来解决。我不明白这两件事是如何联系在一起的。另外,用户报告说它发生在FireFox 3+中,但没有发生在FireFox 1.5和2.0中。我和许多用户无法在IE,任何FireFox和Linux/Windows上重现此内容。

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

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

据我所见,这是在使用jQuery Form插件完成的AJAX请求上发生的。我尝试设置缓存:参数为false,但未成功。

实际上,我尝试不使用AJAX进行纯提交-相同。我还可以看到jQuery表单插件确实调用$ .ajax()并返回。我看到它启动了POST请求。但是,直到有时,在一分钟后,我才在IIS日志中的服务器上看不到此请求-有时,它在FireBug .Net Pane 中被中止。

有趣的是,清除FireFox缓存/Cookie/表单和发布数据会有所帮助-一次尝试,下一个发布也会挂起。

同样,请求以GUID的形式发送有关选定组件的信息。如果未选择组件,则看起来工作正常。组件实际上是JavaScript选中的隐藏复选框(不在提交时,更早)。这是POST数据中的“选定”参数。似乎没有选择任何组件时,它不会挂起,尽管我只尝试了一次,也许以后会再进行调查。

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

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&selected = f98c9ad8-49e0-4a9f-9966-9d3d01203aa5_a1d659c0-b8ec-4f91-ba2f-9d3d01203d4d&d = f98c9ad8-e9d9a9-9e9b3d9d9d1e3d3d01d3d01d3d01d3d01d3d01d3d01d3d01d3d01d3d01d9d9d8d9d9d8d9d9d8dbdfdfdfdfdfdfdfdfd 49e0-4a9f-9966-9d3d01203aa5_0b7cbc1a-35f1-4db8-856b-9d3d01203a4c&selected = f98c9ad8-49e0-4a9f-9966-9d3d01203aa5_0cc7ef9b-085f-4b50-acdb-9d3d01203a4c-d9a3d9-a9c-d9d3d013a9c-d9d3d013a9c3d9a9d3d019a3d3d019a9d3d019a9d3d01a4a9d3d019a9d3d019a9d3d019a3d9a9d9d9d-d3d01203a4c3d9d9a3d9d9d3d013a3d9d-d3d013a9d3d01a9d-a9d-d9d3d01d3d9d-a9c-d9d-db3d01-a9c-a9c 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-9d9d9a9c9c9a9c9c9a9c9a9c9a9c9d9a9c9d9a9c9a9c9a9c9a9c9a9c9a9c9d3d01c9a9c9d3d01c3d9a9c9d9c9d9c9c9d9c9c9d3d01c3d9c9c9d3d01c3d9c3d9c3d9c3d01c3d9c3d9c9d9c9c9c9c9c9c9c9cbdfbffbffbffbffbfffbbfbbfbbfbbfbbfbbfbbfbbffbbfd 9d3d01203aa5&submit =添加+至+套房

已安装WireShark。没有直接控制就很难使用(远程用户遵循我的命令),但是我可以看到,单击“提交”后,TCP请求立即发送到服务器IP地址。因此,浏览器会发出一个请求。

要求远程用户与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

最佳答案

我强烈建议在服务器和客户端同时使用Wireshark,并查看实际发送了哪些数据。我遇到了类似的奇怪错误,并且看到每个客户端和服务器之间的实际通信总是很有启发性的。我将从服务器端开始。捕获数据包,然后在POST上使用“跟随tcp流”。
Wireshark Download
Using Wireshark

关于asp.net-mvc - SSL握手问题? (: Web page hangs,仅清除浏览器缓存帮助),我们在Stack Overflow上找到一个类似的问题:https://stackoverflow.com/questions/3531056/

10-17 00:06