| Oracle® Real User Experience Insightユーザーズ・ガイド 12c リリース6 (12.1.0.7) for Linux x86-64 E61771-02 |
|
 前 |
 次 |
| Oracle® Real User Experience Insightユーザーズ・ガイド 12c リリース6 (12.1.0.7) for Linux x86-64 E61771-02 |
|
前 |
次 |
この付録では、このWebサーバーによって生成され、リクエストに対する応答としてビジターに送信されるHTTP結果コードを説明します。
400番台のステータス・コードは、クライアントにエラーが発生したと思われるケースを対象としています。HEADリクエストに応答する場合を除き、サーバーには、エラー状況に関する説明と、エラーが一時的な状態と永続的な状態のどちらであるかの説明が記載されたエンティティが含まれます。これらのステータス・コードは、任意のリクエスト・メソッドに適用されます。ユーザー・エージェントは、含まれている任意のエンティティをユーザーに表示する必要があります。
クライアントがデータを送信する場合、TCPを使用したサーバーの実装は慎重に行う必要があります。つまり、サーバーが実行されている接続を閉じる前に、レスポンスが含まれるパケットの受信をクライアントが確認できるようにします。接続が閉じられた後もクライアントがデータをサーバーに送信し続けると、サーバーのTCPスタックはリセット・パケットをクライアントに送信します。リセット・パケットにより、クライアントが確認していない入力バッファは、HTTPアプリケーションが読み取って解釈する前に消去される可能性があります。
構文の形式が正しくないため、サーバーがリクエストを理解できませんでした。クライアントは、リクエストを変更しないままで繰り返さないようにする必要があります。
リクエストにはユーザー認証が必要です。レスポンスには、リクエストされたリソースに適用可能なチャレンジが含まれるWWW-Authenticateヘッダー・フィールド(RFC 2616ドキュメント、14.47項)を含める必要があります。クライアントは、適切なAuthorizationヘッダー・フィールドを使用してリクエストを繰り返すことができます。リクエストに認可資格証明がすでに含まれている場合は、401レスポンスはこの資格証明に対して認可が拒否されたことを示しています。401レスポンスに前のレスポンスと同じチャレンジが含まれ、ユーザー・エージェントがすでに少なくとも1回は認証を試行していた場合、このレスポンスに指定されていたエンティティは、関連する診断情報を含んでいる場合があるため、ユーザーに提供する必要があります。
現時点では、このコードはほとんどのWebサーバーで実装されていません。これは、将来使用するために予約されています。
サーバーはリクエストを理解しましたが、その遂行を拒否しています。この場合、認可は役に立たないため、リクエストを繰り返さないでください。リクエスト・メソッドがHEADでなく、リクエストが遂行されなかった理由をサーバーから公開する場合は、拒否の理由を前述のエンティティに記述する必要があります。サーバーでこの情報をクライアントに提供しない場合は、ステータス・コード404(Not Found)をかわりに使用できます。
Request-URIに一致するものが見つかりませんでした。この状態が一時的なものか永続的なものかを示す情報はありません。旧リソースが永続的に使用できず転送先アドレスがないことを、サーバーが内部構成可能なメカニズムを介して把握している場合は、410(Gone)ステータス・コードが使用されます。このステータス・コードは通常、リクエストが拒否された詳細な理由をサーバーで公開しない場合や、適用可能なレスポンスが他にない場合に使用されます。
Request-Lineに指定されたメソッドは、Request-URIによって識別されるリソースでは使用できません。レスポンスには、リクエストされたリソースに対して有効なメソッドのリストを含むAllowヘッダーを含める必要があります。
リクエストによって識別されたリソースは、リクエストで送信されたAcceptヘッダーによって受入れ不可となったコンテンツ特性を含むレスポンス・エンティティを生成することのみが可能です。
レスポンスがHEADリクエストでないかぎり、レスポンスにはエンティティを含める必要があります。このエンティティには、エンティティの特性および場所のリストを含めます。このリストから、ユーザーまたはユーザー・エージェントが最も適切な特性と場所を選択できます。エンティティの形式は、Content-Typeヘッダー・フィールドに指定されたメディア・タイプによって指定されます。ユーザー・エージェントの形式および機能に応じて、最も適切な選択肢が自動的に選択されます。ただし、この指定により、この自動選択の標準値が定義されることはありません。
HTTP/1.1サーバーは、リクエストで送信されたAcceptヘッダーに従って受入れ不可となったレスポンスを戻すことができます。場合によっては、406レスポンスを送信するよりもこの方が適切なこともあります。ユーザー・エージェントは、受信したレスポンスのヘッダーを調べてそれが受入れ可能かどうかを確認できます。
このコードは401(Unauthorized)と似ていますが、クライアントが最初にプロキシから認証を受ける必要があることを示します。プロキシは、Proxy-Authenticateヘッダー・フィールドを戻す必要があります。このフィールドには、リクエストされたリソースがあるかどうかについての、プロキシ自身に適用するチャレンジを含めます。クライアントは、適切なProxy-Authorizationヘッダー・フィールドを使用してリクエストを繰り返すことができます。
サーバーが待機するように設定されていた時間内に、クライアントがリクエストを生成しませんでした。クライアントは、後でいつでも、リクエストを変更しないで繰り返すことができます。
リソースの現在の状態と競合しているため、リクエストを完了できませんでした。このコードは、ユーザーが競合を解消してリクエストを再送できることが見込まれる状況でのみ使用できます。レスポンス本文には、ユーザーが競合のソースを認識するために十分な情報を含める必要があります。レスポンス・エンティティには、ユーザーまたはユーザー・エージェントが問題を解決するために十分な情報を含めることをお薦めします。ただし、これは不可能な場合があり、必須ではありません。
競合が最も発生しやすいのは、PUTリクエストに対するレスポンスにおいてです。たとえば、バージョニングが使用されており、PUTに含まれているエンティティが、前の(サード・パーティ・)リクエストによる変更と競合するリソースに変更された場合、サーバーで409レスポンスを使用して、リクエストを完了できないことを示す場合があります。このような場合は通常、レスポンス・エンティティには、レスポンス内のContent-Typeに定義された形式で2つのバージョン間の差異のリストを含めます。
リクエストしたリソースをサーバーで使用できなくなり、転送アドレスも不明です。この状況は永続的なものと想定されます。リンク編集機能を持つクライアントは、ユーザー承認の後でRequest-URIへの参照を削除する必要があります。この状況が永続的であるかどうかをサーバーが特定できない、またはそのことを判断する機能がサーバーにない場合は、ステータス・コード404(Not Found)をかわりに使用する必要があります。このレスポンスはキャッシュ可能です(キャッシュ不可と指定されていない場合)。
410レスポンスは基本的に、リソースが意図的に使用できなくなっていることと、サーバー所有者がこのリソースに対するリモート・リンクの削除を求めていることを受信者に通知することで、Webのメンテナンス・タスクを支援することを目的としています。このようなケースがよく発生するのは、期間を限定した販売促進サービスや、サーバーのサイトで勤務しなくなった個人に属するリソースにおいてです。永続的に使用できないすべてのリソースをgoneとしてマークしたり、一定期間にわたってマークを保持する必要はありません。これはサーバー所有者の判断に任されます。
サーバーは、Content-Lengthが定義されていないリクエストの受入れを拒否しています。クライアントは、メッセージ本文の長さを含む有効なContent-Lengthヘッダー・フィールドをリクエスト・メッセージに追加することにより、このリクエストを繰り返すことができます。
1つ以上のリクエスト・ヘッダー・フィールドに指定された事前条件が、サーバーでテストされたときに、falseと評価されました。クライアントはこのレスポンス・コードを使用して、現在のリソース・メタ情報(ヘッダー・フィールド・データ)に事前条件を設定できます。これにより、リクエストされたメソッドが目的外のリソースに適用されるのを阻止できます。
サーバーが処理できる長さをリクエスト・エンティティが超えているため、サーバーはリクエストの処理を拒否しています。サーバーは、クライアントがリクエストを続行するのを阻止するために、接続を閉じることができます。
この状況が一時的なものである場合、サーバーはRetry- Afterヘッダー・フィールドを含めることにより、この状況が一時的なものであることと、クライアントが再試行可能になるまでの時間を示す必要があります。
サーバーが解釈できる長さをRequest-URIが超えているため、サーバーはリクエストの処理を拒否しています。この状況はまれにしか発生しませんが、このような状況が発生するのは、クライアントが長い問合せ情報を持つPOSTリクエストをGETリクエストに不正に変換した場合、クライアントがURIのリダイレクションのブラックホールに陥った(リダイレクトされたURI接頭辞がそれ自体の接尾辞を指し示している)場合、または固定長のバッファを使用してRequest-URIを読み取ったり操作するために、一部のサーバー上に存在するセキュリティ・ホールを利用しようとしているクライアントの攻撃をサーバーが受けている場合のいずれかが考えられます。
リクエストされたメソッドに対するリクエストのエンティティが、リクエストされたリソースではサポートされていない形式であるため、サーバーはリクエストの処理を拒否しています。
サーバーがこのステータス・コードを使用してレスポンスを戻す必要があるのは、リクエストにRangeリクエスト・ヘッダー・フィールド(RFC 2616ドキュメント、14.35項)が含まれ、このフィールド内の範囲指定子の値のいずれもが、選択されたリソースの現在のエクステントと重複せず、リクエストにIf-Rangeリクエスト・ヘッダー・フィールドが含まれていない場合です。(バイト範囲の場合、このステータス・コードは、byte-range-specのすべての値のfirst-byte-posが、選択したリソースの現在の長さより大きいことを意味します)。
バイト範囲のリクエストに対してこのステータス・コードが戻された場合、レスポンスには、選択したリソースの現在の長さを指定するContent-Rangeエンティティ・ヘッダー・フィールドを含める必要があります(RFC 2616ドキュメント、14.16項を参照)。このレスポンスでは、複数パートまたはバイト範囲のContent-Typeは使用しないでください。
数値5で始まるレスポンス・ステータス・コードは、エラーがあることやリクエストの実行が不可能であることをサーバーが認識しているケースを示しています。HEADリクエストに応答する場合を除き、サーバーには、エラー状況に関する説明と、エラーが一時的な状態と永続的な状態のどちらであるかの説明が記載されたエンティティが含まれます。ユーザー・エージェントは、含まれている任意のエンティティをユーザーに表示する必要があります。これらのレスポンス・コードは、任意のリクエスト・メソッドに適用されます。
サーバーは、リクエストを遂行するために必要な機能をサポートしていません。これは、サーバーがリクエスト・メソッドを認識しておらず、リソースに対してそのメソッドをサポートできない場合に適したレスポンスです。
RFC 2616ドキュメントの10項では、これは502 Bad Gatewayとして記載されています。サーバーは、ゲートウェイまたはプロキシとして動作中に、リクエストを遂行しようとしてアクセスしたアップストリーム・サーバーから無効なレスポンスを受け取りました。
サーバーは現在、サーバーの一時的な過負荷状態またはメンテナンスのため、リクエストを処理できません。つまり、これは多少の遅延後に緩和される一時的な状況であるということです。遅延の長さは、判明している場合にはRetry-Afterヘッダーに示される場合があります。
|
注意: 503ステータス・コードは、サーバーが過負荷状態になったときに必ずしも使用する必要があるわけではありません。接続を拒否するのみでもかまいません。 |
RFC 2616ドキュメントの10項では、これは504 Gateway Timeoutとして記載されています。サーバーは、ゲートウェイまたはプロキシとして動作中に、リクエストを完了するためにアクセスする必要があった、URI(HTTP、FTPまたはLDAPなど)によって指定されたアップストリーム・サーバーまたは他の補助サーバー(DNSなど)から、適時にレスポンスを受け取りませんでした。
|
注意: DNS参照がタイムアウトしたときに、デプロイされている一部のプロキシは400または500を戻すことが判明しています。 |
クライアントによってリクエストされたがサーバーがまったく応答しなかったヒット数です。これは、サーバー・エラーまたはネットワーク・エラー(あるいはその両方)が原因です。
ネットワーク・エラーとは、TCPレベルのビューから完全な配信が行われなかったヒットです。これには、複数の原因が考えられます。
server-abort
このステータスは、サーバー関連の接続に関する問題を示します。次のいずれかの状況がレポートされます。
サーバーが接続をリセットしました。
これは、サーバー・アプリケーションの問題を示します。すべてのデータが正しく送信または受信されたかどうかを確認できません。
サーバーが不正なデータを送信しました。
サーバーから送信されたデータの形式が正しくないため、上位レベルのHTTP情報を抽出できません。この原因には、パケット・ロスや順序が乱れた多数のパケットなどの多くの要因があります。
クライアントが認識されなくなりました。
クライアントが突然認識されなくなる場合があります(コンピュータまたはモデムのクラッシュ、ISPの停止、あるいは接続が即時切断される原因となる他のハードウェア障害など)。この状況はサーバー・エラーとして現れます。つまり、サーバーが最終的にタイムアウトしたり、接続がリセットされます。クライアントが受信した送信データの量は確認できません。
ビジターへの影響
ビジターは、サーバー・エラー・メッセージを受信します。または、少なくとも、リクエストした情報以外を受信します。場合によっては、部分的に受信した情報がビジターに示されることがあります。多くの場合、これは、サーバーに問題があることを示します。
使用方法
サーバー・エラーは繰り返し発生しないようにする必要があります。多数のサーバー・エラーがレポートされる場合、ネットワーク・プロトコル分析(NPA)ツールを使用してネットワークおよびサーバー・コンポーネントを調べる必要があります。
サーバー・エラーの原因を分析するための指標:
負荷: サーバーまたはロード・バランサ(あるいはその両方)に対する接続が多すぎると、リソースの問題が発生する可能性があります。
バランサ: すべてのサーバー間で負荷が適切に分散されていますか。または、常に1つのサーバーが過負荷状態になっていたりエラーを生成していますか。
URL: 特定のアプリケーションURLのみがこのタイプの問題を起こしていますか。
server-timeout
サーバー・タイムアウトは、サーバーがクライアントからのリクエストに対する応答に失敗した場合に発生します。タイムアウト状況では、サーバーは回線を介してデータを送信しません。つまり、レスポンスまたはレスポンスの一部が送信されません。(サーバーの中断は、完了ステータス4としてレポートされます)。
この完了ステータスの正確な意味は、次のとおりです。
クライアントは完全なHTTPリクエストを送信しました。
サーバーからデータがいっさい返送されませんでした。
|
注意: タイムアウトは、データが送信されなかったことを示します。つまり、サーバーのTCPスタックは、クライアントのリクエストが受信されたことを確認セグメントの送信によって確認している可能性もありますが、サーバー・アプリケーション自体がデータを返送できません。 |
ビジターへの影響
クライアントはコンテンツを受信していません。サーバーが単に応答に失敗しました。これは、ネットワークまたはサーバー・アプリケーションに問題があるにすぎないことを示している場合があります。
使用方法
サーバーのタイムアウトの原因は、この問題が発生したネットワークを分析することによって調べることができます。サーバーのタイムアウトは散発的にしか発生しないため、影響を受けるリクエストの割合が多くないかぎり、問題とみなさないでください。すべてのクライアントでタイムアウトが発生する割合が高い場合は、ネットワーク分析ツールおよびアプリケーション・パフォーマンス・テスト・ツールを使用して、ネットワークおよびサーバー・コンポーネントを調べてください。
network-timeout
受信したクライアントまたはサーバーのヘッダーのパケットが切り捨てられています。これは、ネットワークの問題によるタイムアウトが原因です。
これは、通常はネットワーク・エラーとみなす必要がある例外です。ただし、この問題の原因は顧客が解決できるものではないため、通常は標準の動作とみなされます。このため、この問題は、失敗のキューブには追加されず、このヒットは成功とみなされます。
client-abort
ページのロード中に、クライアントがブラウザを閉じる、リロードをクリックする、何かをクリックして他のページに移動する、またはリダイレクトされた可能性があるために、転送が中断されました。
