Re: HTTP/2 Upgrade with content?

Amos Jeffries <squid3@treenet.co.nz> Fri, 13 March 2015 10:55 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 4F0D41A016A for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 13 Mar 2015 03:55:56 -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 W5Qc-Hq3BgIN for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 13 Mar 2015 03:55:46 -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 84EF81A00C7 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 13 Mar 2015 03:55:46 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1YWNDB-0001UG-9t for ietf-http-wg-dist@listhub.w3.org; Fri, 13 Mar 2015 10:53:01 +0000
Resent-Date: Fri, 13 Mar 2015 10:53:01 +0000
Resent-Message-Id: <E1YWNDB-0001UG-9t@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.80) (envelope-from <squid3@treenet.co.nz>) id 1YWND1-0001TQ-3U for ietf-http-wg@listhub.w3.org; Fri, 13 Mar 2015 10:52:51 +0000
Received: from 121-99-228-82.static.orcon.net.nz ([121.99.228.82] helo=treenet.co.nz) by maggie.w3.org with esmtp (Exim 4.72) (envelope-from <squid3@treenet.co.nz>) id 1YWNCz-0001f0-Nz for ietf-http-wg@w3.org; Fri, 13 Mar 2015 10:52:51 +0000
Received: from [192.168.20.22] (121-99-59-16.bng1.tvc.orcon.net.nz [121.99.59.16]) by treenet.co.nz (Postfix) with ESMTP id 50E5FE6EBD for <ietf-http-wg@w3.org>; Fri, 13 Mar 2015 23:52:18 +1300 (NZDT)
Message-ID: <5502C15B.7050705@treenet.co.nz>
Date: Fri, 13 Mar 2015 23:52:11 +1300
From: Amos Jeffries <squid3@treenet.co.nz>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: ietf-http-wg@w3.org
References: <CAH_y2NF3iwND1ttQDY98KC_u=OZj5aqEABmXHKObMgqPH1npLg@mail.gmail.com> <BL2PR03MB1323474B977B051738AD09187060@BL2PR03MB132.namprd03.prod.outlook.com> <CAH_y2NFV=Z7hqbtWTdiePRwUnhhRjiP8R_Ua7kmpZEkwXtxgEA@mail.gmail.com> <B5C01B7A-9215-4268-B189-E6281F425BF7@greenbytes.de> <alpine.DEB.2.11.1503130833190.13706@tvnag.unkk.fr> <B6F039A0-A58A-4980-9F52-F865BFFAAB0E@greenbytes.de> <alpine.DEB.2.11.1503131030150.13706@tvnag.unkk.fr> <A12A9A36-DB32-4D73-A6D2-26051A08BFA6@greenbytes.de>
In-Reply-To: <A12A9A36-DB32-4D73-A6D2-26051A08BFA6@greenbytes.de>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Received-SPF: pass client-ip=121.99.228.82; envelope-from=squid3@treenet.co.nz; helo=treenet.co.nz
X-W3C-Hub-Spam-Status: No, score=-3.4
X-W3C-Hub-Spam-Report: AWL=-3.417, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TVD_RCVD_IP=0.001
X-W3C-Scan-Sig: maggie.w3.org 1YWNCz-0001f0-Nz 6b87ed7c00a2ee3cc61e99ac8b4eb38c
X-Original-To: ietf-http-wg@w3.org
Subject: Re: HTTP/2 Upgrade with content?
Archived-At: <http://www.w3.org/mid/5502C15B.7050705@treenet.co.nz>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/28958
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 13/03/2015 11:03 p.m., Stefan Eissing wrote:
> 
> Thanks for the link to the discussion, very helpful. I might be able
> to create a request in the server that reads a HTTP/1.1 body and
> produces a HTTP/2 response. Since the body can be read without any flow
> control needing to happen, that might just work. But there may be
> monsters lurking here, for example the server omitting a RST_STREAM on 1
> while the http/1.1 body is still incomplete...

RST_STREAM in 1.1 terms is a TCP RST on the connection. The client
sending 1.1 needs to treat it that way while it is still sending the 1.1
message.

If the client has finished sending it can (should? will?) treat it as
2.0 RST_STREAM on a closed stream. Eventually the end of the payload
will arrive at the server and things are good.

A server sending RST_STREAM 1 before its finished reading that 1.1
payload is shooting itself in the foot potentially and needs to handle
both those possibilities. Implementation choice.

Amos