Re: New Version Notification for draft-nottingham-site-wide-headers-01.txt

[Martin Thomson <[e-mail]>]

On 24 November 2016 at 13:28, Mark Nottingham <[e-mail]> wrote:
> Biggest change in this revision is restricting site-wide headers to a
> whitelist + a prefix ("site-"). Feedback appreciated.

So the intent is to signal to the client that the header field is
valid for inclusion in the site-wide headers?  Doesn't that make it
odd when you have a header field (like CSP) that is perfectly valid on
a per-resource basis?  Isn't a blacklist easier to work with?  I
realize that doesn't give any potential HTTP overlords the ability to
control what appears, but nonsensical responses will be created with
or without blessing from upon high.

You don't describe the consequences if someone puts a Date header
field in a site-wide resource.  You only say not to.

The example of CSP is particularly enlightening: it has very strict
combining rules:
https://w3c.github.io/webappsec-csp/2/#enforcing-multiple-policies
These rules mean that a site-wide CSP can be deployed, but it would
have to be permissive enough to permit the union of all valid policies
for every resource on the origin.  That's certainly possible, but
potentially inconvenient.  Deploying CSP is already a nightmare.

Text describing how site-wide and local header fields are combined
might help point in the right direction.

You say that site-wide headers are appended, but the natural thing to
do when you hit HS is to insert.

P3P lives!