Module workers are fetched with incorrect referrer. #1111

mkruisselbrink · 2016-04-22T23:53:24Z

The way the spec is currently written, a "classic" worker is fetched using whatever document/worker created the worker as referrer for the request of the worker script. I would expect the same referrer to be used for the request of the "main" module of a module type worker, but the way the run a worker algorithm is currently written a module type worker completely ignores the referrer parameter that is passed to the algorithm.

Fixes #1111, although the problem was more widespread than indicated there. Previously, *only* classic workers had their referrer set correctly. This updates the algorithms to: - Pass the document's address as the referrer for <script>-initiated fetches (both classic and module) - Pass the document's address as the referrer for worker-creation fetches (both classic and module) - Pass the importing module's address as the referrer for import-initiated module script fetches

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 feth 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.) This fixes #1111 since now module workers are fetched with the correct client, and thus automatically get the correct referrer.

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 feth 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.

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 self-assigned this Apr 23, 2016

domenic mentioned this issue Apr 25, 2016

Pass along correct referrers when fetching scripts #1122

Closed

domenic mentioned this issue Apr 29, 2016

Use outside settings object to fetch workers #1149

Merged

annevk closed this as completed in #1149 May 11, 2016

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Module workers are fetched with incorrect referrer. #1111

Module workers are fetched with incorrect referrer. #1111

mkruisselbrink commented Apr 22, 2016

Module workers are fetched with incorrect referrer. #1111

Module workers are fetched with incorrect referrer. #1111

Comments

mkruisselbrink commented Apr 22, 2016