You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: index.html
+21-27Lines changed: 21 additions & 27 deletions
Original file line number
Diff line number
Diff line change
@@ -96,7 +96,7 @@ <h2>Introduction</h2>
96
96
97
97
<p>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.</p>
98
98
99
-
<p>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 <a>NEL</a> HTTP response header field that describes the desired <a>NEL policy</a>. 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 API [[!REPORTING]]. As the name implies, NEL reports are primarily used to describe <em>errors</em>. However, in order to determine <em>rates</em> of errors across different client populations, we must also know how many <em>successful</em> requests are occurring; these successful requests can also be reported via the NEL mechanism.</p>
99
+
<p>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 <a>NEL</a> HTTP response header field that describes the desired <a>NEL policy</a>. 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 <em>errors</em>. However, in order to determine <em>rates</em> of errors across different client populations, we must also know how many <em>successful</em> requests are occurring; these successful requests can also be reported via the NEL mechanism.</p>
100
100
101
101
<p>For example, if the user agent fails to fetch a resource from <code>https://www.example.com</code> due to an aborted TCP connection, the user agent would queue the following report via the Reporting API:</p>
102
102
@@ -129,10 +129,7 @@ <h2>Introduction</h2>
129
129
</p>
130
130
</section>
131
131
132
-
<section>
133
-
<h2>Conformance requirements</h2>
134
-
<p>All diagrams, examples, and notes in this specification are non-normative, as are all sections explicitly marked non-normative. Everything else in this specification is normative.</p>
135
-
<p>The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in the normative parts of this document are to be interpreted as described in [[!RFC2119]].</p>
132
+
<sectionid="conformance">
136
133
<p>Requirements phrased in the imperative as part of algorithms (such as "strip any leading space characters" or "return false and abort these steps") are to be interpreted with the meaning of the key word ("must", "should", "may", etc) used in introducing the algorithm.</p>
137
134
<p>Some conformance requirements are phrased as requirements on attributes, methods or objects. Such requirements are to be interpreted as requirements on the user agent.</p>
138
135
<p>Conformance requirements phrased as algorithms or specific steps may be implemented in any manner, so long as the end result is equivalent. (In particular, the algorithms defined in this specification are intended to be easy to follow, and not intended to be performant.)</p>
@@ -141,7 +138,7 @@ <h2>Dependencies</h2>
141
138
<dl>
142
139
<dt>DNS</dt>
143
140
<dd>
144
-
<p>The following terms are defined in the DNS specification: [[!RFC1034]]</p>
141
+
<p>The following terms are defined in the DNS specification: [[RFC1034]]</p>
<li>Refuse to process Set-Cookie response headers when delivering network error reports.</li>
1992
1987
</ul>
1993
1988
1994
-
<p>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.</p>
1989
+
<p>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.</p>
1995
1990
</section>
1996
1991
1997
1992
<section>
@@ -2014,7 +2009,6 @@ <h2><code>NEL</code></h2>
2014
2009
</dl>
2015
2010
</section>
2016
2011
</section>
2017
-
2018
2012
<sectionclass="appendix">
2019
2013
<h2>Acknowledgments</h2>
2020
2014
<p>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.</p>
0 commit comments