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

Stefan Eissing <stefan.eissing@greenbytes.de> Mon, 14 November 2016 10:18 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 83E411294A5 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 14 Nov 2016 02:18:05 -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=o6bJP59Q; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=greenbytes.de header.b=XbNifQQ2
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 lph9KKFU9hjW for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 14 Nov 2016 02:18:04 -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 DD1361293DA for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 14 Nov 2016 02:18:03 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1c6EHR-00082m-R3 for ietf-http-wg-dist@listhub.w3.org; Mon, 14 Nov 2016 10:14:25 +0000
Resent-Date: Mon, 14 Nov 2016 10:14:25 +0000
Resent-Message-Id: <E1c6EHR-00082m-R3@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 1c6EHN-00081r-TI for ietf-http-wg@listhub.w3.org; Mon, 14 Nov 2016 10:14:21 +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 1c6EHH-00082Z-Eu for ietf-http-wg@w3.org; Mon, 14 Nov 2016 10:14:16 +0000
Received: by mail.greenbytes.de (Postfix, from userid 117) id AC95915A0987; Mon, 14 Nov 2016 11:13:47 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=greenbytes.de; s=mail; t=1479118427; bh=qcwCyIkPNHPQ4Oo1QfGy8cTuipsLu4E1jPvKHc8tA3Y=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=o6bJP59Qvw08akHOTDpRNjq5++bwPK7E/oa7H+GQHoZK5+oZ2W55YEx58cfnsF90o 7lsQ5N7EyzcxBQpdK8c3O9A2EJM+RM+5t2/p5+HaQGtBjco+0wKcXdyZ2TkXAOaN8n mmFntCbMdYODetK0RWpy/8F3cacp7LAbz5k/RkUw=
Received: from [192.168.1.150] (unknown [192.168.1.1]) (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 78C6015A0450; Mon, 14 Nov 2016 11:13:46 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=greenbytes.de; s=mail; t=1479118426; bh=qcwCyIkPNHPQ4Oo1QfGy8cTuipsLu4E1jPvKHc8tA3Y=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=XbNifQQ2eeWbB1zGPp+AM8cp5Sp49TMbY6pouqn9HwfYn/sH+E7tUUdO0huaMaNqp MbNePJswlBN1m57Y2pdeOLqeq/yFEF2Ye+jGhvg0Fp2jWyyNIzcJxYRZxYq6dpVjJH 9+hpPG1Ba5wgQ82tU4GFpk4YHlqeTohdXyYdS5KA=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
From: Stefan Eissing <stefan.eissing@greenbytes.de>
In-Reply-To: <CANatvzyDGEXc9tOJtc3svooEHpDMiwK1S9iYvjv-T3sHxuVhng@mail.gmail.com>
Date: Mon, 14 Nov 2016 11:13:48 +0100
Cc: Cory Benfield <cory@lukasa.co.uk>, Kari Hurtta <hurtta-ietf@elmme-mailer.org>, HTTP working group mailing list <ietf-http-wg@w3.org>, Alex Rousskov <rousskov@measurement-factory.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <BD25D1F7-ADB0-481B-AFDC-2CEDD4A494C0@greenbytes.de>
References: <CANatvzy+D3ccYsuCWQu9UZc4_DVbAFK-Dt0xf=WezJutz4oM4A@mail.gmail.com> <20161113164043.9D04B135C7@welho-filter2.welho.com> <116BF934-ADA2-4BC0-BA17-0D0196F04572@lukasa.co.uk> <CANatvzyDGEXc9tOJtc3svooEHpDMiwK1S9iYvjv-T3sHxuVhng@mail.gmail.com>
To: Kazuho Oku <kazuhooku@gmail.com>
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=-6.5
X-W3C-Hub-Spam-Report: AWL=0.252, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-2.799, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1c6EHH-00082Z-Eu 0359c151b6d87f5a4005e0a80f5b348c
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/BD25D1F7-ADB0-481B-AFDC-2CEDD4A494C0@greenbytes.de>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/32892
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 14.11.2016 um 10:44 schrieb Kazuho Oku <kazuhooku@gmail.com>om>:
> 
> 2016-11-14 18:14 GMT+09:00 Cory Benfield <cory@lukasa.co.uk>uk>:
>> 
>>> On 13 Nov 2016, at 16:40, Kari Hurtta <hurtta-ietf@elmme-mailer.org> 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.

+1

>> Cory
> -- 
> Kazuho Oku

Stefan