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

Werner Baumann <> Wed, 02 November 2016 20:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 58871129972 for <>; Wed, 2 Nov 2016 13:52:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.898
X-Spam-Status: No, score=-7.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XvN_da5EN15j for <>; Wed, 2 Nov 2016 13:51:58 -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 C121912996B for <>; Wed, 2 Nov 2016 13:51:58 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1c22Re-0001LN-Em for; Wed, 02 Nov 2016 20:47:38 +0000
Resent-Date: Wed, 02 Nov 2016 20:47:38 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1c22RZ-0001KH-8Q for; Wed, 02 Nov 2016 20:47:33 +0000
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <>) id 1c22RS-0006tr-HC for; Wed, 02 Nov 2016 20:47:28 +0000
Received: from ginster ([]) by (mreue005) with ESMTPSA (Nemesis) id 0LqHEi-1cWxLF31JA-00dpT1 for <>; Wed, 02 Nov 2016 21:46:57 +0100
Date: Wed, 2 Nov 2016 21:46:48 +0100
From: Werner Baumann <>
Message-ID: <20161102214648.130375fd@ginster>
X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K0:95Q11RT2oNO0ku5QZOFnzsm4SxTnlvyMMDv4Jhy9tWyMwYcffVo gvCzRcK9V0wU/rmOKJ1e9KLjL75zx41bxXHtuDpcJxdArDb83FzZrFdidnP35Zt3PGrwqrz 5WG+oVoKVNinfZ+JMgwVfFf5m4yq3f3uIa+0QhyYTpBeEQrmr7GzjaLijjPQuDHvTo46DC7 97g88SKrMvPHhVZR//5Lw==
X-UI-Out-Filterresults: notjunk:1;V01:K0:RvdVK8rHq20=:0YSh9ITMCejVXDMlPzbM3h X66wY5Q0vVLYajjBjdPhGMjcJEBiqIFuF6stJn+WC8MMqx5DI4WU9maqMws146F5gx/BSB1a4 Hyvp3gmCUXJt/n8tZmGvWTFpcYGCBqrNCltwS5IiCMQrAEgdkPYabSkXyvZ58M5II6tYj5+9S fftlj2LcN0rWBbJ3xCttlPmScYmcagV5LxpMaUxtPx6bvLjHsAYfvOWBgPMSMG16rb7MKIMtR 1J0D9h0R1DC0fcbgw9AwedNimsiGcWIMmTJ+l3wEarpFD1c2OEaBFdY2ApaXw6XGZt1DhkLcK XqkTiGaSqPyw9yrMGVUj/bv+l9K1PbBZ9HyOAvTQzmS+YOZqI9n1usofQC41mc2LVrCW3lbbD jbIGu9QamfP5JrtRWAHolEbsuiNHyHnFLqm1zyN4FYH4VCIPc0AqGFOpI1lBSADzuxGQ8sAnu y4dejC/JtQJprDcNk+zizSZTN9UN2uKIakaDlQ0KxBCj0o5j+W1xRJk0E6whUFRetlUGftyEq +Z4umrf9LtBvBX8apKt9sxmws8Xx73Mce7srb+KnFukCnESnMXA4qH+4uQoa2G2J8uB0Z6OiK eNaaSt63RFKlhTZbfkkUBk4dtxrd2+lZHtykQq0RrjdLrt9TF8MPGetNQK1mZkTqlnTooBzBo bXKLvozebNT8EvkHRr9AbJpoz6b5QLzm6xAirUtQ2UU/P9CjTjUwsvGGuYggpOUEjHlfdR4jk MU/8tNuv3tLVR7Qm
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-4.9
X-W3C-Hub-Spam-Report: AWL=-1.458, BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1c22RS-0006tr-HC 7b2a6f88de63f0ce814c1e606bf2b9d1
Subject: Re: New Version Notification for draft-kazuho-early-hints-status-code-00.txt
Archived-At: <>
X-Mailing-List: <> archive/latest/32821
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Just wondering.

Cory Benfield wrote:
> All of this *excludes* the alarming reality of the many millions of
> embedded HTTP/1.1 stacks which are implementing a protocol that is at
> best a second cousin to the one specified in RFCs 7230+.
> ...
> What that means is that the user-agent field will not be used to flag
> non-compliant implementations, it will be used to flag *compliant*
> ones, as there are vastly more of the former than the latter. That
> means that Chrome, Safari, Firefox, Opera (maybe), curl, and wget
> will all get a pass, and everyone else will be “guilty until proven
> innocent”. That means that we are rolling out a feature that is
> expressly a "browsers-only” feature if we deploy it in this way.

Now reading the rationale of the draft:
> Most if not all of the web pages processed by a web browser contain
> links to external resources that need to be fetched prior to
> rendering the documents.  Therefore, it is beneficial to send such
> links as early as possible in order to minimize the time spent until
> the browser becomes possible to render the document.  Link header of
> type "preload" ([Preload]) can be used to indicate such links within
> the response headers of an HTTP response.

Isn't this features mainly intended for the WWW and browsers and
whitelisting these would meet the goal of this draft? What other use
cases would want to benefit from this? Embedded HTTP/1.1 stacks?