W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2016

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

From: Martin Thomson <martin.thomson@gmail.com>
Date: Thu, 24 Nov 2016 15:14:55 +1100
Message-ID: <CABkgnnU6HrfkmqZhLFGMdKwLh2gcddH7eHbv--Tt_Vu8K+jnfw@mail.gmail.com>
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

This archive was generated by hypermail 2.3.1 : Thursday, 24 November 2016 04:15:35 UTC