Reconsider nor and nrr fields.

[alficles]

These two fields exist to indicate to the CDN that it might wish to consider fetching the next content in order to reduce latency. One potential option: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Link

The Link header is a standard and there is already some browser and CDN support around it. It might be worth just leveraging the existing header.

[wilaw]

Arguments against use of LINK header

1. It allows absolute URLS, which is a broader DDOS attack vector than the relative URLs of norr.
2. It does not support Ranges. Range requests are used for much VOD streaming.
3. It is semantically equivalent to the HTML element. This is because it is almost universally used to signal from a server to a browser user-agent, with instructions for identifying and loading HTML assets. I do no know of any other client to server usage of LINK, which would be the CMCD application. It's design has been primarily focused on HTML and it carries a lot of signalling overhead which has no utility for CMCD .
4. Roger Pantos at Apple tried using (and extending) LINK for use with server-push hints for LL-HLS. Big push-back arguing against this off-label usage of their header. See issue thread for details: Specifying Range in Link preload header for HTTP/2 Push w3c/preload#139

[alficles]

Most of these are relevant to rel=preload. It might be appropriate to define a new relation in this specification and register it with IANA. The discussion seems to have largely concluded that the difficulty was the result having the same relation mean "the browser should request this" and "an intermediate cache should push this". The latter has a totally different security profile.

A quick scan shows that there are now a whole collection of preload, prefetch, prerender, preconnect and so on for indicating that a UA should prepare to do a particular thing. None of them handle ranges. :D

But the nor and nrr fields definitely feel "different" than the rest of the fields. They're more general and they have a larger security footprint. This wouldn't leverage any existing CDN behaviour, but it might get better adoption.

[wilaw]

Suggestion to explicitly ask for feedback on this issue as part of final community review. Cover letter with review asking for feedback on some high priority issues. This will be on of them.

[wilaw]

A new relation under a link would be required. rel=prefetch (URL to cache, range). Absolute URL would be an amplification attack vector. CDN would need to implement constraints even with relative URLs.
Having in LINK could help drive adoption if it is generally useful.
Link relations described here: https://www.iana.org/assignments/link-relations/link-relations.xhtml
Link header would require preflighting for CORS clients.

Opened #66.
Existing implementation works for QA transmission. Can deprecate norr and nrr in future once LINK header relation and CORS changes are enabled.