1. 序論
~web~appの処理能~特性を正確aに測定することは、 ~site開発者が,~web~appを改善する方法を解する補助として重要な側面を成す。 ~network~errorに因る[ ~app/特定0の資源 ]読込nの失敗は、 最悪な局面である。 開発者たちがそのような失敗に取組むためには、 そのような失敗が[ いつ,どこで,なぜ ]生じたかを識別するために,~UAからの支援を要する。 ◎ Accurately measuring performance characteristics of web applications is an important aspect in helping site developers understand how to improve their web applications. The worst case scenario is the failure to load the application, or a particular resource, due to a network error, and to address such failures the developer requires assistance from the user agent to identify when, where, and why such failures are occurring.
今日の~app開発者は、[ 末端利用者からの,~web~appの可用性 ]についての~dataを実時間に得ることはできない。 例えば、 利用者が~network~errorに因り ~pageの読込ngに失敗した場合 — [ ~DNS検索に失敗した, 接続が時間切れになった, 接続の再設定-, その他の事由 ]など — ~site開発者は,その問題iを検出して取組むことはできない。 これらの種類の~network~errorは、 純粋に~server側のみからは,検出できないことに注意 — 定義により,~clientは ~serverとの接続を成功裡に確立できないかもしれないので。 ◎ Today, application developers do not have real-time web application availability data from their end users. For example, if the user fails to load the page due to a network error, such as a failed DNS lookup, a connection timeout, a reset connection, or other reasons, the site developer is unable to detect and address this issue. Note that these kinds of network errors cannot be detected purely server-side, since by definition the client might not have been able to successfully establish a connection with the server.
既存の手法(人工的な監視 【 `synthetic monitoring@https://en.wikipedia.org/wiki/Synthetic_monitoring$en 】 など)は、 事前決定された地理的~所在に監視~nodeを配置することにより,部分的な解決策を供するが、 追加的な基盤~投資が要求され,[ 実在の末端利用者にとっての可用性について,真に全域的かつ実時間に近い~data ]は供せない。 ◎ Existing methods (such as synthetic monitoring) provide a partial solution by placing monitoring nodes in predetermined geographic locations, but require additional infrastructure investments, and cannot provide truly global and near real-time availability data for real end users.
~NEL( `Network Error Logging^en )は、[[[[ ~UAが[ 所与の生成元に対する~network~errorを報告する ]ときに利用できる報告用~施策 ]を,~web~appが宣言すること ]を可能化する仕組み ]を定義する ]ことにより,この必要性に取組む。 ~web~appは、[ 欲される`~NEL施策$を述べる `NEL$h ~HTTP応答~headerを給する ]ことにより,~NELの利用を任意選択できる。 この施策は、 その生成元への要請についての情報を~logしてから, その情報を `REPORTING$r ~APIを利用して 以前に環境設定された`報告先~group$へ送達しようと試みるよう、 ~UAに指図する。 その名が含意するように,~NEL報告の主用途は `~error^emを述べることにあるが、 異なる~client集団にわたる~errorの`比率^emを決定するためには,`成功した^em要請が どれだけ生じているかも知る必要がある — これらの成功した要請も,~NELの仕組みを介して報告できる。 ◎ Network Error Logging (NEL) addresses this need by defining a mechanism enabling web applications to declare a reporting policy that can be used by the user agent to report network errors for a given origin. A web application opts into using NEL by supplying a NEL HTTP response header field that describes the desired NEL policy. This policy instructs the user agent to log information about requests to that origin, and to attempt to deliver that information to a group of endpoints previously configured using the [[REPORTING]. As the name implies, NEL reports are primarily used to describe errors. However, in order to determine rates of errors across different client populations, we must also know how many successful requests are occurring; these successful requests can also be reported via the NEL mechanism.
例えば、 ~TCP接続が中止されたことに因り, ~UAが `https://www.example.com^s から資源の~fetchに失敗した場合、 ~UAは, `REPORTING$r ~APIを介して次の様な報告を~queueすることになる: ◎ For example, if the user agent fails to fetch a resource from https://www.example.com due to an aborted TCP connection, the user agent would queue the following report via the Reporting API:
- `種別$nE ◎ type
- `network-error^l
- `報告用~group$nP ◎ endpoint group
- `report_to$c ~fieldにより環境設定された`報告先~group$ ◎ the endpoint group configured by the report_to field
- 設定群 ◎ settings
- TODO
- ~data ◎ data
-
{ "referrer": "https://referrer.com/", "sampling_fraction": 1.0, "server_ip": "192.0.2.42", "protocol": "http/1.1", "elapsed_time": 321, "phase": "connection", "type": "tcp.aborted" }
通信される報告を成す各~field, および報告の形式についての説明は、 `§ ~network~error報告の生成-法@#generate-a-network-error-report$ に見られる。 より~~実践的な,~NEL登録と報告-時の処理-例は、 `§ 例@#examples$ に見られる。 ◎ See 5.4 Generate a network error report for an explanation of the communicated fields and format of the report, and 7. Examples for more hands-on examples of NEL registration and reporting process.
【この訳に特有な表記規約】
◎表記記号この仕様に現れる `要請@ ( `request^en )は、[ ~HTTPが定義する`要請@~HTTPinfra#request$【!~RFCx/rfc7231#introduction】, `FETCH$r が定義する`要請@~FETCH#concept-request$ ]いずれかを指す(両義的である) — どちらを指すかは、 柔軟に解釈する必要がある (原文では、 一律に~HTTP要請を参照しているが)。 `要請$が後者を指す場合、 その `生成元@rq は, `FETCH$r に定義される`要請の生成元@~FETCH#concept-request-origin$を指すことになる。
この仕様に現れる用語 `報告先~group@ は、 `REPORTING$r に定義されていたが,その仕様の更新により廃された — 代わる用語は(`報告$の)`行先$になると思われるが、 はっきりしない。
2. 適合性~要件
【 この節の内容は、 `~W3C日本語訳 共通~page@~W3Ccommon#conformance$に移譲。 】
2.1. 依存関係
【 この節の内容(他の仕様に定義される用語の一覧)は、 省略する。 】
3. 概念
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:
- `~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.
- `~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.
- `要請と応答の伝送@ ⇒ ~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. 施策の送達
`~server$は、 自身が制御する生成元~用の`~NEL施策$を,`NEL$h ~HTTP `応答~header$を介して定義してもヨイ。 ◎ A server MAY define a NEL policy for an origin it controls via the NEL HTTP response header.
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.1.1. `report_to^c ~member
`report_to@c ~memberは、 この`~NEL施策$用の報告の送信-先になる`報告先~group$を指定する。 `report_to$c ~memberは、 `~NEL施策$を登録するときには必須であり、 以前の登録を除去することが意図にあるならば任意選択~である — `max_age$c を見よ。 在る場合、 その値は文字列( `String^jt 型)でなければナラナイ — 他の型は、 構文解析-~errorになるとする。 ◎ The report_to member specifies the endpoint group that reports for this NEL policy will be sent to. The report_to member is REQUIRED to register a NEL policy, and OPTIONAL if the intent is to remove a previous registration – see max_age. If present, its value MUST be a string; any other type will result in a parse error.
注記: ~NEL報告の送達を改善するため、 `~server$は, `report_to^c に設定する`報告先~group$に[ ~fetchした資源の生成元とは隔たれた基盤に属する,代替~生成元 ]内にある報告先を 1 個~以上は包含するべきである — さもなければ、 問題が解消されるまで~network~errorを報告し得なくなるので。 加えて、[ 一部の報告先に到達-不能な場合の代替 ]として複数の報告先を供するべきである。 ◎ Note To improve delivery of NEL reports, the server should set report_to to an endpoint group containing at least one endpoint in an alternative origin whose infrastructure is not coupled with the origin from which the resource is being fetched — otherwise network errors cannot be reported until the problem is solved, if ever — and provide multiple endpoints to provide alternatives if some endpoints are unreachable.
4.1.2. `max_age^c ~member
`max_age@c ~memberは、 必須であり,この`~NEL施策$の存続期間を秒数で指定する。 その値は、 負でない整数でなければナラナイ — 他の型は、 構文解析-~errorになるとする。 ◎ The REQUIRED max_age member specifies the lifetime of this NEL policy, as a non-negative integer number of seconds. Its value MUST be an non-negative integer; any other type will result in a parse error.
値を 0 にすると、 この`生成元$用の`~NEL施策$は, `施策~cache$から除去されることになる。 ◎ A value of 0 will cause any NEL policy for this origin to be removed from the policy cache.
注記: ~NEL報告の送達を確保するため、 `~server$は,[ `報告先~group$も,十分高い `max_age^c で環境設定される ]ことを確保するべきである。 この生成元~用の`報告先~group$が失効した場合、 ~NEL施策が失効していなくとも,~NEL報告は送達されなくなる。 ◎ Note To ensure delivery of NEL reports, the server should ensure that the Reporting endpoint group is also configured with a sufficiently high max_age. If the Reporting policy expires, NEL reports will not be delivered, even if the NEL policy has not expired.
4.1.3. `include_subdomains^c ~member
`include_subdomains@c ~memberは、 任意選択~であり,[ ~obj内にこの~memberが在って, かつ その値は真偽値( `Boolean^jt 型 ) `true^jv ]ならば,この`~NEL施策$を,この生成元のすべての下位domain用にも可能化する (下位domainの深さは制限されない) — 他の場合、 この`~NEL施策$は下位domain用には可能化されない。 ◎ The OPTIONAL include_subdomains member is a boolean that enables this NEL policy for all subdomains of this origin (to an unlimited subdomain depth). If no member named include_subdomains is present in the object, or its value is not true, the NEL policy will not be enabled for subdomains.
注記: ~appは、 下位domain用の~NEL報告の送達を確保するためには、[ その`報告先~group$も, `include_subdomains^c が可能化されるよう環境設定される ]ことを確保するべきである。 この生成元~用の`報告先~group$が無いか,所与の下位domain用に別々な`報告先~group$【!~Reporting施策】は無い場合、 その下位domain用の~NEL報告は送達されなくなる — ~NEL施策にて下位domainを含んでいたとしても。 ◎ Note To ensure delivery of NEL reports for subdomains, the application should ensure that the Reporting endpoint group is also configured with include_subdomains enabled. If the Reporting policy is not, and there is not a separate Reporting policy for a given subdomain, NEL reports for that subdomain will not be delivered, even if the NEL policy includes the subdomain.
4.1.4. `success_fraction^c ~member
`success_fraction@c ~memberは、 任意選択~であり,[ この生成元~用の`~network要請$のうち`成功した$もの ]についての報告に適用されるべきである`見本抽出率$を定義する。 在る場合の値は 0.0 以上 1.0 以下の実数( `Number^jt 型)でなければナラナイ — 他の値は、 構文解析-~errorになるとする。 この~memberが無い場合、 ~UAは[ この生成元~用の`~network要請$のうち`成功した$もの ]については~NEL報告を`収集しない^emことになる。 ◎ The OPTIONAL success_fraction member defines the sampling rate that should be applied to reports about successful network requests for this origin. If present, its value MUST be a number between 0.0 and 1.0, inclusive; any other value will result in a parse error. If this member is not present, the user agent will not collect NEL reports about successful network requests for this origin.
4.1.5. `failure_fraction^c ~member
`failure_fraction@c ~memberは、 任意選択~であり,[ この生成元~用の`~network要請$のうち`失敗した$もの ]についての報告に適用されるべきである`見本抽出率$を定義する。 在る場合の値は 0.0 以上 1.0 以下の実数( `Number^jt 型)でなければナラナイ — 他の値は、 構文解析-~errorになるとする。 この~memberが無い場合、 ~UAは[ この生成元~用の`~network要請$のうち`失敗した$もの ]`すべて^emについての~NEL報告を収集することになる。 ◎ The OPTIONAL failure_fraction member defines the sampling rate that should be applied to reports about failed network requests for this origin. If present, its value MUST be a number between 0.0 and 1.0, inclusive; any other value will result in a parse error. If this member is not present, the user agent will collect NEL reports about all failed network requests for this origin.
4.1.6. `request_headers^c ~member
`request_headers@c ~memberは、 任意選択~であり,`要請~header名~list$nPを定義する。 それを成す各`名前$hdと対応する`値$hdは、 この`生成元$についての`~network~error報告$内に含まれることになる。 在る場合の値は,文字列たちが成す~listでなければナラナイ。 ◎ The OPTIONAL request_headers member defines the list of request headers whose names and values will be included in network error reports about this origin. If present, its value MUST be a list of strings.
4.1.7. `response_headers^c ~member
`response_headers@c ~memberは、 任意選択~であり,`応答~header名~list$nPを定義する。 それを成す各`名前$hdと対応する`値$hdは、 この`生成元$についての`~network~error報告$内に含まれることになる。 在る場合の値は,文字列たちが成す~listでなければナラナイ。 ◎ The OPTIONAL response_headers member defines the list of response headers whose names and values will be included in network error reports about this origin. If present, its value MUST be a list of strings.
4.2. 施策~headerの処理-法
この~algoは、 所与の ( `~network要請$ %要請, その要請に対する`応答$ %応答 ) に対し,[ %要請 の`生成元$用の`~NEL施策$を抽出した結果 ]に則って`施策~cache$を更新する: ◎ Given a network request (request) and its corresponding response (response), this algorithm extracts a NEL policy for request's origin, and updates the policy cache accordingly.
- %生成元 ~LET %要請 の`生成元$ ◎ ↓
- ~IF[ `生成元は信用に価し得るか?$( %生成元 ) ~EQ `価しない^i ] ⇒ ~RET ◎ Abort these steps if any of the following conditions are true: ◎ The result of executing the "Is origin potentially trustworthy?" algorithm on request's origin is not Potentially Trustworthy.
- ~IF[ %応答 は `NEL^h を名前に持つ`応答~header$を包含しない ] ⇒ ~RET ◎ response does not contain a response header whose name is NEL. ◎ ↑Let origin be request's origin.
- %~key ~LET `要請の~network区分~keyを決定する$( %要請 ) ◎ Let key be the result of calling determine the network partition key, given request.
- %~header ~LET 名 `NEL^h の`応答~header$の値 ◎ Let header be the value of the response header whose name is NEL.
- %~list ~LET %~header を与える下で `HTTP-JFV$r § 4 に定義される~algoを実行した結果 ◎ Let list be the result of executing the algorithm defined in Section 4 of [HTTP-JFV] on header.\
- ~IF[ %~list は~errorである ]~OR[ %~list は空である ] ⇒ ~RET ◎ If that algorithm results in an error, or if list is empty, abort these steps.
- %~item ~LET %~list[ 0 ] ◎ Let item be the first element of list.
- %max_age ~LET %~item 内に `max_age$c ~memberは[ 在るならば その値 / 無いならば ε ] ◎ ↓
- %report_to ~LET %~item 内に `report_to$c ~memberは[ 在るならば その値 / 無いならば ε ] ◎ ↓
- %success_fraction ~LET %~item 内に `success_fraction$c ~memberは[ 在るならば その値 / 無いならば 0.0 ] ◎ ↓
- %failure_fraction ~LET %~item 内に `failure_fraction$c ~memberは[ 在るならば その値 / 無いならば 1.0 ] ◎ ↓
- %include_subdomains ~LET ~IS[ %~item 内に `include_subdomains$c ~memberは在って,その値 ~EQ `true^jv ] ◎ ↓
-
%request_headers ~LET %~item 内に `request_headers$c ~memberは[ 在るならば その値 / 無いならば « » † ]
【† 原文には無い場合の値が指定されていないが、 他所の定義から,~listになる必要がある (次の段も同様)。 】
◎ ↓ - %response_headers ~LET %~item 内に `response_headers$c ~memberは[ 在るならば その値 / 無いならば « » ] ◎ ↓
-
~IF[ %max_age は実数でない ]~OR[ %max_age ~LT 0 † ] ⇒ ~RET
【† この条件は、 この訳による補完( `max_age$c の記述を見よ)。 】
◎ If item has no member named max_age, or that member's value is not a number, abort these steps. -
~IF[ %max_age ~EQ 0 ]:
-
`施策~cache$の`~key群$mapを成す ~EACH( %~cache~key ) に対し ⇒ ~IF[ %~cache~key の生成元 ~EQ %生成元 ] ⇒ `施策~cache$[ %~cache~key ] ~SET ε
【 本当は、 単に[ `施策~cache$[ ( %~key, %生成元 ) ] ~SET ε ]かもしれない — 施策~cacheに`~network区分~key$が追加された更新に伴い, この段も更新されるべきならば。 】
- ~RET
-
-
~IF[ ~NOT ~AND↓ ]…
- %report_to は文字列である
- %success_fraction は実数である
- %success_fraction ~GTE 0.0
- %success_fraction ~LTE 1.0
- %failure_fraction は実数である
- %failure_fraction ~GTE 0.0
- %failure_fraction ~LTE 1.0
- %request_headers を成すどの~itemも文字列である
- %response_headers を成すどの~itemも文字列である
…ならば ⇒ ~RET
◎ If item has no member named report_to, or that member's value is not a string, abort these steps. ◎ If item has a member named success_fraction, whose value is not a number in the range 0.0 to 1.0, inclusive, abort these steps. ◎ If item has a member named failure_fraction, whose value is not a number in the range 0.0 to 1.0, inclusive, abort these steps. ◎ If item has a member named request_headers, whose value is not a list, or if any element of that list is not a string, abort these steps. ◎ If item has a member named response_headers, whose value is not a list, or if any element of that list is not a string, abort these steps. -
%施策 ~LET 新たな`~NEL施策$ — その ⇒# `受信した~IP~address$nP ~SET ~UAに %応答 を送信した`~server$の~IP~address†, `生成元$ ~SET %生成元, `下位domainを含むか$nP ~SET %include_subdomains, `要請~header名~list$nP ~SET %request_headers, `応答~header名~list$nP ~SET %response_headers, `報告用~group$nP ~SET %report_to, `有効秒数$nP ~SET %max_age, `作成時刻$nP ~SET `粗化した現在の壁~時計~時刻$, `成功~時の見本抽出率$ ~SET %success_fraction, `失敗~時の見本抽出率$ ~SET %failure_fraction ◎ Let policy be a new NEL policy whose properties are set as follows: ◎ received IP address • the IP address of the server that the user agent received response from • Editor's note • Plumb this through more explicitly in [FETCH]. origin • origin subdomains flag • include if item has a member named include_subdomains whose value is true, exclude otherwise request headers • the value of item's request_headers member response headers • the value of item's response_headers member reporting group • the value of item's report_to member ttl • the value of item's max_age member creation • the current wall time successful sampling rate • the value of item's success_fraction member, if present; 0.0 otherwise failure sampling rate • the value of item's failure_fraction member, if present; 1.0 otherwise
†編集者注記: これを `FETCH$r において,より明示的に掘り下げる。 ◎ ↑
- `施策~cache$[ ( %~key, %生成元 ) ] ~SET %施策 ◎ If there is already an entry in the policy cache for (key, origin), replace it with policy; otherwise, insert policy into the policy cache for (key, origin).
5. 報告の送達
5.1. 要請~用の施策を選ぶ
この~algoは、 所与の ( `~network要請$ %要請 ) に対し,`施策~cache$内のどの`~NEL施策$を %要請 用の報告を生成するときに利用するべきかを決定する: ◎ Given a network request (request), this algorithm determines which NEL policy in the policy cache should be used to generate reports for that network request.
- %生成元 ~LET %要請 の`生成元$rq ◎ Let origin be request's origin.
- %~key ~LET `要請の~network区分~keyを決定する$( %要請 ) ◎ Let key be the result of calling determine the network partition key, given request.
- %施策 ~LET `施策~cache$[ ( %~key, %生成元 ) ] ◎ ↓
- ~IF[ %施策 ~NEQ ε ]~AND[ %施策 は`失効して$いない ] ⇒ ~RET %施策 ◎ If there is an entry in the policy cache for (key, origin): • Let policy be that entry. • If policy is not expired, return it.
-
%生成元 に`上位domain合致-$する ~EACH( %親~生成元 ) に対し: ◎ For each parent origin that is a superdomain match of origin:
- %親~施策 ~LET `施策~cache$[ ( %~key, %親~生成元 ) ] ◎ ↓
- ~IF[ %親~施策 ~NEQ ε ]~AND[ %親~施策 は`失効して$いない ]~AND[ %親~施策 の`下位domainを含むか$nP ~EQ ~T ] ⇒ ~RET %親~施策 ◎ If there is an entry in the policy cache for (key, parent origin): • Let policy be that entry. • If policy is not expired, and its subdomains flag is include, return it.
- ~RET ε ◎ Return no policy.
5.2. 要請~headerたちを抽出する
この~algoは、 所与の ( `~network要請$ %要請, `~NEL施策$ %施策 ) に対し,[ %施策 から指図された一連の~header ]の値を %要請 から抽出する: ◎ Given a network request (request) and a NEL policy (policy), this algorithm extracts header values from the request as instructed by the policy.
- %~header群 ~LET 新たな `Object^jt ◎ Let headers be a new empty ECMAScript object.
-
%施策 の`要請~header名~list$nPを成す ~EACH( %~header名 ) に対し: ◎ For each header name in policy's request headers list:
- %値~list ~LET 新たな~ES~list ◎ If request's header list does not contain header name, skip to the next header name in the list. ◎ Let values be an empty ECMAScript list.
- %要請 の`~header~list$rqを成す ~EACH( %~header名 を`名前に持つ~header$ %~header ) に対し ⇒ %値~list に %~header の`値$hdを付加する ◎ For each header in request's header list whose name is header name, append header's value to values.
- ~IF[ %値~list は空でない ] ⇒ %~header群 に 新たな~prop( 名前 %~header名, 値 %値~list ) を追加する ◎ Add a new property to headers whose name is header name and whose value is values.
- ~RET %~header群 ◎ Return headers.
5.3. 応答~headerたちを抽出する
この~algoは、 所与の ( `応答$ %応答, `~NEL施策$ %施策 ) に対し,[ %施策 から指図された~headerたち ]の値を %応答 から抽出する: ◎ Given a response (response) and a NEL policy (policy), this algorithm extracts header values from the response as instructed by the policy.
- %~header群 ~LET 新たな `Object^jt ◎ Let headers be a new empty ECMAScript object.
-
%施策 の`応答~header名~list$nPを成す ~EACH( %~header名 ) に対し: ◎ For each header name in policy's response headers list:
- %値~list ~LET 新たな~ES~list ◎ If response's header list does not contain header name, skip to the next header name in the list. ◎ Let values be an empty ECMAScript list.
- %応答 の`~header~list$rsを成す ~EACH( %~header名 を`名前に持つ~header$ %~header ) に対し ⇒ %値~list に %~header の`値$hdを付加する ◎ For each header in response's header list whose name is header name, append header's value to values.
- ~IF[ %値~list は空でない ] ⇒ %~header群 に 新たな~prop( 名前 %~header名, 値 %値~list ) を追加する ◎ Add a new property to headers whose name is header name and whose value is values.
- ~RET %~header群 ◎ Return headers.
5.4. ~network~error報告の生成-法
この~algoは、 所与の ( `~network要請$ %要請, その要請に対する`応答$ %応答 ) に対し, 合致している`~NEL施策$が在って指図されたならば %要請 についての報告を生成して, ( 結果の報告, `~NEL施策$ ) 組を返す — 他の場合は ~NULL を返す: ◎ Given a network request (request) and its corresponding response (response), this algorithm generates a report about request if instructed to by any matching NEL policy, and returns the report and the NEL policy. Otherwise this algorithm returns null.
- ~IF[ `生成元は信用に価し得るか?$( %要請 の`生成元$rq ) ~EQ `価しない^i ] ⇒ ~RET ~NULL ◎ If the result of executing the "Is origin potentially trustworthy?" algorithm on request's origin is not Potentially Trustworthy, return null.
- %生成元 ~LET %要請 の`生成元$rq ◎ Let origin be request's origin.
- %施策 ~LET `要請~用の施策を選ぶ$( %要請 ) ◎ Let policy be the result of executing 5.1 Choose a policy for a request on request.\
- ~IF[ %施策 ~EQ ε ] ⇒ ~RET ~NULL ◎ If policy is no policy, return null.
- %見本抽出率 ~LET [ %要請 は`成功した$ならば %施策 の`成功~時の見本抽出率$ / %要請 は`失敗した$ならば %施策 の`失敗~時の見本抽出率$ ] ◎ Determine the active sampling rate for this request: • If request succeeded, let sampling rate be policy's successful sampling rate. • If request failed, let sampling rate be policy's failure sampling rate.
- %賽 ~LET 0.0 以上 1.0 以下の~randomな実数(この要請を報告するかどうか裁定する) ◎ Decide whether or not to report on this request. Let roll be a random number between 0.0 and 1.0, inclusive.\
- ~IF[ %賽 ~GTE %見本抽出率 ] ⇒ ~RET ~NULL ◎ If roll ≥ sampling rate, return null.
-
%報告~本体 ~LET 次に挙げる~propを伴う,新たな `Object^jt `ECMA-262$r : ◎ Let report body be a new ECMAScript object with the following properties: [ECMA-262]
- `sampling_fraction^c
- %見本抽出率 ◎ sampling rate
- `elapsed_time^c
- ~UAが[ 当の資源~fetchを開始してから,完了したか中止したとき ]までに経過した~milli秒数 ◎ The elapsed number of milliseconds between the start of the resource fetch and when it was completed or aborted by the user agent.
- `phase^c
- %要請 は`失敗した$ならば その`~network~error$の`相$nE / %要請 は`成功した$ならば `application^l ◎ If request failed, the phase of its network error. If request succeeded, "application".
- `type^c
- %要請 は`失敗した$ならば その`~network~error$の`種別$nE / %要請 は`成功した$ならば `ok^l ◎ If request failed, the type of its network error. If request succeeded, "ok".
-
~IF[ %報告~本体 の `phase^c ~prop ~NEQ `dns^l ] ⇒ %報告~本体 に次に挙げる~propを付加する: ◎ If report body's phase property is not dns, append the following properties to report body:
- `server_ip^c
-
~UAが %要請 を送信した先の`~server$の~IP~address — 可用でなければ、 空~文字列 ◎ The IP address of the server to which the user agent sent the request, if available. Otherwise, an empty string.
- ~IPv4~addressで識別される~hostは、[ 範囲 0 〜 255 の 4 個の 10 進~数を "." で分離した並び ]( `dotted-decimal^en 表記法) `RFC1123$r で表現される。 ◎ A host identified by an IPv4 address is represented in dotted-decimal notation (a sequence of four decimal numbers in the range 0 to 255, separated by "."). [RFC1123]
- ~IPv6~addressで識別される~hostは、 順序付けられた 8 個の 16-bit 片が成す~list ( `x:x:x:x:x:x:x:x^c の~~形による並び)として表現される — ここで、 各 "x" は、 16-bit 片を表す[ 1 〜 4 個の 16 進数字 ]からなる) `RFC4291$r ◎ A host identified by an IPv6 address is represented as an ordered list of eight 16-bit pieces (a sequence of x:x:x:x:x:x:x:x, where the 'x's are one to four hexadecimal digits of the eight 16-bit pieces of the address). [RFC4291]
- `protocol^c
- 当の資源を~fetchするときに利用した ALPN Protocol ID により識別される`~network~protocol@~RESOURCE-TIMING#dom-performanceresourcetiming-nexthopprotocol$ — 可用でなければ、 空~文字列。 ◎ The network protocol used to fetch the resource as identified by the ALPN Protocol ID, if available. Otherwise, "".
-
~IF[ %報告~本体 の `phase^c ~prop ~NIN { `dns^l, `connection^l } ] ⇒ %報告~本体 に次に挙げる~propを付加する: ◎ If report body's phase property is not dns or connection, append the following properties to report body:
- `referrer^c
- %要請 の`~client$rqに結付けられた`~referrer施策$†により決定される††, %要請 の~referrer††† ◎ request's referrer, as determined by the referrer policy associated with its client.
- 【† ~clientの`施策~容器$enVの`~referrer施策$pC 】【†† `要請の~referrerを決定する~algo@~REFERRER-POLICY#determine-requests-referrer$ 】【††† `要請の~referrer@~FETCH#concept-request-referrer$ 】
- `method^c
- %要請 の`要請~method$ ◎ request's request method.
- `request_headers^c
- `要請~headerたちを抽出する$( %要請, %施策 ) ◎ The result of executing 5.2 Extract request headers on request and policy.
- `response_headers^c
- `応答~headerたちを抽出する$( %応答, %施策 ) ◎ The result of executing 5.3 Extract response headers on response and policy.
- `status_code^c
- ~HTTP応答の`状態s~code$ — 可用でなければ、 0 。 【したがって、可用なときも~data型は(文字列ではなく) `Number^jt になるであろう】 ◎ The status code of the HTTP response, if available. Otherwise, 0.
-
~IF[ ( %生成元, %施策 の`生成元$nP ) は`同一-生成元$でない ]~AND[ %施策 の`下位domainを含むか$nP ~EQ ~T ]~AND[ %報告~本体 の `phase^c ~prop ~NEQ `dns^l ] ⇒ ~RET ~NULL ◎ If origin is not equal to policy's origin, policy's subdomains flag is include, and report body's phase property is not dns, return null.
注記: この段は、[ `下位domainを含んで@#dfn-subdomains$いる`~NEL施策$ ]を利用し得るのは,[ `要請$の`~DNS解決$`相$の間に, 当の施策の`生成元$nPの下位domainについて報告を生成する ]ために限られることを確保する。 詳細は、 `§ ~privacyの考慮点@#privacy-considerations$を見よ。 ◎ Note This step ensures that subdomain NEL policies can only be used to generate reports about subdomains of the policy origin during the DNS resolution phase of a request. See 9. Privacy Considerations for more details.
-
~IF[ %報告~本体 の `phase^c ~prop ~NEQ `dns^l ]~AND[ %報告~本体 の `server_ip^c ~prop ~NIN { 空~文字列, %施策 の`受信した~IP~address$nP } ]: ◎ If report body's phase property is not dns, and report body's server_ip property is non-empty and not equal to policy's received IP address:
- %報告~本体 の `phase^c ~SET `dns^l ◎ Set report body's phase to dns.
- %報告~本体 の `type^c ~SET `dns.address_changed^l ◎ Set report body's type to dns.address_changed.
- %報告~本体 の次に挙げる~propを~clearする ⇒# `request_headers^c, `response_headers^c, `status_code^c, `elapsed_time^c ◎ Clear report body's request_headers, response_headers, status_code, and elapsed_time properties.
- ~Assert: [ `~DNS解決$の間に可用でない情報 ]から導出された %報告~本体 内の~fieldは、 すべて~clear済みである。 ◎ Assert: All fields in report body that are derived from information not available during DNS resolution have been cleared.
注記: この段は、 `~server$の~IP~addressと`~NEL施策$ %施策 が合致しない場合に,~NEL報告を “降格する” 。 これは、[ ~NEL報告は,それが述べる[ ~serviceの所有者 ]のみに送信される ]ことを確保するための,~privacy保護である。 ~IP~addressが合致しない場合、 ~UAは[ %施策 が`生成元$の`~domain名$の所有者により送信されたか否か ]だけを検証yでき,[ %施策 は[ この`~domain名$を解決して得られた`~server$ ]の所有者から送信されたか否か ]は検証yできない。 したがって、 `~DNS解決$についての情報のみ包含するよう,報告を降格する。 より詳細は、[ `§ ~privacyの考慮点@#privacy-considerations$, `§ 複数の~IP~addressを伴う生成元@#origins-with-multiple-ip-addresses$ ]を見よ。 ◎ Note This step "downgrades" a NEL report if the IP addresses of the server and the policy don't match. This is a privacy protection, ensuring that NEL reports are only sent to the owner of the service that the report describes. If the IP addresses don't match, then the user agent can only verify that the NEL policy was sent by the owner of the origin's domain name; it cannot verify that the policy was sent by the owner of the server this domain name resolves to. We therefore downgrade the report to only contain information about DNS resolution. See 9. Privacy Considerations and 7.5 Origins with multiple IP addresses for more details.
- ~IF[ %施策 は`非新鮮$である ] ⇒ `施策~cache$から %施策 を削除する ◎ If policy is stale, then delete policy from the policy cache.
- ~RET ( %報告~本体, %施策 ) ◎ Return report body and policy.
5.5. ~network報告を送達する
この~algoは、 所与の ( `Object^jt %報告~本体, `~NEL施策$ %施策, `~network要請$ %要請 ) に対し,報告を送達~用に~queueする (通例的に、 %報告~本体 は[ `~network~error報告を生成する$ ~algoから返された, これを~callしている仕様により増補されたもの ]であり, %施策 は[ その~algoにて %要請 に合致したもの ]である): ◎ Given a ECMAScript object (report body, usually returned from Generate a network error report and then augmented by the calling specification) and its matching NEL policy (policy) and network request (request), this algorithm queues the report for delivery.
- %~URL ~LET %要請 の`~URL$rq ◎ Let url be request's URL.
- %~URL の`素片$url ~SET ~NULL【!Clear】 ◎ Clear url's fragment.
- ~IF[ %報告~本体 の `phase^c ~prop ~IN { `dns^l, `connection^l } ] ⇒# %~URL の`~path$url ~SET « »【!Clear】; %~URL の`~query$url ~SET ~NULL【!Clear】 ◎ If report body's phase property is dns or connection: • Clear url's path and query.
- %直列化した~URL ~LET `~URLを直列化する$( %~URL ) ◎ ↓
- `~network報告を生成する$( `network-error^l, %施策 の`報告用~group$nP, %報告~本体, %直列化した~URL ) 【最後の引数の型が合致していない】 ◎ Generate a network report given these parameters: ◎ type • network-error data • report body endpoint group • policy's reporting group url • The result of running the URL serializer on url.
6. 定義済み~network~error種別
`~network~error$の`種別$nEには、 定義済みなものがいくつかある。 ◎ There are several predefined network error types.
~UAは、
以下の~listを~custom`~network~error$`種別$nEで拡張してもヨイ
— 例:新たな~protocolに適応するため/既存のものをより詳細に記述するためなど。
そうする場合、
~error報告の単純かつ一貫した処理を手助けするため、
~UAは,`種別$nE名は~dotで区切られる~pattern
( `[group]^v.`[optional-subgroup]^v.`[error-name]^v
)
に従うべきである
— 例えば,【報告の】収集器が供する集約は、
~categoryごとに, あるいは いくつかの下位groupに~~分別されてよい。
◎
The user agent MAY extend this list with custom network error types — e.g. to accommodate new protocols, or more detailed error descriptions of existing ones. When doing so, the user agent SHOULD follow the dot-delimited pattern ([group].[optional-subgroup].[error-name]) for the type names to facilitate simple and consistent processing of the error reports — e.g. the collector may provide aggregation by category and/or one or multiple subgroups.
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. 例
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 }
この `NEL^h ~headerが定義する`~NEL施策$は、[ `example.com^s についての~network~errorを,名前 `network-errors^l の`報告先~group$に報告する ]よう,~UAに指図する。 この施策は 2592000 秒間( 30 日間)適用される。 ◎ This NEL header defines a NEL policy, instructing the user agent to report network errors about example.com to the endpoint group named network-errors. The policy applies for 2592000 seconds (30 days).
上の登録は、 当の応答が`信用に価し得る生成元$から通信された場合に限り成功することに注意。 ◎ Note that above registration will only succeed if the response is communicated from a potentially trustworthy origin.
> GET / HTTP/1.1 > Host: example.com < HTTP/1.1 200 OK < ... < `NEL$h: {"max_age": 0}
この `NEL^h ~headerは、[ `example.com^s 用の`~NEL施策$が存在するならば,それを除去する ]よう,~UAに指図する。 ◎ This NEL header instructs the user agent to remove any existing NEL policy for example.com.
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" } }
上の報告は、 ~UAが次を行ったことを指示する:
- `example.com^s から `www.example.com^s へ~navigateしようと試みて、
- その~IP~addressは `2001:DB8::42^s に成功裡に解決され、
- HTTP/2( `h2^s )~protocolを介して~serverから `200$st 応答を受信したが、
- 交換に際し~protocol~errorに遭遇したため( `http.protocol.error^l ),~naviを放棄するよう強いられた。
- ~naviを開始してから中止するまで, 823 ~milli秒 経過し、
- 最後に,この報告を~network~errorに遭遇した直後に送信した — すなわち、 報告~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" } }
上の報告は、 ~UAが次を行ったことを指示する:
- `https://www.example.com/^s から `https://widget.com/thing.js^s を~fetchしようと試みたが、
- ~DNS名( `widget.com^s )を解決できなかったため、 143 ~milli秒後に要請を中止した。
- `widget.com^s への以前の要請は 妥当な`~NEL施策$を送達したので、 この要請~用に`~network~error$`報告$を生成した。
- その報告は`~network~error$に遭遇した直後に~uploadされた — すなわち、 報告~ageは 0
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 }
この `NEL^h ~headerは、 ~DNS~serverの環境設定を誤ったとき,それを検出することを `example.com^s の所有者に許容する — 一例として, `new-subdomain.example.com^s を~IP~addressに解決するための新たな資源~recordを追加し忘れたときなど。 ~UAは、 `new-subdomain.example.com^s への要請を為そうと試行した場合,次のような報告を生成することになろう: ◎ This NEL header allows the owner of example.com to detect when they have misconfigured their DNS servers — for instance, when they have forgotten to add a new resource record resolving new-subdomain.example.com to an IP address. If a user agent tries to make a request to new-subdomain.example.com, it might generate the following report:
{ "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
この例では、 `example.com^s の所有者は, `ETag$h 応答~headerを利用して~server上で~hostされる資源の各~versionを識別する。 ~UAは、[ 応答を受信した時点で,その資源のどの~versionが~client側に~cacheされているか ]を, `If-None-Match$h 要請~headerを利用して~serverに伝えれる。 それにより,~serverは、[ ~clientの既存の複製が最新の場合には、 資源の内容を生成して送信するのを避ける ]ことが可能になる。 ◎ In this example, the owner of example.com uses ETag response headers to identify different versions of the resources hosted on the server. User agents can then use If-None-Match request headers to inform the server which version of a resource is presently cached client-side, allowing the server to avoid generating and sending the content of the resource if the client's existing copy is up to date.
この~domain用の[ `request_headers$c, `response_headers$c ]~fieldを `NEL^h ~header内に含めることにより、 ~browserは,~NEL報告~内に `If-None-Match$h 要請~headerの複製と自身がその要請~用に作成する `ETag$h 応答~headerを含めることになる。 それにより,~site所有者は、 自身による~cache法~施策の実効性を追跡-可能になる。 ◎ By including request_headers and response_headers fields in the NEL header for this domain, the browser will include a copy of the If-None-Match request header and ETag response header in any NEL report that it creates for that request, allowing the site owner to track the effectiveness of their caching policies.
上が与えられた下で、 以下の順に生じる出来事を考える: ◎ Given the above, consider the following sequence of events:
-
~UAは `example.com^s へ向けて`要請$を送信して,`~server$から`応答$を成功裡に受信したとする — それは、 当の資源の~versionを指示している `ETag$h ~headerを伴う。 ~UAは、 次の~NEL報告を生成することになる: ◎ The user agent sends a request to example.com, and receives a successful response from the server, with an ETag header indicating the version of the resource. The user agent will generate the following NEL report:
{ "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" } }
-
いくばくか後,~UAは `example.com^s に向けて別の`要請$を送信する。 ~UAの局所~cache内には、 元の資源の複製がまだ在るので,その~versionを `If-None-Match$h 要請~header内に含める。 ~serverは、 この~versionを検査して,それがまだ在ることに気付いたので、 `304$st 応答を送信して,~UAに~cacheされている資源の複製は依然として有効であることを~UAに伝える。 ~UAは、 次の報告を生成することになる: ◎ Some time later, the user agent sends another request to example.com. The user agent still has a copy of the original resource in its local cache, and includes its version in a If-None-Match request header. The server checks this version, notices that it is still current, and sends a 304 response informing the user agent that its cached copy of the resource is still valid. The user agent will generate the following report:
{ "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" } }
-
しばらくして後、 ~UAは `example.com^s に向けて,また別の`要請$を送信する。 ~UAの局所~cache内には同じ資源の複製がまだ在り、 前の例と同じように `If-None-Match$h 要請~header内に その~versionを含める。 しかしながら今回は、 ~serverは,資源に新たな~versionが可用であることに気付いたので、 この資源の内容を生成し,新たな~versionを応答の `ETag$h 応答~header値~内に符号化した上で~clientに送信する。 ~UAは、 次の報告を生成することになる: ◎ Even later, the user agent sends yet another request to example.com. The user agent still has the same copy of the resource in its local cache, and includes its version in a If-None-Match request header, as in the previous example. However, this time the server notices that there is a new version of the resource available. It generates the content of this resource, and sends it to the client, with the new version encoded in a new ETag response header value. The user agent will generate the following report:
{ "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" } }
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.
例として、 `example.com^s は,互いに~IP~addressが異なる 3 つの`~server$で取扱われていて、 その~serviceの所有者は `example.com^s は[ `192.0.2.1^s / `192.0.2.2^s / `192.0.2.3^s ]に解決されるよう~DNSを環境設定していて、 各~UAが それらの要請を これらの 3 つの~IP~addressに分散することに依拠していてるとする。 ~serviceの所有者は、 次の`~NEL施策$を送達するようにしたとする: ◎ As an example, assume that example.com is handled by three servers, each with a different IP address. The owner of the service configures DNS to resolve example.com to 192.0.2.1, 192.0.2.2, and 192.0.2.3, and relies on user agents to balance their requests across these three IP addresses. The service owner delivers the following NEL policy:
> 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 }
上が与えられた下で、 以下の順に生じる出来事を考える: ◎ Given the above, consider the following sequence of events:
-
~UAは、 `要請$を `192.0.2.1^s に向けて送信して,`~server$から`応答$を成功裡に受信した。 この応答は,上の`~NEL施策$を含むので、 ~UAは,施策の`受信した~IP~address$nPを `192.0.2.1^s に設定する。 `受信した~IP~address$nPは`~server$の~IP~addressに合致するので (成功したどの要請も,そうなるはずである)、 次の~NEL報告を生成する: ◎ The user agent sends a request to 192.0.2.1, and receives a successful response from the server. This response includes the above NEL policy, and the user agent sets the policy's received IP address to 192.0.2.1. Since the received IP address matches the server's IP address (which it must for any successful request), it generates the following NEL report:
{ "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" } }
-
~UAは、 新たな`要請$を `192.0.2.2^s へ送信して,別の`応答$を成功裡に受信した。 この応答も同じ`~NEL施策$を含む。 ~UAは、 施策の`受信した~IP~address$nPを `192.0.2.2^s に更新する。 `受信した~IP~address$nPは,`~server$の~IP~addressに合致するので (成功したどの要請も,そうなるはずである)、 次の~NEL報告を生成する: ◎ The user agent sends a new request to 192.0.2.2, and receives another successful response. This response also includes the NEL policy, and the user agent updates the policy's received IP address to 192.0.2.2. Since the received IP address matches the server's IP address (which it must for any successful request), it generates the following NEL report:
{ "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" } }
-
~UAは、 `要請$を `192.0.2.3^s へ送信しようと試行したが,~serverへの接続は確立できなかった。 ~UAの`施策~cache$内には,依然として`~NEL施策$があるので、 この施策を利用して,`失敗した$`~network要請$についての報告を — その`種別$nEを `tcp.timed_out^l にして — 生成したい所だが… 当の施策の`受信した~IP~address$nP( `192.0.2.2^s )は,この`要請$を送信-元~の~IP~addressに合致しないため, `192.0.2.3^s にある~serverが実際に `example.com^s の所有者が所有しているか検証yできない。 したがって,~UAは、 報告を `dns.address_changed^l に降格するモノトスル: ◎ The user agent then tries to send a request to 192.0.2.3, but isn't able to establish a connection to the server. The user agent still has the NEL policy in the policy cache, and would ideally use this policy to generate a tcp.timed_out report about the failed network request. However, the because policy's received IP address (192.0.2.2) doesn't match the IP address that this request was sent to, the user agent cannot verify that the server at 192.0.2.3 is actually owned by the owners of example.com. The user agent must therefore downgrade the report to dns.address_changed:
{ "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" } }
-
~UAは、 別の`要請$を `192.0.2.1^s へ送信しようと試行したが,またもや~serverへの接続は確立できなかった。 ~UAは過去のある時点で `192.0.2.1^s から`~NEL施策$を受信していたとしても、 施策の`受信した~IP~address$nPには,そこ 【すなわち `https://example.com^s (から導出される生成元)】 から`最も近過去^emに受信したそれ — この事例では `192.0.2.2^s — しか記録されない。 したがって,~UAは、 報告を `dns.address_changed^l に降格するモノトスル: ◎ The user agent then tries to send another request to 192.0.2.1, but once again isn't able to establish a connection to the server. Even though the user agent received the NEL policy from 192.0.2.1 at some point in the past, the policy's received IP address only records where it was most recently received from — in this case, 192.0.2.2. The user agent must therefore downgrade the report to dns.address_changed:
{ "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" } }
8. 利用事例
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.
9. ~privacyの考慮点
~NELは、[ 利用者の~network環境設定についての新たな情報 ]も公開し得るような,~network~error報告を供する。 例えば,攻撃者は、[ 利用者の~network環境設定を探査したり,利用者の内部~network上の~serverを~scanする ]ために~NEL報告-法を濫用することもできる。 また,[ HSTS, HPKP, ~pinned CSP 施策 ]と類似に、 格納される`~NEL施策$は,[ (利用者ごとに異なる)~customな報告~先~URLを伴う,別個な施策を設定する ]ことにより[ ~HTTP~cookieとの組合nで(または それに代わる),識別子として動作するような “`supercookie^en” ]にも利用できる。 ◎ NEL provides network error reports that could expose new information about the user's network configuration. For example, an attacker could abuse NEL reporting to probe the user's network configuration, or to scan for servers on the user's internal network. Also, similar to HSTS, HPKP, and pinned CSP policies, the stored NEL policy could be used as a "supercookie" by setting a distinct policy with a custom (per-user) reporting URI to act as an identifier in combination with (or instead of) HTTP cookies.
上述の~riskの一部を軽減するため、 ~NEL登録は,`信用に価し得る生成元$に制約され、 ~network~error報告の送達も,同様に`信用に価し得る生成元$に制約される。 これは、 ~NELを持続的な追跡器として自明に濫用するような, 一過性の~HTTP MITM† を許容しないようにする。 【MIIM — `Man In The Middle^en — 中間者(攻撃)】 ◎ To mitigate some of the above risks, NEL registration is restricted to potentially trustworthy origins, and delivery of network error reports is similarly restricted to potentially trustworthy origins. This disallows a transient HTTP MITM from trivially abusing NEL as a persistent tracker.
加えて,~NEL`施策~cache$は、 `~network区分~key$を利用して区分される — 何かを埋込んでいる文脈~内で,ある~site用に格納された`~NEL施策$が、 異なる文脈~内では利用されないよう (一例として,異なる~top-level~siteにより埋込まれたとき)。 ◎ Additionally, the NEL policy cache is partitioned using the network partition key, so that a NEL policy stored for a site in one embedding context will not be used in a different context (for instance, when embedded by a different top-level site.)
~NELは、 既存の~server側~監視を増補することが意図されている。 ~NEL報告の送信-先は、 要請している~serviceの所有者に限られるべきである。 `~DNS解決$の間に生じた~errorに対しては、 ~NEL報告は[ `~NEL施策$が[ その`生成元$nPを包含する`~domain名前空間~tree$ ]の所有者から受信されたとき ]に限り生成される。 [ `~secure接続の確立$ / `要請と応答の伝送$ ]の間に生じた~errorに対しては、 ~NEL報告は[ `要請$を送信した先の`~server$の所有者から`~NEL施策$が受信されたとき ]に限り生成される。 ◎ NEL is intended to augment existing server-side monitoring. NEL reports should only be sent to the owner of the service being requested. For errors that occur during DNS resolution, NEL reports are only generated when the NEL policy was received from the owner of the domain namespace tree that contains the policy origin. For errors that occur during secure connection establishment or transmission of request and response, NEL reports are only generated when the NEL policy was received from the owner of the server that the request was sent to.
以下では、 `~NEL施策$の[ `受信した~IP~address$nP / `下位domainを含むか$nP ]の扱いを説明する。 [ 施策の`受信した~IP~address$nPが`~server$の~IP~addressに合致するか検査する ]ことにより、 ~NELは,施策の信用-境界を[ 施策の`生成元$nPのみならず,~UAが通信している特定の~serverも含む ]ように拡張する。 この検査は、 (一例として) `DNS rebinding^en【 ~domain名を別の~IP~addressに “束縛し直す” 】攻撃を防ぐためにある: そこでは,攻撃者は、 自身が所有する ある~serverから長生きする`~NEL施策$を送達した上で,その名前~server( `name server^en )を[ 施策の`生成元$nPを,自身が制御しない別の~serverに解決する ]ように変更する。 `受信した~IP~address$nPを検証yしなかった場合、 ~UAは,別の~serverについての報告を攻撃者へ送信させられることになる。 ◎ This rationale explains the treatment of the received IP address and subdomains flag of a NEL policy. By checking that the policy's received IP address matches the IP address of the server, NEL extends the trust boundary of the policy to include not just the policy's origin, but also the specific server that the user agent is communicating with. This helps prevent (for instance) DNS rebinding attacks, where an attacker delivers a long-lived NEL policy from a server that they own, and then changes their name servers to resolve the policy origin to a server they don't control. Without the received IP address verification, this would cause user agents to send reports about the second server to the attacker.
同様に,`下位domainを含んで@#dfn-subdomains$いる`~NEL施策$は、[ `要請$の`~DNS解決$の間に,施策の`生成元$nPの下位domainについての報告を生成するとき ]に限り利用できるよう制限される。 この`相$の間は、 ~errorの所有者が誰なのか検証yするための`要請$は無い — それを確立するには[ 当の施策が`要請$の`生成元$rqの上位domainから受信された事実 ]だけで十分になる。 これは、 `~domain名前空間~tree$の特定0の部位の所有者に[ ~NELを利用して,`~DNS環境設定の誤り@#dns-misconfiguration$を検出する ]ことを許容する一方で、 所有者が[ 自身が制御しない~serverについての情報を,悪意的な~DNS~entryを利用して収集する ]ことは防ぐ。 ◎ Similarly, subdomain NEL policies are limited, and can only be used to generate reports about subdomains of the policy origin during the DNS resolution phase of a request. During this phase, there is no server to verify ownership of, and the fact that the policy was received from a superdomain of the request's origin is enough to establish ownership of the error. This allows the owners of a particular portion of the domain namespace tree to use NEL to detect 7.3 DNS misconfiguration errors, while preventing them from using malicious DNS entries to collect information about servers they don't control.
情報~漏洩eを防ぐため、 `要請$についての~NEL報告は,[ `要請$を処理するときに,`~server$からは可視でない情報 ]は包含しない。 `~DNS解決$の間の~errorに対しては、 ~NEL報告は,[ ~DNS自身から可用な情報 ]のみを包含する。 これは、 `~server$が,~NELを濫用して[ 利用者についてすでに~accessを有しているもの ]を超える情報を収集するのを防ぐ。 ◎ To prevent information leakage, NEL reports about a request do not contain any information that is not visible to the server when processing the request. For errors during DNS resolution, a NEL report only contains information available from DNS itself. This prevents servers from abusing NEL to collect more information about their users than they already have access to.
注記: 例として,~NEL報告は、[ `要請$の`~domain名$を~IP~addressに解決するときに,どの`~DNS解決器$が利用されたか ]についての情報は,特定的に包含しない。 ◎ Note As an example, NEL reports specifically do not contain any information about which DNS resolver was used to resolve a request's domain name into an IP address.
上の制約に加えて、 ~UAは,次に従うモノトスル: ◎ In addition to above restrictions, the user agents MUST:
- 利用者が自身の閲覧~data( ~cookie, ~site~data, 履歴, 等々)を~clearしたときは、 格納-済み`~NEL施策$も~clearする。 ◎ Clear the stored NEL policies when the user clears their browsing data (cookies, site data, history, etc).
- ~network~error報告を送達するときは、 `Set-Cookie$h 応答~headerを処理するのを拒否する。 ◎ Refuse to process Set-Cookie response headers when delivering network error reports.
開発者は、 ~NELを配備するときには,[ 指定した収集器に~NEL報告を送達することによる~privacyへの影響n ]を考慮するべきである。 例えば、 報告は,[ 特別な予防策が必要な敏感な~data ]を伴う~URL(例: “`能力~URL$” `CAPABILITY-URLS$r )を包含することもあり、 開発者には,[ そのような~URLが第三者-主体へ報告されるのを防ぐ ]ように[ 自前の~NEL収集器を運用する ]ことが要求され得る。 ◎ When deploying NEL the developer SHOULD consider privacy implications of NEL reports delivered to the specified collectors. For example, reports may contain URLs with sensitive data (e.g. "Capability URLs") that may need special precautions (see [CAPABILITY-URLS]), and may require the developer to operate their own NEL collectors to prevent reporting of such URLs to third parties.
10. IANA 考慮点
恒久的~message~header~registryは、 以下の登録により更新されるべきである `RFC3864$r : ◎ The permanent message header field registry should be updated with the following registrations ([RFC3864]): ◎ 10.1. NEL
- ~header名
- `NEL$h
- 適用-可能な~protocol
- http
- 位置付け
- 標準
- 著作者/変更~制御者
- W3C
- 仕様~文書
- この仕様( `NEL$h 応答~headerを見よ)
謝辞
この文書は `CSP$r, `RFC6797$r 仕様の~textを,その~licenseに従って再利用している。 加えて、 この作業に~~有益な~commentを寄せられ貢献された,次に挙げる各氏に感謝する ⇒ `Julia Tuttle, Chris Bentzel, Todd Reifsteck, Aaron Heady, Mark Nottingham^en ◎ This document reuses text from the [CSP] and [RFC6797] specification, as permitted by the licenses of those specifications. Additionally, sincere thanks to Julia Tuttle, Chris Bentzel, Todd Reifsteck, Aaron Heady, and Mark Nottingham for their helpful comments and contributions to this work.