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

Stefan Eissing <stefan.eissing@greenbytes.de> Sat, 26 November 2016 14:34 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 A65681296F2 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 26 Nov 2016 06:34:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.288
X-Spam-Level:
X-Spam-Status: No, score=-8.288 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=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, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=greenbytes.de header.b=lFP2lgoQ; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=greenbytes.de header.b=lFP2lgoQ
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 jOz-OuabkWN1 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 26 Nov 2016 06:34:22 -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 7160F1296EF for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sat, 26 Nov 2016 06:34:21 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1cAdzz-0007W5-JJ for ietf-http-wg-dist@listhub.w3.org; Sat, 26 Nov 2016 14:30:39 +0000
Resent-Date: Sat, 26 Nov 2016 14:30:39 +0000
Resent-Message-Id: <E1cAdzz-0007W5-JJ@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 <stefan.eissing@greenbytes.de>) id 1cAdzd-0006Aj-DV for ietf-http-wg@listhub.w3.org; Sat, 26 Nov 2016 14:30:17 +0000
Received: from mail.greenbytes.de ([5.10.171.186]) by titan.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <stefan.eissing@greenbytes.de>) id 1cAdzX-0004PQ-6P for ietf-http-wg@w3.org; Sat, 26 Nov 2016 14:30:12 +0000
Received: by mail.greenbytes.de (Postfix, from userid 117) id BDB6515A0892; Sat, 26 Nov 2016 15:29:43 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=greenbytes.de; s=mail; t=1480170583; bh=CRogpIFQSRKiPh94d9GLF6TWn6SMeyFMpxFE16q3vhg=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=lFP2lgoQuDC+TtA4IdAs9eQA6XxdW5pbfPeUHLYSvj/nbIUQ7rCqO+/lwZz3WIDs4 AI7EO6Bx8BZTC3Yr5l5NvwQypu5hcfNA9cPKbAvAd5ctxIDB9+W14inTf3tF3FlLOc 9YTK1WIgfr9PzNEvIpBVpV5MbqZxMEl/5MgSQ3DA=
Received: from [192.168.0.109] (unknown [78.35.93.155]) (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 3416A15A0892; Sat, 26 Nov 2016 15:29:43 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=greenbytes.de; s=mail; t=1480170583; bh=CRogpIFQSRKiPh94d9GLF6TWn6SMeyFMpxFE16q3vhg=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=lFP2lgoQuDC+TtA4IdAs9eQA6XxdW5pbfPeUHLYSvj/nbIUQ7rCqO+/lwZz3WIDs4 AI7EO6Bx8BZTC3Yr5l5NvwQypu5hcfNA9cPKbAvAd5ctxIDB9+W14inTf3tF3FlLOc 9YTK1WIgfr9PzNEvIpBVpV5MbqZxMEl/5MgSQ3DA=
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
From: Stefan Eissing <stefan.eissing@greenbytes.de>
In-Reply-To: <29B32952-C7C3-46B5-B48C-9BA9F9D65F8D@mnot.net>
Date: Sat, 26 Nov 2016 15:29:42 +0100
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <80A4462A-3E4E-4DF0-A8C8-58F792E38B01@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>
To: Mark Nottingham <mnot@mnot.net>
X-Mailer: Apple Mail (2.3251)
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=-2.999, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1cAdzX-0004PQ-6P 31f8d9a2d1f7f35e8a76eef1a9c7e07c
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/80A4462A-3E4E-4DF0-A8C8-58F792E38B01@greenbytes.de>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/33019
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>

> Am 25.11.2016 um 03:32 schrieb Mark Nottingham <mnot@mnot.net>:
> 
> 
>> On 25 Nov. 2016, at 11:53 am, Martin Thomson <martin.thomson@gmail.com> wrote:
>> 
>> I'm of the opinion that a well-known global resource (or set of
>> resources, because we're already there) that contained specific and
>> precise policies about an origin is valuable.  As Mike points out,
>> there are things that you can say more clearly when you aren't
>> constrained by saying something about a specific HTTP response.
>> That's a principled position that I can respect.
>> 
>> At the same time, we need to deal with the fact that we've got a bunch
>> of per-response header fields that are gradually proliferating.  At
>> some level, we're basically just looking for some better compression
>> (as Mark's draft points out, HPACK is pretty close to good enough for
>> this purpose).
>> 
>> The HTTP header fields stuff in Mike's draft is abominable.  I think
>> that Mark is much closer to an approach that will deploy successfully
>> for stuff that we currently have - at least in the short term.
>> 
>> Where the tension seems to come from is that all the existing stuff is
>> basically stuck in header fields for the foreseeable future.  That's
>> unpleasant, because even if we were to define principled equivalents
>> in terms of Mike's draft, then we're still stuck supporting header
>> fields indefinitely.  It makes the work to define the principled thing
>> much less appealing, because now you have two mechanisms to do the
>> same thing with all the duplication and conflicts that come from that.
> 
> Well described, although migrating *existing* site-wide things away from headers is only a nice-to-have goal for me; the real goal is to avoid the need to define future ones (or at least to put them on the wire very often, depending on which way we go).
> 
> If I read things correctly, one strong possibility is to take the generic "headers" out of Mike's spec and define syntax for existing site-wide headers on a case-by-case basis. That gets existing site-wide headers off the wire for those clients that implement, although they will still need to be able to deal with the header version for the foreseeable future.
> 
> I think that's a fine outcome (because it's effectively a graceful transition) if we can get a commitment to implement from most/all browsers (or "convince" them to do it relatively soon). If we can't, we're effectively stuck with site-wide headers for existing *and* future things, no matter what we do; see separate thread with Emily.

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.

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.

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.

-Stefan