Re: HTTP2 server-side stream creation

Andy Green <andy@warmcat.com> Fri, 02 August 2019 00:47 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@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 (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C355120089 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 1 Aug 2019 17:47:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.201, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 Q0OdsxjFk1sl for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 1 Aug 2019 17:46:57 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [IPv6:2603:400a:ffff:804:801e:34:0:38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96FE9120073 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 1 Aug 2019 17:46:57 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1htLfY-00009b-Ij for ietf-http-wg-dist@listhub.w3.org; Fri, 02 Aug 2019 00:43:40 +0000
Resent-Date: Fri, 02 Aug 2019 00:43:40 +0000
Resent-Message-Id: <E1htLfY-00009b-Ij@frink.w3.org>
Received: from mimas.w3.org ([2603:400a:ffff:804:801e:34:0:4f]) by frink.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <andy@warmcat.com>) id 1htLfW-00008e-1A for ietf-http-wg@listhub.w3.org; Fri, 02 Aug 2019 00:43:38 +0000
Received: from warmcat.com ([46.105.127.147]) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <andy@warmcat.com>) id 1htLfU-00040R-7O for ietf-http-wg@w3.org; Fri, 02 Aug 2019 00:43:37 +0000
Date: Fri, 02 Aug 2019 01:43:05 +0100
User-Agent: K-9 Mail for Android
In-Reply-To: <CABgOVaLosPsxYcD=mAgd3EegYuJcHdWmkg5Tq-wcL-FvZs=mkQ@mail.gmail.com>
References: <CABgOVaLosPsxYcD=mAgd3EegYuJcHdWmkg5Tq-wcL-FvZs=mkQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
To: ietf-http-wg@w3.org, Ben Maurer <ben.maurer@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
From: Andy Green <andy@warmcat.com>
Message-ID: <090A960C-C3E1-4C2F-A936-A3482F71C38E@warmcat.com>
Received-SPF: pass client-ip=46.105.127.147; envelope-from=andy@warmcat.com; helo=warmcat.com
X-W3C-Hub-Spam-Status: No, score=-2.9
X-W3C-Hub-Spam-Report: AWL=1.002, BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1htLfU-00040R-7O 2db47fa43d1b0297f952d036628d4707
X-Original-To: ietf-http-wg@w3.org
Subject: Re: HTTP2 server-side stream creation
Archived-At: <https://www.w3.org/mid/090A960C-C3E1-4C2F-A936-A3482F71C38E@warmcat.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/36928
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: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>


On August 1, 2019 10:00:28 PM GMT+01:00, Ben Maurer <ben.maurer@gmail.com>; wrote:
>I've currently been looking at framing protocols that are appropriate
>to
>use in a peer to peer context where there is less of a distinction
>between
>client and server.
>
>This 4-year-old thread (which I selected an email in the middle of,
>that
>best represents the core of the question) discusses this type of
>approach.
>
>https://lists.w3.org/Archives/Public/ietf-http-wg/2015JulSep/0043.html

This has been an interesting subject for properly integrated ws-over-h2 and other things that just wanted opaque bidi streams-on-h2 too.

>Even though the spec says that "Clients send HTTP requests and receive
>HTTP
>responses" it also states that "Streams initiated by a client MUST use
>odd-numbered stream identifiers; those initiated by the server MUST use
>even-numbered stream identifiers". This implies that servers can in
>fact
>receive some sort of request and provide a response.

Maybe you meant "...clients can in fact receive...", it's not contraversial http servers receive requests and provide responses.  However I think they are talking about something more mundane there... PUSH_PROMISE streams where the server takes the initiative to respond to one incoming request also by opening additional even-numbered outgoing streams, each with their own HEADERS and still following http semantics.

>The thread seems to conclude that it's at least plausible to use HTTP2
>in
>this context.
>
>I attempted to find conversations since that time and couldn't find
>any.
>I'm curious if people are aware of any attempts to take this approach.

There are drafts flying around that take various approaches to trying to do this.  But I think none of them tried to just use DATA frames in both directions as much as you like... they introduced a SETTINGS to indicate they could handle bidi streams and usually a new frame type.

The difficulty they were circumventing is that in the standardized http implementation, DATA in a stream can either be request body or response body... those two things are serialized in http.  What existing servers or clients or intermediaries would do if they see more server DATA coming after they completed an http transaction, is a bit unpredictable.

>As a more concrete example, imagine one were creating a protocol like
>bittorrent (where both peers of a connection may initiate requests)
>would
>HTTP2 be an appropriate base layer for that protocol (allowing either
>peer
>to initiate a request a chunk of data in the case of bittorrent).

Take a look at rfc8441

https://tools.ietf.org/html/rfc8441

It shows one way to have an opt-in escape hatch out of the standardized http straitjacket.  Once you have the extended stream established, basically it provides an analogue of tcp connection state handling, either side can "send a FIN" / RST_STREAM etc.  Although RFC8441 is struggling implementation-wise, it seems quite workable in terms of surviving negotiating it through common intermediaries.

So AFAIK it should be workable.  A side effect would be in addition to spawning lots of h2 client connections, every peer would want to be an h2 server on tcp listening through NAT etc somehow... it's a bit different than udp.

-Andy

>
>-b