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

Martin Thomson <martin.thomson@gmail.com> Mon, 07 November 2016 09:08 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 479CC129A28 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 7 Nov 2016 01:08:41 -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 (2048-bit key) header.d=gmail.com
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 9VLOHM2vY_0C for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 7 Nov 2016 01:08:39 -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 3F0D51296B9 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 7 Nov 2016 01:08:39 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1c3fqS-0004k7-4I for ietf-http-wg-dist@listhub.w3.org; Mon, 07 Nov 2016 09:04:00 +0000
Resent-Date: Mon, 07 Nov 2016 09:04:00 +0000
Resent-Message-Id: <E1c3fqS-0004k7-4I@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 <martin.thomson@gmail.com>) id 1c3fqM-0004hc-3d for ietf-http-wg@listhub.w3.org; Mon, 07 Nov 2016 09:03:54 +0000
Received: from mail-qk0-f169.google.com ([209.85.220.169]) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <martin.thomson@gmail.com>) id 1c3fqF-0007pS-L0 for ietf-http-wg@w3.org; Mon, 07 Nov 2016 09:03:48 +0000
Received: by mail-qk0-f169.google.com with SMTP id n204so157655759qke.2 for <ietf-http-wg@w3.org>; Mon, 07 Nov 2016 01:03:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Yh5X8bHSy497xurOQ51LkbjLRQCalLCoU4U9TCuIUYs=; b=jUbGd3sSTUjs92pCYKsL+qOavsA+JuvQIMhBMrPFbDU7eV1hceZreQC5ywpuWUs05b f9SWQhpmbakRsB3ueKagz7xuzBcp+Y8aHKoM9/2E6taSvJOaY1yNA+9yGrprZTF1c53F le5Sr8rVvRz3hf1CYajy7aVp7dCm42bItCkoGWpwL1S3kiipTCeG/I4lE0QYq7javEuE y8zojCKQaBp0Ul58zUQPJUVCdvUBbB062SLE1coxTe4laobioEzByX1YTukj8F01XwbQ Ro75i3v8rLtvcBhZtMa7P9TRmIkNH4EcGSw1mQymJh1Wu3Lux8Qq8NrdW2lVVXoFASO5 202A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Yh5X8bHSy497xurOQ51LkbjLRQCalLCoU4U9TCuIUYs=; b=EIo3iY4rOs6KQpY7RPDp57HZJJefAjDgO6U9cRyWAzPnHVekrzNP8iN5Ei1uFf3oBL koQDKwmbZ+uGUb7hLzI62NQ78AKxVHodCrhuy+mgMYVYMJvlV0GrYd9/BNkmdc4JUvMi HzTomF/7UAqOc9k+qBEjxE2sk40rY+Fv5RZzcB+cuGS3pWc9OjDeR8KHIAPPmMlqcnYG 6BYqEgE+D/2xxmwlLBok08HvHJFntD5Jd2HLGDH7LzTEjRu9uBS/Z6Ui1Li/5xEDGcrP ObQ9u6BvVZstYXg6ymu1HzcwOi9A6G79+di6/0FtbRFLn4k0sBif9DJPrm1GqLX4NPN3 QT+Q==
X-Gm-Message-State: ABUngvej7lLy6towx+H2QQtaTegtb6lEqFYT/hBekOkjOx/NRxU2kAF14LzwFkUzLlTOPKjd42Edy4afWIz3Ig==
X-Received: by 10.55.74.1 with SMTP id x1mr6113005qka.316.1478509401659; Mon, 07 Nov 2016 01:03:21 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.85.7 with HTTP; Mon, 7 Nov 2016 01:03:20 -0800 (PST)
In-Reply-To: <3134DBCF-A038-4B11-B457-8126ECD22920@mnot.net>
References: <147792294052.32397.15544665152412530374.idtracker@ietfa.amsl.com> <CANatvzwm_T-HW0yT1MAWEUrfw5OAVkmAZe890575qg8HuU9Z_Q@mail.gmail.com> <3134DBCF-A038-4B11-B457-8126ECD22920@mnot.net>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Mon, 7 Nov 2016 20:03:20 +1100
Message-ID: <CABkgnnU2xq41VbJ3pyjVvrVMZ+tr9OM8EDHoHfPQ4yzDDqwEkA@mail.gmail.com>
To: Mark Nottingham <mnot@mnot.net>
Cc: Kazuho Oku <kazuhooku@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass client-ip=209.85.220.169; envelope-from=martin.thomson@gmail.com; helo=mail-qk0-f169.google.com
X-W3C-Hub-Spam-Status: No, score=-5.8
X-W3C-Hub-Spam-Report: AWL=-0.253, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1c3fqF-0007pS-L0 56458f6e455ef4291945de6e87bbd539
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/CABkgnnU2xq41VbJ3pyjVvrVMZ+tr9OM8EDHoHfPQ4yzDDqwEkA@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/32850
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 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.