Hi Aleks, On Sat, Dec 31, 2016 at 12:08:41AM +0100, Aleksandar Lazic wrote: > Hi. > > I plan to try to implement http/2 into haproxy based on > https://github.com/nghttp2/nghttp2. > Before I start I must know if this the patches will be accepted. > > There are some pros > > Lib is already used in some applications. > It looks to me that the lib is able to handle event based traffic. > > also some cons > > Another dependency like pcre and ssl > > What's the opinion about my plan?
Well, I have already started working on H2. I'll start to publish a branch when I think that some parts I've put there have a chance to survive. The lib is perfect when you want to implement a new product because you just arrange your development around the lib. In our case most of the complexity comes from the fact that we have to modify haproxy's internal architecture to support multiple streams per session, the rest is almost a detail in comparison. Just to give you an idea, in 1.6 we extracted the streams and the sessions, and we made the applet 100% autonomous so that they could interact between each other, in order to be mostly compatible with what we need. And two weeks ago I wanted to start something as simple as directing streams negociating h2 in ALPN to a dedicated applet which would dump the frames it received and I thought it would just take one day to do this... and found that it was very difficult to get rid of the analysers that were automatically added when selecting the backend, so I had to change the way streams are initialized and to use new flags to say "we want to tunnel this stream to the applet without any new analyzer". And it took me one week of head scratching. All this just in order to say on stderr "hey look I received an h2 settings frame"! And that's just an example. So in the end while trying to plug onto an existing lib will solve a small part of the decoding, it will put some additional constraints regarding how you can modify what needs to be modified and/or how some data need to be presented, and that's much more complicated than implementing some h2 encoding/decoding. I already implemented an encoder 2 years ago just to experiment with various frame encodings to optimize the framing overhead, it's not that difficult. HPACK is not very difficult either, the huffman part probably being the biggest part. One difficult part to deal with in the case of H2 is the flow control. And again it's 100% specific to the product it's implemented in (haproxy here). I expect new surprises. And the most difficult we'll face will be the communications between two applets (H2 and H1) because we're recreating a proxy in fact and I'm afraid we'll have to reproduce all the stuff we have already had to deal with in process_stream(), so I'll try to stay soft on this. Regardless of this I'm making progress. I'd like to be able to handle a trivial "GET /" because it will make it easier to make some tests and improve the design. At least now we have nghttp, h2load and modern browsers to server as debugging clients, that's very helpful. Best regards, Willy
