-
Notifications
You must be signed in to change notification settings - Fork 32
-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Default assertion based on extension #101
Comments
Extensions have no meaning whatsoever in browsers, though. |
@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). |
@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. |
@ljharb I doesn't seem you've read README.md of the proposal...
Look at this issue, and with more context, maybe you'll reconsider your opinion... |
@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. |
In WICG/webcomponents#839 , this idea was extensively discussed and rejected by browsers for the reasons @ljharb explained. |
I suppose
proposal-import-assertions
should cover it by having such thing as "default type assertion", so even when I use no assertion:The type is determined from the extension, - i.e.
application/json
here, even if the MIME-type will beapplication/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?
The text was updated successfully, but these errors were encountered: