Re: site-wide headers

Willy Tarreau <w@1wt.eu> Sat, 01 October 2016 06:17 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0354212B1F4 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 30 Sep 2016 23:17:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.237
X-Spam-Level:
X-Spam-Status: No, score=-9.237 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mODUxKyYbzT0 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 30 Sep 2016 23:17:33 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9E4B12B054 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 30 Sep 2016 23:17:33 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1bqDY7-0000LH-Bj for ietf-http-wg-dist@listhub.w3.org; Sat, 01 Oct 2016 06:13:27 +0000
Resent-Date: Sat, 01 Oct 2016 06:13:27 +0000
Resent-Message-Id: <E1bqDY7-0000LH-Bj@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <w@1wt.eu>) id 1bqDY5-0000KN-3c for ietf-http-wg@listhub.w3.org; Sat, 01 Oct 2016 06:13:25 +0000
Received: from wtarreau.pck.nerim.net ([62.212.114.60] helo=1wt.eu) by maggie.w3.org with esmtp (Exim 4.80) (envelope-from <w@1wt.eu>) id 1bqDY1-0004O4-QA for ietf-http-wg@w3.org; Sat, 01 Oct 2016 06:13:24 +0000
Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id u916Ctit031670; Sat, 1 Oct 2016 08:12:55 +0200
Date: Sat, 1 Oct 2016 08:12:55 +0200
From: Willy Tarreau <w@1wt.eu>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20161001061255.GA31660@1wt.eu>
References: <CABkgnnWDys91VF5xCBPc4+J8JQnj75VsGoLVkpXxM60egYd5GQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CABkgnnWDys91VF5xCBPc4+J8JQnj75VsGoLVkpXxM60egYd5GQ@mail.gmail.com>
User-Agent: Mutt/1.6.0 (2016-04-01)
Received-SPF: pass client-ip=62.212.114.60; envelope-from=w@1wt.eu; helo=1wt.eu
X-W3C-Hub-Spam-Status: No, score=-5.5
X-W3C-Hub-Spam-Report: AWL=-0.575, BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: maggie.w3.org 1bqDY1-0004O4-QA 838b8abf72320ce2916d5374976008cc
X-Original-To: ietf-http-wg@w3.org
Subject: Re: site-wide headers
Archived-At: <http://www.w3.org/mid/20161001061255.GA31660@1wt.eu>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/32432
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

Hi Martin,

On Wed, Sep 28, 2016 at 09:00:05PM +1000, Martin Thomson wrote:
> (https://tools.ietf.org/html/draft-nottingham-site-wide-headers-00)
> 
> 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
> powerful.
> 
> 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.

In fact that's what I find powerful here. I know *many* places where
these headers are set by the front reverse-proxy, simply because it
ensures that they're uniform across all the servers. But it also
happens that there are exceptions (eg: for static some servers or
certain unrelated applications). With this mechanism, there's almost
nothing to change in the way it works. The admin will just have to
add "HS" to the responses instead of adding all these header fields,
when the reverse-proxy notices that the client provided the valid SM
field. And it also ensures the proxy an simply remove HS: and replace
it with all appropriate headers when it comes from a server where it's
not appropriate at all (you know, some application developers like to
copy-paste when they don't know).

So in fact, it supports everything already supported today but the
smarter way. It's really nice in my opinion.

Cheers,
Willy