Make preload headers work for fetches created by workers

[annevk]

Given the header it seems this should also work for workers. Would require a bit more abstracting in the prose.

[Krinkle]

@annevk Do you mean the fetch for a worker's script, or fetches created from within a worker?

I'm not very familiar with how workers are defined, but from the title ("Documents only?") it sounds like it might imply that preload is limited to navigation requests. If that's what you meant, then per #92 I believe it's been established already to also apply to other fetches from a browsing context. That might mean workers are still not covered, though. Not sure :)

[annevk]

Preloading "fetches created from within a worker".

[noamr]

While it sounds like it should work, I wonder how useful it would be in practice.
Unlike loading HTML, the loading process of a worker is simple, so loading things at the beginning of the worker is trivial.
Are any implementors interested in this?

[annevk]

It seems that for module workers that might not necessarily be the case, but I'm not sure if preload is the best way to identify "nested" modules.

cc @domenic

[domenic]

For module workers I'd expect using modulepreload.

[noamr]

One thing to consider here is that link headers work for subresources - e.g. a script can specify another script to preload in the context of the document by sending a link header. If worker scripts have a preload link - perhaps they should also be treated as subresources of the document and the document itself should handle those headers?

[annevk]

I'm not sure what you mean. A worker is roughly equivalent to a document as far as all kinds of things are concerned.

(To be clear, I'm okay with not adding this feature as there might not be much need or demand for it.)

[noamr]

I'm not sure what you mean. A worker is roughly equivalent to a document as far as all kinds of things are concerned.

I meant that perhaps when a worker has a link header, it should be loaded in the context of the owner document as if the worker was a subresource

(To be clear, I'm okay with not adding this feature as there might not be much need or demand for it.)

[annevk]

I see. No that would not be appropriate. Note that workers might also be owned by other workers and some do not have an owner document at all (or do not have a stable owner document).

@domenic for a worker to use modulepreload it would have to be the worker that uses it, right? Otherwise the lookup ends up failing. I guess that's not currently defined as a thing as Link headers are not defined.

[noamr]

I see. No that would not be appropriate. Note that workers might also be owned by other workers and some do not have an owner document at all (or do not have a stable owner document).

@domenic for a worker to use modulepreload it would have to be the worker that uses it, right? Otherwise the lookup ends up failing. I guess that's not currently defined as a thing as Link headers are not defined.

I'm currently working on link headers here, but it doesn't yet specify link headers on subresources, only as part of navigation. I'd have to make the right check there to show that workers are not treated as "subresources" in that scenario.

[annevk]

Fetch calls out workers as non-subresources (though they are not navigations either). Maybe we should have "environment request" as a concept, though thus far we haven't needed it concretely I think.

[noamr]

Fetch calls out workers as non-subresources (though they are not navigations either). Maybe we should have "environment request" as a concept, though thus far we haven't needed it concretely I think.

Great, that definition would do for now.

[yoavweiss]

Discussion continues at whatwg/html#7889