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

Mark Nottingham <mnot@mnot.net> Mon, 28 November 2016 23:56 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 1335712A03C for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 28 Nov 2016 15:56:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.398
X-Spam-Level:
X-Spam-Status: No, score=-8.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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
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 T4JSYQbpGBLH for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 28 Nov 2016 15:56:48 -0800 (PST)
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 ED14912A167 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 28 Nov 2016 15:56:47 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1cBVjN-00018A-VJ for ietf-http-wg-dist@listhub.w3.org; Mon, 28 Nov 2016 23:53:05 +0000
Resent-Date: Mon, 28 Nov 2016 23:53:05 +0000
Resent-Message-Id: <E1cBVjN-00018A-VJ@frink.w3.org>
Received: from titan.w3.org ([128.30.52.76]) by frink.w3.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <mnot@mnot.net>) id 1cBVjH-00016Q-6i for ietf-http-wg@listhub.w3.org; Mon, 28 Nov 2016 23:52:59 +0000
Received: from mxout-07.mxes.net ([216.86.168.182]) by titan.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <mnot@mnot.net>) id 1cBVjA-0005kk-GS for ietf-http-wg@w3.org; Mon, 28 Nov 2016 23:52:53 +0000
Received: from [192.168.3.104] (unknown [124.189.98.244]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id F1C2122E253; Mon, 28 Nov 2016 18:52:26 -0500 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <15A265AD-1218-415A-9D73-CF1C3A1A27F1@greenbytes.de>
Date: Tue, 29 Nov 2016 10:52:23 +1100
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <A004AC44-D27E-4D22-92E1-CDAE5209D24A@mnot.net>
References: <147995400666.32746.15867339667353417986.idtracker@ietfa.amsl.com> <FCDFC352-5D68-456F-AFF4-39E9E1697AF2@mnot.net> <CAKXHy=d18Zy-khibw78iC5i=8iOu2v_M2VS_aKV2jOexp8=gBg@mail.gmail.com> <CABkgnnW2+ewi=YViiNqJgne2WFApEEasje3wwU5RsvEBmNPMjg@mail.gmail.com> <29B32952-C7C3-46B5-B48C-9BA9F9D65F8D@mnot.net> <80A4462A-3E4E-4DF0-A8C8-58F792E38B01@greenbytes.de> <DF0B10BA-C35D-450A-A392-50D9A4CB52C9@mnot.net> <15A265AD-1218-415A-9D73-CF1C3A1A27F1@greenbytes.de>
To: Stefan Eissing <stefan.eissing@greenbytes.de>
X-Mailer: Apple Mail (2.3251)
Received-SPF: pass client-ip=216.86.168.182; envelope-from=mnot@mnot.net; helo=mxout-07.mxes.net
X-W3C-Hub-Spam-Status: No, score=-7.9
X-W3C-Hub-Spam-Report: AWL=1.746, BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1cBVjA-0005kk-GS 72409809d33a3b27da5ff1d06a02f4b2
X-Original-To: ietf-http-wg@w3.org
Subject: Re: New Version Notification for draft-nottingham-site-wide-headers-01.txt
Archived-At: <http://www.w3.org/mid/A004AC44-D27E-4D22-92E1-CDAE5209D24A@mnot.net>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/33028
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>

> On 28 Nov. 2016, at 3:22 am, Stefan Eissing <stefan.eissing@greenbytes.de> wrote:
> 
> Hi Mark,
> 
>> Am 27.11.2016 um 08:38 schrieb Mark Nottingham <mnot@mnot.net>et>:
>> 
>> Hi Stefan,
>> 
>>> On 27 Nov. 2016, at 1:29 am, Stefan Eissing <stefan.eissing@greenbytes.de> wrote:
>>> Well, from a server PoV, supporting this for existing headers is not straight forward. Headers can be injected into the response at several stages of processing and some may already be on the wire when the server finds out that a "side-wide" header was changed.
>> 
>> Are you talking about handling responses in flight when the .well-known file is updated, or something else?
> 
> I was thinking of someone at the end of the request output filtering adding a header like access-control-allow-origin. It might be mistaken, but that header only allows a single value.
> 
> If there is the same header in the well-known site-wide definition, it would cause a problem, it seems to me. The client appends the sh headers and sees duplicate values, right?

Yep. My thinking is that this is no different than any other potential clash caused by a configuration mechanism -- the solution is "don't do that."


>>> Servers would need to know the complete set of headers before sending the first one or, alternately, preventing application code to insert such headers from a certain point in time onwards. I am almost certain that this will break some deployments.
>> 
>> I think you're over-complicating it. In Apache, .htaccess files don't prevent you from inserting (e.g.) Strict-Transport-Security if CGI or PHP already did so; why is this different?
>> 
>> 
>>> If the whole purpose - for existing headers - is to save some bytes on the wire, then I find it hard to justify the complexity in these days of h2 and hpack.
>> 
>> See the intro of my doc. HPACK has per-connection overhead, so if we keep on adding headers, it's going to get crowded in there, and that takes memory server-side. Doing a .well-known (of whatever flavour) is per-origin, so it takes the pressure off of HPACK. Because it persists beyond a connection, it also means you spend less time at the beginning of each conn setting up HPACK state.
> 
> I agree with the goal of this spec. I am not certain it will work for all headers listed. There are obvious once where it does and others, with the example above, where it might not be straightforward. 

We definitely need to go through the headers and evaluate each one, no matter what mechanism we choose.

Cheers,


--
Mark Nottingham   https://www.mnot.net/