ネットワークエラーロギング

ネットワークリクエストは、 ユーザーエージェントが、指定されたHTTP ネットワークフェッチによってネットワーク経由でリソースを リクエストしようとすると発生します。

ユーザー エージェントがオフラインであることが分かっている場合（すなわち、navigator. onLine が false を返す場合）、リクエストによってネットワークリクエストが発生してはなりません。

リクエストがネットワークリクエストを発生させてはならないのは、それが 混在コンテンツまたは CORS の失敗によってブロックされた場合です。すべての CORS プリフライトリクエストは、それ自体の ネットワークリクエストを発生させなければなりません。

使用されるフェッチアルゴリズム、基盤となるアプリケーションプロトコルおよび トランスポートプロトコルにかかわらず、ネットワークリクエストの処理は、 次の フェーズで構成されます。

1. DNS 名前解決: ユーザーエージェントは Domain Name System [RFC1034] を使用して、ドメイン名を、そのドメインへの HTTP リクエストを処理できる サーバーの IP アドレスへ解決します。
2. 安全な接続の確立: ユーザーエージェントは サーバーへの接続を開き、この接続上に安全なチャネルを 確立します。
3. リクエストおよびレスポンスの送信: 安全な チャネルが確立されると、ユーザーエージェントは HTTP リクエストを送信し、レスポンスを サーバーから受信できます。

必須の フェーズは リクエストおよびレスポンスの 送信のみです。他の フェーズは、すべての ネットワークリクエストで必要になるとは限りません。たとえば、DNS の結果は ユーザーエージェント内でローカルにキャッシュできるため、同じドメインへの以後のリクエストでは DNS 名前解決を省略できます。 同様に、HTTP 持続的接続では、 同じネットワークパーティションキーへの複数のリクエストで開いている接続を共有できます。ただし、複数の フェーズが 発生する場合、それらは 上記の順序で発生します。

ユーザーエージェントが サーバーから有効な HTTP レスポンスを受信でき、そのレスポンスに 4xx または 5xx ステータスコードが含まれない場合、ネットワークリクエストは成功です。

ネットワークリクエストが成功していない場合、そのリクエストは失敗です。

ネットワークエラーとは、 ネットワークリクエストを失敗させたエラー状態です。

各 ネットワークエラーには、文字列である型があります。

各 ネットワークエラーには、エラーがどのフェーズで 発生したかを記述するフェーズがあります。

dns

エラーは DNS 名前解決中に発生しました

connection

エラーは 安全な接続の 確立中に発生しました

application

エラーは リクエストおよび レスポンスの送信中に発生しました

6. 定義済みのネットワーク エラー型では、いくつかの定義済み ネットワークエラー 型が定義されています。

ネットワークエラーレポートとは、Reporting API のレポートであり、 ネットワークエラーを記述します。

ネットワークエラーレポートのレポート 型は network-error です。

ネットワークエラーレポートは、 ReportingObserver から見えるものではありません。

NEL ポリシーは、 ネットワークリクエストについてのレポートをオリジンに対して収集するかどうか、収集する場合はどこに送信するかをユーザーエージェントに指示します。 NEL ポリシーは HTTP レスポンスヘッダーを介してユーザーエージェントに配信されます。

各 NEL ポリシーには、ユーザーエージェントがこの NEL ポリシーを受信したサーバーの IP アドレスである受信 IP アドレスがあります。

各 NEL ポリシーにはオリジンがあります。

各 NEL ポリシーには、include または exclude のいずれかであるサブドメインフラグがあります。

各 NEL ポリシーには、リクエストヘッダーのリストと、レスポンス ヘッダーのリストがあり、それぞれはヘッダー 名のリストです。

各 NEL ポリシーには報告グループがあり、これはこのポリシーのレポートが 送信される Reporting エンドポイントグループの名前です。

各 NEL ポリシーには、ポリシーが有効であり続ける 秒数を表す ttl があります。

各 NEL ポリシーには、ユーザーエージェントがポリシーを受信した時刻を表す タイムスタンプである 作成時刻があります。

NEL ポリシーは、その 作成時刻からウォール クロックの安全でない現在時刻までの経過時間が 172800 秒（48 時間）を超える場合、古い状態です。

NEL ポリシーは、その 作成時刻からウォール クロックの安全でない現在時刻までの経過時間が、その ttl（秒単位）を超える場合、期限切れです。

大量のトラフィックを処理することを想定しているオリジンは、そのオリジンに対して行われるすべての ネットワークリクエストについて NEL レポートを取り込む設備を備えていない可能性があります。オリジンは、各ユーザーエージェントが 送信する NEL レポートの数を制限するために、サンプリング レートを定義できます。通常、成功したリクエストは 失敗したリクエストを大幅に上回るはずなので、オリジンはそれぞれに異なる サンプリングレートを指定できます。

各 NEL ポリシーには、0.0 以上 1.0 以下の 数値である成功サンプリングレートがあります。

各 NEL ポリシーには、0.0 以上 1.0 以下の 数値である失敗サンプリングレートがあります。

適合するユーザーエージェントは、（ネットワークパーティションキー、オリジン）のタプルをキーとして、一連の NEL ポリシーを保持する ストレージ機構であるポリシーキャッシュを提供しなければなりません。

このストレージ機構は不透明で、ベンダー固有であり、Web には公開されませんが、この文書で定義する アルゴリズムで使用される次のメソッドを提供しなければなりません。

• NEL ポリシーを挿入、更新、および削除する。
• 指定されたオリジン およびネットワークパーティションキーに対応する NEL ポリシーが存在する場合、それを取得する。
• キャッシュを消去する。

NEL レスポンスヘッダーは、 オリジンの NEL ポリシーをユーザーエージェントに伝達するために使用されます。 NEL ヘッダーの ABNF (Augmented Backus-Naur Form) [RFC5234] 構文は次のとおりです。

NEL = json-field-value

ヘッダーの値は、 json-field-value で定義される JSON オブジェクトの配列として解釈されます。配列内の各オブジェクトは、 オリジンに対する NEL ポリシーを定義します。ユーザーエージェントは、配列内の最初の有効な ポリシーを処理し、配列内の追加のポリシーを無視しなければなりません。

ユーザーエージェントは、この仕様で定義された構文に適合しない未知または無効なフィールドまたは値を 無視しなければなりません。有効な NEL ヘッダーフィールドは、少なくとも、この仕様で定義されるすべての 「必須」フィールドを含む1つのオブジェクトを 含まなければなりません。

ユーザーエージェントは、スクリプティング攻撃によるエラー報告の乗っ取りを軽減するため、 meta 要素によって指定された NEL ヘッダーを無視しなければなりません。 NEL ポリシーは、 NEL レスポンスヘッダーを介して配信されなければなりません。

ネットワークリクエスト（request）と、それに対応する レスポンス（response）が与えられたとき、このアルゴリズムは、 request のオリジンに対する NEL ポリシーを抽出し、それに応じて ポリシーキャッシュを更新します。

1. 次の条件のいずれかが真である場合、これらの手順を中止します。
   • request の オリジンに対して「オリジンは潜在的に 信頼できるか？」アルゴリズムを実行した結果が Potentially Trustworthy ではない。
   • response に、名前が NEL であるレスポンスヘッダーが 含まれていない。
2. origin を request のオリジンとします。
3. key を、request の 予約済みクライアントを与えて、 ネットワーク パーティションキーを決定するを呼び出した結果とします。
4. header を、名前が NEL であるレスポンスヘッダーの値とします。
5. list を、header に対して [HTTP-JFV] の第4節で定義されたアルゴリズムを実行した結果とします。そのアルゴリズムが エラーになる場合、または list が空の場合、これらの 手順を中止します。
6. item を list の最初の要素とします。
7. item に max_age という名前のメンバーがない場合、またはその メンバーの値が数値でない場合、これらの手順を中止します。
8. item の max_age メンバーの値が 0 の場合、ポリシー キャッシュから、そのオリジンが origin であるすべての NEL ポリシーを削除し、残りの手順をスキップします。
9. item に report_to という名前のメンバーがない場合、またはその メンバーの値が文字列でない場合、これらの手順を中止します。
10. item に success_fraction という名前のメンバーがあり、 その 値が 0.0 以上 1.0 以下の範囲の数値でない場合、これらの 手順を中止します。
11. item に failure_fraction という名前のメンバーがあり、 その 値が 0.0 以上 1.0 以下の範囲の数値でない場合、これらの 手順を中止します。
12. item に request_headers という名前のメンバーがあり、その 値がリストでない場合、またはそのリスト内のいずれかの要素が文字列でない場合、 これらの手順を中止します。
13. item に response_headers という名前のメンバーがあり、 その 値がリストでない場合、またはそのリスト内のいずれかの要素が文字列でない場合、 これらの手順を中止します。

14. policy を、プロパティが次のように設定された新しい NEL ポリシーとします。

    受信 IP アドレス

    ユーザーエージェントが response を受信したサーバーの IP アドレス

    編集者注

    [FETCH] でこれをより明示的に受け渡すようにします。

    オリジン

    origin

    サブドメインフラグ

    item に include_subdomains という名前のメンバーがあり、その値が true の場合は include、 それ以外の場合は exclude

    リクエストヘッダー

    item の request_headers メンバーの値

    レスポンスヘッダー

    item の response_headers メンバーの値

    報告グループ

    item の report_to メンバーの値

    ttl

    item の max_age メンバーの値

    作成時刻

    ウォールクロックの安全でない現在時刻

    成功サンプリングレート

    item の success_fraction メンバーが 存在する場合はその値、それ以外の場合は 0.0

    失敗サンプリングレート

    item の failure_fraction メンバーが 存在する場合はその値、それ以外の場合は 1.0

15. （key、origin）に対応するエントリが ポリシーキャッシュにすでに存在する場合は、それを policy に置き換えます。それ以外の場合は、（key、origin）について policy を ポリシーキャッシュに挿入します。

ネットワークリクエスト（request）が与えられたとき、このアルゴリズムは、 ポリシーキャッシュ内のどの NEL ポリシーを、その ネットワークリクエストについてのレポート生成に 使用すべきかを決定します。

1. origin を request のオリジンとします。
2. key を、request の 予約済みクライアントを与えて、 ネットワーク パーティションキーを決定するを呼び出した結果とします。
3. （key、 origin）についてポリシーキャッシュにエントリがある場合:
   1. policy をそのエントリとします。
   2. policy が期限切れでない場合、それを返します。
4. origin とスーパードメイン一致する各 parent origin について:
   1. （key、parent origin）についてポリシーキャッシュに エントリがある場合:
      1. policy をそのエントリとします。
      2. policy が期限切れでなく、その サブドメインフラグが include の場合、 それを返します。
5. no policy を返します。

ネットワークリクエスト（request）と NEL ポリシー（policy）が与えられたとき、このアルゴリズムはポリシーの指示に従って リクエストからヘッダー値を抽出します。

1. headers を新しい空の ECMAScript オブジェクトとします。
2. policy のリクエストヘッダーリスト内の各 header name について:
   1. request のヘッダーリストが header name を含まない場合、 リスト内の次の header name に進みます。
   2. values を空の ECMAScript リストとします。
   3. request の ヘッダーリスト内で、名前が header name である各 header について、header の 値を values に追加します。
   4. 名前が header name で、値が values である新しいプロパティを headers に追加します。
3. headers を返します。

レスポンス（response）と NEL ポリシー （policy）が与えられたとき、このアルゴリズムはポリシーの指示に従って レスポンスからヘッダー値を抽出します。

1. headers を新しい空の ECMAScript オブジェクトとします。
2. policy のレスポンスヘッダーリスト内の各 header name について:
   1. response のヘッダーリストが header name を含まない場合、 リスト内の次の header name に進みます。
   2. values を空の ECMAScript リストとします。
   3. response の ヘッダーリスト内で、名前が header name である各 header について、header の値を values に追加します。
   4. 名前が header name で、値が values である新しいプロパティを headers に追加します。
3. headers を返します。

ネットワークリクエスト（request）とそれに対応する レスポンス（response）が与えられたとき、このアルゴリズムは、一致するいずれかの NEL ポリシーによって指示されている場合、request についてのレポートを生成し、 レポートと NEL ポリシーを返します。それ以外の場合、この アルゴリズムは null を返します。

1. request のオリジンに対して「オリジンは潜在的に 信頼できるか？」アルゴリズムを実行した結果が Potentially Trustworthy ではない場合、null を返します。
2. origin を request のオリジンとします。
3. policy を、request に対して 5.1 リクエスト用のポリシーを選択するを実行した結果とします。 policy が no policy の場合、null を返します。
4. このリクエストに対する有効なサンプリングレートを決定します。
   • request が成功した場合、sampling rate を policy の成功サンプリング レートとします。
   • request が失敗した場合、sampling rate を policy の失敗サンプリングレートとします。
5. このリクエストについて報告するかどうかを決定します。roll を 0.0 以上 1.0 以下の乱数とします。roll > sampling rate の場合、null を返します。
6. report body を、次のプロパティを持つ新しい ECMAScript オブジェクトとします。 [ECMA-262]

   sampling_fraction

   sampling rate

   elapsed_time

   リソースのフェッチ開始から、完了するかユーザーエージェントによって中止されるまでに 経過したミリ秒数。

   phase

   request が失敗した場合、その ネットワーク エラーのフェーズ。request が成功した場合は "application"。

   type

   request が失敗した場合、その ネットワークエラーの型。request が成功した場合は、 "ok"。

7. report body の phase プロパティが dns でない場合、次のプロパティを report body に追加します。

   server_ip

   利用可能な場合、ユーザーエージェントがリクエストを送信したサーバーの IP アドレス。 それ以外の場合は空文字列。

   • IPv4 アドレスによって識別されるホストは、 ドット付き10進表記（0 から 255 の範囲の4つの10進数を "." で区切った並び）で表されます。[RFC1123]
   • IPv6 アドレスによって識別されるホストは、 8個の16ビット部分の順序付きリスト（ x:x:x:x:x:x:x:x の並びで、各 'x' はアドレスの8個の16ビット部分を表す 1〜4桁の16進数字）として表されます。[RFC4291]

   protocol

   利用可能な場合、ALPN Protocol ID によって識別される、リソースの取得に使用された ネットワークプロトコル。 それ以外の場合は ""。

8. report body の phase プロパティが dns または connection でない場合、次の プロパティを report body に追加します。

   referrer

   request のクライアントに関連付けられたリファラーポリシーによって決定された request のリファラー。

   method

   request の リクエストメソッド。

   request_headers

   request と policy に対して 5.2 リクエストヘッダーを抽出するを実行した結果。

   response_headers

   response と policy に対して 5.3 レスポンスヘッダーを抽出するを実行した結果。

   status_code

   利用可能な場合、HTTP レスポンスのステータスコード。それ以外の場合は 0。

9. origin が policy のオリジンと等しくなく、policy の サブドメインフラグが include であり、report body の phase プロパティが dns でない場合、 null を返します。
   注記

   この手順により、サブドメインの NEL ポリシーは、リクエストのDNS 名前解決 フェーズ中に限り、 ポリシーオリジンのサブドメインについてのレポート生成に使用できます。 詳細については 9. プライバシーに関する考慮事項を参照してください。

10. report body の phase プロパティが dns でなく、report body の server_ip プロパティが空でなく、かつ policy の受信 IP アドレスと等しくない場合:
    1. report body の phase を dns に設定します。
    2. report body の type を dns.address_changed に設定します。
    3. report body の request_headers、 response_headers、status_code、および elapsed_time プロパティを消去します。
    4. 表明: DNS 名前解決中に利用できない 情報から派生した report body のすべてのフィールドが 消去されています。
    注記

    この手順は、サーバーと ポリシーの IP アドレスが一致しない場合、NEL レポートを 「格下げ」します。 これはプライバシー保護であり、NEL レポートがそのレポートで記述されるサービスの 所有者にのみ送信されることを保証します。IP アドレスが一致しない場合、ユーザーエージェントが検証できるのは、 NEL ポリシーがオリジンの ドメイン名の所有者によって送信されたことだけです。このポリシーが、その サーバーの所有者によって送信されたことは検証できません。このドメイン名はそのサーバーに解決されます。したがって、 レポートを格下げして、 DNS 名前解決に関する情報のみを含むようにします。詳細については 9. プライバシーに 関する考慮事項および 7.5 複数の IP アドレスを持つオリジンを参照してください。

11. policy が古い場合、policy を ポリシーキャッシュから削除します。
12. report body と policy を返します。

ECMAScript オブジェクト（report body、通常は ネットワークエラー レポートを生成するから返された後、呼び出し側の仕様によって拡張されたもの）と、それに 一致する NEL ポリシー（policy）およびネットワークリクエスト （request）が与えられたとき、このアルゴリズムはレポートを配信用にキューに入れます。

1. url を request の URL とします。

2. url のフラグメントを消去します。

3. report body の phase プロパティが dns または connection の場合:

   1. url のパスおよびクエリを消去します。

4. 次のパラメーターを与えてネットワークレポートを生成するを実行します。

   型

   network-error

   データ

   report body

   エンドポイントグループ

   policy の報告グループ

   url

   url に対してURL シリアライザーを実行した結果。

この節のすべての ネットワークエラーは DNS 名前解決中に発生するため、フェーズは dns です。

dns.unreachable

DNS サーバーに到達できない

dns.name_not_resolved

DNS サーバーは応答したが、アドレスを解決できない

dns.failed

前述のエラーに該当しない理由により DNS サーバーへのリクエストが失敗した

dns.address_changed

対応する NEL ポリシーが受信されて以降、リクエストのオリジンについて 解決された IP アドレスが変更されたことを示す

この節のすべての ネットワークエラーは 安全な 接続の確立中に発生するため、 フェーズは connection です。

tcp.timed_out

サーバーへの TCP 接続がタイムアウトした

tcp.closed

TCP 接続がサーバーによって閉じられた

tcp.reset

TCP 接続がリセットされた

tcp.refused

TCP 接続がサーバーによって拒否された

tcp.aborted

TCP 接続が中止された

tcp.address_invalid

IP アドレスが無効である

tcp.address_unreachable

IP アドレスに到達できない

tcp.failed

前述のエラーに該当しない理由により TCP 接続が失敗した

tls.version_or_cipher_mismatch

バージョンまたは暗号スイートの不一致により TLS 接続が中止された

tls.bad_client_auth_cert

無効なクライアント証明書により TLS 接続が中止された

tls.cert.name_invalid

無効な名前により TLS 接続が中止された

tls.cert.date_invalid

無効な証明書の日付により TLS 接続が中止された

tls.cert.authority_invalid

無効な発行機関により TLS 接続が中止された

tls.cert.invalid

無効な証明書により TLS 接続が中止された

tls.cert.revoked

失効したサーバー証明書により TLS 接続が中止された

tls.cert.pinned_key_not_in_cert_chain

キーピニングエラーにより TLS 接続が中止された

tls.protocol.error

TLS プロトコルエラーにより TLS 接続が中止された

tls.failed

前述のエラーに該当しない理由により TLS 接続が失敗した

この節のすべての ネットワークエラーは、 リクエストおよびレスポンスの送信中に発生するため、 フェーズは application です。

http.error

ユーザーエージェントはレスポンスを正常に受信したが、そのレスポンスのステータスコードが 4xx または 5xx だった

http.protocol.error

HTTP プロトコルエラーにより接続が中止された

http.response.invalid

レスポンスが空である、content-length が一致しない、不適切なエンコーディングがある、および／またはユーザーエージェントが レスポンスを処理できないその他の状態がある

http.response.redirect_loop

リダイレクトループが検出されたためリクエストが中止された

http.failed

前述のエラーに該当しない HTTP プロトコル上のエラーにより接続が失敗した

abandoned

リソースの取得が完了する前にユーザーが中止した

unknown

エラー型が不明である

> GET / HTTP/1.1
> Host: example.com

< HTTP/1.1 200 OK
< ...
< Report-To: {"group": "network-errors", "max_age": 2592000,
              "endpoints": [{"url": "https://example.com/upload-reports"}]}
< NEL: {"report_to": "network-errors", "max_age": 2592000}

この NEL ヘッダーは NEL ポリシーを定義し、 example.com に関するネットワークエラーを network-errors という名前のエンドポイントグループに報告するようユーザーエージェントに指示します。この ポリシーは2592000秒（30日間）適用されます。

上記の登録は、レスポンスが潜在的に信頼できるオリジンから通信された場合にのみ成功することに注意してください。

> GET / HTTP/1.1
> Host: example.com

< HTTP/1.1 200 OK
< ...
< NEL: {"max_age": 0}

この NEL ヘッダーは、example.com に対する 既存の NEL ポリシーをすべて削除するようユーザーエージェントに指示します。

この節には、登録済みの NEL ポリシーを持つ オリジンでネットワークエラーが発生した際に、 ユーザーエージェントがキューに入れる可能性のある ネットワークエラー レポートの例を示します。 レポートをアップロードする際に [REPORTING] API によって作成される 完全なレポートペイロードを示します。ペイロードの body フィールドには、 ネットワークエラーのレポート本文が含まれます。

{
  "age": 0,
  "type": "network-error",
  "url": "https://www.example.com/",
  "body": {
    "sampling_fraction": 0.5,
    "referrer": "http://example.com/",
    "server_ip": "2001:DB8:0:0:0:0:0:42",
    "protocol": "h2",
    "method": "GET",
    "request_headers": {},
    "response_headers": {},
    "status_code": 200,
    "elapsed_time": 823,
    "phase": "application",
    "type": "http.protocol.error"
  }
}

このレポートは、ユーザーエージェントが example.com から www.example.com へのナビゲーションを試み、 2001:DB8::42 への名前解決に成功したことを示しています。しかし、 ユーザーエージェントは HTTP/2（h2）プロトコルを介してサーバーから 200 レスポンスを受信したものの、 通信中にプロトコルエラーが発生し、ナビゲーションを中止せざるを得ませんでした。 ユーザーエージェントは、ナビゲーション開始から823ミリ秒後にナビゲーションを中止しました。 最後に、ユーザーエージェントはネットワークエラーの発生直後にこのレポートを送信しました。 すなわち、レポートの経過時間は0です。

{
  "age": 0,
  "type": "network-error",
  "url": "https://widget.com/thing.js",
  "body": {
    "sampling_fraction": 1.0,
    "referrer": "https://www.example.com/",
    "server_ip": "",
    "protocol": "",
    "method": "GET",
    "request_headers": {},
    "response_headers": {},
    "status_code": 0,
    "elapsed_time": 143,
    "phase": "dns",
    "type": "dns.name_not_resolved"
  }
}

上記のレポートは、ユーザーエージェントが https://www.example.com/ から https://widget.com/thing.js を取得しようとしたことを示しています。しかし、ユーザーエージェントは DNS 名（widget.com）を解決できず、リクエストは 143ミリ秒後にユーザーエージェントによって中止されました。 widget.com への以前のリクエストによって有効な NEL ポリシーが配信されていたため、ユーザーエージェントはこのリクエストについてネットワークエラー レポートを生成します。レポートは ネットワークエラーの発生直後にアップロードされました。すなわち、レポートの経過時間は 0です。

> GET / HTTP/1.1
> Host: example.com

< HTTP/1.1 200 OK
< ...
< Report-To: {"group": "network-errors", "max_age": 2592000,
              "endpoints": [{"url": "https://example.com/upload-reports"}]}
< NEL: {"report_to": "network-errors", "max_age": 2592000, "include_subdomains": true}

この NEL ヘッダーにより、 example.com の所有者は、自身の DNS サーバーを誤って構成した場合を検出できます。たとえば、 new-subdomain.example.com を IP アドレスに解決する新しいリソースレコードを追加し忘れた場合です。ユーザーエージェントが new-subdomain.example.com にリクエストを送信しようとすると、次の レポートを生成する可能性があります。

{
  "age": 0,
  "type": "network-error",
  "url": "https://new-subdomain.example.com/",
  "body": {
    "sampling_fraction": 1.0,
    "server_ip": "",
    "protocol": "http/1.1",
    "method": "GET",
    "request_headers": {},
    "response_headers": {},
    "status_code": 0,
    "elapsed_time": 48,
    "phase": "dns",
    "type": "dns.name_not_resolved"
  }
}

> GET / HTTP/1.1
> Host: example.com

< HTTP/1.1 200 OK
< ...
< Report-To: {"group": "network-errors", "max_age": 2592000,
              "endpoints": [{"url": "https://example.com/upload-reports"}]}
< NEL: {"report_to": "network-errors", "max_age": 2592000, "success_fraction": 1.0,
        "request_headers": ["If-None-Match"], "response_headers": ["ETag"]}
< ETag: 01234abcd

この例では、example.com の所有者は、 サーバー上でホストされているリソースの異なるバージョンを識別するために、 ETag レスポンス ヘッダーを使用します。その後、ユーザーエージェントは If-None-Match リクエストヘッダーを使用して、現在クライアント側でキャッシュされているリソースのバージョンを サーバーに通知できます。これにより、クライアントが保持する既存のコピーが 最新であれば、サーバーはリソースの内容を生成して 送信することを回避できます。

このドメインの NEL ヘッダーに request_headers および response_headers フィールドを 含めることで、ブラウザーは、そのリクエストについて作成するすべての NEL レポートに If-None-Match リクエストヘッダーと ETag レスポンスヘッダーのコピーを 含めるようになり、サイト所有者がキャッシュポリシーの 有効性を追跡できるようになります。

上記を踏まえ、次の一連のイベントを考えます。

1. ユーザーエージェントは example.com にリクエストを送信し、 サーバーから成功したレスポンスを受信します。 これには、リソースのバージョンを示す ETag ヘッダーが含まれます。 ユーザーエージェントは次の NEL レポートを生成します。

   例 8

   {
     "age": 0,
     "type": "network-error",
     "url": "https://example.com/",
     "body": {
       "sampling_fraction": 1.0,
       "server_ip": "192.0.2.1",
       "protocol": "http/1.1",
       "method": "GET",
       "request_headers": {},
       "response_headers": {
         "ETag": ["01234abcd"]
       },
       "status_code": 200,
       "elapsed_time": 1392,
       "phase": "application",
       "type": "ok"
     }
   }

2. しばらくして、ユーザーエージェントは example.com に別のリクエストを送信します。 ユーザーエージェントは元のリソースのコピーを ローカルキャッシュにまだ保持しており、そのバージョンを If-None-Match リクエスト ヘッダーに含めます。サーバーは このバージョンを確認し、まだ最新であることを認識して、 キャッシュされたリソースのコピーがまだ有効であることをユーザーエージェントに通知する 304 レスポンスを送信します。ユーザーエージェントは 次のレポートを生成します。

   例 9

   {
     "age": 0,
     "type": "network-error",
     "url": "https://example.com/",
     "body": {
       "sampling_fraction": 1.0,
       "server_ip": "192.0.2.1",
       "protocol": "http/1.1",
       "method": "GET",
       "request_headers": {
         "If-None-Match": ["01234abcd"]
       },
       "response_headers": {
         "ETag": ["01234abcd"]
       },
       "status_code": 304,
       "elapsed_time": 45,
       "phase": "application",
       "type": "ok"
     }
   }

3. さらに後に、ユーザーエージェントは example.com にさらに別のリクエストを送信します。 ユーザーエージェントは同じリソースのコピーを ローカルキャッシュにまだ保持しており、前の 例と同様に、そのバージョンを If-None-Match リクエスト ヘッダーに含めます。しかし今回は、サーバーがリソースの新しい バージョンが利用可能であることを認識します。サーバーはこの リソースの内容を生成してクライアントに送信し、新しいバージョンを 新しい ETag レスポンスヘッダー値にエンコードします。ユーザー エージェントは次のレポートを生成します。

   例 10

   {
     "age": 0,
     "type": "network-error",
     "url": "https://example.com/",
     "body": {
       "sampling_fraction": 1.0,
       "server_ip": "192.0.2.1",
       "protocol": "http/1.1",
       "method": "GET",
       "request_headers": {
         "If-None-Match": ["01234abcd"]
       },
       "response_headers": {
         "ETag": ["56789ef01"]
       },
       "status_code": 200,
       "elapsed_time": 935,
       "phase": "application",
       "type": "ok"
     }
   }

ドメイン名が複数の IP アドレスに解決されるオリジンでは、NEL は、 オリジンの所有者が、リクエストを処理する サーバーの所有者と同一であることを検証できないため、 エラーの原因に関する情報を少なくして、エラーレポートを「格下げ」することがあります。

例として、example.com が、それぞれ異なる IP アドレスを持つ3台の サーバーによって処理されると仮定します。サービスの所有者は、 example.com を 192.0.2.1、192.0.2.2、および 192.0.2.3 に解決するよう DNS を構成し、ユーザーエージェントが これら3つの IP アドレス間でリクエストを分散することに依存します。サービス所有者は 次の NEL ポリシーを配信します。

> GET / HTTP/1.1
> Host: example.com

< HTTP/1.1 200 OK
< ...
< Report-To: {"group": "network-errors", "max_age": 2592000,
              "endpoints": [{"url": "https://example.com/upload-reports"}]}
< NEL: {"report_to": "network-errors", "max_age": 2592000,
        "success_fraction": 1.0, "failure_fraction": 1.0}

上記を踏まえ、次の一連のイベントを考えます。

1. ユーザーエージェントは 192.0.2.1 にリクエストを送信し、 サーバーから成功したレスポンスを受信します。 このレスポンスには上記の NEL ポリシーが含まれ、ユーザー エージェントはポリシーの受信 IP アドレスを 192.0.2.1 に設定します。受信 IP アドレスは サーバーの IP アドレスと一致するため（成功した リクエストでは必ず一致します）、次の NEL レポートを生成します。

   例 12

   {
     "age": 0,
     "type": "network-error",
     "url": "https://example.com/",
     "body": {
       "sampling_fraction": 1.0,
       "server_ip": "192.0.2.1",
       "protocol": "http/1.1",
       "method": "GET",
       "request_headers": {},
       "response_headers": {},
       "status_code": 200,
       "elapsed_time": 57,
       "phase": "application",
       "type": "ok"
     }
   }

2. ユーザーエージェントは 192.0.2.2 に新しいリクエストを送信し、別の成功した レスポンスを受信します。このレスポンスにも NEL ポリシーが含まれ、 ユーザーエージェントはポリシーの受信 IP アドレスを 192.0.2.2 に更新します。受信 IP アドレスは サーバーの IP アドレスと一致するため（成功した リクエストでは必ず一致します）、次の NEL レポートを生成します。

   例 13

   {
     "age": 0,
     "type": "network-error",
     "url": "https://example.com/",
     "body": {
       "sampling_fraction": 1.0,
       "server_ip": "192.0.2.2",
       "protocol": "http/1.1",
       "method": "GET",
       "request_headers": {},
       "response_headers": {},
       "status_code": 200,
       "elapsed_time": 34,
       "phase": "application",
       "type": "ok"
     }
   }

3. 次にユーザーエージェントは 192.0.2.3 にリクエストを送信しようとしますが、 サーバーへの接続を確立できません。ユーザーエージェントは依然として NEL ポリシーを ポリシーキャッシュに保持しており、理想的にはこのポリシーを使用して、 失敗した ネットワークリクエストについて tcp.timed_out レポートを生成します。しかし、ポリシーの受信 IP アドレス（192.0.2.2）が、このリクエストの送信先 IP アドレスと一致しないため、ユーザーエージェントは 192.0.2.3 のサーバーが実際に example.com の所有者によって所有されていることを検証できません。したがって、ユーザーエージェントは レポートを dns.address_changed に格下げしなければなりません。

   例 14

   {
     "age": 0,
     "type": "network-error",
     "url": "https://example.com/",
     "body": {
       "sampling_fraction": 1.0,
       "server_ip": "192.0.2.3",
       "protocol": "http/1.1",
       "method": "GET",
       "request_headers": {},
       "response_headers": {},
       "status_code": 0,
       "elapsed_time": 0,
       "phase": "dns",
       "type": "dns.address_changed"
     }
   }

4. 次にユーザーエージェントは 192.0.2.1 に別のリクエストを送信しようとしますが、 再びサーバーへの接続を確立できません。ユーザーエージェントは過去のある時点で 192.0.2.1 から NEL ポリシーを受信していたものの、ポリシーの 受信 IP アドレスは、 直近にどこから受信したかのみを記録します。この場合は 192.0.2.2 です。したがって、ユーザーエージェントは レポートを dns.address_changed に格下げしなければなりません。

   例 15

   {
     "age": 0,
     "type": "network-error",
     "url": "https://example.com/",
     "body": {
       "sampling_fraction": 1.0,
       "server_ip": "192.0.2.1",
       "protocol": "http/1.1",
       "method": "GET",
       "request_headers": {},
       "response_headers": {},
       "status_code": 0,
       "elapsed_time": 0,
       "phase": "dns",
       "type": "dns.address_changed"
     }
   }

ユーザーによって開始されたナビゲーションリクエスト（たとえば、リンクのクリック、ロケーション バーへの直接入力、ユーザー操作に起因してスクリプトによって開始されたものなど）は、さまざまな接続上の理由によって失敗する可能性があります。 DNS 障害、TCP エラー、TLS プロトコル違反などです。これらのエラーは、ネットワークの 設定不備、一時的なルーティングの問題、サーバーの停止、マルウェアまたはユーザーに対するその他の攻撃 などによって引き起こされる可能性があります。

このような場合、宛先ホストは、定義上、 リクエストが自身のインフラストラクチャに到達するのを確認できず、問題を調査することもできないため、失敗したナビゲーションに気付かないことがよくあります。これに 対処するため、ホストはユーザーエージェントに NEL ポリシーを登録できます。このポリシーは、 調査できるように、このような失敗のレポートをどこへ配信すべきかを指定します。

一般的なアプリケーションは数十個のリソースを必要とし、それらの取得は通常 HTML、CSS、または JavaScript を介して開始されます。このようなリソースを要求するアプリケーションは、そのような 取得のほとんどについて失敗を観測できます（たとえば onerror コールバックを介して）が、失敗が発生した理由についての詳細なネットワーク エラーレポート、たとえば DNS 障害、TCP エラー、TLS プロトコル違反などにはアクセスできません。

これに対処するため、アプリケーションは、サブリソースの取得元となる ファーストパーティホストについて、関連する NEL ポリシーをユーザーエージェントに登録できます。その後、そのようなポリシーが存在し、 登録済みの NEL ポリシーを持つオリジンからのリソースについてネットワークエラーが発生した場合、ユーザー エージェントは詳細なネットワークエラーレポートを報告し、アプリケーション開発者が エラーを調査できるようにします。

リソースがサードパーティによって埋め込まれる場合、そのリソースの提供者は、多くの場合、 障害を計測して観測することができません。たとえば、example.com がそのサイトに widget.com/thing.js リソースを埋め込み、example.com を訪問しているユーザーが ネットワークエラーによってそのリソースの取得に失敗した場合、widget.com ホストはその失敗を認識することも 検出することもできません。

これに対処するため、widget.com は自身のホストに対する NEL ポリシーを登録できます。その後、そのようなポリシーが 存在し、登録済みの NEL ポリシーを持つオリジンからリソースを取得する際に、ファーストパーティまたはサードパーティのオリジンのどちらから 要求されているかに関係なくネットワークエラーが発生した場合、ユーザー エージェントはネットワークエラーを報告し、提供者がエラーを調査できるようにします。

ヘッダーフィールド名

NEL

適用可能なプロトコル

http

ステータス

標準

著者／変更管理者

W3C

仕様文書

この仕様（NEL レスポンスヘッダーを参照）