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

"Roy T. Fielding" <> Wed, 02 November 2016 22:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BC6191294CF for <>; Wed, 2 Nov 2016 15:54:37 -0700 (PDT)
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 (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SdQwoQkIu75t for <>; Wed, 2 Nov 2016 15:54:36 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 05235129486 for <>; Wed, 2 Nov 2016 15:54:35 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1c24Mi-0002lg-AW for; Wed, 02 Nov 2016 22:50:40 +0000
Resent-Date: Wed, 02 Nov 2016 22:50:40 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1c24Ma-0002ki-Gs for; Wed, 02 Nov 2016 22:50:32 +0000
Received: from ([] by with esmtps (TLS1.1:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from <>) id 1c24MU-0003CM-EM for; Wed, 02 Nov 2016 22:50:27 +0000
Received: from (localhost []) by (Postfix) with ESMTP id D7B7360000E03; Wed, 2 Nov 2016 15:50:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=content-type :mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to;; bh=4byF+Km9jFjvIRyInzRy07E1rtQ=; b=ZDKHRuD5nErWT1VfMMde3DiB8sUp LmVZxKwy8O75NcSlYaL/vxaiVRCeVHVceSuE3FXglTEZwnrSWY6uIzcSyiZbmOeo Pk+4n2+VRTBacnh2mvywLRRUmDnIW520NdVZZc44UvUC73rYgGkJ64FvrQtKIr3f kRXrM7/Lf58hsck=
Received: from [] ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: by (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" <>
In-Reply-To: <>
Date: Wed, 2 Nov 2016 15:50:02 -0700
Cc: Julian Reschke <>, Kazuho Oku <>, HTTP Working Group <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <>
To: Cory Benfield <>
X-Mailer: Apple Mail (2.2104)
Received-SPF: none client-ip=;;
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: 1c24MU-0003CM-EM 9e53fd2286ccc059a2b3efc3733b6c6c
Subject: Re: New Version Notification for draft-kazuho-early-hints-status-code-00.txt
Archived-At: <>
X-Mailing-List: <> archive/latest/32823
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

> On Nov 2, 2016, at 2:59 AM, Cory Benfield <> wrote:
>> On 1 Nov 2016, at 22:50, Roy T. Fielding <> wrote:
>>> On Nov 1, 2016, at 1:17 AM, Cory Benfield <> 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.