Re: New Version Notification for draft-kazuho-early-hints-status-code-00.txt
"Roy T. Fielding" <fielding@gbiv.com> Wed, 02 November 2016 22:54 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 BC6191294CF for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 2 Nov 2016 15:54:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.998
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gbiv.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 SdQwoQkIu75t for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 2 Nov 2016 15:54:36 -0700 (PDT)
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 05235129486 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 2 Nov 2016 15:54:35 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1c24Mi-0002lg-AW for ietf-http-wg-dist@listhub.w3.org; Wed, 02 Nov 2016 22:50:40 +0000
Resent-Date: Wed, 02 Nov 2016 22:50:40 +0000
Resent-Message-Id: <E1c24Mi-0002lg-AW@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 <fielding@gbiv.com>) id 1c24Ma-0002ki-Gs for ietf-http-wg@listhub.w3.org; Wed, 02 Nov 2016 22:50:32 +0000
Received: from sub5.mail.dreamhost.com ([208.113.200.129] helo=homiemail-a125.g.dreamhost.com) by titan.w3.org with esmtps (TLS1.1:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from <fielding@gbiv.com>) id 1c24MU-0003CM-EM for ietf-http-wg@w3.org; Wed, 02 Nov 2016 22:50:27 +0000
Received: from homiemail-a125.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a125.g.dreamhost.com (Postfix) with ESMTP id D7B7360000E03; Wed, 2 Nov 2016 15:50:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=content-type :mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=gbiv.com; bh=4byF+Km9jFjvIRyInzRy07E1rtQ=; b=ZDKHRuD5nErWT1VfMMde3DiB8sUp LmVZxKwy8O75NcSlYaL/vxaiVRCeVHVceSuE3FXglTEZwnrSWY6uIzcSyiZbmOeo Pk+4n2+VRTBacnh2mvywLRRUmDnIW520NdVZZc44UvUC73rYgGkJ64FvrQtKIr3f kRXrM7/Lf58hsck=
Received: from [192.168.1.3] (ip68-228-71-159.oc.oc.cox.net [68.228.71.159]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: fielding@gbiv.com) by homiemail-a125.g.dreamhost.com (Postfix) with ESMTPSA id AB43160000E01; Wed, 2 Nov 2016 15:50:02 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: "Roy T. Fielding" <fielding@gbiv.com>
In-Reply-To: <5D00C20A-0421-406A-AE2A-79E713507D02@lukasa.co.uk>
Date: Wed, 02 Nov 2016 15:50:02 -0700
Cc: Julian Reschke <julian.reschke@gmx.de>, Kazuho Oku <kazuhooku@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <08467A5B-78F7-4993-B3E3-C9A24F16D02E@gbiv.com>
References: <147792294052.32397.15544665152412530374.idtracker@ietfa.amsl.com> <CANatvzwm_T-HW0yT1MAWEUrfw5OAVkmAZe890575qg8HuU9Z_Q@mail.gmail.com> <86447165-100C-407D-8512-A32F93B11BBA@lukasa.co.uk> <CANatvzzRvbEjy4AqDHeRtQfcJX0Ls14qJf0qv0QWZBMMd-HRnQ@mail.gmail.com> <5f155947-e74c-0761-b5d4-64f8aabec846@gmx.de> <F2EE2E10-9129-47D4-8C6E-BEE079503F34@lukasa.co.uk> <86EAA775-324C-41C9-87E0-9D04E51EE141@gbiv.com> <5D00C20A-0421-406A-AE2A-79E713507D02@lukasa.co.uk>
To: Cory Benfield <cory@lukasa.co.uk>
X-Mailer: Apple Mail (2.2104)
Received-SPF: none client-ip=208.113.200.129; envelope-from=fielding@gbiv.com; helo=homiemail-a125.g.dreamhost.com
X-W3C-Hub-Spam-Status: No, score=-7.6
X-W3C-Hub-Spam-Report: AWL=0.929, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1c24MU-0003CM-EM 9e53fd2286ccc059a2b3efc3733b6c6c
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/08467A5B-78F7-4993-B3E3-C9A24F16D02E@gbiv.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/32823
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 Nov 2, 2016, at 2:59 AM, Cory Benfield <cory@lukasa.co.uk> wrote: > > >> On 1 Nov 2016, at 22:50, Roy T. Fielding <fielding@gbiv.com> wrote: >> >>> On Nov 1, 2016, at 1:17 AM, Cory Benfield <cory@lukasa.co.uk> wrote: >>> >>> I’m right there with you Julian. The 1XX response category gets to be another marker pointing us to the lesson the IETF has been learning for the past decade or so: extension points on a specification that no-one uses rust over time and become unusable. >> >> No. What I've learned is that every feature in every protocol is poorly >> implemented by some poor soul who thinks they deserve special consideration >> for their inability to interoperate with the future. I have, in the past, >> consistently refused such considerations. > > I don’t understand where you think anyone who wrote a broken implementation is asking for special consideration. The only HTTP implementation I fully wrote is a HTTP/2 implementation that can handle 1XX codes per the specification. I certainly don’t need the special consideration for libraries I maintain, because I’ll be shipping patches for them. Sorry, I was talking about the past. You made a general comment about the nature of protocol extensibility mechanisms based on the evidence of existing implementations having bugs. But existing implementations have bugs for every aspect of the protocol, for the same reason: some developers don't read specifications. The only distinction here is how long it takes for someone to get around to testing a use case which triggers the bug and results in a bug report which can then be fixed by some developer. > I am simply informing the IETF that the vast majority of widely deployed HTTP client libraries today will fail in the face of the 103 status code. Since I looked at Python I have gone back and looked at Ruby, Javascript, and Go, and the same remains true there. All of these languages have implementations that surface the 103 to the user and swallow the 200. So far curl and wget are the only widely-deployed non-browser implementations I have found that handle the 103 the way that RFC 7230 says they should. While we should praise those implementers, we should acknowledge that curl and wget are so widely deployed that they get bug reports for all the wacky edge cases in the way that the smaller implementations do not. (Yes, I called 1XX a wacky edge case, let’s all move on from it.) Thanks for the information. FTR, 100 and 101 were originally defined. 102 was an extension. There have been several attempts to define a 103 for various reasons, but they were deemed close enough to 102 that they were not worth pursuing further. There are also many uses of 1xx status codes within non-standard systems for which no registration was necessary, mostly for the sake of hinting at optional features or local status. >>> In this case, I think the 1XX problem is more oversight than anything else. The problems in all these cases are tractable, and can be fairly easily fixed. It’s just that someone needs to spend that time. >> >> They are easily fixed. Force the broken implementations to die in a miserable >> way and teach people not to write crappy code. > > That fixes nothing. While I’m sure it’s emotionally satisfying to metaphorically slap developers around the face and scream “OBEY. THE. RFC” at them, the very existence of RFCs 7230+ is a good reminder that developers almost universally do not pay attention to the RFCs: they pay attention to the protocol *as encountered on the web*. That protocol has had for its entire lifetime only two 1XX status codes: 100 and 101. Protocol implementations almost universally handle those status codes correctly: just no others in the range. And that hasn’t mattered because no-one is *using* those other codes. Please don't lecture me on the nature of HTTP deployment. You are aware of maybe 5% of deployed implementations. I get regular questions from a much broader scope, because my name is on the specs. Your premise is mistaken, and the lesson you took from it is simply wrong. In my experience, most developers (especially open source developers like me) are happy to fix bugs in their software, particularly when they are backed by specification text that is now 21 years old (and still counting). I don't care how widely they are deployed. Not a single client on your list existed when 1xx was invented. Not a single one will still exist (in any meaningful sense) more than ten years from now. They are broken in terms of the protocol usage, today, regardless of how Kazuho chooses to negotiate the feature. Adding another 10 or so bytes to every request is not going to make them any less broken. Let them surface the 103. Force the bug to be fixed. Encourage people to upgrade their software. That is far less expensive than sending extra bytes on every request for the next 40 years. ....Roy
- Fwd: New Version Notification for draft-kazuho-ea… Kazuho Oku
- Re: Fwd: New Version Notification for draft-kazuh… Julian Reschke
- Re: New Version Notification for draft-kazuho-ear… Cory Benfield
- Re: New Version Notification for draft-kazuho-ear… Julian Reschke
- Re: New Version Notification for draft-kazuho-ear… Kazuho Oku
- Re: New Version Notification for draft-kazuho-ear… Julian Reschke
- Re: New Version Notification for draft-kazuho-ear… Kazuho Oku
- Re: New Version Notification for draft-kazuho-ear… Julian Reschke
- Re: New Version Notification for draft-kazuho-ear… Cory Benfield
- Re: New Version Notification for draft-kazuho-ear… Tatsuhiro Tsujikawa
- RE: New Version Notification for draft-kazuho-ear… Mike Bishop
- Re: New Version Notification for draft-kazuho-ear… Stefan Eissing
- Re: New Version Notification for draft-kazuho-ear… Cory Benfield
- RE: New Version Notification for draft-kazuho-ear… Mike Bishop
- Re: New Version Notification for draft-kazuho-ear… Roy T. Fielding
- Re: New Version Notification for draft-kazuho-ear… Kazuho Oku
- Re: New Version Notification for draft-kazuho-ear… Cory Benfield
- Re: New Version Notification for draft-kazuho-ear… Kazuho Oku
- Re: New Version Notification for draft-kazuho-ear… Patrick McManus
- Re: New Version Notification for draft-kazuho-ear… Werner Baumann
- Re: New Version Notification for draft-kazuho-ear… Cory Benfield
- RE: New Version Notification for draft-kazuho-ear… Mike Bishop
- Re: New Version Notification for draft-kazuho-ear… Werner Baumann
- Re: New Version Notification for draft-kazuho-ear… Roy T. Fielding
- Re: New Version Notification for draft-kazuho-ear… Kazuho Oku
- Re: New Version Notification for draft-kazuho-ear… Willy Tarreau
- Re: New Version Notification for draft-kazuho-ear… Cory Benfield
- Re: New Version Notification for draft-kazuho-ear… Andy Green
- Re: New Version Notification for draft-kazuho-ear… Werner Baumann
- Re: New Version Notification for draft-kazuho-ear… Cory Benfield
- Re: New Version Notification for draft-kazuho-ear… Tatsuhiro Tsujikawa
- Re: New Version Notification for draft-kazuho-ear… Stefan Eissing
- RE: New Version Notification for draft-kazuho-ear… Mike Bishop
- Re: New Version Notification for draft-kazuho-ear… Roy T. Fielding
- Re: New Version Notification for draft-kazuho-ear… Mark Nottingham
- Re: New Version Notification for draft-kazuho-ear… Martin Thomson
- Re: New Version Notification for draft-kazuho-ear… Kazuho Oku
- RE: New Version Notification for draft-kazuho-ear… Mike Bishop
- Re: New Version Notification for draft-kazuho-ear… Mark Nottingham
- Re: New Version Notification for draft-kazuho-ear… Julian Reschke
- Re: New Version Notification for draft-kazuho-ear… Julian Reschke
- Re: New Version Notification for draft-kazuho-ear… Julian Reschke
- Re: New Version Notification for draft-kazuho-ear… Alex Rousskov
- Re: New Version Notification for draft-kazuho-ear… Julian Reschke
- Re: New Version Notification for draft-kazuho-ear… Alex Rousskov
- Re: New Version Notification for draft-kazuho-ear… Kazuho Oku
- Re: New Version Notification for draft-kazuho-ear… Kari Hurtta
- Re: New Version Notification for draft-kazuho-ear… Julian Reschke
- Re: New Version Notification for draft-kazuho-ear… Kazuho Oku
- Re: New Version Notification for draft-kazuho-ear… Cory Benfield
- Re: New Version Notification for draft-kazuho-ear… Kazuho Oku
- Re: New Version Notification for draft-kazuho-ear… Stefan Eissing