Re: HTTP/2 Upgrade with content?

Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Fri, 13 March 2015 11:36 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ietf.org@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3831E1A036B for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 13 Mar 2015 04:36:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level:
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fux7zBEkDj58 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 13 Mar 2015 04:36:45 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 409E81A0367 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 13 Mar 2015 04:36:45 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1YWNps-0002qH-7i for ietf-http-wg-dist@listhub.w3.org; Fri, 13 Mar 2015 11:33:00 +0000
Resent-Date: Fri, 13 Mar 2015 11:33:00 +0000
Resent-Message-Id: <E1YWNps-0002qH-7i@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.80) (envelope-from <ilari.liusvaara@elisanet.fi>) id 1YWNpk-0002mC-1f for ietf-http-wg@listhub.w3.org; Fri, 13 Mar 2015 11:32:52 +0000
Received: from emh02.mail.saunalahti.fi ([62.142.5.108]) by maggie.w3.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <ilari.liusvaara@elisanet.fi>) id 1YWNpg-0003j2-0N for ietf-http-wg@w3.org; Fri, 13 Mar 2015 11:32:52 +0000
Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh02.mail.saunalahti.fi (Postfix) with ESMTP id 9B5DD8188A; Fri, 13 Mar 2015 13:32:23 +0200 (EET)
Date: Fri, 13 Mar 2015 13:32:23 +0200
From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
To: Amos Jeffries <squid3@treenet.co.nz>
Cc: ietf-http-wg@w3.org
Message-ID: <20150313113223.GA17124@LK-Perkele-VII>
References: <CAH_y2NF3iwND1ttQDY98KC_u=OZj5aqEABmXHKObMgqPH1npLg@mail.gmail.com> <7C1D0B76-0C00-4BF4-B2D2-EE0D311B75A0@redhat.com> <20150313094242.GA16018@LK-Perkele-VII> <5502BF3F.10004@treenet.co.nz>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <5502BF3F.10004@treenet.co.nz>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Received-SPF: pass client-ip=62.142.5.108; envelope-from=ilari.liusvaara@elisanet.fi; helo=emh02.mail.saunalahti.fi
X-W3C-Hub-Spam-Status: No, score=-3.1
X-W3C-Hub-Spam-Report: AWL=-3.119, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1YWNpg-0003j2-0N 17a10b7d9ac01171570f41ce80552f65
X-Original-To: ietf-http-wg@w3.org
Subject: Re: HTTP/2 Upgrade with content?
Archived-At: <http://www.w3.org/mid/20150313113223.GA17124@LK-Perkele-VII>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/28959
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

On Fri, Mar 13, 2015 at 11:43:11PM +1300, Amos Jeffries wrote:
> 
> No matter what you do the client has started sending a request specifid
> as having a payload in HTTP/1 format. It must finish that request,
> including the payload it promised, before any HTTP/2 may happen.
>  - if the client is smart it would use chunked encoding then abandon
> with 0-sized chunk on seeing the 30x. But that has other nasty problems,
> and servers cant rely on it.

Sigh.

And if the client did 100-Continue, starts sending and gets 307, there
is real risk that client has no choice but treat that as a fatal error
(will not retry, report failure back to user/caller).

> We have some prior painful experience applicable from NTLM vs POST
> requests. In all cases there is large bandwidth wastage and latency.
 
And in some cases, things just plain won't work...


-Ilari