What is the right destination type for non-JS modules?

[littledan]

In the now-reverted JSON module PR in HTML, the request destination was (accidentally) "script". As discussed in the PR, this is probably a bug: If the server responds with nosniff headers, then the response will be rejected, since the JSON MIME types are not JS MIME types.

In that JSON module PR, the general model was that the server would respond with a MIME type that indicates the module type; the client doesn't know what type the module will be until it gets the response, so of course it would use the "script" destination. However, with the discussion in WICG/webcomponents#839, and the TC39 module attributes proposal, it's possible that the client would indicate something about what kind of module it's expecting back. This could feed into the destination.

In general, what destinations should we use for non-JS module types, such as WebAssembly modules, HTML modules, CSS modules, and JSON modules?

I see two general paths:

• Keep using the script-like destinations, and add a special internal flag to prevent the nosniff issue
• Make the requested module type part of the destination, or part of some other request parameter

Some considerations:

• The destination is visible to the Web in <link rel=modulepreload> (which currently requires a script-like destination) as well as in the destination attribute in Requests in ServiceWorker.
• We may want a Worker or Worklet to run WebAssembly directly, as their entrypoint. So if WebAssembly had its own destination, we might want to also make wasm-worker, wasm-serviceworker, wasm-paintworklet, etc destinations. (I imagine the non-executable module types wouldn't need to indicate the environment.)
• Some weird things might happen if we started fetching certain things with the "script" destination, e.g., styles might be missing the Accept headers unless some other logic was added to fix that up.

Thoughts?

(thanks to @annevk and @slightlyoff in explaining a bunch of these concepts to me.)

[annevk]

I think bypassing nosniff if you're enforcing MIME types yourself is fine. (Also, this all requires CORS, which helps a lot.)

I think the tricky bit with changing destination is that it's a single value and you might accept multiple types. If you accept JSON or JS, what's the destination? Does the server need to know both are acceptable? (tc39/proposal-import-attributes#7)

Furthermore, if you accept Wasm, does that mean you're also accepting JS or for that Wasm to import JS? (tc39/proposal-import-attributes#19)

[domenic]

I suspect the right answer here is not to change destination, precisely because it is developer-facing in <link rel=modulepreload> (and also service worker interception).

Part of the reason we did <link rel=modulepreload> instead of reusing rel=preload was so that we wouldn't need to double the number of as= values: i.e., the current design allows rel=modulepreload as=script|worker|sharedworker|serviceworker instead of rel=preload as=modulescript|moduleworker|modulesharedworker|moduleserviceworker. Adding the script's category as a a new combinatorial axis to the destination seems suboptimal, although not as bad since we probably won't have JSON workers/sharedworkers/serviceworkers. (Maybe we would have wasm ones though?)

In other words, we have multiple factors that go into script loading:

• Type: classic vs. module
• Destination: script vs. worker vs. shared worker vs. service worker
• Category (?): JS vs. JSON vs. wasm vs. HTML

We decided not to merge type into destination, and I suggest we do the same for category. Destination is a good independent axis, as-is.

[littledan]

OK, how should we phrase the logic to turn off nosniff? Should we add "category" to the request, or add a simpler bit to request as @annevk suggested just to turn off this particular thing?

For CSS modules, do we have to worry about sending the right Accept headers (whose logic is based on destination) or is it OK to omit those?

[annevk]

I think we should offer the server the Category information, in particular as there might be multiple acceptable Categories for a given URL. Accept might be a useful vehicle to do so (alternative is Sec-Fetch-Category or some such). If that means that all non-classic script loads always include a Category we could use that to bypass nosniff and there would be no need for a separate flag there.

There's an alternative where Category is a single value and signifies the privilege of the response, but that's not useful for signalling that a worker cannot import a CSS module (which would have the same privilege as JSON, presumably).

[littledan]

OK, making an additional "category" parameter to request SGTM as a starting point for a future proposal here. I don't have any strong reason to suspect from here that we'll need to change the destination, so I'm closing this issue. Thanks for talking this through.