Re: I-D for a YANG data model to configure HTTP clients and servers

Willy Tarreau <> Tue, 12 May 2020 03:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C0F103A09DD for <>; Mon, 11 May 2020 20:48:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.649
X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id O-0_n4Ibcfhe for <>; Mon, 11 May 2020 20:48:11 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2BB683A09B1 for <>; Mon, 11 May 2020 20:48:10 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1jYLqs-0003Tr-Db for; Tue, 12 May 2020 03:45:06 +0000
Resent-Date: Tue, 12 May 2020 03:45:06 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jYLqq-0003Sj-RT for; Tue, 12 May 2020 03:45:04 +0000
Received: from ([] by with esmtp (Exim 4.92) (envelope-from <>) id 1jYLqo-00056s-QO for; Tue, 12 May 2020 03:45:04 +0000
Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id 04C3ifZZ004658; Tue, 12 May 2020 05:44:41 +0200
Date: Tue, 12 May 2020 05:44:41 +0200
From: Willy Tarreau <>
To: Kent Watsen <>
Cc: Mark Nottingham <>, 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)
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-7.9
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: 1jYLqo-00056s-QO 082828a75b28efd0eb17849a96f8d4ad
Subject: Re: I-D for a YANG data model to configure HTTP clients and servers
Archived-At: <>
X-Mailing-List: <> archive/latest/37597
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Hi Kent,

On Mon, May 11, 2020 at 06:57:23PM +0000, Kent Watsen wrote:
> > Regarding the http-server-grouping - I'm not sure I understand why it's
> > important to configure the version that the server supports. Wouldn't a
> > server just support all of the versions it implements?
> Maybe.  But my understanding is that older/newer HTTP versions are purposely
> disabled sometimes for application-level compatibility reasons.  By
> "application", it may not necessarily be a standard web content server (i.e.,
> it might be an application that uses a REST-based API).

As a server-side reverse-proxy developer, I don't think I've ever heard
of a single case where an application required not to use a certain
version due to compatibility issue. Furthermore, applications designed
to work over HTTP/1.1 work pretty fine when the reverse-proxy speaks h2
with the client, and the application doesn't even know, so I'd say this
is totally transparent to the application. The only known interoperability
situation we've found is some rare servers still matching some header
fields in a case-sensitive way, and failing to see them when these
headers come from h2. But this is so rare that a year ago we've switched
everything to lowercase (even HTTP/1) and received extremely few issue
reports (probably a handful among tens to hundreds of thousands of

> FWIW, the NGINX server configuration file has an "http2" flag in its "listen"
> directive, and Apache's "Protocols" directive takes values like "h2" and
> "http/1.1".    To be fair, these directives may only exist to introduce
> support for new protocol versions (e.g., HTTP/2) in a backwards-compatible
> manner. 

That's it, and also because the new protocols usually introduce new bugs
that you don't want to expose users to. In haproxy we used to require an
explicit declaration for the first two years, then we've simplified the
configuration and enabled h2 by default, then we recently got caught by a
vulnerability in our implementation, and figured it was so well integrated
that we couldn't disable it anymore! We may reintroduce a tunable for this
but quite frankly, disabling a standard protocol is similar to thinking
about explicitly disabling HTTP/1.1: nobody would find this wise nowadays.

Just my two cents,