asp.net-mvc – SSL握手问题？ (当时：网页挂起,只清除浏览器缓存有帮助)

我遇到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缓存/ cookie /表单和发布数据有助于 – 一次尝试,下一篇文章也会挂起.

此外,请求以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&安培;选择= f98c9ad8-49e0-4a9f-9966-9d3d01203aa5_5020b52f-baa2-4aea-be10-9d3d01203a4d&安培;选择= f98c9ad8-49e0-4a9f- 9966-9d3d01203aa5_8b2cd95a-c014-4c83-9ec6-9d3d01203a4d& SELEcted = f98c9ad8-49e0-4a9f-9966-9d3d01203aa5& submit = Add to Suite

已安装的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