Please see at the end, as I constantly update with latest investigation data. Currently, I need help with server-side WireShark log.
I experience strange issues with ASP.NET MVC web application. Few users experience form post timeouts and hangs, so that after clicking submit it just lasts forever and does not advance to next page. The strange thing is, this is resolved by clearing browser's cache. I don't understand how these two things can be related. Also, a user reported that it happens in FireFox 3+, but does not happen in FireFox 1.5 and 2.0. Me and many users cannot reproduce this, on IE, any FireFox and both Linux/Windows.
How and why browser cache can affect form POST processing?
OK I checked with users and FireBug. I see the POST request, and it fails after long timeout. The server does not receive the request - at least, not the base controller's OnBeforeExecuting where I do logging, nor in the IIS log files. The response is empty. Also, once the request took long time but finally executed - and on the server I see that it takes very little time to execute.
As far as I see this happens on AJAX requests done with jQuery Form plugin. I tried setting cache: false in parameters, no success.
Actually, I tried without AJAX, plain submit - the same. I can also see that jQuery form plugin DOES call $.ajax() and returns. I see that it initiates POST request. But I don't see this request on the server in IIS logs, until, sometimes, in a minute later - and sometimes it gets aborted in FireBug .Net pane.
Funny thing, is that clearing FireFox cache/cookies/form&post data helps - for one attempt, next post also hangs.
Also, requests sends info about selected components in form of GUIDs. When components are not selected, it seems to work OK. Components are actually hidden checkboxes checked by JavaScript (not at the time of submit, earlier). This is the "selected" parameter in the POST data. Seems like when there're no components selected, it doesn't hang, though I only tried once, maybe will investigate more later.
Any thoughts with this additional info?
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
POST data
order=842f2988-abff-413c-a092-9dde00a8b9a8&selected=f98c9ad8-49e0-4a9f-9966-9d3d01203aa5_a1d659c0-b8ec-4f91-ba2f-9d3d01203a4c&selected=f98c9ad8-49e0-4a9f-9966-9d3d01203aa5_d6e1984e-227d-4bd0-b8d2-9d3d01203a4d&selected=f98c9ad8-49e0-4a9f-9966-9d3d01203aa5_0b7cbc1a-35f1-4db8-856b-9d3d01203a4c&selected=f98c9ad8-49e0-4a9f-9966-9d3d01203aa5_0cc7ef9b-085f-4b50-acdb-9d3d01203a4c&selected=f98c9ad8-49e0-4a9f-9966-9d3d01203aa5_ad273397-ed5d-49bb-b181-9d3d01203a4c&selected=f98c9ad8-49e0-4a9f-9966-9d3d01203aa5_b5fbf67f-202f-464b-a9e4-9d3d01203a4c&selected=f98c9ad8-49e0-4a9f-9966-9d3d01203aa5_ae275579-8163-4f6b-9d36-9d3d01203a4c&selected=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
Installed WireShark. It's hard to use without direct control (the remote user follows my commands) but I could see that immediately after clicking submit, a TCP request was send to the server IP address. So the browser does a request.
Asked remote user to collaborate with IT/network support to check if request goes from client / arrives to server.
And here is a VERY similar problem, unfortunately without any answer: http://stackoverflow.com/questions/3355000/my-iis-server-wont-serve-ssl-sites-to-some-browsers
Here's WireShark log from the server. Submit starts, then some SSL change cypher/handshake occurs (in 90 secs!), then after long time request finally fails.
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