Re: New Version Notification for draft-kazuho-early-hints-status-code-00.txt

Mark Nottingham <mnot@mnot.net> Tue, 08 November 2016 06:02 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 D9DE21294FE for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 7 Nov 2016 22:02:48 -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 GXi9CcjTiRgX for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 7 Nov 2016 22:02:47 -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 2FF09128E19 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 7 Nov 2016 22:02:46 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1c3zRE-000436-3t for ietf-http-wg-dist@listhub.w3.org; Tue, 08 Nov 2016 05:59:16 +0000
Resent-Date: Tue, 08 Nov 2016 05:59:16 +0000
Resent-Message-Id: <E1c3zRE-000436-3t@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 1c3zR5-00041l-BL for ietf-http-wg@listhub.w3.org; Tue, 08 Nov 2016 05:59:07 +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 1c3zQz-0002uv-AZ for ietf-http-wg@w3.org; Tue, 08 Nov 2016 05:59:02 +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 B487922E1FA; Tue, 8 Nov 2016 00:58:37 -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: <BN6PR03MB2708E3C9C2AE0E3154B892BD87A70@BN6PR03MB2708.namprd03.prod.outlook.com>
Date: Tue, 8 Nov 2016 16:58:33 +1100
Cc: Martin Thomson <martin.thomson@gmail.com>, Kazuho Oku <kazuhooku@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <6F4A4B4E-9AC8-4CE6-B990-EE2EA229EDB5@mnot.net>
References: <147792294052.32397.15544665152412530374.idtracker@ietfa.amsl.com> <CANatvzwm_T-HW0yT1MAWEUrfw5OAVkmAZe890575qg8HuU9Z_Q@mail.gmail.com> <3134DBCF-A038-4B11-B457-8126ECD22920@mnot.net> <CABkgnnU2xq41VbJ3pyjVvrVMZ+tr9OM8EDHoHfPQ4yzDDqwEkA@mail.gmail.com> <BN6PR03MB2708E3C9C2AE0E3154B892BD87A70@BN6PR03MB2708.namprd03.prod.outlook.com>
To: Mike Bishop <Michael.Bishop@microsoft.com>
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=-8.4
X-W3C-Hub-Spam-Report: AWL=1.212, 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 1c3zQz-0002uv-AZ ca27e10e5285b042c80ee616200fa90a
X-Original-To: ietf-http-wg@w3.org
Subject: Re: New Version Notification for draft-kazuho-early-hints-status-code-00.txt
Archived-At: <http://www.w3.org/mid/6F4A4B4E-9AC8-4CE6-B990-EE2EA229EDB5@mnot.net>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/32855
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>

I think if we focus on the "hints" part of the 1xx's semantics, it helps clarify those decisions. I.e., nothing you get in that message is something you can depend upon when interpreting the final response; it's just information you can use for optimisation.



> On 8 Nov. 2016, at 5:15 am, Mike Bishop <Michael.Bishop@microsoft.com> wrote:
> 
> Compare to including differing headers between a 200 and a 304, for example -- the RFC says that servers SHOULD NOT emit headers that change the interpretation of the cached content, but that clients MUST merge in any headers the server chooses to emit.  But in practice, every browser has a list of headers it won't let the server change its mind about, and will ignore the server if it tries.  Allowing contradictory information here runs into the same effective problem.
> 
> -----Original Message-----
> From: Martin Thomson [mailto:martin.thomson@gmail.com] 
> Sent: Monday, November 7, 2016 1:03 AM
> To: Mark Nottingham <mnot@mnot.net>
> Cc: Kazuho Oku <kazuhooku@gmail.com>om>; HTTP Working Group <ietf-http-wg@w3.org>
> Subject: Re: New Version Notification for draft-kazuho-early-hints-status-code-00.txt
> 
> On 7 November 2016 at 18:40, Mark Nottingham <mnot@mnot.net> wrote:
>> In retrospect, it's a bit of a shame that we have this requirement in H2: "All pseudo-header fields MUST appear in the header block before regular header fields." If not for that, we could send an "early" HEADERS followed by the :status etc. in a CONTINUATION.
> 
> I don't think that this is a problem.  I mean, for requests it means that routing based on the URL can happen without arbitrary buffering.
> That we also did it for responses is perhaps unnecessary, but it's a little bit of certainty and opening the door for progressive generation of headers also opens the door to new classes of ambiguity as well.  Especially since we still allow individual header fields to come in piecemeal.  I think that I prefer Kazuho's approach.
> 
> The progressive response means that this is OK for progressive things.
> I wouldn't want to see a server change its mind about something; content-type might be hazardous, for example.
> 

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