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

Cory Benfield <cory@lukasa.co.uk> Mon, 14 November 2016 09:19 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 ECAD812953D for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 14 Nov 2016 01:19:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.898
X-Spam-Level:
X-Spam-Status: No, score=-7.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lukasa-co-uk.20150623.gappssmtp.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 04okK5LaA8mP for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 14 Nov 2016 01:19:03 -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 868D7129534 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 14 Nov 2016 01:19: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 1c6DMP-0000mi-7T for ietf-http-wg-dist@listhub.w3.org; Mon, 14 Nov 2016 09:15:29 +0000
Resent-Date: Mon, 14 Nov 2016 09:15:29 +0000
Resent-Message-Id: <E1c6DMP-0000mi-7T@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 <cory@lukasa.co.uk>) id 1c6DMJ-0000lq-EY for ietf-http-wg@listhub.w3.org; Mon, 14 Nov 2016 09:15:23 +0000
Received: from mail-wm0-f45.google.com ([74.125.82.45]) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <cory@lukasa.co.uk>) id 1c6DMD-0005tS-J6 for ietf-http-wg@w3.org; Mon, 14 Nov 2016 09:15:18 +0000
Received: by mail-wm0-f45.google.com with SMTP id t79so85645220wmt.0 for <ietf-http-wg@w3.org>; Mon, 14 Nov 2016 01:14:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lukasa-co-uk.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Oc0KCB2qllEeItVthqWqEz7Hjexk4hRrI58bibdThMk=; b=ifX6cy8uURZeQfhapat+Bmg0mp9wwli6HjMeHdnFfWBLtwPfhV31Zst430e2Ftfct8 yYZAUi933hdfn7dJqH/QdceEp3P7rVGaKJnZrkb34ITAOyq/hC78HH1PWzNk35bQNLhl 5Q36+W1PzFVsFa9Oxh+67tfp5orhl5covNIRoStO+vnxO/245sGuHl1P2WiuVLfcXlij QHy5Nfz90gkalbvUhCUbdaU8+MyHhGXYCoPU/ndS11nUG2dQFnsnpJfKhwJ5pkJNic3k XY2ZT9uAvKyhrdSp9BIglFQF5AuK4gOkdy2Woj+NaWYhZ4nrsNlZzQ4niorBaPADp6AW lx8Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Oc0KCB2qllEeItVthqWqEz7Hjexk4hRrI58bibdThMk=; b=VJjlt//0NJkj4xZMZVyYr0EbZCSRTeQyQoqs+yS1JQggyYu24ImFbBBJwfaUFSCBKQ nV1gSL6s5HGns59rG1CyPsTsOayFHQ8roSlH/Lz4jtLkMOu3ICaARcoFPKoJFcLUr2E8 rDFPWAxiTmc1uHEZOqZrs10rvl2PBXgubHuPVMFnvIX9SDFVY26Igl5OdV2hnmKFu+ou SbsHOx6g4uyEaXhet9nSC6lQFj8R1dCVIneX3ySGzRpLLYWZj4xnWA3/johAztnG7XPI ebiotJWT9Zd3zEvAirxebw4rPlWFyaXWXltspKsSg/GUXxwixK2LZZdTJmNE0J+2kTRf MhCw==
X-Gm-Message-State: ABUngvfxAPqzG63W8Hpdp3U0F4OWaMklO15Vrx8d7emSYp1O+LyWtMzDsw6hO1q8rTdvZA==
X-Received: by 10.28.213.74 with SMTP id m71mr9208242wmg.39.1479114890447; Mon, 14 Nov 2016 01:14:50 -0800 (PST)
Received: from [192.168.1.5] (72.6.208.46.dyn.plus.net. [46.208.6.72]) by smtp.gmail.com with ESMTPSA id v2sm27428813wja.41.2016.11.14.01.14.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 14 Nov 2016 01:14:49 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3254\))
From: Cory Benfield <cory@lukasa.co.uk>
In-Reply-To: <20161113164043.9D04B135C7@welho-filter2.welho.com>
Date: Mon, 14 Nov 2016 09:14:47 +0000
Cc: HTTP working group mailing list <ietf-http-wg@w3.org>, Alex Rousskov <rousskov@measurement-factory.com>, Kazuho Oku <kazuhooku@gmail.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <116BF934-ADA2-4BC0-BA17-0D0196F04572@lukasa.co.uk>
References: <CANatvzy+D3ccYsuCWQu9UZc4_DVbAFK-Dt0xf=WezJutz4oM4A@mail.gmail.com> <20161113164043.9D04B135C7@welho-filter2.welho.com>
To: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
X-Mailer: Apple Mail (2.3254)
Received-SPF: pass client-ip=74.125.82.45; envelope-from=cory@lukasa.co.uk; helo=mail-wm0-f45.google.com
X-W3C-Hub-Spam-Status: No, score=-2.3
X-W3C-Hub-Spam-Report: AWL=1.092, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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: mimas.w3.org 1c6DMD-0005tS-J6 4275e8163732e30f519461003e372663
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/116BF934-ADA2-4BC0-BA17-0D0196F04572@lukasa.co.uk>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/32890
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 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.

Cory