Default assertion based on extension

[jerrygreen]

I suppose proposal-import-assertions should cover it by having such thing as "default type assertion", so even when I use no assertion:

import json from "./foo.json";

The type is determined from the extension, - i.e. application/json here, even if the MIME-type will be application/javascript.

I.e. MIME-type shouldn't be ever taken into consideration at all, except just for an error, that there's a mismatch.

I haven't found any info about the behavior without assertion, so... What do you think?

[ljharb]

Extensions have no meaning whatsoever in browsers, though.

[jerrygreen]

@ljharb well, extensions are already a thing, and since we can't securely use just MIME-type that comes from a server, so why not use extension as a "default assertion"? Of course, there's still a possibility for a case where extension can't provided, and default assertion can't be determined, like these two examples:

import json from "./foo";
import json from "https://jsonplaceholder.typicode.com/posts/1";

In this case I think the error should be thrown: "AssertionError: assertion or extension isn't provided", and since users may not control what's provided by the server (the whole reason of a security concern), like in the second example, and they can't just add an extension there because it's another path with potentially different results (exactly like in the example: https://jsonplaceholder.typicode.com/posts/1.json returns a different json), in this case you'll have to use assertion as proposed initially.

But in many cases extensions exist in the path, particularly for json files, so a default assertion can be often determined.

This will also partly solve the problem for people complaining the syntax is overcomplicated (#12, me included), in case the proposal is already too committed to this key/value object-like syntax (though I personally hope that usage of key/value syntax can still be reconsidered, but that's another story related to #12).

[ljharb]

@jerrygreen i agree they're a thing - but in the browser they are precisely zero a thing. The MIME type is the only thing the browser has available, and it's sufficiently secure (not sure what you mean there).

The extension in the URL certainly might be a hint to the server for what the MIME type should be, but on the web, the MIME type is the sole authority for how a response should be interpreted. The request URL (which contains the "extension" that doesn't actually exist on the web) doesn't matter.

[jerrygreen]

@ljharb I doesn't seem you've read README.md of the proposal...

However, in an issue, Ryosuke Niwa (Apple) and Anne van Kesteren (Mozilla) proposed that security would be improved if some syntactic marker were required when importing JSON modules and similar module types which cannot execute code, to prevent a scenario where the responding server unexpectedly provides a different MIME type, causing code to be unexpectedly executed. The solution was to somehow indicate that a module was JSON, or in general, not to be executed, somewhere in addition to the MIME type.

Look at this issue, and with more context, maybe you'll reconsider your opinion...

[ljharb]

@jerrygreen import assertions are that syntactic marker. The contents of the specifier are currently not parsed by any browser, and one of the benefits of this proposal is that there's no need for browsers to start doing so. The specifier, in a browser, is an opaque URL, and should remain so.

[littledan]

In WICG/webcomponents#839 , this idea was extensively discussed and rejected by browsers for the reasons @ljharb explained.