New 'Sec-Fetch-Dest' Type - "import"

[Randy-Buchholz]

Consider adding "import" to the list of valid sec-fetch-dest values. https://www.w3.org/TR/fetch-metadata/#sec-fetch-dest-header

This would indicate that the response is intended to be processed by a Module Import function.

Currently (in Chromium) an import from Window produces type "script", but from a Worker produces "worker". Adding "import" to the options would allow more consistent behavior and provide the server with meta information about the intended use of the response.

[mikewest]

Pedantically, this is a suggestion for Fetch, not for this specification. Fetch Metadata relies on the destination definition in the Fetch specification, and hopefully won't diverge from it: https://fetch.spec.whatwg.org/#concept-request-destination.

That said, it's not clear to me what decisions this would enable on the server that aren't covered by script or worker. Those destinations do seem to cover how the import is actually going to be used, and the risks of the import are tied in some real respect to that context (imports in a worker don't have DOM access, while imports in a window might). Can you help me see the value of this addition?

[Randy-Buchholz]

@mikewest, thanks for the Fetch reference. Since Fetch destination piggy-backs on sec-fetch-dest what is the thinking on this being more restrictive in terms of valid values? Wouldn't this spec be "All Fetch Destination" + ...

Regarding server decisions, here are two cases.

1. I see import as a specialized case of script that has distinct features/keywords (e.g., export and default) and a distinct target environment - module, and also gets special processing. Imports aren't just executed, but are parsed into "import/export/default objects" and "immediate execution commands" (for lack of a better descriptions). If they are served as static files the distinction doesn't really matter to the server - it's up to the client to know what they are requesting. But, if they are dynamically composed it can impact how the server handles the request.

• A simple example might be reusing a class definition. Say I have class Foo { } in file foo.mjs. I can use this in most js environments as a static file. But in a module I may want Foo as an export or form of export. Potentially, I might end up with three or four static cases/files - class Foo, export class Foo, default class Foo, or even export { Foo }; export default class Foo { } . With import I can use sec-fetch-dest as a switch in my request routing. If http://foo.mjs shows up without import I do nothing and just serve the static file. But if sec-fetch-dest is import I route to a server process . This could read and parse foo.mjs returning e.g. export class Foo { } from the common source file that contains the base class Foo{ } definition. Having import doesn't help me determine which form to produce, but does let me know that the response will be parsed/processes by an "importer" and run in a module environment. This is something I can't get from script or worker.

2. Another more common situation is "namespace imports" - where an import file only contains a list of other imports. This triggers several additional imports and server trips. I could send all of the imports in a single file on the initial request, but would need to inspect the content of every static script/worker file request to handle this situation. Seeing sec-fetch-dest: import could be a hint to "peek" into the file and determine if it should be served static or can use aggregation.

Note: My ultimate goal is to get to "smarter" imports. Having import as a valid type here would make it easier to get it as a valid type in Fetch, and then into import as a value set by the import request process. Eventually, I can see import sending the parts it wants (import { parts, it, wants } from "/source") where we can tree-shake or resolve dependencies on the server.

[annevk]

Sec-Fetch-Dest builds on destination, not the other way around.

[annevk]

I suggest closing this. We don't want these fields to diverge.