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.

Sign up for GitHub

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

Jump to bottom

What should be the referrer when fetching imported module scripts? #1150

Closed
domenic opened this issue Apr 29, 2016 · 3 comments
Closed

What should be the referrer when fetching imported module scripts? #1150

domenic opened this issue Apr 29, 2016 · 3 comments
Assignees
@domenic

Comments

@domenic
Copy link
Member

domenic commented Apr 29, 2016 •
edited
Loading

Given

<!-- x.html -->
<script type="module" src="a.js">
// a.js
import "./b.js";

should the referrer that the server sees when fetching b.js be x.html, or a.js?

The spec currently says x.html because that was easier to spec.

The only relevant precedent I can see is importScripts, which always uses the top-level worker URL, even in the case of importScripts-ing a script that also importScripts another script.

I don't have any strong opinion. @ajklein @jonco3 @Constellation @DigiTec?
@ajklein
Copy link
Contributor

ajklein commented Apr 29, 2016

I don't think I care very much, but a.js makes more intuitive sense to me. And it matches the way other parts of the spec work: HostResolveImportedModule sees a.js as the referencing module for b.js, and URL resolution is (of course) relative to a.js.

@annevk
Copy link
Member

annevk commented May 1, 2016

I think it should be a.js as that matches CSS. That also leaks less information about where the user currently is to various CDNs that might host b.js.

@domenic
Copy link
Member Author

domenic commented May 2, 2016

OK, makes sense. I would like to get #1149 merged before working on this if possible.

@domenic domenic self-assigned this May 2, 2016
@domenic domenic mentioned this issue May 10, 2016
Merged
annevk pushed a commit that referenced this issue May 11, 2016
@domenic @annevk
Use outside settings object to fetch workers
4e2b006 
As discussed in #1122, #1111, and in
w3c/ServiceWorker#889 (comment),
a number of problems are caused by the current setup of using the
settings object of the worker itself as the fetch client. Instead, we use
the incumbent settings object to do the fetching. (Incumbent, instead
of e.g. current, because almost everything else in the (Shared)Worker
constructors uses the incumbent settings object.)

Notably, for fetching module script trees, this necessitates separating
the fetch client settings object from the one used for the module map.

This fixes #1111 since now module workers are fetched with the correct
client, and thus automatically get the correct referrer. Dependencies,
however, require further work which will happen as part of #1150.
domenic added a commit that referenced this issue May 17, 2016
@domenic
Make import statements set the importing script as the referrer
3d0f0f2 
Fixes #1150. Previously, they would set the top-level document (that
requested the root of the module script tree) as the referrer. This
makes more sense, being for example consistent with CSS @import.
@domenic domenic mentioned this issue May 17, 2016
Merged
annevk pushed a commit that referenced this issue May 19, 2016
@domenic @annevk
Make import statements set the importing script as the referrer
a6c1171 
Fixes #1150. Previously, they would set the top-level document (that requested the root of the module script tree) as the referrer. This makes more sense, being for example consistent with CSS @import.
@domenic domenic mentioned this issue Nov 12, 2017
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@domenic domenic

Labels
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@domenic @annevk @ajklein