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

Mark Nottingham <> Tue, 12 May 2020 00:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A11F53A0DF0 for <>; Mon, 11 May 2020 17:45:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.748
X-Spam-Status: No, score=-2.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=DamVPTe9; dkim=pass (2048-bit key) header.b=e+u7ia81
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iI1VMcdU_Tr8 for <>; Mon, 11 May 2020 17:45:09 -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 37FC03A0DE9 for <>; Mon, 11 May 2020 17:45:09 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1jYJ0Q-000493-NB for; Tue, 12 May 2020 00:42:46 +0000
Resent-Date: Tue, 12 May 2020 00:42:46 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jYJ0O-00048I-Hq for; Tue, 12 May 2020 00:42:45 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jYJ0M-0005dP-O1 for; Tue, 12 May 2020 00:42:44 +0000
Received: from compute4.internal (compute4.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id A29D55C018E; Mon, 11 May 2020 20:42:29 -0400 (EDT)
Received: from mailfrontend2 ([]) by compute4.internal (MEProxy); Mon, 11 May 2020 20:42:29 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=S 2aF87IE04Wch5XunkIh+2RDgcy93S3rOws37EuxFsA=; b=DamVPTe97R25yBoIF E99fuzbv+m47zYhgJSepGhOsy8/ue43/wBGo4a/xUs48XrSdGsnKTAoUoqpA7Jja UcIJbChQZlZ5jPEhQ8IUU6W0S1snGsOFJ//LwVygI09UUrddIhawyExgdwkpzRkj C9kg5xoa03sY93BZtPOnb2wfmaaru5RVfLdKzcTGU9lcjDzh2OUhnYMboBuDW7nI ae0JX5PkGsV6iKkYC72Iayq4p2GdTubIWuwbG6bUmMXozITbof3GOf0e0avRv/sv TtY+v6Pjo3IvzSBozwxvbxYOGpqq3+KAW0PA94qLVt7CfZW6hauq2T//Z9GfzPrj OVH4w==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=S2aF87IE04Wch5XunkIh+2RDgcy93S3rOws37EuxF sA=; b=e+u7ia816/wb6YQPWtebTXU3iZGDpX7HWa3FjVfpisJ9MPKmltNElIOBd lngQKm4iU5btFBjUHfk1jvLLkOItePLIsOFWwBfP5LHx2xPh39xemkauvlyawTsY TDy7nLn0rAZZIxFTGJwl5U5CSixTOgo6wyh+XSYdGbgPb1FuB5Q0QTpNpRTpDm3S 9F5u/z1yQEel19rdk9lql6t4R5QyAUND0zkf8/r9kjWYzNvR54TsuViCK6MHKJ9l e+GR4iqozfcijy76vivRZqfjeLaJRXqNm1PeqGT1BcH9fKZpbpaN5cp/45FfC8U6 eE2jmobSWtt+wQPh3a2IW5+QMd45w==
X-ME-Sender: <xms:9PC5Xg0XfEltE5ao7dOmLCMwo4DveO506hAzUVeUmXsHb59ZMjMF2w>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrledugdefkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurheptggguffhjgffgffkfhfvofesthhqmh dthhdtvdenucfhrhhomhepofgrrhhkucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhn ohhtrdhnvghtqeenucggtffrrghtthgvrhhnpeeufefgiefhieeivedvgfeuhfdtiedvte euudelvedugefffedtiedvteffhedtgfenucffohhmrghinhepihgrnhgrrdhorhhgpdhh thhtphdvihhsrhgvghhishhtvghrvggurghshhdvrdihohhupdhmnhhothdrnhgvthenuc fkphepudduledrudejrdduheekrddvhedunecuvehluhhsthgvrhfuihiivgeptdenucfr rghrrghmpehmrghilhhfrhhomhepmhhnohhtsehmnhhothdrnhgvth
X-ME-Proxy: <xmx:9PC5XmPh8dOhXAu-o3oJYgo0KL71V6zT-mzxA4SFrThVEN3UG2Eajw> <xmx:9PC5XoQtmYTTm2CsJOxnViDu5Di6uXYibW7ber8rGgbUmDBtB-AE4w> <xmx:9PC5XpHnXnjKq4Y0EXjDj0sfcyqPf0HJgt5hFKF42BjqJu5JMqyHWA> <xmx:9fC5XvQZppT-On6Jz02-N8Z7y3Rs83X21xK14P0I-6iKiNTnLb6U9A>
Received: from ( []) by (Postfix) with ESMTPA id 68BD63066266; Mon, 11 May 2020 20:42:27 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Mark Nottingham <>
In-Reply-To: <>
Date: Tue, 12 May 2020 10:42:17 +1000
Cc: HTTP Working Group <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <>
To: Kent Watsen <>
X-Mailer: Apple Mail (2.3608.
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-9.8
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: 1jYJ0M-0005dP-O1 1f4be44f49b2d6068317c482a1d2fb1f
Subject: Re: I-D for a YANG data model to configure HTTP clients and servers
Archived-At: <>
X-Mailing-List: <> archive/latest/37596
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

> On 12 May 2020, at 4:57 am, 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).
> 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 said, the NETCONF WG isn't particularly beholden to limiting which HTTP versions a server supports.   If the HTTP WG doesn't think there's any value, then this ability likely should be removed!

I'm not against it per se, it just seems odd to me. 

>> Also, what are you using for the values of <protocol-version/>? "HTTP/2.0" is a valid version, but the specification that you're probably referring to is "http/2".
> According to the Section 4.3 in the I-D, the configurable values are "HTTP/1.0", "HTTP/1.1", and "HTTP/2.0".
>> These days, people tend to use ALPN protocol identifiers (which isn't without problem, but it is populated and widely understood): 
> I see "HTTP/1.0" and "HTTP/1.1" in that registry but not "HTTP/2.0".   Regardless, assuming we keep the ability to limit what protocol versions an HTTP server supports (see above discussion), we're happy to use the preferred values (though it seems like that might be the case already).

HTTP/2 is registered as "h2". You won't see HTTP/2.0 because the protocol is called "HTTP/2" - see RFC7540.


Mark Nottingham