Specify that the single module request sets the Accept header to mime types that are accepted

[andyearnshaw]

In browsers that I've tested (Google Chrome, Safari, Firefox), the following will generate a single network request, with the Accept header set to */*:

<script type="module">
    import '/foo.js';
</script>

The fetch a single module script algorithm defines how this request is made, but does not specify that the Accept header is set. There are suggestions (external to the HTML spec) to spec imports of types such as JSON or WASM using ES modules. If I'm reading the spec correctly, this would require the implementor to specify custom fetch steps, which would be applied at step 8 of the algorithm. I'm concerned that, once these features make it into browsers, there would be no way to detect them on the server, unless the browser specifies the MIME types it supports as part of the accept header in the request.

Step 9 of the fetch a single module script algorithm, which is arrived at after mapping the dependency graph says:

If any of the following conditions are met, set moduleMap[url] to null, asynchronously complete this algorithm with null, and abort these steps:

• response's type is "error"
• response's status is not an ok status
• The result of extracting a MIME type from response's header list is not a JavaScript MIME type

So, since the default fetch algorithm requires a JavaScript MIME type, I think it also makes sense to require that the browser specify JavaScript MIME types (or a modern subset of them) in the Accept header. This would mean that, if the browser implements custom fetch steps, they would be required to override this header with something that makes sense instead of deferring to the default */*. I fully accept that this would not enforce them to use a list of supported MIME types, but it would encourage it (why would a vendor override the header with */*, for instance).

To clarify the use case here, let's imagine Firefox adds support for importing JSON data, but other browsers are lagging behind. If the server can reasonably guess (maybe using the referrer) that the request comes from a module, and Firefox sends Accept: <javascript mime types>, application/json then a server could detect this and serve the raw file to Firefox whilst serving a wrapped version of the file export default <json> to all other browsers.

[annevk]

It seems that might end up being quite a bit of request bloat though, especially as we get more module types.

I'd also be somewhat worried about compatibility, given that servers are known to do branching on Accept.

[andyearnshaw]

It seems that might end up being quite a bit of request bloat though, especially as we get more module types.

This did occur to me, especially when I refreshed myself on the list of accepted JavaScript MIME types (which was the reason I suggested the modern subset, e.g. dropping javascript1.x, jscript and friends) 😕 I guess it could get pretty large if a significant number of module types were added, though I don't know how much of a concern it would be.

[travisleithead]

While this is a nice attempt to give servers something to detect against, I have a couple of concerns. First, the current behavior of the import matches what <script> elements do (e.g., they both send Accept: */*). Would it not makes sense for this feature to apply to both these scenarios? Second, agree with the potential header bloat concern raised by @annevk. Third, thinking about how module imports may be extended in the future made me think about the venerable <object> tag and how it could also load a variety of MIME-types... I think <object> used the type attribute as a hint for what to accept (but haven't checked), and that at least helps scope what might be sent in an Accept header. However, I don't think there's a related way to provide the hint about what type of content you may expect via an import statement.

[andyearnshaw]

First, the current behavior of the import matches what <script> elements do (e.g., they both send Accept: /). Would it not makes sense for this feature to apply to both these scenarios?

I don't think this is much of a concern since they diverge on the request anyway (CORS settings differ, for example). You could maybe apply to both scenarios anyway; I can't think of any issues that might arise, but I don't really have any strong feelings about it either.