- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Thu, 24 Nov 2016 15:14:55 +1100
- To: Mark Nottingham <mnot@mnot.net>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>, Mike West <mkwst@google.com>, "Emily Stark (Dunn)" <estark@google.com>
On 24 November 2016 at 13:28, Mark Nottingham <mnot@mnot.net> 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!
Received on Thursday, 24 November 2016 04:15:28 UTC