网络错误日志记录

当 用户代理尝试通过网络针对给定执行 HTTP 网络获取 某个资源的请求时，就会发生一个 网络请求。

如果已知用户 代理处于离线状态（即 navigator. onLine 返回 false），则请求不得产生网络请求。

如果请求因混合内容或 CORS 失败而被阻止，则该请求不得产生网络请求。任何 CORS 预检请求必须产生其自身的网络请求。

无论使用哪种获取算法以及哪种底层应用和 传输协议，处理一个网络请求都由 以下阶段组成：

1. DNS 解析：用户代理使用域名系统 [RFC1034] 将域名解析为能够为该域处理 HTTP 请求的 服务器的 IP 地址。
2. 安全连接建立：用户代理打开到 服务器的连接，并在 此连接上建立安全通道。
3. 请求和响应的传输：安全 通道建立后，用户代理可以传输 HTTP 请求，并从服务器接收响应。

唯一强制的阶段是请求和 响应的传输；其他阶段可能并非每个 网络请求都需要。例如，DNS 结果可以在用户代理中本地缓存， 从而省去以后向相同域发出请求时的DNS 解析。 类似地，HTTP 持久连接 允许多个对相同 网络分区键的请求共享已打开的连接。不过，如果发生多个阶段， 它们将按照上述顺序发生。

如果用户代理能够 从服务器接收到有效的 HTTP 响应，并且该响应没有 4xx 或 5xx 状态码，则一个网络请求是成功的。

如果一个网络请求并非成功的，则它是失败的。

网络错误是导致网络请求失败的错误条件。

每个网络错误都有一个类型，它是 一个字符串。

每个网络错误都有一个阶段，用于描述错误发生在哪个阶段：

dns

错误发生在 DNS 解析期间

connection

错误发生在安全连接 建立期间

application

错误发生在请求和 响应的传输期间

6. 预定义网络 错误类型中定义了若干预定义的网络错误类型。

网络错误报告是一种描述 网络错误的 Reporting API 报告。

网络错误报告的报告 类型为 network-error。

网络错误报告不会对 ReportingObserver 可见。

NEL 策略 指示用户代理是否收集有关向某个源发出的 网络请求的报告，以及在收集时将其发送到何处。 NEL 策略通过 HTTP 响应标头交付给用户代理。

每个NEL 策略都有一个接收 IP 地址，即用户代理从中接收该 NEL 策略的服务器的 IP 地址。

每个NEL 策略都有一个源。

每个NEL 策略都有一个子域标志， 其值为 include 或 exclude。

每个NEL 策略都有一个请求标头列表和一个响应 标头列表，其中每个列表都是标头 名称的列表。

每个NEL 策略都有一个报告组，它是此策略的报告将 被发送到的 Reporting 端点组的名称。

每个NEL 策略都有一个ttl，表示该策略保持有效的 秒数。

每个NEL 策略都有一个创建时间，即用户代理接收到该策略时的 时间戳。

如果从 创建时间到墙上 时钟的不安全当前时间的持续时间 大于 172800 秒（48 小时），则一个NEL 策略是陈旧的。

如果从 创建时间到墙上 时钟的不安全当前时间的持续时间 大于其ttl（以秒为单位），则一个NEL 策略是已过期的。

预计会处理大量流量的源可能 没有能力接收针对向该源发出的每个网络请求的 NEL 报告。 该源可以定义采样 率，以限制每个用户代理 提交的 NEL 报告数量。由于成功请求通常应远远 多于失败请求，因此该源可以分别为二者指定不同的 采样率。

每个NEL 策略都有一个成功采样率，它是 一个介于 0.0 和 1.0 之间（含两端）的数字。

每个NEL 策略都有一个失败采样率，它是一个 介于 0.0 和 1.0 之间（含两端）的数字。

一致的用户代理必须提供一个策略缓存，它是一种 存储机制，用于维护一组NEL 策略，并以 （网络分区键、源）元组作为键。

此存储机制是不透明的、供应商特定的，并且不会暴露给 Web，但它必须提供以下方法，本文档定义的 算法将使用这些方法：

• 插入、更新和删除NEL 策略。
• 检索给定源 和网络分区键对应的NEL 策略（如果存在）。
• 清除缓存。

NEL 响应标头用于 将源的NEL 策略传达给用户代理。NEL 标头的 ABNF（扩充巴科斯-诺尔形式）[RFC5234] 语法 如下：

NEL = json-field-value

标头的值被解释为 JSON 对象数组，如 json-field-value 中所定义。数组中的每个对象都为该源定义一个 NEL 策略。用户代理必须处理数组中的第一个有效 策略，并忽略数组中的所有其他策略。

用户代理必须忽略任何不符合本规范中所定义语法的未知或无效字段或值。一个有效的NEL 标头字段必须至少包含一个对象，并包含本规范中定义的所有“必需”字段。

用户代理必须忽略通过 meta 元素指定的NEL 标头，以缓解通过脚本攻击劫持错误报告的问题。NEL 策略必须通过 NEL 响应标头交付。

给定一个网络请求（request）及其对应的 响应（response），此算法为 request 的NEL 策略提取其源，并相应地更新 策略缓存。

1. 如果以下任一条件为真，则中止这些步骤：
   • 对 request 的 源执行“源是否可能 可信？”算法的结果不是 Potentially Trustworthy。
   • response 不包含名称为 NEL 的响应标头。
2. 令 origin 为 request 的源。
3. 令 key 为给定 request 的 保留客户端，调用确定网络 分区键所得的结果。
4. 令 header 为名称为 NEL 的响应标头的值。
5. 令 list 为执行 [HTTP-JFV] 第 4 节中定义的算法 对 header 所得的结果。如果该算法 导致错误，或者 list 为空，则中止这些 步骤。
6. 令 item 为 list 的第一个元素。
7. 如果 item 没有名为 max_age 的成员，或者该 成员的值不是数字，则中止这些步骤。
8. 如果 item 的 max_age 成员的值为 0，则从策略 缓存中移除其源为 origin 的任何NEL 策略，并跳过剩余步骤。
9. 如果 item 没有名为 report_to 的成员，或者该 成员的值不是字符串，则中止这些步骤。
10. 如果 item 有一个名为 success_fraction 的成员， 且其 值不是 0.0 到 1.0（含两端）范围内的数字，则中止这些 步骤。
11. 如果 item 有一个名为 failure_fraction 的成员， 且其 值不是 0.0 到 1.0（含两端）范围内的数字，则中止这些 步骤。
12. 如果 item 有一个名为 request_headers 的成员，且其 值不是列表，或者该列表中的任何元素不是字符串， 则中止这些步骤。
13. 如果 item 有一个名为 response_headers 的成员， 且其 值不是列表，或者该列表中的任何元素不是字符串， 则中止这些步骤。

14. 令 policy 为一个新的NEL 策略，其属性 设置如下：

    接收 IP 地址

    用户代理从中接收 response 的服务器的 IP 地址

    编辑者注

    在 [FETCH] 中更明确地传递此信息。

    源

    origin

    子域标志

    如果 item 有一个名为 include_subdomains 且值为 true 的成员，则为 include， 否则为 exclude

    请求标头

    item 的 request_headers 成员的值

    响应标头

    item 的 response_headers 成员的值

    报告组

    item 的 report_to 成员的值

    ttl

    item 的 max_age 成员的值

    创建时间

    墙上时钟的不安全当前时间

    成功采样率

    如果存在，则为 item 的 success_fraction 成员的值； 否则为 0.0

    失败采样率

    如果存在，则为 item 的 failure_fraction 成员的值； 否则为 1.0

15. 如果策略缓存中已经存在 (key, origin) 的条目，则用 policy 替换它；否则，将 policy 插入 策略缓存中的 (key, origin)。

给定一个网络请求（request），此算法 确定策略缓存中的哪个NEL 策略应 用于为该网络请求生成报告。

1. 令 origin 为 request 的源。
2. 令 key 为给定 request 的 保留客户端，调用确定网络 分区键所得的结果。
3. 如果策略缓存中存在 (key, origin) 的条目：
   1. 令 policy 为该条目。
   2. 如果 policy 未过期，则返回它。
4. 对于 origin 的每个超域匹配 parent origin：
   1. 如果策略缓存中存在 (key, parent origin) 的条目：
      1. 令 policy 为该条目。
      2. 如果 policy 未过期，并且其 子域标志为 include， 则返回它。
5. 返回 no policy。

给定一个网络请求（request）和一个NEL 策略（policy），此算法按照该策略的指示从请求中 提取标头值。

1. 令 headers 为一个新的空 ECMAScript 对象。
2. 对于 policy 的请求标头列表中的每个 header name：
   1. 如果 request 的标头列表不包含 header name，则跳到列表中的下一个 header name。
   2. 令 values 为一个空 ECMAScript 列表。
   3. 对于 request 的 标头列表中其名称 为 header name 的每个 header，将 header 的 值追加到 values。
   4. 向 headers 添加一个新属性，其名称为 header name，值为 values。
3. 返回 headers。

给定一个响应（response）和一个NEL 策略 （policy），此算法按照该策略的指示从 响应中提取标头值。

1. 令 headers 为一个新的空 ECMAScript 对象。
2. 对于 policy 的响应标头列表中的每个 header name：
   1. 如果 response 的标头列表 不包含 header name，则跳到列表中的下一个 header name。
   2. 令 values 为一个空 ECMAScript 列表。
   3. 对于 response 的 标头列表中其名称为 header name 的每个 header，将 header 的值追加到 values。
   4. 向 headers 添加一个新属性，其名称为 header name，值为 values。
3. 返回 headers。

给定一个网络请求（request）及其对应的 响应（response），如果任何匹配的NEL 策略指示这样做，则此算法生成一份关于 request 的报告， 并返回该报告和 NEL 策略。否则，此 算法返回 null。

1. 如果对 request 的源执行“源是否可能 可信？”算法的结果 不是 Potentially Trustworthy，则返回 null。
2. 令 origin 为 request 的源。
3. 令 policy 为对 request 执行 5.1 为请求选择策略所得的结果。如果 policy 为 no policy，则返回 null。
4. 确定此请求的有效采样率：
   • 如果 request 成功，令 sampling rate 为 policy 的成功采样 率。
   • 如果 request 失败，令 sampling rate 为 policy 的失败采样率。
5. 决定是否报告此请求。令 roll 为 0.0 到 1.0（含两端）之间的随机数。如果 roll > sampling rate，则返回 null。
6. 令 report body 为一个具有以下 属性的新 ECMAScript 对象：[ECMA-262]

   sampling_fraction

   sampling rate

   elapsed_time

   从资源开始获取到获取完成或被用户代理中止之间 经过的毫秒数。

   phase

   如果 request 失败，则为其网络 错误的阶段。如果 request 成功，则为 "application"。

   type

   如果 request 失败，则为其 网络错误的类型。如果 request 成功， 则为 "ok"。

7. 如果 report body 的 phase 属性不是 dns，则将以下属性追加到 report body：

   server_ip

   用户代理向其发送 请求的服务器的 IP 地址（如果可用）。否则为空字符串。

   • 由 IPv4 地址标识的主机以 点分十进制表示法表示（由四个范围在 0 到 255 之间的十进制数字组成的序列，以“.”分隔）。[RFC1123]
   • 由 IPv6 地址标识的主机表示为 八个 16 位部分的有序列表（即 x:x:x:x:x:x:x:x 序列，其中每个“x”是该地址八个 16 位部分之一的一到四位十六进制 数字）。[RFC4291]

   protocol

   用于获取资源的网络协议， 由 ALPN 协议 ID 标识（如果可用）。否则为 ""。

8. 如果 report body 的 phase 属性不是 dns 或 connection，则将以下 属性追加到 report body：

   referrer

   request 的 referrer，由与其客户端关联的referrer 策略确定。

   method

   request 的 请求方法。

   request_headers

   对 request 和 policy 执行 5.2 提取请求标头所得的结果。

   response_headers

   对 response 和 policy 执行 5.3 提取响应标头所得的结果。

   status_code

   HTTP 响应的状态码（如果可用）。否则为 0。

9. 如果 origin 不等于 policy 的源，policy 的 子域标志为 include，并且 report body 的 phase 属性不是 dns， 则返回 null。
   注

   此步骤确保子域NEL 策略只能在请求的DNS 解析阶段期间， 用于生成有关策略源的子域的报告。有关 更多详细信息，请参阅 9. 隐私注意事项。

10. 如果 report body 的 phase 属性不是 dns，且 report body 的 server_ip 属性非空并且不等于 policy 的接收 IP 地址：
    1. 将 report body 的 phase 设置为 dns。
    2. 将 report body 的 type 设置为 dns.address_changed。
    3. 清除 report body 的 request_headers、 response_headers、status_code 和 elapsed_time 属性。
    4. 断言：report body 中所有派生自 DNS 解析期间不可用信息的字段均已 清除。
    注

    如果服务器与策略的 IP 地址不匹配， 此步骤会“降级”NEL 报告。 这是一种隐私保护措施，可确保 NEL 报告只发送 给报告所描述服务的所有者。如果 IP 地址不匹配，则用户代理只能验证 NEL 策略是由源的 域名所有者发送的；它无法验证 该策略是否由此域名解析到的服务器的所有者发送。因此，我们 将报告降级为仅包含有关 DNS 解析的信息。有关更多详细信息，请参阅9. 隐私 注意事项和 7.5 具有多个 IP 地址的源。

11. 如果 policy 已陈旧，则从策略缓存中删除 policy。
12. 返回 report body 和 policy。

给定一个 ECMAScript 对象（report body，通常由 生成网络错误 报告返回，然后由调用规范扩充）、与之 匹配的NEL 策略（policy）以及网络请求 （request），此算法将报告排入交付队列。

1. 令 url 为 request 的 URL。

2. 清除 url 的片段。

3. 如果 report body 的 phase 属性为 dns 或 connection：

   1. 清除 url 的路径和查询。

4. 使用以下参数生成网络报告：

   类型

   network-error

   数据

   report body

   端点组

   policy 的报告组

   url

   对 url 运行URL 序列化器所得的结果。

本节中的所有网络错误都发生在DNS 解析期间，因此其阶段 为 dns。

dns.unreachable

DNS 服务器无法访问

dns.name_not_resolved

DNS 服务器已响应，但无法解析该地址

dns.failed

由于前述错误未涵盖的原因，对 DNS 服务器的请求失败

dns.address_changed

表示自收到相应的NEL 策略以来，请求的源所解析到的 IP 地址 已发生变化

本节中的所有网络错误都发生在安全 连接建立期间，因此其 阶段为 connection。

tcp.timed_out

与服务器的 TCP 连接超时

tcp.closed

TCP 连接被服务器关闭

tcp.reset

TCP 连接被重置

tcp.refused

TCP 连接被服务器拒绝

tcp.aborted

TCP 连接被中止

tcp.address_invalid

IP 地址无效

tcp.address_unreachable

IP 地址无法访问

tcp.failed

由于前述错误未涵盖的原因，TCP 连接失败

tls.version_or_cipher_mismatch

由于版本或密码套件不匹配，TLS 连接被中止

tls.bad_client_auth_cert

由于客户端证书无效，TLS 连接被中止

tls.cert.name_invalid

由于名称无效，TLS 连接被中止

tls.cert.date_invalid

由于证书日期无效，TLS 连接被中止

tls.cert.authority_invalid

由于签发机构无效，TLS 连接被中止

tls.cert.invalid

由于证书无效，TLS 连接被中止

tls.cert.revoked

由于服务器证书已被吊销，TLS 连接被中止

tls.cert.pinned_key_not_in_cert_chain

由于密钥固定错误，TLS 连接被中止

tls.protocol.error

由于 TLS 协议错误，TLS 连接被中止

tls.failed

由于前述错误未涵盖的原因，TLS 连接失败

本节中的所有网络错误都发生在 请求和响应的传输期间， 因此其阶段为 application。

http.error

用户代理成功接收到响应，但其状态码为 4xx 或 5xx

http.protocol.error

由于 HTTP 协议错误，连接被中止

http.response.invalid

响应为空、content-length 不匹配、编码不正确和/或存在其他 阻止用户代理处理响应的情况

http.response.redirect_loop

由于检测到重定向循环，请求被中止

http.failed

由于前述错误未涵盖的 HTTP 协议错误，连接失败

abandoned

用户在资源获取完成之前将其中止

unknown

错误类型未知

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

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

此 NEL 标头定义了一个NEL 策略，指示 用户代理将有关 example.com 的网络错误报告 给名为 network-errors 的端点组。该 策略适用 2592000 秒（30 天）。

请注意，只有当响应来自可能可信的源时，上述注册才会成功。

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

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

此 NEL 标头指示用户代理移除 example.com 的任何现有NEL 策略。

本节包含一些网络错误报告示例， 当具有已注册NEL 策略的源遇到网络错误时，用户代理可能会将这些报告排入队列。这里展示了 [REPORTING] API 在 上传报告时创建的完整报告载荷；该载荷的 body 字段包含 网络错误报告正文。

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

此报告表示用户代理尝试从 example.com 导航到 www.example.com，后者 成功解析为 2001:DB8::42。但是，虽然 用户代理通过 HTTP/2（h2）协议从服务器接收到200 响应， 但在交换过程中遇到协议错误，并被迫放弃 导航。用户代理在导航开始 823 毫秒后 中止了导航。最后，用户代理在遇到网络错误后立即发送了此报告 ——即报告的 age 为 0。

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

上述报告表示用户代理尝试从 https://www.example.com/ 获取 https://widget.com/thing.js。但是，用户代理 无法解析 DNS 名称（widget.com），并且请求 在 143 毫秒后被用户代理中止。由于先前 对 widget.com 的请求交付了有效的NEL 策略，用户代理为此请求生成一个网络错误 报告。该报告在遇到网络错误后立即上传——即报告的 age 为 0。

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

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

此 NEL 标头使 example.com 的所有者能够检测其 DNS 服务器何时配置错误——例如，当他们忘记添加一条新的 资源记录，将 new-subdomain.example.com 解析为 IP 地址时。如果用户代理尝试向 new-subdomain.example.com 发出请求，它可能会生成以下 报告：

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

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

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

在此示例中，example.com 的所有者使用 ETag 响应 标头来标识托管在服务器上的不同资源版本。 用户代理随后可以使用 If-None-Match 请求标头来告知服务器客户端当前缓存的是资源的哪个版本， 从而在客户端已有副本仍为最新时，使服务器无需生成 和发送该资源的内容。

通过在此域的 NEL 标头中包含request_headers 和response_headers 字段， 浏览器将在它 为该请求创建的任何 NEL 报告中包含If-None-Match 请求标头 和 ETag 响应标头的副本， 从而使网站所有者能够跟踪其缓存策略的 有效性。

基于上述内容，请考虑以下事件序列：

1. 用户代理向 example.com 发送一个请求， 并从服务器接收到成功的响应， 其中包含一个指示资源版本的ETag 标头。 用户代理将生成以下 NEL 报告：

   示例 8

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

2. 一段时间后，用户代理再次向 example.com 发送请求。用户代理的本地缓存中仍有 原始资源的副本，并在 If-None-Match 请求 标头中包含其版本。服务器检查 该版本，发现其仍为当前版本，并发送 304 响应，告知用户代理其缓存的 资源副本仍然有效。用户代理将生成 以下报告：

   示例 9

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

3. 再过一段时间，用户代理又向 example.com 发送了一个请求。用户代理的本地缓存中仍有同一个 资源副本，并像上一个 示例一样，在If-None-Match 请求 标头中包含其版本。不过，这一次服务器发现有新的 资源版本可用。它生成此 资源的内容并将其发送给客户端，同时将新版本编码 到新的ETag 响应标头值中。用户 代理将生成以下报告：

   示例 10

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

对于其域名解析为多个 IP 地址的源，NEL 有时会“降级”错误报告，提供 较少的错误原因信息，因为它无法验证 源的所有者是否与处理请求的 服务器所有者相同。

例如，假设 example.com 由三台 服务器处理，每台服务器具有不同的 IP 地址。服务所有者 配置 DNS，将 example.com 解析为 192.0.2.1、192.0.2.2 和 192.0.2.3，并依赖用户代理在 这三个 IP 地址之间均衡其请求。服务所有者交付 以下NEL 策略：

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

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

基于上述内容，请考虑以下事件序列：

1. 用户代理向 192.0.2.1 发送一个请求， 并从服务器接收到成功的响应。 此响应包含上述NEL 策略，用户 代理将该策略的接收 IP 地址设置为 192.0.2.1。由于接收 IP 地址 与服务器的 IP 地址匹配（对于任何 成功请求都必须如此），因此它生成以下 NEL 报告：

   示例 12

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

2. 用户代理向 192.0.2.2 发送一个新的请求，并接收到另一个成功的 响应。此响应也包含该NEL 策略， 用户代理将该策略的接收 IP 地址 更新为 192.0.2.2。由于接收 IP 地址 与服务器的 IP 地址匹配（对于任何 成功请求都必须如此），因此它生成以下 NEL 报告：

   示例 13

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

3. 随后，用户代理尝试向 192.0.2.3 发送一个请求，但无法与 服务器建立连接。用户代理的策略缓存中仍有该NEL 策略，理想情况下会使用该策略 为这个失败的 网络请求生成 tcp.timed_out 报告。但是，由于策略的接收 IP 地址（192.0.2.2）与此请求所发送到的 IP 地址不匹配，因此用户代理无法 验证位于 192.0.2.3 的服务器实际上是否归 example.com 的所有者所有。因此，用户代理必须 将报告降级为 dns.address_changed：

   示例 14

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

4. 随后，用户代理又尝试向 192.0.2.1 发送一个请求，但再次无法与 服务器建立连接。尽管用户代理过去某个时候曾从 192.0.2.1 接收到 NEL 策略， 但策略的接收 IP 地址只记录它 最近一次从何处接收——在此情况下为 192.0.2.2。因此，用户代理必须将 报告降级为 dns.address_changed：

   示例 15

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

由用户发起的导航请求（例如通过点击链接、在地址 栏中直接输入、因用户交互而由脚本发起等）可能因任意数量的连接问题而失败： DNS 失败、TCP 错误、TLS 协议违规等。这些错误可能由网络 配置错误、暂时性路由问题、服务器停机、恶意软件或针对用户的其他攻击 等原因引起。

在这种情况下，目标主机通常不会知道导航失败，因为按照定义， 它无法看到请求到达其基础设施，也无法调查该问题。为 解决此问题，主机可以向用户代理注册一个NEL 策略，该策略 指定此类失败的报告应交付到何处，以便进行调查。

典型应用需要数十个资源，这些资源的获取通常通过 HTML、CSS 或 JavaScript 发起。请求这些资源的应用可以观察到大多数此类 获取的失败（例如通过 onerror 回调），但它无法访问有关失败原因的详细网络 错误报告——例如 DNS 失败、TCP 错误、TLS 协议违规等。

为解决此问题，应用可以针对获取子资源所来自的 第一方主机，向用户代理注册相关的NEL 策略。然后，如果存在此类策略，并且从具有已注册源的资源遇到网络错误，而该源具有已注册的NEL 策略，则用户 代理将报告详细的网络错误报告，使应用开发者能够调查 该错误。

当资源由第三方嵌入时，资源提供者通常无法 检测和观察失败。例如，如果 example.com 在其网站上嵌入 widget.com/thing.js 资源，而访问 example.com 的用户 因网络错误而无法获取该资源，则 widget.com 主机既不知道 该失败，也无法检测到它。

为解决此问题，widget.com 可以为其主机注册 NEL 策略。然后，如果存在此类策略， 并且在获取资源时遇到网络错误——无论该资源是从 第一方还是第三方源请求的——只要该资源来自具有已注册源的NEL 策略，用户 代理就会报告网络错误，使提供者能够调查该错误。

标头字段名称

NEL

适用协议

http

状态

标准

作者/变更控制者

W3C

规范文档

本规范（参见 NEL 响应标头）