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

Stefan Eissing <stefan.eissing@greenbytes.de> Sun, 27 November 2016 16:27 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 D0B9C1294ED for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 27 Nov 2016 08:27:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.498
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=greenbytes.de header.b=PaiyNj9U; dkim=pass (1024-bit key) header.d=greenbytes.de header.b=PaiyNj9U
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 PRmY2hYqicW3 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 27 Nov 2016 08:27:12 -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 27120129538 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sun, 27 Nov 2016 08:27:11 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1cB2Eo-0005U7-2F for ietf-http-wg-dist@listhub.w3.org; Sun, 27 Nov 2016 16:23:34 +0000
Resent-Date: Sun, 27 Nov 2016 16:23:34 +0000
Resent-Message-Id: <E1cB2Eo-0005U7-2F@frink.w3.org>
Received: from mimas.w3.org ([128.30.52.79]) by frink.w3.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <stefan.eissing@greenbytes.de>) id 1cB2Ee-0005Sp-5J for ietf-http-wg@listhub.w3.org; Sun, 27 Nov 2016 16:23:24 +0000
Received: from mail.greenbytes.de ([5.10.171.186]) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <stefan.eissing@greenbytes.de>) id 1cB2EX-0000e9-JO for ietf-http-wg@w3.org; Sun, 27 Nov 2016 16:23:18 +0000
Received: by mail.greenbytes.de (Postfix, from userid 117) id A601F15A1085; Sun, 27 Nov 2016 17:22:49 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=greenbytes.de; s=mail; t=1480263769; bh=N++m+KSTQAosKadlbMQmXRbAFFixT4GWoeHig6AJIZg=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=PaiyNj9UcPOvlZjXAWsPmZtsLA2vMM5KpzJ5rwwyTiRqAWrO5lKw1Hsugae86JSO1 0Oiky3EWHCh4Zqz0LLRZu7ro0V9idjmHojnRTsIhPZPgQgWJ8P5+yMlVZ9p7hsLX+u bfE8nRktR/QmkpqhVeqdv0jss3aOzif+og9X2Vs0=
Received: from [192.168.0.100] (unknown [81.173.168.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.greenbytes.de (Postfix) with ESMTPSA id 38FF715A0527; Sun, 27 Nov 2016 17:22:49 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=greenbytes.de; s=mail; t=1480263769; bh=N++m+KSTQAosKadlbMQmXRbAFFixT4GWoeHig6AJIZg=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=PaiyNj9UcPOvlZjXAWsPmZtsLA2vMM5KpzJ5rwwyTiRqAWrO5lKw1Hsugae86JSO1 0Oiky3EWHCh4Zqz0LLRZu7ro0V9idjmHojnRTsIhPZPgQgWJ8P5+yMlVZ9p7hsLX+u bfE8nRktR/QmkpqhVeqdv0jss3aOzif+og9X2Vs0=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Stefan Eissing <stefan.eissing@greenbytes.de>
X-Mailer: iPhone Mail (14B150)
In-Reply-To: <DF0B10BA-C35D-450A-A392-50D9A4CB52C9@mnot.net>
Date: Sun, 27 Nov 2016 17:22:48 +0100
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <15A265AD-1218-415A-9D73-CF1C3A1A27F1@greenbytes.de>
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>
To: Mark Nottingham <mnot@mnot.net>
Received-SPF: pass client-ip=5.10.171.186; envelope-from=stefan.eissing@greenbytes.de; helo=mail.greenbytes.de
X-W3C-Hub-Spam-Status: No, score=-7.0
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-3, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1cB2EX-0000e9-JO e0dc641411014bf6687a3feff5ab7293
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/15A265AD-1218-415A-9D73-CF1C3A1A27F1@greenbytes.de>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/33023
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 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?


> 
>> 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. 

Cheers, Stefan
> 
> Cheers,
> 
> 
> --
> Mark Nottingham   https://www.mnot.net/
> 
>