Allow URL as ModuleSpecifier?

[xtuc]

The ModuleSpecifier in the ECMAScript specification is a string and some environment allows to load a module from an arbitrary URL.

I don't see a reason to explicitly disallow it but it should be under the CSP and the same JavaScript Module loading checks should be applied. That's probably a case where HTTPs should be required?

While I don't really see a use case in bundlers, in browser it would make sense to me. It could also act as a RPC framework.

Here's an example:

(import "https://doh.com/module.js" "specifier" (func))

It would probably make sense to add a few restriction, disallowing this for example:

(import "https://remote-memory.com/module.js" "specifier" (memory 1))
(import "https://remote-table.com/module.js" "specifier" (table 1 anyfunc))

We will need appropriate error handling, if the imported module isn't reachable you will end up with a NULL pointer in the wasm module?

[domenic]

I don't think considerations here are really in scope for the wasm spec. Instead, each host gets to decide what specifiers mean. For web browsers, that's specified in the HTML Standard; Node will similarly make its own decisions. Those decisions apply across the entire module system, and are not in the scope of individual language specs.

[xtuc]

Ok, that's right.

I think that we should still make a distinction here between importing:

• a function (its execution is safe and don't allow the access to the module)
• a Memory/Table (allows access to the module)
  • as you said the host could control the loading of the remote resource but not its usage in wasm.

[domenic]

I don't think such a distinction should be made, or at least, should not be in browsers or Node.js. In both environments you can only import modules whose source text you can already read the entire contents of, so any access restrictions wasm would put in place are faulty.

[linclark]

Agreed with Domenic, this would be out of scope for this WG.