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

Kent Watsen <> Tue, 12 May 2020 20:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C094E3A0A90 for <>; Tue, 12 May 2020 13:06:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.647
X-Spam-Status: No, score=-2.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JvMWwAoYCvKB for <>; Tue, 12 May 2020 13:06:19 -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 699673A0A8F for <>; Tue, 12 May 2020 13:06:19 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1jYb6Q-0005JR-Mm for; Tue, 12 May 2020 20:02:11 +0000
Resent-Date: Tue, 12 May 2020 20:02:10 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jYb6P-0005If-5b for; Tue, 12 May 2020 20:02:09 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.92) (envelope-from <>) id 1jYb6N-00026W-Gf for; Tue, 12 May 2020 20:02:09 +0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono;; t=1589313716; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=dI4Juy0JCGg0k8EuAlAvPwjinehUg/ahHIYZvfadtt0=; b=Br06/R65kLZcqFWWaQ+EKTKKQzq0OQ8QSWLTCAqaq3ivUOB2b8zxyLMKIXc/wN1p weIKuM7RbxZ5EP0WuUefmelEPfERcRy9tpsQqk573VFBhR0S3+RpyBzUS4UiU82Ur3V rGwbWHGSDrJPy+5Z7vE6GoNYh1qKyO6HRkn3NAQo=
From: Kent Watsen <>
Message-ID: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_31A9C54C-EC70-481F-833A-55880889EBC7"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Tue, 12 May 2020 20:01:56 +0000
In-Reply-To: <>
Cc: Mark Nottingham <>, HTTP Working Group <>, "" <>
To: Willy Tarreau <>
References: <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3445.104.11)
X-SES-Outgoing: 2020.05.12-
Received-SPF: none client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-3.9
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1jYb6N-00026W-Gf 6593b7d18e637d28f838b7aab07bc928
Subject: Re: I-D for a YANG data model to configure HTTP clients and servers
Archived-At: <>
X-Mailing-List: <> archive/latest/37609
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

[Top-posting for convenience]

Hi Willy (and Mark!)

Based on yours and Mark's comments, I plan to remove the "protocol-version" field from the "ietf-http-server" YANG module.   As you say, it's seldomly used and, if ever needed, implementations of the "ietf-http-server" YANG module can "augment" (a YANG term) it back in.

Any other comments on draft-ietf-netconf-http-client-server?


> On May 11, 2020, at 11:44 PM, Willy Tarreau <> wrote:
> 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