HTTP/2 implementation?
Has anyone started a HTTP/2 implementation in Haskell? I see there's a HPACK-08 Haskell implementation, but I haven't seen an actual HTTP/2 impl. I've been looking at starting some work on this and didn't want to replicate effort elsewhere that I may have missed. Cheers, Ben
2014-07-20 21:11 GMT+02:00 Ben Bangert
Has anyone started a HTTP/2 implementation in Haskell?
I see there's a HPACK-08 Haskell implementation, but I haven't seen an actual HTTP/2 impl. I've been looking at starting some work on this and didn't want to replicate effort elsewhere that I may have missed.
Certainly you have seen this package http://hackage.haskell.org/package/http2 ? That package was uploaded this month and there is a GitHub repository ; you could ask Kazu to join forces.
Hi,
I see there's a HPACK-08 Haskell implementation, but I haven't seen an actual HTTP/2 impl. I've been looking at starting some work on this and didn't want to replicate effort elsewhere that I may have missed.
Certainly you have seen this package http://hackage.haskell.org/package/http2 ?
This package implements HPACK only at this moment. I'm planning to implement HTTP/2 itself soon and integrate it into Warp. HTTP/2 is at the stage of IETF working group last call. The specs are being dynamically changed. For instance, it is just decided to remove referense set from HPACK finally. --Kazu
On Jul 22, 2014, at 12:19 AM, Kazu Yamamoto (山本和彦)
This package implements HPACK only at this moment. I'm planning to implement HTTP/2 itself soon and integrate it into Warp.
HTTP/2 is at the stage of IETF working group last call. The specs are being dynamically changed. For instance, it is just decided to remove referense set from HPACK finally.
I've forked your HTTP/2 package and implemented the HTTP/2 frame parsers along with some basic checks using draft14. While having Warp support it would definitely help, I'm actually planning on implementing a complete HTTP/2 proxy (HTTP/2 from clients, consolidated down to multiple HTTP/2 connections to backend app servers). This type of work requires rather direct access to the entirety of the frame processing and stream handling aspects, while I'd imagine Warp would generally only expose a WAI interface. I'm a bit new to Haskell yet, so any thoughts or input would be greatly appreciated. Cheers, Ben
Hi Ben,
I've forked your HTTP/2 package and implemented the HTTP/2 frame parsers along with some basic checks using draft14. While having Warp support it would definitely help, I'm actually planning on implementing a complete HTTP/2 proxy (HTTP/2 from clients, consolidated down to multiple HTTP/2 connections to backend app servers).
I would be nice if we can work together. 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.
This type of work requires rather direct access to the entirety of the frame processing and stream handling aspects, while I'd imagine Warp would generally only expose a WAI interface.
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. I think that web-devel@haskell.org is a proper place to discuss this. --Kazu
On Jul 25, 2014, at 6:45 PM, Kazu Yamamoto (山本和彦)
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: http://tools.ietf.org/html/draft-thomson-webpush-http2-00 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 that started it. The node-http2 API implemented a special command to enable this.
I think that web-devel@haskell.org is a proper place to discuss this.
Ah, thanks, I didn't know that list existed. :) Cheers, Ben
participants (3)
-
Ben Bangert -
Kazu Yamamoto -
Vo Minh Thu