Re: HTTP/2 plaintext upgrade

Kazuho Oku <> Fri, 27 January 2017 02:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2628B1293FD for <>; Thu, 26 Jan 2017 18:13:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.72
X-Spam-Status: No, score=-9.72 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.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DUjtEo2S4_6Z for <>; Thu, 26 Jan 2017 18:13:00 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F39921293F9 for <>; Thu, 26 Jan 2017 18:12:59 -0800 (PST)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1cWvzg-0003QP-Bc for; Fri, 27 Jan 2017 02:10:28 +0000
Resent-Date: Fri, 27 Jan 2017 02:10:28 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1cWvzd-0003Pd-88 for; Fri, 27 Jan 2017 02:10:25 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <>) id 1cWvz3-000189-GT for; Fri, 27 Jan 2017 02:10:20 +0000
Received: by with SMTP id j15so149587916oih.2 for <>; Thu, 26 Jan 2017 18:09:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=JNdZN1pnxnPIBqET48f2pz3HNlBFO9Ye6SA3oVnriY0=; b=CNR0K4v3L2aqCuN9E+tM232jT7f5nc9/p9Xa19byyb3QDpePGajX6fipuMy1DyK9N5 vGHSREkXKPeYJ7GM8x3AZbjc/iioUf+vTGsRy7X9E6PixHDaDLKb+zS7/YlF/NvyeTmi tV9efb2tnXZ4IScb6FAnYNskwEF92tUYpCJUpOCJdvM7DWJOx940JShnQN1oahjN0cQu tnOxfPK0rrvVgZBE1VzD7zxyq8BSSyBxwwkk7MMeZE7MUl+ex5dQ/IMfEck2SZxfP1MV 3HvOtiGMkOiqbLR8zZcGbyS/8Q4tH074xDbmVduEcQ249R7OMAl6cFAzBTtJSC882gt/ msrg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=JNdZN1pnxnPIBqET48f2pz3HNlBFO9Ye6SA3oVnriY0=; b=j96deUOXHEU3aFjP4CRMzXXoZuqs1TOV55MEQDcFQhgSPy2WrUG0JVeF9bZUDL+BzL 4fMs+1YOZsf+YfTsMiAgbzvGMWLiTN+Qhq7d2pyMi3cG88QLAU7XdTGrDd9epRhtriV0 tc9ycmPtjcuZIJq6q/R1BROl89UX5DbqqDI6aOba5Ut2o6rrNnT3fxr2XgraNVDa/SnN JM5v+lP/KtT7FQeK4UGtfdwrbz850Cu7vNJbK+Bqk3odcU45lqIVz8WvJWHNqZY3nIzz mCjRmJL3ij1/IteMlCeep8RfoVe8Z3c5eQ9p5vrnWk23paTMKsQAIWx7RdHyQI946KIG Qm9Q==
X-Gm-Message-State: AIkVDXI4oKQG+CPtHvONNx8cJ+nNC/bAjLxN6ixwhKwCgvSAQGaw9Ht8Jj62fwjHFSWpNSVCsMEmvs+1N10eDw==
X-Received: by with SMTP id g188mr3910294oia.185.1485482963065; Thu, 26 Jan 2017 18:09:23 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Thu, 26 Jan 2017 18:09:22 -0800 (PST)
In-Reply-To: <>
References: <>
From: Kazuho Oku <>
Date: Fri, 27 Jan 2017 11:09:22 +0900
Message-ID: <>
To: Cory Benfield <>
Cc: HTTP Working Group <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=0.5
X-W3C-Scan-Sig: 1cWvz3-000189-GT f7ce51a7eadfdf157c901a37fb20819e
Subject: Re: HTTP/2 plaintext upgrade
Archived-At: <>
X-Mailing-List: <> archive/latest/33386
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

2017-01-26 19:13 GMT+09:00 Cory Benfield <>uk>:
> I’ve got a question about HTTP/2 plaintext upgrade. RFC 7540 Section 3.2.1 says about the HTTP2-Settings header field:
>> The content of the HTTP2-Settings header field is the payload of a SETTINGS frame
> My initial implementation provided an entire SETTINGS frame in the HTTP2-Settings field, but a contributor has pointed out that the word “payload” may mean that only the body of the SETTINGS frame should be provided. It’s not really entirely clear to me in the text which I should do, and there are no textual examples either, so I’m genuinely not sure.
> Can I get an idea of what other implementers have done here?

I think the most direct answer to the quession would be the following
sentence in section 6.5.1.

   The payload of a SETTINGS frame consists of zero or more parameters,
   each consisting of an unsigned 16-bit setting identifier and an
   unsigned 32-bit value.

> Cory

Kazuho Oku