サーバーがリクエストに応答する前に、エラーが表示されるまでブラウザはどのくらい待つことができますか?今回は無制限にできますか?
4 に答える
jQuery $ .ajax呼び出しを使用している場合は、timeoutプロパティを設定して、リクエストがタイムアウトステータスで戻るまでの時間を制御できます。タイムアウトはミリ秒単位で設定されるため、非常に高い値に設定するだけです。「無制限」の場合は0に設定することもできますが、私の意見では、代わりに高い値を設定する必要があります。
注:実際には無制限がデフォルトですが、ほとんどのブラウザーにはデフォルトのタイムアウトがあり、これがヒットします。
タイムアウトのためにajax呼び出しが返されると、「timeout」のエラーステータスで返されます。これは、必要に応じて別のケースで処理できます。
したがって、3秒のタイムアウトを設定し、タイムアウトを処理する場合は、次の例を使用します。
$.ajax({
url: "/your_ajax_method/",
type: "GET",
dataType: "json",
timeout: 3000, //Set your timeout value in milliseconds or 0 for unlimited
success: function(response) { alert(response); },
error: function(jqXHR, textStatus, errorThrown) {
if(textStatus==="timeout") {
alert("Call has timed out"); //Handle the timeout
} else {
alert("Another error was returned"); //Handle other error type
}
}
});
はいといいえ。はい、サーバーはそれを実行するか、実行するように構成できます。ブラウザー(バージョン/ディストリビューターの詳細についてはわかりません)でタイムアウトが有効になっている可能性はありません。
HTTPを介してこれを実現/エミュレートするには、2つの解決策があります。
- これが単純で長時間実行されるスクリプトであり、結果を待っている場合、これは進むべき道ではありません。代わりに、前のポスターで述べたように実行し、結果のサーバーポーリングで非同期処理を使用する必要があります。これは、はるかに確実な解決策になります。 。例:画像プロセッササーバー側からのサムネイルスクリプト:ユーザーが画像をアップロードすると、サーバーはすぐに200と「ジョブID」を返します。クライアント(javascript ^^)は、JobIDを使用してジョブのステータス/結果を要求できます。
- ブラウザとサーバー間のリアルタイム接続(一方向接続、ブラウザによってリクエストが行われると、新しいリクエストを使用せずにそれ以上の情報を送信することはできません(ajax ^^))のようなものを目標とする場合、これはロングポーリングと呼ばれます/ reverse ajaxであり、httpを介したリアルタイム通信に使用できます。2つの長いポーリングされた要求を並行して使用するいくつかの手法があり、そのうちの1つがタイムアウトすると、2番目の要求がアクティブになり、最初の要求が再接続を試みます。
あなたが達成しようとしていることについてもう少し説明できますか?サーバー上で長時間実行されているプロセスがありますか、ローカルマシンだけで設定を変更したいですか、それとも多数のマシンを管理する方法を求めていますか?ユーザーの?
ブラウザが待機する時間は、タイムアウトが発生する場所など、さまざまな要因によって異なります。TCPレベル、サーバー、またはローカルブラウザのいずれでしょうか。
サーバー上で長時間実行されているプロセスがあり、後でWebページを更新する場合、それを処理する一般的な方法は、長いプロセスを非同期で実行し、完了時にクライアントに通知することです。たとえば、サーバーをポーリングするajax呼び出しがあります。または、HTTP 1.1を使用して、クライアントに通知ストリームを提供します。
いずれの場合も、接続を閉じることは可能であるため、クライアントは接続を再度開くことができます。
通常の(HTMLページ)リクエストの場合、ブラウザはccaの後にタイムアウトするまで実行されることがわかりました。30秒 他の参加者がおそらくそれに続くので、それは重要です:プロキシ、ルーター(ルーターはこのゲームでプレイしますか?私にはわかりません)。4秒のサーバー側遅延を使用しており(クライアントに送信するものがない場合)、AJAXクライアントはすぐに別のHTTP要求を実行します(ローカルネットワーク上にあり、インターネットラグはありません)。4秒は、頻繁なポーリングでサーバーとネットワークに過負荷をかけないようにするのに十分な長さであり、クライアントが検出および処理できない行から1つのポーリングが失敗した場合には十分に短いです。
また、comet(長いHTTPリクエスト)には他にも問題があります:同時HTTPリクエストの数に対するブラウザの制限、クライアント側のイベントの処理(サーバーにすぐに送信する必要があります)、サーバー/ネットワークのダウン検出とリカバリ、マルチユーザー処理等