Report-To header no longer defined

[nicjansma]

Hi!

With the current editor's draft for NEL, the NEL: header is defined but the "old" Reporting API Report-To: header is referenced (in examples), but not defined anywhere.

If you follow a few links e.g. for some underlined report-to text in NEL examples, it goes to https://w3c.github.io/reporting/network-reporting.html#endpoint-group, but that doesn't define the Report-To: header either.

Since this spec is in a small bit of flux with the Reporting API changing to the new Reporting-Endpoints: header, maybe we can add a notice about the state of this document vs. Reporting API, and in the description and examples link to something else?

The WebAppSec CSP document is linked from the Network-Reporting spec, but it merely defines the header and doesn't give any examples of the options

https://w3c.github.io/webappsec-csp/#directives-reporting

I guess in summary, I don't think reviewers of this spec can find any of the Report-To: options defined anywhere anymore.

[clelland]

I think that's right -- when Network Reporting split from Reporting, I intended to provide a better configuration mechanism for it, that could avoid the issues with the Report-To header (It's a response header that is treated as authoritative for an entire origin, or even an entire site). Originally that was going to be Origin Policy, but that never launched, and so we don't have a well-specified way to configure endpoint groups.

I don't really like the idea of reintroducing the header into Network Reporting, but it may be the best option for now (and happens to match Chromium's implementation)

[valenting]

It would be quite nice if NEL adopted the Reporting API's use of structured fields for Reporting-Endpoints.
We haven't implemented NEL in Firefox yet, so it would be preferable to just use the structured-field-values for this instead of the non-standard json-field-value.

[clelland]

I agree, and I'd prefer to see something like that as well. As I recall, though (and this is going back a while, so my recollection may be incomplete) the reason we didn't do that was that we introduced Reporting-Endpoints specifically to define endpoints that would not outlive the resource they were delivered with. To avoid creating a persistent fingerprint, those endpoints are always ephemeral, and so can't support some of NEL's most important use cases.

We also couldn't redefine the Report-To header to accept a structured header, as it introduced several parsing incompatibilities if we needed to support both old and new formats.

I think that an interesting way forward here would be something like #173, to use a different channel completely, rather than headers, to configure NEL.