Re: HTTP/2.0 section 2.4 "Starting HTTP/2.0 with Prior Knowledge"

Martin Thomson <> Wed, 17 April 2013 21:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 80AEA21F8CEE for <>; Wed, 17 Apr 2013 14:51:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.366
X-Spam-Status: No, score=-10.366 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wR00BQd2sMal for <>; Wed, 17 Apr 2013 14:51:22 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 627B421F8C08 for <>; Wed, 17 Apr 2013 14:51:21 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1USaFR-0006iv-Pj for; Wed, 17 Apr 2013 21:50:37 +0000
Resent-Date: Wed, 17 Apr 2013 21:50:37 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1USaFO-0006iA-QR for; Wed, 17 Apr 2013 21:50:34 +0000
Received: from ([]) by with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <>) id 1USaFN-00026a-JN for; Wed, 17 Apr 2013 21:50:34 +0000
Received: by with SMTP id l13so1519201wie.16 for <>; Wed, 17 Apr 2013 14:50:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=XZlhlCVkmdS6WIpWrjK2W2sdm8yB99/ty7c+NB9FIn0=; b=dMdN1KakhU847nrOYLwJXbckEVxt8SiU4cU4Fabwr/AmQJUEa3rP84f57+iGPaeUAU Onr/VMf9xKy0maHAlYTJLUgvZLcyJXHRCVNA2ApdjJERX0Wy4dwVAArKCkIWE4qJFYdp /VQqgNYJUi1hjbPggP9YBH31ITWHS9K0ORdO61mxZ1ozPEA/IWvAvmaaCuwwgFawGrkA uF4t7knNCYKugaROeXb1d6rPuLs9wi83t4l4PBPNF/et7itdTpkVno8j/slcxPItuGQ2 +UFIKHyKjyLYyT/zvZ48W/IJnVe4Cb3ZCQ69B+YMI3aKxHwd+zeUVpLyUsZdVFC2OQS6 i9dw==
MIME-Version: 1.0
X-Received: by with SMTP id cl1mr29144985wib.19.1366235407400; Wed, 17 Apr 2013 14:50:07 -0700 (PDT)
Received: by with HTTP; Wed, 17 Apr 2013 14:50:07 -0700 (PDT)
In-Reply-To: <>
References: <> <20130417113926.GA6710@LK-Perkele-VII> <> <>
Date: Wed, 17 Apr 2013 14:50:07 -0700
Message-ID: <>
From: Martin Thomson <>
To: Gabriel Montenegro <>
Cc: Ilari Liusvaara <>, "" <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.695, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: 1USaFN-00026a-JN 67db8d13af1ab8f7a878a3fe6af44c7b
Subject: Re: HTTP/2.0 section 2.4 "Starting HTTP/2.0 with Prior Knowledge"
Archived-At: <>
X-Mailing-List: <> archive/latest/17304
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

ALPN is going to add only a handful of bytes to the handshake.  It's
probably not going to cause the handshake to hit CWND limits (whatever
they are).  Larger certificates are more likely to do that.  So it
comes down to implementation cost - do you want to build the switch
and provide a way to actuate that switch?

Sure, some folks will build their own stack, but if they are at the
point of building their own stack, they aren't going to be overly
bothered by what some standard says if it turns out to be
inconvenient.   It's also likely that if they are sinking that much
engineering effort into it, then something like ALPN is probably a
flyspeck on the overall cost of the project.

On 17 April 2013 14:29, Gabriel Montenegro
<> wrote:
>> On 17 April 2013 04:39, Ilari Liusvaara <> wrote:
>> > On Wed, Apr 17, 2013 at 01:15:34AM +0000, Gabriel Montenegro wrote:
>> >> says:
>> >>
>> >> A client can learn that a particular server supports HTTP/2.0 by
>> >> other means. A client MAY immediately send HTTP/2.0 frames to a
>> >> server that is known to support HTTP/2.0. This only affects the resolution
>> of "http:"
>> >> URIs, servers supporting HTTP/2.0 are required to support protocol
>> >> negotiation in TLS<> [TLSNPN].
>> >>
>> >> The above fails to include "https:" URIs. It only mentions "http:" URIs.
>> >
>> > HTTPS is over TLS, so NPN (ALPN) is a requirement and will reveal if
>> > server supports HTTP2 without additional RTTs.
>> That was certainly the intent of the text.  However, I know that Gabriel is a
>> pretty smart guy and he has been paying attention.  If this isn't obvious, we
>> should definitely make it more so.
>>    This only affects the resolution of "http:" URIs, servers supporting HTTP/2.0
>> are required to
>>    support <xref target="TLSNPN">protocol negotiation in TLS</xref> for
>> "https:" URIs.
>> spec/commit/329d29e58a88628435ebd4678d3a3bd250155d47
>> (Note, the ALPN edit isn't in yet, the reference will need to change.)
> I was just wondering about the twitter apps scenario. Jeff Pinner indicated in Tokyo that for some scenarios (non-browser based apps using their specific servers), they forgo any TLS negotiation as the client simply knows that those particular servers talk HTTP/2.  This allows them to deploy with no dependency on anything but the usual TLS on their target platforms.
> It seems like a valid scenarios for "prior knowledge", but I'll let Jeff argue for that. I'm ok with requiring ALPN as the text currently implies (might help to make it explicit, yes).