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

Martin Thomson <> Thu, 24 November 2016 04:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 098A012953B for <>; Wed, 23 Nov 2016 20:19:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.498
X-Spam-Status: No, score=-8.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WH47Q0qEA0Nl for <>; Wed, 23 Nov 2016 20:19:32 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 72E031294CA for <>; Wed, 23 Nov 2016 20:19:32 -0800 (PST)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1c9lRl-0005HZ-2m for; Thu, 24 Nov 2016 04:15:41 +0000
Resent-Date: Thu, 24 Nov 2016 04:15:41 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1c9lRY-0005GX-IJ for; Thu, 24 Nov 2016 04:15:28 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <>) id 1c9lRS-0004pC-FD for; Thu, 24 Nov 2016 04:15:23 +0000
Received: by with SMTP id c47so30201660qtc.2 for <>; Wed, 23 Nov 2016 20:15:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mnT3OYhXEo4i3QniM1pJUZGGvCCFbRFL3E36cp8kJrg=; b=L7X7bJEaVgVo9IBe1ovHQXu7ZzmybS8f6VKYB4+H8Tp2PEhiWrYjwEpgVuICrwRfGm keWLN5ZqR8UGomx28/KMYUZ3GKYHddrTJPVwk1ZA64W9PIDAesgwt/k/VAAUv4fOCHOo h1WnMTZ+OLdefAZqrfssGmKHIYSNcy5yHHKwXOzmBLFvQyD/SEK2yKTuEoLepHXkkGjC bM+iCNUfyV4yJKfYea+cbh8MADtoXTO/3WCi5fu4Ln6R7QREZwIXYUcjdFsGOv1lYNX5 UMwQvnyrCpihKDqRrbHbuK3ixxBijePSdSI0gspcXK87Dk4VGmQDRrGBgnt51jtwRwbk mSew==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mnT3OYhXEo4i3QniM1pJUZGGvCCFbRFL3E36cp8kJrg=; b=GpUPHIGyXIzYLi+XY1MYk3AG2/JaH1/po2ifMt9I5zN4tEIZy5FQ0sqstDKfhRbflr XUV5JMApLos73APbf3VCuBbrvLA99rf9/m6S3T9H0y8furoQircHJD5bw0rs8HMxWBhF sxZ2D3ZIFvgXv4t/wl8YOb3Vvd9TZB53XxXz5Yb4jnJQ1hcpQL9AFfPLxiR2AN6ZTh7y 6qV9m2kBJ93GH+8LRgSoGbgBfmCqrRGp5Gw7UrQ2Uy7xiebUnlSUWWomHbLsOh+afqr1 qh1ABhg3m1GOnmmNFDLLbL4FgoQ0yr85y/8/FdpFwcxzbma1K6z/IkNCImLks6vnfsNf dxDA==
X-Gm-Message-State: AKaTC015C4pw6YHV/r5eNbfhqO90/SmlXYSRuwdtvRk3bCWilS6lULvM5h//oTbbP+kHuxWSHjxva1bbRkg49g==
X-Received: by with SMTP id v23mr276431qtb.143.1479960896321; Wed, 23 Nov 2016 20:14:56 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Wed, 23 Nov 2016 20:14:55 -0800 (PST)
In-Reply-To: <>
References: <> <>
From: Martin Thomson <>
Date: Thu, 24 Nov 2016 15:14:55 +1100
Message-ID: <>
To: Mark Nottingham <>
Cc: HTTP Working Group <>, Mike West <>, "Emily Stark (Dunn)" <>
Content-Type: text/plain; charset="UTF-8"
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-6.4
X-W3C-Hub-Spam-Report: AWL=0.352, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1c9lRS-0004pC-FD 1dd1df217b111d3aac31e08a66ead086
Subject: Re: New Version Notification for draft-nottingham-site-wide-headers-01.txt
Archived-At: <>
X-Mailing-List: <> archive/latest/32987
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On 24 November 2016 at 13:28, Mark Nottingham <> 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:
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!