Subject: HTTP2 server-side stream creation

From: Ben Maurer <[email-masked]>
Date: Thu, 1 Aug 2019 14:00:28 -0700

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

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.

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.

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).

-b

---

From: Andy Green <[email-masked]>
Date: Fri, 02 Aug 2019 01:43:05 +0100

>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.

>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.

>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.

>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