Re: Overhead of HTTP/2 Stream Management.

Each request adds a X-Req-ID to the headers as such:

GET / HTTP/1.1
X-Req-ID: random-unique-per-connection-id
other headers...

and the server responds...

HTTP/1.1 200 OK
X-Req-ID: request-id-here
X-Req-Target: /
other headers...

BUT, can also respond twice or more for server pushing:

HTTP/1.1 200 OK
X-Req-ID: -PUSH-
X-Req-Target: /logo.png
other headers...

The best part? If the server doesn't support it, it just responds as
normal, and the client interprets as normal.
I have a live implementation here: http://www.avuna.org/ OR
https://github.com/JavaProphet/Avuna-HTTPD

^^^ Excerpt from my email to Mark.

Once you have verified on both ends that they support this extension based
on the response, you can decide how to pair response->request, and the
request(which in my server is just a duplication of the original, removing
the ETag). Pushed resources may already be cached, as determined by the
server.
You can from the on also use HPACK if supported.

On Sun, Apr 5, 2015 at 4:49 PM, Willy Tarreau <w@1wt.eu> wrote:

> On Sun, Apr 05, 2015 at 01:08:28PM -0700, Max Bruce wrote:
> > The way HTTP works though, we don't need streams in such a conventional
> and
> > TCP-like way. We only need multiplexed packets to carry data over, so
> just
> > associate request/response pairs with an ID, and allow server push via
> > server sending the request path in a header too.
>
> Would you please describe what you call "packets" here and how you
> associate
> them with a request/response pair, and when a request/response message has
> begun, when it is finished, when it is certain that a "packet" from an
> aborted response is to be ignored, etc ? I think you'll come to a solution
> pretty similar to what was obtained here in the end.
>
> Willy
>
>