Is a general Script: header a good idea?

[domenic]

Hi HTML community,

Over in WICG/nav-speculation, we're looking to extend <script type=speculationrules> with a header-based version, based on feedback from framework developers that it's easier to inject speculation rules at the HTTP level than the HTML level. (Somewhat surprising, I know!)

I think we have two main options:

1. A speculation-rules specific header. Example:

   Speculation-Rules: "/speculation-rules.json"

2. A header which allows you to do any "data-like" <script> type, such as speculationrules, importmap, or webbundle. This use of <script> is increasingly common, as due to how HTML parsing works it's one of the few ways to shove in arbitrary data. And it's believable many of these cases would benefit from a HTTP header delivery system, in the same way we've heard speculationrules would.

   Example:

   Script: "/speculation-rules.json";type="speculationrules", "/import-map.json";type="importmap"

(We could even extend (2) to allow type="text/javascript", causing script execution, if we were feeling ambitious. But that opens up a big bag of worms, so let's set that aside for now.)

For right now, I just want to get a sense of the community's feelings on (1) vs. (2). (1) is probably the path of least resistance, but it would be kind of lame if we went that route, and then a year later introduced an Import-Map: header, and a Web-Bundle: header, and so on. Or if there's been latent demand for JavaScript execution via HTTP headers for some time, which would point toward the more-expanded version of (2).

So if people think that (2) is potentially interesting, please let me know as soon as possible!

Appendix: why not `Link:`?

Although none of the data-like <script>s mentioned currently support external versions, we hope for them to do so using <script src=""> in the future. E.g.

<script type="importmap" src="/import-map.json"></script>

Given this, it would be really weird if the header was spelled Link: </import-map.json>; rel="importmap", but the HTML version was spelled like the above. So I think reusing Link would lead to a bad place.

[annevk]

Nit: I would be inclined to only support "module" if we went down the path of allowing script execution, but allowing script execution would bring a number of challenges along with it, such as determining the earliest point it could execute. (And if we really wanted to allow the other one it should be "classic".)

[tbondwilkinson]

2 does literally feel like embedding a <script> tag in HTTP, but what's weird to me is that <script> is only being used because of limitations in the HTML parser, right?

(The use of <script> is basically because only a few elements allow the HTML parser to enter RCDATA mode, and <script> has already been used in this way. This doesn't necessarily mean that these rules should respect the script-src CSP directive.)

So then carrying that HTML limitation into header naming just feels kinda of weird. What would you have used if HTML didn't have parsing limitations? Data? Browser-directive? I feel like we should pick a name that is more descriptive of the behavior, rather than the HTML-specific implementation detail.

(I don't think you should open the can of words of script embedding in HTTP headers. Passing data seems unremarkable, running arbitrary JS seems like an unreasoned security risk).

[domenic]

We discussed this in the triage meeting (#8250). There were not very strong feelings, but generally the room was against creating something as generic as this proposed Script header, instead favoring separate headers like Speculation-Rules: and Import-Map:.

There was also some discussion about how the Link: header has proven problematically over-generic in the past; some people thought there might be TAG guidance against such over-generic designs. (But, we weren't able to find any such TAG guidance when looking after the meeting.)

Finally, in the most recent meeting @annevk pointed out that some WebKit folks were concerned about this general class of headers making pages less serializable, because the common serialization formats of today (namely: a .html file plus a folder of subresources; or, a .mhtml file) do not have room for expressing headers. This is an existing problem though, including stuff like Content-Type for charset declarations, CORP+COEP for capabilities, and the Firefox-only Link: with rel="stylesheet". I pointed out that newer serialiation formats such as web bundles solve this.