Document the headers being introduced

[sleevi]

Currently, the ABNF of both the 'Service-Worker' and 'Service-Worker-Allowed' headers are undocumented, as are the contents.

Concretely:

• Review RFC 7231, Section 8.3 for considerations when registering new header fields
• Review BCP 90 for the technical requirements (cc @mnot )
• Add language for both Service-Worker and Service-Worker-Allowed
  • From the spec, it would appear that Service-Worker is a request header, whose syntax is token, and in practice whose value is script (but I don't think the ABNF should be so restrictive; leave that for prose)
  • From Chrome's implementation (but unspecified in the spec), it would appear that Service-Worker-Allowed is a response header, whose syntax is either URI-reference or, due to the fact that it should only contain a path relative to the same origin (scheme/authority) or is path - although it's unclear whether this is supposed to be path-abempty (is "Service-Worker-Allowed: " a valid header? Chrome appears to allowed this, counter-intuitively), path-absolute (does "Service-Worker-Allowed: " always require a leading /? Chrome's implementation appears to resolve it as a relative URL, and thus doesn't require this), path-noscheme (doesn't seem to fit at all), or path-rootless (prohibits absolute). My gut from the spec is that it's probably meant to be path-absolute, although I'm not sure if @annevk has better language.
• Update maxScope to be the result of resolving the URL relative to the document's registering script url, since it incorrectly refers to being the result of parsing serviceWorkerAllowed, which is incorrect, since serviceWorkerAllowed is already parsed (presumably, as a URL)

[annevk]

I think Service-Worker-Allowed should match Location in terms of URL parsing and both should allow basically any relative URL. And I think as far as the contents, the browser will allow "any" for either and not require a specific production.

[jakearchibald]

Agree with @annevk, relative urls are fine here, and are supported by the current spec. As for an empty value, I agree that's an indication of error but the result is the same as omitting the header, so allowing it seems fine.

Excuse my lack of knowledge here, but does the service worker spec count as an open standard as per https://tools.ietf.org/html/rfc2026#section-7, or will we have to define these headers in a seperate doc?

Is the goal to get these headers listed at http://www.iana.org/assignments/message-headers/message-headers.xhtml? I don't see content-security-policy there, is that just an oversight?

Update maxScope to be the result of resolving the URL relative to the document's registering script url, since it incorrectly refers to being the result of parsing serviceWorkerAllowed, which is incorrect, since serviceWorkerAllowed is already parsed (presumably, as a URL)

serviceWorkerAllowed is the result of parsing the header, maxScope is the result of parsing serviceWorkerAllowed as a url.

[sleevi]

@jakearchibald The spec should clarify that, then - because it's a non-guaranteed behaviour as implemented in Chrome.

open standard - The SW spec is part of the W3C WebApps WG, right? If so, yes, it's already covered, so no need for a separate doc. You can see some of the Provisional registrations (e.g. the many CORS headers). The absence of Content-Security-Policy I don't recall whether that was because of some of the IETF vs W3C stuff or just an oversight.

re: maxScope - here's what the language currently reads:

Let maxScope be the result of parsing serviceWorkerAllowed with registration's registering script url.

Here's what it probably should be:

Let maxScope be the result of resolving serviceWorkerAllowed relative to the registration's registering script url.

[jungkees]

re: maxScope

Running https://url.spec.whatwg.org/#concept-url-parser passing a URL and an optional base URL returns a parsed URL which is used in the rest of the steps. I don't think it has any problem here.

[annevk]

What does Location with an empty value do? Might just be the same as <a href></a>, no? Not sure why we should disallow that, unless it's already a parse error for Location, which I somewhat doubt.

[jungkees]

F2F: Will add ABNF definition (referring to 4.2.4 HTTP new-header syntax).

[mnot]

Dont't worry about the 'open standard' thing.