ネットワークエラー記録

A ネットワークリクエストは、ユーザーエージェントが特定のrequestに対して ネットワーク越しにリソースをHTTP-network fetchしようと試みるときに発生します。

requestは、ユーザーエージェントがオフラインであることが判明している場合（すなわちnavigator. onLineが falseを返すとき）、network requestを発生させてはなりません（MUST NOT）。

requestは、mixed contentやCORSの失敗によりブロックされる場合、network requestを発生させてはなりません（MUST NOT）。任意のCORS-preflight requestは、それ自体のnetwork requestを必ず（MUST）発生させなければなりません。

使用されるフェッチアルゴリズムや基盤となるアプリケーション・トランスポートプロトコルが何であれ、network requestの処理は次のフェーズから構成されます：

1. DNS解決: ユーザーエージェントはドメイン名をserverがそのドメインへのHTTP requestsをサービスできるように、RFC1034で定義されるDomain Name Systemを使用してIP addressに解決します。
2. セキュア接続の確立: ユーザーエージェントはserverへ接続を開き、その接続上でセキュアチャネルを確立します。
3. リクエストとレスポンスの送受信: セキュアチャネルが確立されると、ユーザーエージェントはHTTPのrequestを送信し、responseをserverから受信できます。

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

network request は、ユーザーエージェントがサーバーから有効なHTTPレスポンスを受信でき、かつそのレスポンスが 4xx または 5xx ステータスコードでない場合、成功 (successful) とみなされます。

network requestは、成功（successful）でない場合、failed（失敗）とされます。

ネットワークエラーは、network requestがfailする原因となったエラー条件です。

各ネットワークエラーは文字列であるtype（タイプ）を持ちます。

各ネットワークエラーは、どのphase（フェーズ）でエラーが発生したかを示す属性を持ちます。

dns

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

connection

エラーはセキュア接続確立中に発生しました

application

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

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

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

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

ネットワークエラーレポートは、ReportingObserverに対して表示されません（NOT visible）。

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

各NELポリシーは、受信IPアドレスを持ちます。これはユーザーエージェントがこのサーバーから受け取った IPアドレスです。

各NELポリシーはオリジンを持ちます。

各NELポリシーはsubdomainsフラグを持ち、これは includeまたはexcludeです。

各NELポリシーは、リクエストヘッダーのリストと、レスポンスヘッダーのリストを持ち、どちらもヘッダー名のリストです。

各NELポリシーはレポートグループを持ちます。これはこのポリシーのレポートを送信するReportingの エンドポイントグループの名前です。

各NELポリシーは、有効期間を秒数で表すttl（有効期限）を持ちます。

各NELポリシーは、ユーザーエージェントがそのポリシーを受信した時刻を表す作成時刻（creation）を持ちます。

NELポリシーは、作成時刻から creationと ウォールクロックの unsafe current time の差が172800秒（48時間）を超えるとstale（陳腐化）とみなされます。

NELポリシーは、 作成時刻から creationと ウォールクロックの unsafe current time との差がそのttl（秒）より大きい場合、expired（期限切れ）とみなされます。

大量のトラフィックを扱う可能性のあるoriginは、各ユーザーエージェントが送信するすべてのnetwork requestについてのNELレポートを受信する体制が整っていない可能性があります。オリジンは、各ユーザーエージェントが提出するNELレポート数を制限するために、サンプリングレートを定義できます。通常、successful（成功した）リクエストは failed（失敗した）リクエストよりはるかに多いはずであるため、オリジンはそれぞれに異なるサンプリングレートを指定できます。

各NELポリシーは、0.0から1.0の範囲の数値であるsuccessful sampling rate（成功サンプリングレート）を持ちます。

各NELポリシーは、0.0から1.0の範囲の数値であるfailure sampling rate（失敗サンプリングレート）を持ちます。

準拠したユーザーエージェントは、ポリシーキャッシュを提供することが必須（MUST）です。これは NELポリシーの集合を保持するストレージ機構で、(network partition key, origin)のタプルでキー付けされます。

このストレージ機構は不透明でベンダー固有でありウェブに公開されませんが、本仕様が定義するアルゴリズムで使用される以下のメソッドを提供することが必須（MUST）です：

• NELポリシーの挿入、更新、削除。
• 指定したoriginとnetwork partition keyに対するNELポリシー（存在する場合）の取得。
• キャッシュのクリア。

NEL レスポンスヘッダーは、 オリジンのNELポリシーをユーザーエージェントに伝達するために使用されます。 NELヘッダーのABNF（拡張バッカス・ナウア記法）[RFC5234]による構文は以下の通りです：

NEL = json-field-value

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

ユーザーエージェントは、この仕様で定義された構文に適合しない未知もしくは無効なフィールドや値は無視（MUST）しなければなりません。有効なNELヘッダーフィールドには、少なくともこの仕様で定義された全ての "REQUIRED" フィールドを含むオブジェクトが1個存在しなければなりません。

ユーザーエージェントは、エラー報告の乗っ取りを防ぐため、meta要素によって指定されたNELヘッダーを無視しなければなりません（MUST）。NELポリシーは、必ず NEL レスポンスヘッダーで配信されなければなりません。

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

1. 以下のいずれかの条件が真であれば、これらの手順を中止すること：
   • requestのオリジンに対し"起源が潜在的に信頼できるか？"アルゴリズムの結果がPotentially Trustworthyでない場合。
   • responseにNELという名前のレスポンスヘッダーが含まれていない場合。
2. originをrequestのオリジンとする。
3. keyを、requestのreserved clientを引数にネットワークパーティションキーを決定で得られる値とする。
4. headerをNELという名前のレスポンスヘッダーの値とする。
5. listを[HTTP-JFV]4章のアルゴリズムをheaderに実行した結果とする。そのアルゴリズムがエラーになる、または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

    サブドメインフラグ

    include_subdomainsという名前のメンバーがtrueであればinclude、 それ以外はexclude

    リクエストヘッダー

    request_headersメンバーの値

    レスポンスヘッダー

    response_headersメンバーの値

    レポートグループ

    report_toメンバーの値

    ttl

    max_ageメンバーの値

    作成時刻

    ウォールクロックのunsafe current time

    成功サンプリングレート

    success_fractionメンバーの値（存在しなければ0.0）

    失敗サンプリングレート

    failure_fractionメンバーの値（存在しなければ1.0）

15. 既に(key, origin)のポリシーキャッシュエントリが存在すれば、それをpolicyで置き換え、そうでなければ(key, origin)のポリシーキャッシュにpolicyを挿入する。

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

1. origin を request の オリジン とする。
2. key を request の reserved client を引数に ネットワークパーティションキーを決定 で得られる値とする。
3. (key, origin) のポリシーキャッシュエントリが存在する場合：
   1. policy をそのエントリとする。
   2. policy が期限切れでない場合、それを返す。
4. originのスーパーオリジン一致（親オリジン）それぞれについて：
   1. (key, parent origin) のポリシーキャッシュエントリが存在する場合：
      1. policy をそのエントリとする。
      2. policy が期限切れでなく、かつpolicyのサブドメインフラグがincludeの場合、それを返す。
5. ポリシーなし を返す。

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

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

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

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

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

1. requestのオリジンに対し"起源が潜在的に信頼できるか？"アルゴリズムの結果がPotentially Trustworthyでない場合、nullを返す。
2. origin を request の オリジンとする。
3. policy を 5.1 リクエストに対するポリシーの選択 を request に対して実行した結果とする。 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進表記（例: 192.0.2.1）。[RFC1123]
   • IPv6ホストは8セットの16ビット数をコロン区切り16進で（例: x:x:x:x:x:x:x:x）。[RFC4291]

   protocol

   リソース取得時に用いられたネットワークプロトコル（ALPN Protocol IDで識別）。 情報がなければ""。

8. report body の phase プロパティが dns または connection でない場合、以下のプロパティを追加：

   referrer

   requestのリファラー（関連するreferrer policyによる）。

   method

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

   request_headers

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

   response_headers

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

   status_code

   HTTPレスポンスのステータスコード（利用可能なら）。なければ0。

9. origin が policy の origin と異なり、policy の サブドメインフラグが include で、かつ report body の phase プロパティが dns でない場合は、nullを返す。
   注記

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

10. report body の phase プロパティがdnsでなく、かつ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. report body内でDNS解決時点で取得できない情報に由来するすべてのフィールドがクリアされていることを保証する。
    注記

    この手順は、サーバーとNELポリシーの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. 下記パラメータで ネットワークレポートの生成 を呼び出す：

   type

   network-error

   data

   report body

   endpoint group

   policy の レポートグループ

   url

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

このセクションのすべてのネットワークエラーはDNS解決フェーズで発生し、そのphaseはdnsとなります。

dns.unreachable

DNSサーバーに到達できません

dns.name_not_resolved

DNSサーバーは応答しましたがアドレスを解決できませんでした

dns.failed

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

dns.address_changed

リクエストのoriginに対して解決されたIPアドレスが対応するNELポリシー受信後に変更されたことを示します

このセクションのすべてのネットワークエラーはセキュア接続確立フェーズで発生し、そのphaseは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接続が失敗しました

このセクションのすべてのネットワークエラーは リクエスト・レスポンス送信フェーズで発生し、そのphaseは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ミリ秒後にナビゲーションを中止しました。最終的に、ネットワークエラー発生直後、つまりレポートのageは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ポリシーが配信されていたため、ユーザーエージェントはこのリクエストについてネットワークエラー レポートを生成します。レポートはネットワークエラー発生直後、すなわちageは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の所有者は、たとえばnew-subdomain.example.comをIPアドレスへ解決するリソースレコードの追加を忘れた場合など、DNSサーバー構成ミスを検出できます。ユーザーエージェントが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が3つのサーバー（それぞれ異なるIPアドレス）で処理されている場合を考えます。サービス所有者はDNSをexample.comが192.0.2.1、192.0.2.2、192.0.2.3に解決されるよう構成し、ユーザーエージェントがこれら3つにリクエストを分散するよう任せています。サービス所有者は次の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ポリシーが含まれており、ユーザーエージェントはreceived IP addressを192.0.2.1に設定します。received IP addressがサーバーの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に新たなリクエストを送り、再びsuccessとなるレスポンスを受信します。このレスポンスもNELポリシー付きで、received IP addressは192.0.2.2に更新されます。この場合も、IPがサーバーIPと一致するので次のレポートが生成されます：

   例 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のレポートを生成すべきですが、NELポリシーのreceived IP address（192.0.2.2）が今回のリクエスト先IPと一致しないため、そのサーバーが本当に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ポリシーを受信したことがあっても、ポリシーのreceived IP addressには直近で受信した場所（ここでは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ポリシーをユーザーエージェントに登録できます。そうすることで、ポリシー有効なオリジンからのリソース取得でネットワークエラーが発生すると、ユーザーエージェントは詳細なネットワークエラーレポートを生成し、アプリケーション開発者が原因調査を行うことができます。

サードパーティによる埋め込みリソースの場合、リソース提供者は失敗を検知・観測できないことが多いです。例えば、example.comがwidget.com/thing.jsリソースを自サイトに埋め込み、example.com訪問ユーザーがネットワークエラーでそのリソースを取得できなかった場合、widget.com側はその失敗自体に気づくことができません。

この課題に対処するため、widget.comは自身のホストにNELポリシーを登録できます。これによって、ファースト/サードパーティ出自を問わず、登録済みNELポリシーのあるオリジンからリソース取得時にネットワークエラーが発生した場合、ユーザーエージェントはエラーをレポートし、提供者が原因を調査できるようにします。

ヘッダーフィールド名

NEL

対象プロトコル

http

ステータス

標準

作成者/変更管理者

W3C

仕様書

本仕様（NELレスポンスヘッダー参照）