Make http-equiv Accept-CH non-persistent

[yoavweiss]

Closes #21

[yoavweiss]

/TBR @morlovich

[eeeps]

I can't say I understand the renderer trust issues, but I, uh, trust you when you say this solves them. If it does, this seems like a simple-enough change. The main issue, for me, is author confusion, now that two different Accept-CHs have different effects.

Zooming out from this change - is the dynamic nature of pragmas a problem? IIUC, one of the reasons the CSP pragmas are considered a mistake is that when scripts start adding/modifying them, things get weird. For instance:

• what happens if the is processed after a request has already been initiated? I'm assuming it can only affect requests that happen after it's processed; are there situations where this may be racy or otherwise confusing to authors?
• the algorithm in this spec allows new hints to be opted into; it does not seem to allow existing hints to be opted-out of. I can't think of any use cases for using to opt out, but I can see an author being confused as to why extra headers, not in their , are being sent (because they were already in the Accept-CH cache for that origin, for whatever reason)

Also, I left a comment about whether or not this solves my bigger issue (3P subresource client hints needing some kind of header) on #21.

[yoavweiss]

The main issue, for me, is author confusion, now that two different Accept-CHs have different effects.

I agree that's not ideal. I'm hoping that "headers are persistent, http-equiv only impacts the current page" is a simple-enough message to get across.

• what happens if the is processed after a request has already been initiated? I'm assuming it can only affect requests that happen after it's processed; are there situations where this may be racy or otherwise confusing to authors?

If you're setting http-equiv in script, that certainly can be racy, pretty much by definition. The only way to remove that raciness is to remove http-equiv support.

• the algorithm in this spec allows new hints to be opted into; it does not seem to allow existing hints to be opted-out of. I can't think of any use cases for using to opt out, but I can see an author being confused as to why extra headers, not in their , are being sent (because they were already in the Accept-CH cache for that origin, for whatever reason)

Yeah, http-equiv won't enable opt-out. For overriding previously set hints, one would need to use headers.
If we would see this resulting in developer confusion, maybe we could add console logs in cases where we have a mix of persistent and document-only hints.

[morlovich]

LGTM