HTML <meta>-delivery

[eeeps]

Addresses #55

This is a first, naive, stab at this. I've copied some language from https://www.w3.org/TR/CSP3/#meta-element and given it a once over.

At the very least, it needs a corresponding PR to HTML, which I'll link to here, as soon as it's in.

[annevk]

Does this have interest from multiple implementers?

[eeeps]

@annevk I think the only browser folks in #55 were Googlers (who seemed positive) and yourself (who expressed concerns). So unless I've missed conversations elsewhere: no, not yet.

[Malvoz]

Is it important to mention that the <meta charset> should be set before <meta http-equiv>s? I asked the same thing in w3c/webappsec-csp#387.

[eeeps]

Good question, and thanks for the heads up. I'll plan to monitor the conversation there and copy any changes over.

[briansmith]

What about adding a new <meta http-equiv='Feature-Policy'> header to the DOM using script? This is done regularly with CSP to tighten the policy after the initial scripts have loaded.

[eeeps]

This language doesn't say anything about what happens when new elements are inserted. As I plan to re-use as much of the specific HTML processing step language from CSP as possible, I expect that the behavior will be similar.

Because FP is more about client side behavior, and less about loading/blocking resources, I don't expect that pattern to be as common here, as it is with CSP.

That said, if we do expect it to be a common pattern, it may merit a mention in this high-level-guideline-y, non-normative bit of text.

Thoughts?

[briansmith]

How multiple Feature-Policy headers should be combined is the subject of #148. I don't think this PR should change anything other than adding text to say that using <meta> for Feature Policy is allowed, and each such <meta> is interpreted as though a separate Feature-Policy header field were appended to the HTTP response header. Then the text that resolves #148 can explain how multiple 'Feature-Policy' header fields are combined together.

[annevk]

I don't think that's possible as they are parsed independently. If you start a quoted string in one and end inside a <meta> that should not work.

[clelland]

Good point :)

A <meta> element would have to be parsed and merged separately from the response headers.

That's also necessary because it would be encountered after create a new browsing context has already initialized the document's policy (unless we specify that it interacts with the preload scanner somehow, but I think there is legitimate hesitancy to adding more dependencies on that).

[briansmith]

and each such <meta> is interpreted as though a separate Feature-Policy header field were appended to the HTTP response header.

I don't think that's possible as they are parsed independently.

I think you're probably interpreting me too literally. I just meant that each <meta http-equiv=Feature-Policy> should be interpreted the same as if it were a HTTP header.

More generally, it seems bad that CSP and Feature-Policy as specifying so many details for <meta http-equiv>; it seems like HTML5 itself should provide more infrastructure for these specs to reuse.

[annevk]

Well, for starters there's disagreement on whether we should add more <meta http-equiv>. I don't think it's a good idea as it makes all these policies dynamic and there's usually subtly different processing models across browsers leading to issues.

Then, the value-space is different, headers contain bytes, attribute values contain strings. Then, headers can be parsed as a single-block (and ideally combined, then parsed), elements are typically parsed case-by-case.

There are some reusable bits there, but all of it requires quite a bit of care.

And then, for consistency across <meta http-equiv>, it's unclear to what extent that exists today, but if someone were to invest time in that maybe some abstraction is feasible as you suggest.

[eeeps]

@annevk I think that this and whatwg/html#4670 are now at a place where it makes sense to critique specifics. Does the flow here make sense? Are there weirdnesses resulting from the fact that these pragma directives are parsed and set later/differently, that I haven't considered?

In general, being able to set Feature Policies from HTML will allow the large group of authors who do not have the ability to modify HTTP headers to use the spec. Doing so in a pragma directive seems to enable re-using as much syntax and parsing as possible, even if there are subtle differences and potential problems.