Network Error Logging

2.1. 依存関係

【 この節の内容（他の仕様に定義される用語の一覧）は、 省略する。 】

3.1. ~network要請

`~network要請@ （ `network request^en ）は、 ~UAが単独の`要請$を~serviceするときに~networkを利用する必要があるときに生じる： ◎ A network request occurs when the user agent must use the network to service a single request.

• ~UAが局所~cacheから~serviceできる`要請$は、 `~network要請$にならないモノトスル。 ◎ If the user agent can service a request out of a local cache, that request MUST NOT result in a network request.
• ~UAが`~navi$の一部として`~redirect$に追従する場合、 ~redirect連鎖を成す各`要請$ごとに 別々な`~network要請$になるモノトスル。 ◎ If the user agent follows redirects as part of a navigation, there MUST be separate network requests for each request in the redirect chain.

• 次のいずれかに該当する`要請$は、 `~network要請$にならないモノトスル： ◎ ↓

  • ~UAは~offlineにあることが既知であるもの （すなわち `navigator.onLine$m が ~F を返すとき）。 ◎ A request MUST NOT result in a network request if the user agent is known to be offline (i.e., when navigator.onLine returns false).
  • `混在~内容$や`~CORS＠~FETCH#cors-protocol$の失敗に因り，阻止されたもの。 ◎ A request MUST NOT result in a network request if it is blocked due to mixed content or CORS failures.＼
• 各`~CORS予行~要請$は、 それだけで`~network要請$になるモノトスル。 ◎ Any CORS-preflight request MUST result in its own network request.

注記： `FETCH$r 標準に則って`要請$を~serviceする~UAにおいては、 各`~network要請$は，`~HTTP~network~fetch$ ~algoの 1 回の実行に対応する。 ◎ Note For user agents that service requests according to the [FETCH] standard, a network request corresponds to one execution of the HTTP-network fetch algorithm.

どの［ ~fetch~algo, 下層の~app, ~transport~protocol ］を利用するかを問わず、 `~network要請$を~serviceする~~過程は，次に挙げる `相@ （ `phase^en ）からなる： ◎ Regardless of which fetch algorithm and which underlying application and transport protocols are used, servicing a network request consists of the following phases:

1. `~DNS解決@ ⇒ ~UAが~DNS（ `Domain Name System^en `RFC1034$r ）を利用して、 ~domain名を［ その~domainへ向けた~HTTP要請に対し~serviceできる`~server$ ］の~IP~addressに解決するまでの間。 ◎ DNS resolution: The user agent uses the Domain Name System [RFC1034] to resolve a domain name into an IP address of a server can that service HTTP requests to that domain.
2. `~secure接続の確立@ ⇒ ~UAが`~server$への接続を~openして、 その接続~越しに~secure~channelを確立するまでの間。 ◎ Secure connection establishment: The user agent opens a connection to the server, and establishes a secure channel over this connection.
3. `要請と応答の伝送@ ⇒ ~secure~channelが確立されたなら、 ~UAは，~HTTP要請を伝送して`~server$からの応答を受信できるようになる。 ◎ Transmission of request and response: Once the secure channel is established, the user agent can transmit the HTTP request, and receive the response from the server.

`~network要請$を成すために義務付けられる`相$は，これらのうち`要請と応答の伝送$のみであり、 他の`相$は，必要ないかもしれない。 一例として，~DNSの結果は、 ~UAにおいて局所的に~cacheできる — その場合、 同じ~domain向けの未来の要請に対する`~DNS解決$は不要になる。 同様に，~HTTPの`持続的な接続$は、 同じ`生成元$への複数の要請が同じ~open接続を共有することを許容する。 しかしながら，複数の`相$が生じる場合、 上の順序で生じることになる。 ◎ The only mandatory phase is the transmission of request and response; the other phases might not be needed for every network request. For instance, DNS results can be cached locally in the user agent, eliminating DNS resolution for future requests to the same domain. Similarly, HTTP persistent connections allow open connections to be shared for multiple requests to the same origin. However, if multiple phases occur, they will occur in the above order.

編集者注記： これらの`相$たちを成す定義は、 もっと再利用できるよう `FETCH$r に移動したい所。 ◎ Editor's note We would like to move the definition of these phases into [FETCH] so that they are more reusable.

`~network要請$は、 次が~~判明した時点で `成功した@ （ `successful^en ）とされる ⇒ ［ ~UAは、 ~serverから妥当な~HTTP応答を受信できた ］~AND［ その応答の状態s~codeは［ `4xx$st ／ `5xx$st ］でない ］ ◎ A network request is successful if the user agent is able to receive a valid HTTP response from the server, and that response does not have a 4xx or 5xx status code.

`~network要請$は、 `成功-$しなかったことが~~判明した時点で `失敗した@ （ `failed^en ）とされる。 ◎ A network request is failed if it is not successful.

注記： ~HTTP~error応答（すなわち 状態s~codeに［ `4xx$st ／ `5xx$st ］を伴うもの）は、 それが `~NEL施策$の`成功~時の見本抽出率$に代えて`失敗~時の見本抽出率$の~subjectになるよう，`失敗した$ものと見なされることに注意。 ◎ Note Note that HTTP error responses (i.e., those with a 4xx or 5xx status code) are considered failures, so that they are subject to a NEL policy's failure sampling rate instead of its successful sampling rate.

3.2. ~network~error

`~network要請$を `失敗-$させた~error条件を `~network~error@ という。 ◎ A network error is the error condition that caused a network request to fail.

各`~network~error$には、 文字列として与えられる `種別@nE （ `type^en ）がある。 ◎ Each network error has a type, which is a string.

各`~network~error$には、 当の~errorはどの`相$で生じたかを述べる `相@nE （ `phase^en ）がある： ◎ Each network error has a phase, which describes which phase the error occurred in:

`dns^l

当の~errorは、 `~DNS解決$の間に生じた ◎ the error occurred during DNS resolution

`connection^l

当の~errorは、 `~secure接続の確立$の間に生じた ◎ the error occurred during secure connection establishment

`application^l

当の~errorは、 `要請と応答の伝送$の間に生じた ◎ the error occurred during the transmission of request and response

`~network~error$の`種別$nEとして定義済みなものがいくつかあり、 `定義済み~network~error種別＠#predefined-network-error-types$にて定義される。 ◎ There are several predefined network error types defined in 6. Predefined network error types.

3.3. ~network~error報告

`~network~error$を述べる`報告$ `REPORTING$r は、 `~network~error報告@ （ `network error report^en ）と呼ばれる。 ◎ A network error report is a Reporting API report that describes a network error.

`~network~error報告$の`報告~種別$は、 `network-error^l とする。 ◎ Network error reports have a report type of network-error.

`~network~error報告$は、 `報告用~観測器から可視$でない。 ◎ Network error reports are NOT visible to ReportingObservers.

注記： `報告用~観測器から可視$でないとされているのは、 `~network~error報告$は，要請を`受信している^em~serverの［ 管理者／所有者 ］からに限り可視になることが意図されているからである。 報告が`報告用~観測器から可視$にされたなら、 要請の`起動元o^emからも可視になる。 その結果，非同一-生成元~要請に対しては、 その~serverの制御の外側にある主体にも，~serverの~network環境設定についての情報が漏洩され得ることにもなる。 ◎ Note Network error reports are not visible to ReportingObservers because they are only intended to be visible to the administrator or owner of the server receiving the requests. If they were visible to ReportingObservers, then the reports would also be visible to the originator of the request. For cross-origin requests, this could leak information about the server's network configuration to parties outside of its control.

3.4. ~NEL施策

`~NEL施策@ （ `NEL policy^en ）は、 ある`生成元$への`~network要請$についての報告を収集するかどうか， 収集した報告はどこへ送信するかを、 ~UAに指図する。 `~NEL施策$は， `NEL$h ~HTTP`応答~header$を介して~UAに送達される。 ◎ A NEL policy instructs a user agent whether to collect reports about network requests to an origin, and if so, where to send them. NEL policies are delivered to the user agent via HTTP response headers.

各`~NEL施策$は、 次に挙げるものを持つ： ◎ ↓

• `受信した~IP~address@nP ⇒ ~UAがこの`~NEL施策$を受信した`~server$の~IP~address。 ◎ Each NEL policy has a received IP address,＼ which is the IP address of the server that the user agent received this NEL policy from.
• `生成元@nP （ `policy origin^en ） ⇒ `生成元$ ◎ Each NEL policy has an origin.
• `下位domainを含むか@nP （ `subdomains flag^en ） ⇒ 真偽値【！include or exclude】 【原文は `include^en ／ `exclude^en をとるように定義されているが、この訳では真偽値に改める。】 ◎ Each NEL policy has a subdomains flag,＼ which is either include or exclude.
• `要請~header名~list@nP （ `list of request headers^en ） ⇒ `名前$hdたちが成す~list。 ◎ ↓
• `応答~header名~list@nP （ `list of response headers^en ） ⇒ `名前$hdたちが成す~list。 ◎ Each NEL policy has＼ a list of request headers and a list of response headers,＼ each of which is a list of header names.
• `報告用~group@nP （ `reporting group^en ） ⇒ この施策~用の報告の送信-先になる`報告先~group$の名前を与える。 ◎ Each NEL policy has a reporting group,＼ which is the name of the Reporting endpoint group that reports for this policy will be sent to.
• `有効秒数@nP （ `ttl^en ） ⇒ 施策が有効であり続ける秒数を表現する。 ◎ Each NEL policy has a ttl＼ representing the number of seconds the policy remains valid.
• `作成時刻@nP （ `creation^en ） ⇒ ~UAがこの施策を受信したときの時刻印。 ◎ Each NEL policy has a creation＼ which is the timestamp when the user agent received the policy.

次を満たす `~NEL施策$は、 `非新鮮@ （ `stale^en ）とされる ⇒ `所要時間を得る$( その`作成時刻$nP, `現在の壁~時計~時刻$ ) ~GT 172800 秒 （ 48 時間t） ◎ A NEL policy is stale if the duration from its creation to the current wall time is greater than 172800 seconds (48 hours).

次を満たす `~NEL施策$は、 `失効した@ （ `expired^en ）とされる ⇒ `所要時間を得る$( その`作成時刻$nP, `現在の壁~時計~時刻$ ) ~GT `有効秒数$nP ◎ A NEL policy is expired if the duration from its creation to the current wall time is greater than its ttl (in seconds).

3.5. 見本抽出率

多量の流通を~serveすることが予期される`生成元$は、 その生成元に向けて為された あらゆる`~network要請$に対する~NEL報告を取り込む備えはないかもしれない。 生成元は、 `見本抽出率@ （ `sampling rate^en ）を定義して，各~UAが提出する ~NEL報告の個数を制限できる。 概して，`成功した$要請の方が`失敗した$要請より ずっと多いはずなので、 生成元は，それぞれに異なる見本抽出率を指定できる。 ◎ An origin that expects to serve a large volume of traffic might not be equipped to ingest NEL reports for every network request made to the origin. The origin can define sampling rates to limit the number of NEL reports that each user agent submits. Since successful requests should typically greatly outnumber failed requests, the origin can specify different sampling rates for each.

各`~NEL施策$は、 `成功~時の見本抽出率@, `失敗~時の見本抽出率@ を持つ — どちらも 0.0 以上 1.0 以下の実数とする。 ◎ Each NEL policy has a successful sampling rate, which is a number between 0.0 and 1.0 inclusive. ◎ Each NEL policy has a failure sampling rate, which is a number between 0.0 and 1.0 inclusive.

3.6. 施策~cache

適合t~UAは、 `~NEL施策$の集合を保守する~storageの仕組みを成す `施策~cache@ （ `policy cache^en ）を供するモノトスル。 それは、 ( `~network区分~key$, `生成元$ ) が成す~tupleを~keyに，施策を格納する。 ◎ A conformant user agent MUST provide a policy cache, which is a storage mechanism that maintains a set of NEL policies, keyed by (network partition key, origin) tuples.

【 この訳では、 `施策~cache$は［ 各 ( `~network区分~key$, `生成元$ ) を`~NEL施策$に対応付ける`~map$ ］であると見なした上で， `~map$用に定義された各種［ 演算／表記法 ］を利用する。 以下に挙げられる要件を満たすためには、 ~mapで足るので （この~mapを成す~entryたちの順序は有意でない）。 この~mapにおける、 ~keyどうしの比較は成分ごと，それらを成す［ `~network区分~key$／`生成元$ ］どうしの比較は［ `同じ~site$／`同一-生成元$ ］の定義に基づくことになろう。 】

この~storageの仕組みは、 不透明かつ~vendorに特有であり，~webには公開されないが、 次の~methodを供するモノトスル — それは、 この文書が定義する各種~algoから利用されることになる： ◎ This storage mechanism is opaque, vendor-specific, and not exposed to the web, but it MUST provide the following methods which will be used in the algorithms this document defines:

• `~NEL施策$を［ 挿入- ／ 更新- ／ 削除- ］する。 ◎ Insert, update, and delete NEL policies.
• 所与の ( `~network区分~key$, `生成元$ ) 用の`~NEL施策$があれば それを検索取得する。 ◎ Retrieve the NEL policy, if any, for a given origin and network partition key.
• ~cacheを~clearする。 ◎ Clear the cache.

4.1. `NEL^h 応答~header

`生成元$の`~NEL施策$を~UAに向けて通信するためには、 `NEL@h `応答~header$が利用される。 その~ABNF構文は： ◎ The NEL response header is used to communicate an origin's NEL policy to the user agent. The ABNF (Augmented Backus-Naur Form) syntax for the NEL header is as follows:

NEL
	= json-field-value

この~headerの値は、 ~JSON~objの配列として， `json-field-value$P に定義されるように解釈される。 この配列~内の各~objは、 ある`~NEL施策$を生成元~用に定義する。 ~UAは、 配列~内の最初の施策が妥当である†ならば，それを処理した上で、 残りの施策は無視するモノトスル。 ◎ The header's value is interpreted as an array of JSON objects, as defined by json-field-value. Each object in the array defines an NEL policy for the origin. The user agent MUST process the first valid policy in the array and ignore any additional policies in the array.

【† 原文は “妥当な施策のうち最初のもの” と解釈できてしまうが、 `実際の定義＠#process-policy-headers$では， 配列~内の最初の~item以外はすべて無視している。 】

~UAは、 ~fieldや値のうち［ この仕様に定義する構文に適合しないもの／ 未知なもの／ 妥当でないもの ］を無視するモノトスル。 妥当な `NEL$h ~headerは、［ この仕様が必須であると定義する~field ］すべてを伴う~objを， 1 個~以上は包含しなければナラナイ。 ◎ User agents MUST ignore any unknown or invalid field(s) or value(s) that do not conform to the syntax defined in this specification. A valid NEL header field MUST, at a minimum, contain one object with all of the "REQUIRED" fields defined in this specification.

［ ~scripting 【 XSS 】 攻撃による，~error報告処理の乗取り ］を軽減するため、 ~UAは， `meta^e 要素を介して指定された `NEL$h ~headerは，無視するモノトスル。 `~NEL施策$は、 `NEL$h `応答~header$を介して送達されなければナラナイ。 ◎ The user agent MUST ignore the NEL header specified via a meta element to mitigate hijacking of error reporting via scripting attacks. The NEL policy MUST be delivered via the NEL response header.

注記： `meta^e 要素に対する制約は、 `CSP$r 仕様に整合する — それも、 同じ事由から，報告処理 登録を~HTTP~headerのみに制約している。 ◎ Note The restriction on meta element is consistent with the [CSP] specification, which restricts reporting registration to HTTP header fields only for the same reasons.

4.2. 施策~headerの処理-法

5.1. 要請~用の施策を選ぶ

5.2. 要請~headerたちを抽出する

5.3. 応答~headerたちを抽出する

5.4. ~network~error報告の生成-法

5.5. ~network報告を送達する

6.1. ~DNS解決~error

この節に挙げるすべての`~network~error$は、 `~DNS解決$の間に生じるので，その`相$nEは `dns^l になる。 ◎ All of the network errors in this section occur during DNS resolution, and therefore have a phase of dns.

`dns.unreachable^l

~DNS~serverに到達-不能。 ◎ DNS server is unreachable

`dns.name_not_resolved^l

~DNS~serverは応答してきたが，~addressは解決できなかった。 ◎ DNS server responded but is unable to resolve the address

`dns.failed^l

上の各項に挙げた~errorに因る事由を除く， ~DNS~serverへの要請に際しての失敗。 ◎ Request to the DNS server failed due to reasons not covered by previous errors

`dns.address_changed^l

要請の`生成元$rq用に解決された~IP~addressは、 対応する`~NEL施策$を受信したときから変化したことを 指示する。 ◎ Indicates that the resolved IP address for a request's origin has changed since the corresponding NEL policy was received

6.2. ~secure接続~確立の~error

この節に挙げるすべての`~network~error$は、 `~secure接続の確立$の間に生じるので，その`相$nEは `connection^l になる。 ◎ All of the network errors in this section occur during secure connection establishment, and therefore have a phase of connection.

`tcp.timed_out^l

~serverへの~TCP接続が時間切れになった。 ◎ TCP connection to the server timed out

`tcp.closed^l

~TCP接続が~serverにより~closeされた。 ◎ The TCP connection was closed by the server

`tcp.reset^l

~TCP接続が再設定された。 ◎ The TCP connection was reset

`tcp.refused^l

~TCP接続は ~serverにより拒否された。 ◎ The TCP connection was refused by the server

`tcp.aborted^l

~TCP接続は中止された。 ◎ The TCP connection was aborted

`tcp.address_invalid^l

無効な~IP~address。 ◎ The IP address is invalid

`tcp.address_unreachable^l

~IP~addressに到達-不能。 ◎ The IP address is unreachable

`tcp.failed^l

上の各項に挙げた~errorによるもの以外の事由に因り， ~TCP接続に失敗した。 ◎ The TCP connection failed due to reasons not covered by previous errors

`tls.version_or_cipher_mismatch^l

~versionまたは暗号の不一致に因り， ~TLS接続は中止された。 ◎ The TLS connection was aborted due to version or cipher mismatch

`tls.bad_client_auth_cert^l

無効な~client証明書に因り， ~TLS接続は中止された。 ◎ The TLS connection was aborted due to invalid client certificate

`tls.cert.name_invalid^l

無効な名前に因り， ~TLS接続は中止された。 ◎ The TLS connection was aborted due to invalid name

`tls.cert.date_invalid^l

無効な証明書~日付に因り， ~TLS接続は中止された。 ◎ The TLS connection was aborted due to invalid certificate date

`tls.cert.authority_invalid^l

無効な発行~権限に因り， ~TLS接続は中止された。 ◎ The TLS connection was aborted due to invalid issuing authority

`tls.cert.invalid^l

無効な証明書に因り， ~TLS接続は中止された。 ◎ The TLS connection was aborted due to invalid certificate

`tls.cert.revoked^l

廃止された~server証明書に因り， ~TLS接続は中止された。 ◎ The TLS connection was aborted due to revoked server certificate

`tls.cert.pinned_key_not_in_cert_chain^l

~key~pinning~errorに因り， ~TLS接続は中止された。 ◎ The TLS connection was aborted due to a key pinning error

`tls.protocol.error^l

~TLS~protocol~errorに因り， ~TLS接続は中止された。 ◎ The TLS connection was aborted due to a TLS protocol error

`tls.failed^l

上の各項に挙げた~errorによるもの以外の事由に因り， ~TLS接続に失敗した。 ◎ The TLS connection failed due to reasons not covered by previous errors

6.3. 要請／応答 ~errorの伝送

この節に挙げるすべての`~network~error$は、 `要請と応答の伝送$の間に生じるので，その`相$nEは `application^l になる。 ◎ All of the network errors in this section occur during the transmission of request and response, and therefore have a phase of application.

`http.error^l

~UAは応答を成功裡に受信したが，その状態s~codeは［ `4xx$st ／ `5xx$st ］であった。 ◎ The user agent successfully received a response, but it had a 4xx or 5xx status code

`http.protocol.error^l

~HTTP~protocol~errorに因り， 接続は中止された。 ◎ The connection was aborted due to an HTTP protocol error

`http.response.invalid^l

応答【の`内容$】が空である ／ `Content-Length$h に不一致がある ／ 符号化法【`内容~符号法$】が適正でない ／ ~UAが応答を処理できなくさせるような他の条件。 ◎ Response is empty, has a content-length mismatch, has improper encoding, and/or other conditions that prevent user agent from processing the response

`http.response.redirect_loop^l

~redirect~loopが検出されたことに因り， 要請は中止された。 ◎ The request was aborted due to a detected redirect loop

`http.failed^l

上の各項に挙げた~HTTP~protocolにおける~errorに因るもの以外の事由に因り， 接続に失敗した。 ◎ The connection failed due to errors in HTTP protocol not covered by previous errors

`abandoned^l

利用者が，資源~fetchを完了する前に中止した。 ◎ User aborted the resource fetch before it is complete

`unknown^l

未知な~error種別。 ◎ error type is unknown

7.1. 施策~定義の見本

【 以下に示される~code内の行頭に現れる［ ">" ／ "<" ］は、［ 要請／応答 ］の~dataを表す （それらの文字~自体は~dataの一部を成さない）。 それぞれ，以降に連なる［ ">" ／ "<" ］が無い行とともに “単独の行” を成す （それらの中の改行は、 見易くするための整形）。 】【 以下に現れる `Report-To@h ~headerは， `REPORTING$r に定義されていたが、 その仕様の更新により `Reporting-Endpoints$h ~headerに取って代わられ，その値も異なるものをとる。 】

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

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

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

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

7.2. ~network~error報告の見本

この節では、 ~UAが［ `~NEL施策$が登録されている`生成元$に対し，~network~errorに遭遇した ］ときに~queueし得る，`~network~error$`報告$の例を示す。 ここでは、 報告を~uploadするとき `REPORTING$r ~APIにより作成される全部的な報告~payloadを示す。 ~payloadの `body^c ~fieldが`~network~error$の報告~本体を包含する。 ◎ This section contains example network error reports the user agent might queue when a network error is encountered for an origin with a registered NEL policy. We show the full report payload that would be created by the [REPORTING] API when uploading the report; the payload's body field contains the network error report body.

【 他の~fieldに関する記述は、 `REPORTING$r の`報告先へ報告を送達する手続き＠~REPORTING#try-delivery$にある。 】

{
  "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"
  }
}

{
  "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"
  }
}

7.3. ~DNS環境設定の誤り

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

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

{
  "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"
  }
}

7.4. ~cache検証の監視-法

> 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

7.5. 複数の~IP~addressを伴う生成元

`生成元$のうち，その`~domain名$が複数の~IP~addressに解決されるものに対しては、 ~NELは，~error報告を “降格して” ~error~~要因について供する情報を減らすこともある — ［ `生成元$の所有者が，`要請$を取扱っている`~server$の所有者と同じかどうか ］を検証yできない場合に。 ◎ For origins whose domain name resolves to multiple IP addresses, NEL will sometimes "downgrade" an error report, providing less information about the cause of the error, since it cannot verify that the owner of the origin is the same as the owner of the server handling the request.

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

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

8.1. ~navi失敗~時の報告-法

利用者により起動される~navi要請 （例： ~linkの~click ／ ~URL~barを介する直な入力 ／ 利用者-ヤリトリに因り~scriptから起動されたもの ／ 等々） は、 いくつもの接続性の事由に因り失敗し得る — ~DNSにおける失敗, ~TCP~error, ~TLS~protocol違反, 等々。 これらの~errorは、［ ~network環境設定の誤り, 一過性の~routingの問題i, ~serverの~downtime, ~malware, 利用者に対する他の攻撃, 等々 ］により~~生じ得る。 ◎ A navigation request initiated by the user (e.g. via a click on a link, direct input via the location bar, script-initiated due to user interaction, etc.) may fail due any number of connectivity reasons: DNS failure, TCP error, TLS protocol violation, and so on. These errors may be caused by network misconfiguration, transient routing issues, server downtime, malware or other attacks against the user, etc.

そのような事例では、 行先の~hostは，失敗した~naviに気付かないままになることが多い — 定義により、 要請が~hostの基盤まで到達したかどうかを見れず，問題を究明できないので。 これに取組むため、 ~hostは，［ そのような究明できない失敗~報告を どこへ送達するべきかを指定する，`~NEL施策$ ］を~UAに登録できる。 ◎ In such cases the destination host is often left unaware of the failed navigation since, by definition, it cannot see the request reach its infrastructure and it is unable to investigate the problem. To address this, the host can register an NEL policy with the user agent, which specifies where reports of such failures should be delivered such that they can be investigated.

8.2. 当事者-主体に属する下位資源に対する~fetch失敗~時の報告-法

典型的な~appは、 数多くの資源を要求する。 その~fetchingは、 概して［ HTML／CSS／JavaScript ］を介して起動される。 そのような資源を要請している~appは、 大概は，その~fetchの失敗を観測できるが （例： `onerror^c ~callbackを介して）、 失敗がなぜ生じたかについての，詳細な~network~error報告 — 例： ~DNS失敗, ~TCP~error, ~TLS~protocol違反, 等々 — には~accessできない。 ◎ A typical application requires dozens of resources, the fetching of which is typically initiated via HTML, CSS, or JavaScript. The application requesting such resources can observe failures of most such fetches (e.g. via onerror callbacks), but it does not have access to the detailed network error report of why the failure has occurred - e.g. DNS failure, TCP error, TLS protocol violation, etc.

これに取組むため、 ~appは，［ ~fetch中にある下位資源が属する当事者-主体~host用の，関連な`~NEL施策$ ］を~UAに登録できる。 そのような`~NEL施策$が在る下では、 それが登録された`生成元$からの資源に対し~network~errorに遭遇した場合，~UAは詳細な~network~error報告を報告することを可能化することになり、 ~app開発者は，~errorについて究明できるようになる。 ◎ To address this, the application can register relevant NEL policies with the user agent for the first-party hosts from which the subresources are being fetched. Then, if such a policy is present and a network error is encountered for a resource from an origin with a registered NEL policy, the user agent will report the detailed network error report and enable the application developers to investigate the error.

8.3. 第三者-主体に属する下位資源に対する~fetch失敗~時の報告-法

資源が第三者-主体により埋込まれている事例では、 資源を供する側は、 失敗を［ 計測できない／観測できない ］ことが多い。 `example.com^s が 自身の~siteに資源 `widget.com/thing.js^s を埋込んでいて， `example.com^s を訪問している利用者が，~network~errorに因りそのような資源の~fetchに失敗した場合、 ~host `widget.com^s は、 失敗に気付くことも，それを検出することもできない。 ◎ In the case where a resource is embedded by a third party, the provider of the resource is often unable to instrument and observe the failure. For example, if example.com embeds a widget.com/thing.js resource on its site, and the user visiting example.com fails to fetch such resource due to a network error, the `widget.com` host is both unaware of the failure and unable to detect it.

`widget.com^s は、 これに取組むため，自身の~host用に`~NEL施策$を登録できる。 そのような施策が在る下で，それが登録された`生成元$から資源を~fetchする際に~network~errorに遭遇した場合 — 当事者-主体, 第三者-主体どちらの生成元から要請されたかを問わず — ~UAは~network~errorを報告することになり，資源を供する側は~errorを究明-可能になる。 ◎ To address this, widget.com can register an NEL policy for its host. Then, if such policy is present and a network error is encountered while fetching a resource — regardless of whether it is being requested from a first-party or third-party origin — from the origin with a registered NEL policy, the user agent will report the network error and enable the provider to investigate the error.