Skip to content
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

Speculative parser and dynamic import maps #234

Closed
annevk opened this issue Oct 30, 2020 · 5 comments · Fixed by #241
Closed

Speculative parser and dynamic import maps #234

annevk opened this issue Oct 30, 2020 · 5 comments · Fixed by #241

Comments

@annevk
Copy link

annevk commented Oct 30, 2020

For https://github.com/WICG/import-maps#dynamic-import-map-example it seems that a good speculative parser might also fetch my-library (parsed with the relevant base URL). This risk seems worth highlighting.

This also relates to #218.

@domenic
Copy link
Collaborator

domenic commented Oct 30, 2020

Hmm, that'd be pretty surprising. Bare specifiers like 'my-library' have never (and will never) be treated as relative URLs. Before import maps, they were errors; after import maps, they require a lookup in the import map.

What would alleviate the concern here? A section spelling out how speculative parsers currently could work, and explaining how import maps change them?

@annevk
Copy link
Author

annevk commented Oct 30, 2020

The concern is with dynamic import maps and specifiers that are treated as relative URLs. You're right that my-library is a bad example. (It seems like static import maps could be supported by the speculative parser just fine.)

@LarsDenBakker
Copy link

Wouldn't this speculative parser already break today with patterns like this:

<!DOCTYPE html>
<html>
<head></head>
<body>
  
  <script>
    const base = document.createElement('base');
    base.href = '/base/';
    document.head.appendChild(base);
  </script>
  
  <script type="module">
    import './foo.js';
  </script>

</body>
</html>

@domenic
Copy link
Collaborator

domenic commented Oct 30, 2020

@LarsDenBakker that's a good point, and I think you are right. I'd be curious if @annevk sees something we might be missing though.

Regardless, it speaks toward how it'd be a good idea to document the pitfalls of doing speculative parsing of JS module specifiers. Maybe formally as part of whatwg/html#5959, and informally in a section in this repo's explainer?

@annevk
Copy link
Author

annevk commented Nov 2, 2020

Inserting a base element dynamically would indeed be another way of getting incorrect fetches. I suspect that's already the case in user agents today if you used <script src> for the second script element.

I'm not sure why that would be a pitfall for JS module specifiers though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants