Re: HTTP/2 Upgrade with content?

Greg Wilkins <> Fri, 13 March 2015 22:21 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2F5391A89AD for <>; Fri, 13 Mar 2015 15:21:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.289
X-Spam-Status: No, score=-6.289 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QPYQPJ5A-wTD for <>; Fri, 13 Mar 2015 15:21:26 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5A7BD1A87C2 for <>; Fri, 13 Mar 2015 15:21:26 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1YWXv5-0006Ls-3F for; Fri, 13 Mar 2015 22:19:03 +0000
Resent-Date: Fri, 13 Mar 2015 22:19:03 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.80) (envelope-from <>) id 1YWXux-0006Bu-1Y for; Fri, 13 Mar 2015 22:18:55 +0000
Received: from ([]) by with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <>) id 1YWXuu-0007q5-Jz for; Fri, 13 Mar 2015 22:18:55 +0000
Received: by labjg1 with SMTP id jg1so231388lab.2 for <>; Fri, 13 Mar 2015 15:18:25 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=gz/Eba0TNJju6cYqwZ5nWYGzBJsVV660/xbzpXkjhmY=; b=PGGL9jp0jNUau8a8j6jlcAUqotw+lAB+Atl6BQx/lv81kS3Pb6qJMrU05fYp4vDYmm o7WmR7Vs+l3hZUIcca/wVaxwvO3t9ooaLRUCpjBM8Fj3glQL5SsmK5lfkJswdw4gcfXU ZpsenDlhnGCLdpi5Y57CbYftPf36AZ3uE8l7oI4vsTqE/jlNr65ZSU1scuzITNauqRyU nR2FhEC7XP7VkkoYMryjGmxIgnOYX/qfk+Hy4owES5gvKL+Jz5kSz4XbDlZtFAuhq/kk JDttDNhIazegAN2d42nMbv0UoktkEOJ/23UKfqiRyn7IZz8utlwOD85Cocu6Tv1OwbEe zI/g==
X-Gm-Message-State: ALoCoQmVkIySeKW6A5hbz46i7hG1G/RuU55B+KN7gkvqe+at8yt3YNwgefieGFRV+pgfL+chruaq
MIME-Version: 1.0
X-Received: by with SMTP id u3mr44861080lae.105.1426285105303; Fri, 13 Mar 2015 15:18:25 -0700 (PDT)
Received: by with HTTP; Fri, 13 Mar 2015 15:18:25 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <>
Date: Sat, 14 Mar 2015 09:18:25 +1100
Message-ID: <>
From: Greg Wilkins <>
To: Daniel Stenberg <>
Cc: "Jason T. Greene" <>, Stefan Eissing <>, Mike Bishop <>, HTTP Working Group <>
Content-Type: multipart/alternative; boundary="089e0149397a0cebe3051132e187"
Received-SPF: permerror client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-3.6
X-W3C-Hub-Spam-Report: AWL=-2.903, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001
X-W3C-Scan-Sig: 1YWXuu-0007q5-Jz a4ad21665ad09b1a4d98142c96f40662
Subject: Re: HTTP/2 Upgrade with content?
Archived-At: <>
X-Mailing-List: <> archive/latest/28968
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On 14 March 2015 at 01:04, Daniel Stenberg <> wrote:

> The issue with the curl usecase using upgrade is that all the upgrade work
>> is essentially wasted effort - as the bulk upload is done with HTTP/1.1,
> Yes, but... for example, what if that is the first operation out of
> several, and then once the first operation has updated to version 2 all the
> subsequent ones can continue using HTTP/2. And since the upgrade, it would
> just work with 1.1 servers as we all as 2 servers without the client having
> to know before-hand.
> And in the end, we usually allow curl to exercise every possible protocol
> option that is valid (and sometimes also a few that aren't valid) to allow
> people like readers of this list to test out and torture our own and others
> servers!


So if curl is asked to use http2 on multiple requests and the upgrade is
rejected on the first one, will it still proceed to the next request and if
so will it attempt the upgrade again?  Or is it going to fail the first
request because the desired protocol was not used?

If implemented like that, the multiple requests would work and the upgrade
would be done as soon as the server saw an acceptable request on which it
was prepared to do the update.

Users who wanted to insist that a specific POST was HTTP/2 could insert a
small request prior to ensure an acceptable upgrade takes place before the


Greg Wilkins <>  @  Webtide - *an Intalio subsidiary* HTTP, SPDY, Websocket server and client that scales  advice and support for jetty and cometd.