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

Willy Tarreau <> Fri, 07 July 2017 09:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0D8A7126B6D; Fri, 7 Jul 2017 02:23:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 lqGdnzzFhqAd; Fri, 7 Jul 2017 02:23:25 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id DC1D41204DA; Fri, 7 Jul 2017 02:23:24 -0700 (PDT)
Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id v679NG3K027610; Fri, 7 Jul 2017 11:23:16 +0200
Date: Fri, 7 Jul 2017 11:23:16 +0200
From: Willy Tarreau <>
To: Melinda Shore <>
Cc: Kazuho Oku <>,,, IETF Discussion Mailing List <>, HTTP Working Group <>
Message-ID: <>
References: <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.6.1 (2016-04-27)
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 09:23:27 -0000

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

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).

Just my two cents,