Re: [secdir] Secdir last call review of draft-ietf-httpbis-early-hints-03

Stefan Eissing <> Fri, 07 July 2017 11:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 971B112EA7C; Fri, 7 Jul 2017 04:44:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key) header.b=FK0WGOGU; dkim=pass (1024-bit key) header.b=MQie0i0t
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9Jl7l4J-KUfb; Fri, 7 Jul 2017 04:44:23 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 17F6B129AD2; Fri, 7 Jul 2017 04:44:22 -0700 (PDT)
Received: by (Postfix, from userid 117) id 9FEA615A3BC2; Fri, 7 Jul 2017 13:44:20 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=mail; t=1499427860; bh=0mXG+i6vAshXeCMWrnXN6xMGBPErEjzMWIY/WYLK54w=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=FK0WGOGUzTLJiNzoqRpOB2wK6gBnNfFntSsDruDyceZc92Ww6FE7lFC7vl0Ukdrbt 1QgvlZZ55kq0OxU3ZwABUU/FRPqFhMREhK2KXJonrPuM20xCJj9g1jMwHsvK1m4OHw BIhfPhMUqunH/g5XgfwwJXUNlUkWBwipAyKuiuXs=
Received: from resistance.greenbytes.local (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by (Postfix) with ESMTPSA id 7342815A0221; Fri, 7 Jul 2017 13:44:19 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=mail; t=1499427859; bh=0mXG+i6vAshXeCMWrnXN6xMGBPErEjzMWIY/WYLK54w=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=MQie0i0taoJuO8AHwqH4QtSVOXq1oO0KNeiBaUttj8PPlqW+QRX6lH6e/eZg7ubT+ 5RBpMqFyR1PIi9Z7xNZUze+f7M10/GN1RckvM9S/IR3FICTflHyb9IcCVFJkNGlr7W HwyePHYRaNE9g/RL5nocMirsktNtyujtlfJUppIU=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Stefan Eissing <>
In-Reply-To: <>
Date: Fri, 7 Jul 2017 13:44:19 +0200
Cc: Willy Tarreau <>, Melinda Shore <>,,, IETF Discussion Mailing List <>, HTTP Working Group <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <>
To: Kazuho Oku <>
X-Mailer: Apple Mail (2.3273)
Archived-At: <>
Subject: Re: [secdir] Secdir last call review of draft-ietf-httpbis-early-hints-03
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 07 Jul 2017 11:44:25 -0000

I am not a big fan of "MUST not use protocol features if it is known not to work" advise.

> Am 07.07.2017 um 13:29 schrieb Kazuho Oku <>om>:
> 2017-07-07 18:23 GMT+09:00 Willy Tarreau <>eu>:
>> On Fri, Jul 07, 2017 at 05:54:41AM +0000, Melinda Shore wrote:
>>> On 7/6/17 8:40 PM, Kazuho Oku wrote:
>>>> Regarding the wording, I think it would be better to keep the tone
>>>> as-is, rather than suggesting implementers not to send an Early Hints
>>>> response over HTTP/1.1 depending on the client.
>>> Yeah, you don't want to discourage implementation.  I think
>>> the goal is to find some balance between not putting off
>>> implementers on the one hand, and having to deal with an
>>> embarrassing incident on the other.  I'd be more comfortable
>>> with language that's a bit stronger but it's not a huge
>>> issue, certainly not one that's an impediment to moving the
>>> document forward (particularly given that it's intended for
>>> publication as an experimental standard).
>> I'm just thinking about the fact that we're not even sure that any
>> HTTP/1.1 client doesn't support these informational responses,
>> because such clients can already make use of Expect: 100-continue
>> (so they know about 100), and if I remember well when designing the
>> 101 upgrade for WebSocket, which was reused for HTTP/2, some of
>> the difficulties we faced was that some clients/intermediaries
>> were consuming 101 as 1xx and waiting for a final response after
>> it.
>> Maybe the stronger wording should be oriented differently, such as
>> "Servers MUST not send 103 to HTTP/1.0 clients nor to any client
>> known not to support 1xx informational responses" ? This way it
>> leaves the possibility opened (ie rely on version and/or user-agent
>> or anything else once an exception is known).
> Considering that this is merely an advice on how to deal with broken
> clients, I think that we should not use the verbs defined in RFC 2119
> or state a strong prohibition.
> I also believe that a whitelist-based approach will be a better choice
> than a blacklist-based one, since 103 is an optimization that is
> beneficial when sent to a client that is known to make use of it. For
> most websites, whitelisting the major browsers that support it (once
> they do) or the CDN they use will be enough to get the most out of the
> status code.
>> Just my two cents,
>> Willy
> -- 
> Kazuho Oku