site-wide headers

Martin Thomson <> Wed, 28 September 2016 11:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 72EA612B0B0 for <>; Wed, 28 Sep 2016 04:05:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.337
X-Spam-Status: No, score=-9.337 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.316, 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 bO5KhmpjZoAV for <>; Wed, 28 Sep 2016 04:05:23 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E6BE712B0B9 for <>; Wed, 28 Sep 2016 04:05:22 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1bpCbU-0007KD-T7 for; Wed, 28 Sep 2016 11:00:44 +0000
Resent-Date: Wed, 28 Sep 2016 11:00:44 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1bpCbJ-0007JD-T5 for; Wed, 28 Sep 2016 11:00:33 +0000
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1bpCbI-0007QV-AK for; Wed, 28 Sep 2016 11:00:33 +0000
Received: by with SMTP id 11so20142189qtc.0 for <>; Wed, 28 Sep 2016 04:00:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=8OvRZkP5G/rMGDxBhpbef7yI1x4+5v65W4m/zqCUMkQ=; b=slxyrp3fsR+HZLVLb480gwnFj3EJ/hm4E1raRMPHKZoNwA5OTtNGiouGlDTlYYYuO6 f03KBsbk0BFfutB/1ACLqc2P58AheKtnZnWgQDZCZ2PJFHLPNDjqc7lm8OVOnnBXQFvj sTZBeefpyMD2pFJM4+j78XT9j64gN6H6X1ns8gx0AYZse0sCoS8EY05KOEIl5mvDP9+0 JGCO27W/qoQtnrzQ0rDzRAL+c+SpBrl6keSgRYU3vUc8kZQDuP14qbT4XvP/yK7msFKA oAqqxPArDX+mAIteH2EFKHpGXWEpXhLJIpHk3QFGKcalnoqx7Oz/rTp4M8x3hm0DE8uD k0Eg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=8OvRZkP5G/rMGDxBhpbef7yI1x4+5v65W4m/zqCUMkQ=; b=lBavfQorYAttSuBCjqhZGnYbnMyfqZGsuPqwOFq8J+LiwQ5WM3ZttJtU2FqCgmgYsA EW/y9TplAtlYn2r4g5301Kqf8Hn0JqNQH1DK61FU1j3AOn1APGYPMsF8Q73omHqWWt9g PC0JhGz14hRxuCIAC3J29tk+lUh/asjv9ZIVpZZ0yCn0JG1EtwioWIXE84SRhnb2FEOl NKhBSsuZdIF2UE3rNyOqPJHlugUgDwHxGluwNMneCYdDjjvG67RGAE3rsgJC25mqH266 5XfBTgJfU304BQlXWqzVmF3llC3hPra0jThIVJKDDGv64mPWoAOzZF5NT1qlxSNO3i/B B7OA==
X-Gm-Message-State: AA6/9Rm4QfephT+2IaxWcTN0RhrK4LRScRyZ2ZqtJa3JhVj5FW61R3il51r3pQzymJSD+1kzdD6Bc8r9i+Zk2A==
X-Received: by with SMTP id g29mr33279820qtg.88.1475060406441; Wed, 28 Sep 2016 04:00:06 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 28 Sep 2016 04:00:05 -0700 (PDT)
From: Martin Thomson <>
Date: Wed, 28 Sep 2016 21:00:05 +1000
Message-ID: <>
To: Mark Nottingham <>, HTTP Working Group <>
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.333, 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, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1bpCbI-0007QV-AK d022150eb70a2a2f68f974a6814b4e11
Subject: site-wide headers
Archived-At: <>
X-Mailing-List: <> archive/latest/32426
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>


I like this approach because it is more obviously composable into an
existing system at the consuming end.  I especially like that the
format is without opinion about its contents.  That makes it quite

I dislike this approach (in contrast to the JSON-based
origin-policy[1]) because it uses header fields.  Of course that makes
it better suited to HTTP.  I dislike that the format is without
opinion about its contents.  That makes it quite powerful.

On balance, I think that this is a distinct improvement.

One thing that this can't do but the origin-policy does is do
something to manage the downside of CORS.  The idea that you might
give out a pass to avoid CORS preflight is very appealing.  As far as
I can tell, this proposal cannot address that problem.  It would be
justifiable to say that this is a completely different problem that
might build on this work, but it's a very appealing problem to look

(It's tempting to suggest that you could include a label that just
applies to preflight requests, but I don't know how to solve the
origin enumeration problem.  origin-policy seems to punt on that.)

---Nits and suggestions

I think that this needs a little more rigour in the definition of the
format and the algorithm.  They should at least match.  It's unclear
from the algorithm how blank lines (CRLF CRLF) are handled.

The character set for labels could be expanded a little to include
[0-9\-_] so that you can base64url things you might have lying around
to produce the label (or just keep the label very short).

You should also note another reason to keep things out of the h2
header table: any change to the table eventually pushes entries out,
necessitating re-creation.  This is more manageable because it is
directly under control.

The draft should note that these advantages come with a cost in memory
to clients and that clients that receive unreasonably large header
sets can/should pretend that they don't exist.