Specify serviceworker link type for link element and link header.

[mkruisselbrink]

This is my attempt to specify the serviceworker link element and header type to address issue #685.

[mkruisselbrink]

Currently I wrote this to only trigger a register when a element is inserted into a document, but maybe it makes more sense to be more consisted with other link elements, and also trigger whenever one of the attributes changes?

And thinking about this more, I need to somehow modify the Register algorithm to make it work without a client, while still keeping the origin checks that are currently done based on the client.

[annevk]

@mkruisselbrink you should probably figure out what bits the algorithm needs from client and require those to be passed in, instead.

[mkruisselbrink]

@mkruisselbrink you should probably figure out what bits the algorithm needs from client and require those to be passed in, instead.

Yeah, it seems the client is used for two (well, currently three) things:

1. the origin is needed to make sure the script/scope are on the origin as the client that called register
2. the full client is used to set the client property of the fetch request that retrieves the worker script
3. Issue Resolve Job Promise can resolve jobs with an incorrect value #829, the client is for some reason associated with the returned ServiceWorkerRegistration

This third one I'll ignore for now, since it's broken anyway. For the second one it is probably correct to have a null client, just like in some update checks. So that leaves the first one; either I can add the "client" origin as a separate field for a job (which would only be used by register jobs), or maybe it makes sense to move those checks to before the job is scheduled. It's not entirely clear to me why some origin checks are done before a register job is created, and some are done when the register job is executed. It seems like it should be fine to do all parameter validation before potentially scheduling a register job.

[mkruisselbrink]

Okay, I changed it to move the origin checks to be done before a job is created. Also made the link element processing more in line with how other specs process link elements.

One thing I was wondering is if processing of a Link: header should somehow make sure that the response on which the header is set is the response to a request that originated in a secure context. I think having such a check would make sense, but specifying it is slightly tricky since the whole Link: header processing isn't very precisely defined currently. Ideally there would just be a step somewhere in the fetch spec where Link: headers are processed, at which point the algorithm would have access to the client associated with the request. Maybe currently it's enough to be hand-wavy about where such a client might come from.

[annevk]

We could definitely add a hook in Fetch to make it more explicit that's what's happening.

[wanderview]

Gecko bug to implement: https://bugzilla.mozilla.org/show_bug.cgi?id=1247141

[domenic]

Can you add [CEReactions] to this, per WICG/webcomponents#186 ?