I'm not persuaded we should address "cannot modify HTTP headers" scenarios in this manner. As I outlined in w3c/webappsec-permissions-policy#55 this results in mutable policies, race conditions, and other problems.

Instead, we should figure out how to address the more fundamental problem of HTTP headers being hard to configure. (One way this can be done is by not providing solutions such as these, eventually resulting in CDNs that do offer flexibility here getting more customers.)

This is aside from client hints, which as noted at https://mozilla.github.io/standards-positions/#http-client-hints we're not exactly favorable on and as noted at WICG/client-hints-infrastructure#100 has unresolved same-origin policy issues.

@annevk HTTP headers are hard HTML authors to configure and maintain. Why?

1. There are many possible stacks
2. Each stack probably has multiple places where HTTP headers could be set
3. All of those places are often out-of-view or even out-of-bounds for the people who write HTML
4. There are no easy answers; how headers are best configured depends on many variables. Many of those variables are technical, but just as many are organizational.

A concrete example: let's say I'm working with a Cloudinary customer to set the Permissions-Policy header needed for us to receive responsive image client hints. The customer is authoring a custom theme for WordPress, on Apache, fronted by Cloudflare. There are at least four places where they could set HTTP headers: with a WP plugin, using .htaccess, via PHP, or using Cloudflare config.

Depending on the person I'm working with's role and expertise, they may have the ability to set headers using some or none of these. Other people in the organization might need to be brought in. But if they're writing an <img> component, they almost certainly have editing permissions over and visibility into the HTML.

The problem isn't CDN providers with inadequate feature sets. Most offer ways for people to set headers. The problem is that those people often aren't the same people who are writing markup.

So, we get results like these, where markup authors overwhelmingly use markup to solve a problem, rather than HTTP: https://almanac.httparchive.org/en/2021/resource-hints#fig-1

I get that there are many potential layering problems that fall out of using HTML to alter HTTP. We should continue to seek solutions like the original vision of Origin-Policy which provide a standard, more-accessible way front-end authors to do arbitrary HTTP things.

In the meantime, (and here's where I think we disagree) we shouldn't hold use cases that don't suffer from layering problems back. If authors overwhelmingly want to use HTML to accomplish an important task, and (if and only if) there are no end-user-facing problems that arise from that, why not pave the cowpath until a more general solution arises?