Bitte sehen Sie am Ende, wie ich ständig mit neuesten Untersuchungsdaten aktualisiere. Derzeit brauche ich Hilfe bei der serverseitigen WireShark-Protokollierung.
Ich habe seltsame Probleme mit ASP.NET MVC-Webanwendungen. Einige Benutzer erleben Form Post Timeouts und hängt, so dass nach dem Klicken auf Submit dauert es einfach ewig und nicht auf die nächste Seite weiter. Das Seltsame ist, dass dies durch das Löschen des Browser-Caches behoben wird. Ich verstehe nicht, wie diese beiden Dinge zusammenhängen können. Außerdem berichtete ein Benutzer, dass dies in FireFox 3+ passiert, aber nicht in FireFox 1.5 und 2.0. Ich und viele andere Benutzer können dies nicht reproduzieren, weder mit IE noch mit FireFox noch mit Linux/Windows.
Wie und warum kann der Browser-Cache die Verarbeitung von POST-Formularen beeinflussen?
OK, ich habe mit Benutzern und FireBug überprüft. Ich sehe die POST-Anfrage, und sie schlägt nach langem Timeout fehl. Der Server empfängt die Anforderung nicht - zumindest nicht im OnBeforeExecuting des Basiscontrollers, wo ich die Protokollierung durchführe, noch in den IIS-Protokolldateien. Die Antwort ist leer. Auch einmal die Anforderung dauerte lange Zeit, aber schließlich ausgeführt - und auf dem Server sehe ich, dass es sehr wenig Zeit, um auszuführen nimmt.
Soweit ich sehe, geschieht dies bei AJAX-Anfragen, die mit dem jQuery Form Plugin durchgeführt werden. Ich habe versucht, cache: false in Parameter, kein Erfolg.
Eigentlich habe ich versucht, ohne AJAX, plain submit - das gleiche. Ich kann auch sehen, dass jQuery Form Plugin DOES Aufruf $.ajax() und kehrt. Ich sehe, dass es POST-Anfrage initiiert. Aber ich sehe diese Anfrage nicht auf dem Server in den IIS-Protokollen, bis, manchmal, in einer Minute später - und manchmal wird es im FireBug .Net-Fenster abgebrochen.
Lustig ist, dass das Löschen von FireFox-Cache/Cookies/Formular- und Beitragsdaten hilft - bei einem Versuch bleibt der nächste Beitrag auch hängen.
Außerdem werden bei Anfragen Informationen über ausgewählte Komponenten in Form von GUIDs gesendet. Wenn die Komponenten nicht ausgewählt sind, scheint es gut zu funktionieren. Bei den Komponenten handelt es sich um versteckte Kontrollkästchen, die durch JavaScript aktiviert werden (nicht zum Zeitpunkt des Absendens, sondern früher). Dies ist der Parameter "selected" in den POST-Daten. Scheint, wie wenn es keine Komponenten ausgewählt sind, es nicht hängen, obwohl ich nur einmal versucht, vielleicht wird mehr später untersuchen.
Hat jemand eine Idee zu diesen zusätzlichen Informationen?
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-cachePOST-Daten
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
Installieren Sie WireShark. Ohne direkte Kontrolle ist es schwer zu benutzen (der entfernte Benutzer folgt meinen Befehlen), aber ich konnte sehen, dass sofort nach dem Klicken auf "Submit" eine TCP-Anfrage an die Server-IP-Adresse gesendet wurde. Der Browser führt also eine Anfrage aus.
Der Remote-Benutzer wird gebeten, mit dem IT-/Netzwerk-Support zusammenzuarbeiten, um zu prüfen, ob die Anfrage vom Client zum Server geht bzw. dort ankommt.
Und hier ist ein SEHR ähnliches Problem, leider ohne jede Antwort: https://stackoverflow.com/questions/3355000/my-iis-server-wont-serve-ssl-sites-to-some-browsers
Hier ist das WireShark-Protokoll des Servers. Die Übermittlung beginnt, dann erfolgt eine SSL-Änderung der Chiffre/Handshake (in 90 Sekunden!), und nach langer Zeit schlägt die Anfrage schließlich fehl.
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
