5

最新の調査データを随時更新しておりますので、最後までご覧ください。現在、サーバー側の WireShark ログについてサポートが必要です。

ASP.NET MVC Web アプリケーションで奇妙な問題が発生します。フォーム ポストのタイムアウトやハングを経験するユーザーはほとんどいないため、[送信] をクリックした後は永遠に続き、次のページに進みません。奇妙なことに、これはブラウザのキャッシュをクリアすることで解決されます。この 2 つのことがどのように関連しているのか理解できません。また、ユーザーは FireFox 3+ で発生するが、FireFox 1.5 および 2.0 では発生しないと報告しています。私と多くのユーザーは、IE、FireFox、および Linux/Windows の両方でこれを再現できません。

ブラウザのキャッシュがフォームの POST 処理にどのように、またなぜ影響するのでしょうか?

OK ユーザーと FireBug に確認しました。POST リクエストが表示されますが、長いタイムアウトの後に失敗します。サーバーは要求を受信しません。少なくとも、ログを記録するベース コントローラーの OnBeforeExecuting や IIS ログ ファイルでは受信しません。応答は空です。また、リクエストに時間がかかりましたが、最終的に実行された後、サーバー上では実行にほとんど時間がかからないことがわかりました。

私が見る限り、これは jQuery Form プラグインで行われた AJAX リクエストで発生します。パラメータで cache: false を設定しようとしましたが、成功しませんでした。

実際、私はAJAXなしで試してみました.plain submit - 同じです。また、jQuery フォーム プラグインが $.ajax() を呼び出して戻ることもわかります。POST リクエストを開始していることがわかります。しかし、サーバーの IIS ログにこの要求が表示されないことがあります。1 分後になることもあれば、FireBug .Net ペインで中断されることもあります。

面白いことに、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

投稿データ

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

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 Firewall であることがわかりました (私の限られた理解から、ポップアップなどをブロックするため)。私は Sygate をシャットダウンし、現在ベアボーンの Windows ファイアウォールを使用していますが、問題は解決しました。

于 2010-12-18T11:11:04.537 に答える
0

IIS 6.0 を実行している Win2k3 サーバーから Mac ブラウザーが SSL ページをロードしないという同様の問題がありました。.net フレームワークを更新すると、Firefox と Camino の問題は修正されましたが、Safari の問題は修正されませんでした。AVG オンライン スキャナーを無効にすると Safari の問題は解決しましたが、リンク スキャナーがインストールされていませんでした。この投稿を見つけて、私の問題を修正しました。

ありがとう

于 2010-12-20T19:10:26.317 に答える
0

私が見つけたものから、それはAVGの問題のようです。LinkScanner と Online Shield (両方) の機能をオフにすると、Chrome と Safari からの POST 要求 (まったく機能しませんでした) が機能し始めます。

于 2010-11-18T19:53:25.813 に答える