Ben Bangert | 20 Jul 21:11 2014

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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Vo Minh Thu | 22 Jul 08:43 2014
Picon

Re: HTTP/2 implementation?

2014-07-20 21:11 GMT+02:00 Ben Bangert <ben <at> groovie.org>:
> 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.
Kazu Yamamoto | 22 Jul 09:19 2014
Picon

Re: HTTP/2 implementation?

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
Ben Bangert | 25 Jul 18:50 2014

Re: HTTP/2 implementation?

On Jul 22, 2014, at 12:19 AM, Kazu Yamamoto (山本和彦) <kazu <at> iij.ad.jp> wrote:

> 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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Kazu Yamamoto | 26 Jul 03:45 2014
Picon

Re: HTTP/2 implementation?

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 <at> haskell.org is a proper place to discuss this.

--Kazu
Ben Bangert | 26 Jul 06:00 2014

Re: HTTP/2 implementation?

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:
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
(Continue reading)


Gmane