Re: HTTP/2 implementation?
Ben Bangert <ben <at> groovie.org>
2014-07-26 04:00:31 GMT
On Jul 25, 2014, at 6:45 PM, Kazu Yamamoto (山本和彦) <kazu <at> iij.ad.jp> wrote:
> I would be nice if we can work together.
Absolutely! I definitely would prefer not to do this by myself. :)
> Mighty is a web server based on Warp. Currently, Mighty implements
> reverse proxy only. I'm planning to implement (forward) proxy and
> supports HTTP/2 in forward/reverse proxy.
Cool! From my evaluation, HTTP/2 proxy is going to be very very different from HTTP/1. In HTTP/1 every
request/response cycle is a separate TCP connection, while proxying in HTTP/2 to a single authority
server can multiplex (or use multiple multiplexed connections). A server that knows its being proxied to
will require very different settings (with much higher max concurrent streams) than a server expected to
handle public requests. I've been trying to determine the various requirements and config options needed.
I've also been considering the ability to 'replay' specific streams for fail-over. For example, if a
stream enter half-closed (remote), and nothing except perhaps push promise frames have been sent before
the server being proxied to dies, then the proxy can replay the headers needed to restore that state to a new app-server.
> I don't understand this problem yet due to the lack of experience. But
> if direct access is really necessary, you can propose to extend WAI.
In my case, after a client does a GET to a specific URI, I don't want to send any content. I want to keep the
connection open indefinitely and occasionally send PUSH PROMISE frames down to send messages, per the
new HTTP/2 PUSH spec:
This requires the ability in a request handler to send push promise frames and write the content for the
newly allocated streams, all without fully returning (and thus ending) the request/response stream