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

Kazuho Oku <> Mon, 14 November 2016 09:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 723A41294DA for <>; Mon, 14 Nov 2016 01:48:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.998
X-Spam-Status: No, score=-7.998 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, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6fYZ6vzyvcVg for <>; Mon, 14 Nov 2016 01:48:19 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 22EF2129431 for <>; Mon, 14 Nov 2016 01:48:18 -0800 (PST)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1c6Dod-0006SC-MX for; Mon, 14 Nov 2016 09:44:39 +0000
Resent-Date: Mon, 14 Nov 2016 09:44:39 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1c6DoY-0006Pn-9v for; Mon, 14 Nov 2016 09:44:34 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <>) id 1c6DoS-00067s-CG for; Mon, 14 Nov 2016 09:44:29 +0000
Received: by with SMTP id f82so87180157wmf.1 for <>; Mon, 14 Nov 2016 01:44:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Ilc7beIXDTWG7dGYBtrM0y6YriQNmNNO8Z++D9FgP88=; b=MZZV5YKq4qCds+rdpgFUiJydUH7PGC0VbCceDYaqFAZ/eo6M/PSm1DKZu4LFNQ2LmN RHwkroLNKVBvTMG9x48h7S98tuKLegCEh2HPq32TJYJ7eBf5PYDgswZwlG3x79N1Wt4A kXW37/UYHng81O2xyiPPOSYu3u1KkuajJ6Rc5mvOtz66gkBefLXu8/qfReJyixZEbcvk //xkP9yKlOOQEi7aaeQW80pN5Q45QZbgVZjEWX23XDmw4EQSxEt6oSHEOrflpHZpfHXA dSVJfTkyVF5qfh3L0BWJ1Do0hB2ubRwwxn9sh5+ysELJa7ZTiW0sMbFvU9n+D4c68t0l fWCg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Ilc7beIXDTWG7dGYBtrM0y6YriQNmNNO8Z++D9FgP88=; b=ABwgqOSizo9BlMcmU/wKq1k5wiqnt9+/1W2bO2cRlCn6ZDyahr/RS5OYM6sjM3aBtJ JONDN7hmoArW8FIxoqmlWXQfcV1RUsYSxuw5LbQwhNzHrFPv0qZofK+k0WOXM4CQNHP2 u/Hdj4YNoGX74CZZ1+gSeAt6uO4ikBvWcuRd9IZUP2H8omiGuWYyAR4WKoh+ArD42vkG 8t6N4jTT2h10z4Zk7a3q6EGEzpyuHqLV3rrA4dUXP/CWeq3QQSBenfedeD4Q2U6SxXwE Dx3QUPO8jVqSVwZupyCkT2X6PHQHAXD1ezlqPuuT+yzPxkQJXDN6BcArbcgKToIIqu9V 6VsA==
X-Gm-Message-State: ABUngvcuxP2HCCB+RkhaHIx+sribSul8sBYxgaOMqDMK/rI/m6GZ57C1jsO+d/AlYoZgo3fAXejbP7ekSqiu6g==
X-Received: by with SMTP id l184mr8732470wmd.88.1479116641708; Mon, 14 Nov 2016 01:44:01 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Mon, 14 Nov 2016 01:44:00 -0800 (PST)
In-Reply-To: <>
References: <> <> <>
From: Kazuho Oku <>
Date: Mon, 14 Nov 2016 18:44:00 +0900
Message-ID: <>
To: Cory Benfield <>
Cc: Kari Hurtta <>, HTTP working group mailing list <>, Alex Rousskov <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-4.3
X-W3C-Hub-Spam-Report: AWL=-0.786, 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_WL=-1
X-W3C-Scan-Sig: 1c6DoS-00067s-CG 802497a95af961532b11ddd68fd12da1
Subject: Re: New Version Notification for draft-kazuho-early-hints-status-code-00.txt
Archived-At: <>
X-Mailing-List: <> archive/latest/32891
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

2016-11-14 18:14 GMT+09:00 Cory Benfield <>uk>:
>> On 13 Nov 2016, at 16:40, Kari Hurtta <> wrote:
>> It is also possible to Connection: -header implementation is broken.
>> So if 1xx is broken, it does not help use Connection: for to
>> indicate hop-by-hop header if this is not honored either.
>> Seems likely that both little used featured are broken
>> on same implementation.
> I suspect Kari and Kazuho are right here: it is likely that any implementation that mishandles 1XX responses will also mishandle the Connection header. My experience of working with implementations and implementers is that the Connection field is extremely poorly understood.
> This is unfortunate. I was advocating for the header-based negotiation because I believed that the state of affairs for intermediaries was likely to be better than it is for the long-tail of OSS client implementations, but it looks like it isn’t. With that in mind then, I think we have three options:
> 1. As Julian suggested, restrict use of this response to HTTPS only and then negotiate via header field. This doesn’t necessarily solve the problem (HTTPS may be used to an intermediary), and also preferences the needs of clients over intermediaries. I’m not sure that’s a good plan.
> 2. As Kazuho has suggested, restrict use of the status code to H2 where implementations generally-speaking handle the less-used spec features better.
> 3. Don’t put any spec limitations on the use of the status code and allow implementers to decide under what conditions they are willing to emit the header field.
> For my part, I think either 2 or 3 is the best solution. I don’t see any reason to want to do an end-run around intermediaries like in (1). I’m open to (3). I think in practice we will see limited update in HTTP/1.1 for a while, but that may have to just be ok.

Thank you for laying down the options.

My preference is 3, with possibly some warnings using non-normative
form alerting the reader that there might be interoperability issues
especially when HTTP/1 is used.

> Cory

Kazuho Oku