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

Willy Tarreau <w@1wt.eu> Tue, 12 May 2020 03:48 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0F103A09DD for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 11 May 2020 20:48:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.649
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O-0_n4Ibcfhe for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 11 May 2020 20:48:11 -0700 (PDT)
Received: from lyra.w3.org (lyra.w3.org [128.30.52.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BB683A09B1 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 11 May 2020 20:48:10 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1jYLqs-0003Tr-Db for ietf-http-wg-dist@listhub.w3.org; Tue, 12 May 2020 03:45:06 +0000
Resent-Date: Tue, 12 May 2020 03:45:06 +0000
Resent-Message-Id: <E1jYLqs-0003Tr-Db@lyra.w3.org>
Received: from titan.w3.org ([128.30.52.76]) by lyra.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <w@1wt.eu>) id 1jYLqq-0003Sj-RT for ietf-http-wg@listhub.w3.org; Tue, 12 May 2020 03:45:04 +0000
Received: from wtarreau.pck.nerim.net ([62.212.114.60] helo=1wt.eu) by titan.w3.org with esmtp (Exim 4.92) (envelope-from <w@1wt.eu>) id 1jYLqo-00056s-QO for ietf-http-wg@w3.org; 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 <w@1wt.eu>
To: Kent Watsen <kent+ietf@watsen.net>
Cc: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>, "netconf-chairs@ietf.org" <netconf-chairs@ietf.org>
Message-ID: <20200512034441.GC4623@1wt.eu>
References: <01000171e5dd76ed-e0bb6d02-faa5-4672-93ab-74bc96ae9775-000000@email.amazonses.com> <CC4173EC-67BB-4652-885E-4C50564CB05A@mnot.net> <01000171eaff2503-d978e760-f03b-416b-9208-f9a95d1ecadb-000000@email.amazonses.com> <41183D9D-6287-416D-B160-F67E0B40916C@mnot.net> <0100017205194aed-7b540ec1-10ac-4d1e-b66b-682f321c3e99-000000@email.amazonses.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <0100017205194aed-7b540ec1-10ac-4d1e-b66b-682f321c3e99-000000@email.amazonses.com>
User-Agent: Mutt/1.6.1 (2016-04-27)
Received-SPF: pass client-ip=62.212.114.60; envelope-from=w@1wt.eu; helo=1wt.eu
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: titan.w3.org 1jYLqo-00056s-QO 082828a75b28efd0eb17849a96f8d4ad
X-Original-To: ietf-http-wg@w3.org
Subject: Re: I-D for a YANG data model to configure HTTP clients and servers
Archived-At: <https://www.w3.org/mid/20200512034441.GC4623@1wt.eu>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37597
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=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
deployments).

> 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,
Willy