Re: Experimental / broken HTTP/2 support
Hi, On Sun, Oct 15, 2017 at 11:54:10PM +0500, ??? wrote: > 2017-10-15 23:43 GMT+05:00 Willy Tarreau : > > > On Sun, Oct 15, 2017 at 07:16:51PM +0100, Aaron West wrote: > > > Hi Willy, > > > > > > Sorry to bother you, just a quick question if I may. > > > > > > Does support for QUIC imply we'd have rudimentary UDP support as well > > > or is it only going to support QUIC Protocol? > > > > It will be UDP for QUIC only. > > > > Do you have a *valid* use case for UDP proxying ? I'm asking because every > > time people ask for UDP support, it's for totally stupid reasons like NFS, > > for non-proxyable protocols, for protocols which are designed not to need > > a load balancer (eg: DNS) or for trivial stuff that is already naturally > > handled by their operating system (eg: done by LVS). That's why I'm > > interested in knowing about a valid case ;-) > > > dns is valid case, DNS is indeed the most common reason people ask for UDP support, and is the main reason people are using LVS in association with haproxy, as it's really trivial to set up. Also, certain DNS servers present different views depending on the source IP address of the request, which is one case where proxying the traffic can cause trouble. > openvpn comes to mind also, but need to look carefully > with switching between two or more servers. Openvpn is a good example of why *not* to proxy the traffic. Openvpn's performance is limited by the fact that packets are bounced between kernel, user and kernel again, something which will affect haproxy as well. So in short, if you need more than one openvpn server for performance reasons, haproxy will not be able to stand the load either due to the cost of doing this bounce. In practice you'll need as many haproxy servers as openvpn servers and you'll need something in front of haproxy, which makes no sense as the same component can already load-balance openvpn then. As a rule of thumb, count on 1 million packet per second exchanged between user and kernel, and roughly half of this if the packet has to be forwarded by userland. If you're doing this in a VM, divide it by 3. > I'd say, udp balancing is tricky (thre's no syn/ack), so let us stick to > QUIC Yep totally agreed. Cheers, Willy
Re: Experimental / broken HTTP/2 support
Hi all, Aleksandar Lazic wrote on 16.10.2017: [snipp] > I have also started to create a image based on the h2 branch > https://gitlab.com/aleks001/haproxy18-centos > It's not finished yet but when it's finished you can use the docker > image then from docker hub. > https://hub.docker.com/u/me2digital/ => haproxy18 The Docker image is now available. https://hub.docker.com/r/me2digital/haproxy18/ -- Best Regards Aleks
Re: Experimental / broken HTTP/2 support
On Mon, Oct 16, 2017 at 08:07:17PM +0200, Sander Klein wrote: > On 2017-10-16 14:19, Willy Tarreau wrote: > > On Mon, Oct 16, 2017 at 01:28:12PM +0200, Pavlos Parissis wrote: > > > I guess following step-by-step approach, 1st client side, it makes > > > sense as > > > it reduces the size of breakage:-) > > > > Yes but not only this. It's also the fact that the main benefits of H2 > > are > > on the client side, where the latency is the highest. > > Which is funny, because I wanted to use H2 to connect to the server side > since I have a situation (please, don't ask) where latency between HAProxy > and the server is quite high. Looking at this I thought using H2 to connect > to the server might be a dirty/easy 'fix' to get this more acceptable. I really want to have this done ultimately (ie: for 1.9). For various use cases like inter-DC communications, CDNs etc it makes sense. Willy
Re: Experimental / broken HTTP/2 support
On 2017-10-16 14:19, Willy Tarreau wrote: On Mon, Oct 16, 2017 at 01:28:12PM +0200, Pavlos Parissis wrote: I guess following step-by-step approach, 1st client side, it makes sense as it reduces the size of breakage:-) Yes but not only this. It's also the fact that the main benefits of H2 are on the client side, where the latency is the highest. Which is funny, because I wanted to use H2 to connect to the server side since I have a situation (please, don't ask) where latency between HAProxy and the server is quite high. Looking at this I thought using H2 to connect to the server might be a dirty/easy 'fix' to get this more acceptable. Since latency on the client side is also high-ish in this setup, using H2 on the client side might help as well. Regards, Sander 0x2E78FBE8.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: Experimental / broken HTTP/2 support
On Mon, Oct 16, 2017 at 01:28:12PM +0200, Pavlos Parissis wrote: > I guess following step-by-step approach, 1st client side, it makes sense as > it reduces the size of breakage:-) Yes but not only this. It's also the fact that the main benefits of H2 are on the client side, where the latency is the highest. > On a serious note, having support for QUIC is a huge advantage over other LB > softwares. > Having said, we don't really know if QUIC will be used as it requires changes > on several places, > Firewalls, bot/robot detection... It is interesting that Google decided to > switch protocol, from TCP > to UDP, as they decided to not use SCTP for HTTP2 as it required changes on > Firewall and etc. If we speak from the L4 protocol's perspective, it can indeed be seen as a TCP to UDP migration (and I'm sure that's what journalists will say once QUIC is completed). But from an implementation perspective in fact TCP is reimplemented on top of UDP. Why, would most people ask ? Because this way they can make all the clients immediately adapt to a new behaviour, to a new congestion control algorithm, to faster retransmits or larger initial windows without having to wait for a decade for the various underlying OS to adapt. It will just require pushing a new version of the browser which embeds the whole stack. But this will definitely come with a significant cost for intermediaries like haproxy to have to lose all the optimizations that were created both in software and hardware over the last 20 years, as basically we're back to dealing with dumb packets as it used to be the case with dumb network cards when you could saturate your CPU processing only 100 Mbps :-/ Cheers, Willy
Re: Experimental / broken HTTP/2 support
On 16/10/2017 11:27 πμ, Willy Tarreau wrote: > Hi Pavlos! > > On Mon, Oct 16, 2017 at 10:46:44AM +0200, Pavlos Parissis wrote: >>> Now after several failed attempts and with a lot of design sessions >>> with my coworkers, I've made a good progress on a totally different >>> approach which will later allow us to implement HTTP/2 on both sides, >>> as well as implement support for QUIC. I have not merged anything yet >>> because as I'm picking code from the first implementation, >> >> HTTP/2 on client and servers side, and at the same time QUIC support!! >> 1.8 version will be very hot release, thanks a lot for your hard work. > > Wait wait wait... I never said that! I'm speaking about *design*. Look, > "will later allow us". For 1.8, client-side only is expected. I don't know > how long it will take to support server-side, as there are some painful > shortcomings related to maintaining the server connections alive and being > able to share them (and my beloved coworkers working on threads will hate > me when they'll see that they'll have to deal with connections floating > between multiple threads due to the full mesh you can have between client > streams and servers streams). I guess following step-by-step approach, 1st client side, it makes sense as it reduces the size of breakage:-) On a serious note, having support for QUIC is a huge advantage over other LB softwares. Having said, we don't really know if QUIC will be used as it requires changes on several places, Firewalls, bot/robot detection... It is interesting that Google decided to switch protocol, from TCP to UDP, as they decided to not use SCTP for HTTP2 as it required changes on Firewall and etc. Cheers, Pavlos signature.asc Description: OpenPGP digital signature
Re: Experimental / broken HTTP/2 support
Hi Willy, Willy Tarreau wrote on 16.10.2017: > Hi Pavlos! > On Mon, Oct 16, 2017 at 10:46:44AM +0200, Pavlos Parissis wrote: >> > Now after several failed attempts and with a lot of design sessions >> > with my coworkers, I've made a good progress on a totally different >> > approach which will later allow us to implement HTTP/2 on both sides, >> > as well as implement support for QUIC. I have not merged anything yet >> > because as I'm picking code from the first implementation, >> >> HTTP/2 on client and servers side, and at the same time QUIC support!! >> 1.8 version will be very hot release, thanks a lot for your hard work. > Wait wait wait... I never said that! I'm speaking about *design*. ;-) you know small finger => whole hand ;-) > Look, > "will later allow us". For 1.8, client-side only is expected. I don't know > how long it will take to support server-side, as there are some painful > shortcomings related to maintaining the server connections alive and being > able to share them (and my beloved coworkers working on threads will hate > me when they'll see that they'll have to deal with connections floating > between multiple threads due to the full mesh you can have between client > streams and servers streams). Also before supporting server-side H2, we'll > have to turn the internal HTTP into "HTTP" and not "HTTP/1" anymore. This > means we won't have native HTTP/1 anymore inthe request buffer but more > something indexed, implying a rewrite of most of the HTTP processing. For > QUIC, *some* work was started already to try to spot what will be needed. > That's also what helped a lot abandon the dead end design I initially > started with. I have also started to create a image based on the h2 branch https://gitlab.com/aleks001/haproxy18-centos It's not finished yet but when it's finished you can use the docker image then from docker hub. https://hub.docker.com/u/me2digital/ => haproxy18 > cheers, > Willy -- Best Regards Aleks
Re: Experimental / broken HTTP/2 support
Hi Pavlos! On Mon, Oct 16, 2017 at 10:46:44AM +0200, Pavlos Parissis wrote: > > Now after several failed attempts and with a lot of design sessions > > with my coworkers, I've made a good progress on a totally different > > approach which will later allow us to implement HTTP/2 on both sides, > > as well as implement support for QUIC. I have not merged anything yet > > because as I'm picking code from the first implementation, > > HTTP/2 on client and servers side, and at the same time QUIC support!! > 1.8 version will be very hot release, thanks a lot for your hard work. Wait wait wait... I never said that! I'm speaking about *design*. Look, "will later allow us". For 1.8, client-side only is expected. I don't know how long it will take to support server-side, as there are some painful shortcomings related to maintaining the server connections alive and being able to share them (and my beloved coworkers working on threads will hate me when they'll see that they'll have to deal with connections floating between multiple threads due to the full mesh you can have between client streams and servers streams). Also before supporting server-side H2, we'll have to turn the internal HTTP into "HTTP" and not "HTTP/1" anymore. This means we won't have native HTTP/1 anymore inthe request buffer but more something indexed, implying a rewrite of most of the HTTP processing. For QUIC, *some* work was started already to try to spot what will be needed. That's also what helped a lot abandon the dead end design I initially started with. cheers, Willy
Re: Experimental / broken HTTP/2 support
On 15/10/2017 07:02 μμ, Willy Tarreau wrote: > Hi Sander, > > On Sun, Oct 15, 2017 at 04:27:15PM +0200, Sander Klein wrote: >> Hi, >> >> I haven't been paying much attention to the list lately, but I am wondering >> what the current status of http/2 support is in 1.8-(dev|snapshot). >> >> Is it in a usable-but-needs testing state? Or more like >> stay-away-because-it-kills-kittens state? > > The code I posted was not merged because it was experimental and I was > not satisfied with what the architecture would look like in the long > term. So I kept it handy "just in case" but didn't want to merge it. > > Now after several failed attempts and with a lot of design sessions > with my coworkers, I've made a good progress on a totally different > approach which will later allow us to implement HTTP/2 on both sides, > as well as implement support for QUIC. I have not merged anything yet > because as I'm picking code from the first implementation, HTTP/2 on client and servers side, and at the same time QUIC support!! 1.8 version will be very hot release, thanks a lot for your hard work. Cheers, Pavlos signature.asc Description: OpenPGP digital signature
Re: Experimental / broken HTTP/2 support
Hi Willy, On 2017-10-15 19:02, Willy Tarreau wrote: If everything goes well, the final rebased and cleaned up code should be available for a release candidate by the end of the month. Great, I will wait and see what you have available at the end of the month. I'm in no hurry, I just wanted to fiddle around. Stay tuned! I will! Greets, Sander 0x2E78FBE8.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
RE: Experimental / broken HTTP/2 support
I know this has gotten off topic, but PCoIP still a requirement for some Smartphones with View, +1 on the RDP 8+, The MS guys here give us heaps about this, Tim From: Gibson, Brian (IMS) [gibs...@imsweb.com] Sent: 16 October 2017 08:54 To: Aaron West; Willy Tarreau; HAProxy Subject: Re: Experimental / broken HTTP/2 support PCoIP comes to mind but blast seems to have replaced the need. Sent from Nine<http://www.9folders.com/> From: Aaron West Sent: Oct 15, 2017 3:11 PM To: Willy Tarreau; HAProxy Subject: Re: Experimental / broken HTTP/2 support Yes! RDP 8.0+ can use UDP traffic for a better connection, that's what I was thinking when I asked. Aaron West Loadbalancer.org Ltd. www.loadbalancer.org<http://www.loadbalancer.org> +1 888 867 9504 / +44 (0)330 380 1064 aa...@loadbalancer.org LEAVE A REVIEW | DEPLOYMENT GUIDES | BLOG Information in this e-mail may be confidential. It is intended only for the addressee(s) identified above. If you are not the addressee(s), or an employee or agent of the addressee(s), please note that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this e-mail in error, please notify the sender of the error.
Re: Experimental / broken HTTP/2 support
PCoIP comes to mind but blast seems to have replaced the need. Sent from Nine<http://www.9folders.com/> From: Aaron West Sent: Oct 15, 2017 3:11 PM To: Willy Tarreau; HAProxy Subject: Re: Experimental / broken HTTP/2 support Yes! RDP 8.0+ can use UDP traffic for a better connection, that's what I was thinking when I asked. Aaron West Loadbalancer.org Ltd. www.loadbalancer.org<http://www.loadbalancer.org> +1 888 867 9504 / +44 (0)330 380 1064 aa...@loadbalancer.org LEAVE A REVIEW | DEPLOYMENT GUIDES | BLOG Information in this e-mail may be confidential. It is intended only for the addressee(s) identified above. If you are not the addressee(s), or an employee or agent of the addressee(s), please note that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this e-mail in error, please notify the sender of the error.
Re: Experimental / broken HTTP/2 support
Yes! RDP 8.0+ can use UDP traffic for a better connection, that's what I was thinking when I asked. Aaron West Loadbalancer.org Ltd. www.loadbalancer.org +1 888 867 9504 / +44 (0)330 380 1064 aa...@loadbalancer.org LEAVE A REVIEW | DEPLOYMENT GUIDES | BLOG
Re: Experimental / broken HTTP/2 support
2017-10-15 23:43 GMT+05:00 Willy Tarreau : > On Sun, Oct 15, 2017 at 07:16:51PM +0100, Aaron West wrote: > > Hi Willy, > > > > Sorry to bother you, just a quick question if I may. > > > > Does support for QUIC imply we'd have rudimentary UDP support as well > > or is it only going to support QUIC Protocol? > > It will be UDP for QUIC only. > > Do you have a *valid* use case for UDP proxying ? I'm asking because every > time people ask for UDP support, it's for totally stupid reasons like NFS, > for non-proxyable protocols, for protocols which are designed not to need > a load balancer (eg: DNS) or for trivial stuff that is already naturally > handled by their operating system (eg: done by LVS). That's why I'm > interested in knowing about a valid case ;-) > dns is valid case, openvpn comes to mind also, but need to look carefully with switching between two or more servers. I'd say, udp balancing is tricky (thre's no syn/ack), so let us stick to QUIC > > Cheers, > Willy > >
Re: Experimental / broken HTTP/2 support
On Sun, Oct 15, 2017 at 07:16:51PM +0100, Aaron West wrote: > Hi Willy, > > Sorry to bother you, just a quick question if I may. > > Does support for QUIC imply we'd have rudimentary UDP support as well > or is it only going to support QUIC Protocol? It will be UDP for QUIC only. Do you have a *valid* use case for UDP proxying ? I'm asking because every time people ask for UDP support, it's for totally stupid reasons like NFS, for non-proxyable protocols, for protocols which are designed not to need a load balancer (eg: DNS) or for trivial stuff that is already naturally handled by their operating system (eg: done by LVS). That's why I'm interested in knowing about a valid case ;-) Cheers, Willy
Re: Experimental / broken HTTP/2 support
Hi Willy, Sorry to bother you, just a quick question if I may. Does support for QUIC imply we'd have rudimentary UDP support as well or is it only going to support QUIC Protocol? Aaron West Loadbalancer.org Ltd. www.loadbalancer.org +1 888 867 9504 / +44 (0)330 380 1064 aa...@loadbalancer.org LEAVE A REVIEW | DEPLOYMENT GUIDES | BLOG On 15 October 2017 at 18:02, Willy Tarreau wrote: > Hi Sander, > > On Sun, Oct 15, 2017 at 04:27:15PM +0200, Sander Klein wrote: >> Hi, >> >> I haven't been paying much attention to the list lately, but I am wondering >> what the current status of http/2 support is in 1.8-(dev|snapshot). >> >> Is it in a usable-but-needs testing state? Or more like >> stay-away-because-it-kills-kittens state? > > The code I posted was not merged because it was experimental and I was > not satisfied with what the architecture would look like in the long > term. So I kept it handy "just in case" but didn't want to merge it. > > Now after several failed attempts and with a lot of design sessions > with my coworkers, I've made a good progress on a totally different > approach which will later allow us to implement HTTP/2 on both sides, > as well as implement support for QUIC. I have not merged anything yet > because as I'm picking code from the first implementation, I regularly > encounter obstacles that I need to overcome and this leads to lots of > rebases to keep only bisectable code. The good point is that the code > that finally settles there is much better and contains much less hacks. > > If anyone is interested, I can publish a work-in-progress branch once > in a while, but for now the code in this branch only supports establishing > a connection and exchanging PING frames, so that's totally useless, which > is why I've not considered publishing it for now :-/ > > If everything goes well, the final rebased and cleaned up code should > be available for a release candidate by the end of the month. > > Stay tuned! > Willy >
Re: Experimental / broken HTTP/2 support
Hi Sander, On Sun, Oct 15, 2017 at 04:27:15PM +0200, Sander Klein wrote: > Hi, > > I haven't been paying much attention to the list lately, but I am wondering > what the current status of http/2 support is in 1.8-(dev|snapshot). > > Is it in a usable-but-needs testing state? Or more like > stay-away-because-it-kills-kittens state? The code I posted was not merged because it was experimental and I was not satisfied with what the architecture would look like in the long term. So I kept it handy "just in case" but didn't want to merge it. Now after several failed attempts and with a lot of design sessions with my coworkers, I've made a good progress on a totally different approach which will later allow us to implement HTTP/2 on both sides, as well as implement support for QUIC. I have not merged anything yet because as I'm picking code from the first implementation, I regularly encounter obstacles that I need to overcome and this leads to lots of rebases to keep only bisectable code. The good point is that the code that finally settles there is much better and contains much less hacks. If anyone is interested, I can publish a work-in-progress branch once in a while, but for now the code in this branch only supports establishing a connection and exchanging PING frames, so that's totally useless, which is why I've not considered publishing it for now :-/ If everything goes well, the final rebased and cleaned up code should be available for a release candidate by the end of the month. Stay tuned! Willy
Re: Experimental / broken HTTP/2 support
Hi, I haven't been paying much attention to the list lately, but I am wondering what the current status of http/2 support is in 1.8-(dev|snapshot). Is it in a usable-but-needs testing state? Or more like stay-away-because-it-kills-kittens state? Greets, Sander On 2017-08-18 16:49, Willy Tarreau wrote: ...well, I think everything is in the subject :-) Hi, by the way! I'm able to gateway http/2 traffic to www.haproxy.org and am getting logs to prove it : <134>Aug 18 15:56:51 haproxy[6566]: 127.0.0.1:43740 [18/Aug/2017:15:56:51.282] www~ www/ -1/13/0/-1/18 0 15 - - 1/1/0/0/0 0/0 http=1 "" <134>Aug 18 15:56:51 haproxy[6566]: 127.0.0.1:43746 [18/Aug/2017:15:56:51.302] www~ www/www 0/0/58/18/104 200 36300 - - CD-- 1/1/0/0/0 0/0 http=2 "GET / HTTP/1.1" <134>Aug 18 15:56:51 haproxy[6566]: 127.0.0.1:43746 [18/Aug/2017:15:56:51.415] www~ www/www 0/0/30/16/46 200 504 - - CD-- 1/1/0/0/0 0/0 http=2 "GET /size.js HTTP/1.1" <134>Aug 18 15:56:51 haproxy[6566]: 127.0.0.1:43746 [18/Aug/2017:15:56:51.466] www~ www/www 0/0/30/16/46 200 215 - - CD-- 12/12/11/11/0 0/0 http=2 "GET /size.css?1509x761 HTTP/1.1" <134>Aug 18 15:56:51 haproxy[6566]: 127.0.0.1:43746 [18/Aug/2017:15:56:51.491] www~ www/www 0/0/25/19/44 200 11198 - - CD-- 13/13/12/12/0 0/0 http=2 "GET /img/HAProxy_mini_pub.gif HTTP/1.1" <134>Aug 18 15:56:51 haproxy[6566]: 127.0.0.1:43746 [18/Aug/2017:15:56:51.492] www~ www/www 0/0/26/19/45 200 10443 - - CD-- 12/12/11/11/0 0/0 http=2 "GET /img/POM_mini_pub.gif HTTP/1.1" <134>Aug 18 15:56:51 haproxy[6566]: 127.0.0.1:43746 [18/Aug/2017:15:56:51.491] www~ www/www 0/0/28/19/47 200 7772 - - CD-- 11/11/10/10/0 0/0 http=2 "GET /img/ALOHA_mini_pub.gif HTTP/1.1" <134>Aug 18 15:56:51 haproxy[6566]: 127.0.0.1:43746 [18/Aug/2017:15:56:51.491] www~ www/www 0/0/29/22/51 200 1731 - - CD-- 10/10/9/9/0 0/0 http=2 "GET /img/btn_donate_SM_eur.gif HTTP/1.1" <134>Aug 18 15:56:51 haproxy[6566]: 127.0.0.1:43746 [18/Aug/2017:15:56:51.489] www~ www/www 0/0/29/24/53 200 3743 - - CD-- 9/9/8/8/0 0/0 http=2 "GET /img/logo-med.png HTTP/1.1" <134>Aug 18 15:56:51 haproxy[6566]: 127.0.0.1:43746 [18/Aug/2017:15:56:51.490] www~ www/www 0/0/29/23/52 200 1729 - - CD-- 8/8/7/7/0 0/0 http=2 "GET /img/btn_donate_SM_usd.gif HTTP/1.1" <134>Aug 18 15:56:51 haproxy[6566]: 127.0.0.1:43746 [18/Aug/2017:15:56:51.500] www~ www/www 0/0/26/18/44 200 3220 - - CD-- 7/7/6/6/0 0/0 http=2 "GET /img/haproxy-pmode.png HTTP/1.1" <134>Aug 18 15:56:51 haproxy[6566]: 127.0.0.1:43746 [18/Aug/2017:15:56:51.501] www~ www/www 0/0/26/18/44 200 2261 - - CD-- 6/6/5/5/0 0/0 http=2 "GET /img/pwby.gif HTTP/1.1" <134>Aug 18 15:56:51 haproxy[6566]: 127.0.0.1:43746 [18/Aug/2017:15:56:51.492] www~ www/www 0/0/26/31/58 200 19247 - - CD-- 5/5/4/4/0 0/0 http=2 "GET /img/World_IPv6_launch_banner_256.png HTTP/1.1" <134>Aug 18 15:56:51 haproxy[6566]: 127.0.0.1:43746 [18/Aug/2017:15:56:51.501] www~ www/www 0/0/25/24/49 200 396 - - CD-- 4/4/3/3/0 0/0 http=2 "GET /img/fr-off.png HTTP/1.1" <134>Aug 18 15:56:51 haproxy[6566]: 127.0.0.1:43746 [18/Aug/2017:15:56:51.501] www~ www/www 0/0/25/25/50 200 441 - - CD-- 3/3/2/2/0 0/0 http=2 "GET /img/en-off.png HTTP/1.1" <134>Aug 18 15:56:51 haproxy[6566]: 127.0.0.1:43746 [18/Aug/2017:15:56:51.514] www~ www/www 0/0/28/15/43 200 850 - - CD-- 2/2/1/1/0 0/0 http=2 "GET /img/ipv6nok.gif HTTP/1.1" <134>Aug 18 15:56:51 haproxy[6566]: 127.0.0.1:43746 [18/Aug/2017:15:56:51.525] www~ www/www 0/0/30/232/262 200 376 - - CD-- 1/1/0/0/0 0/0 http=2 "GET /img/ipv6back.png HTTP/1.1" <134>Aug 18 15:57:11 haproxy[6566]: 127.0.0.1:43746 [18/Aug/2017:15:56:51.300] www~ www/ -1/2/0/-1/20489 0 99131 - - cD-- 0/0/0/0/0 0/0 http=1 "" Look at the accept dates for the request, many of them are grouped, and there's this "http=2" field in the log indicating the on-wire format. But you'll also note all the "CD--" flags, the "" etc... The code more or less works. There are still some race conditions that will occasionally cause some requests to time out, especially if you build with "-DDEBUG_H2" which will emit a lot of printf. At least now with this code in place I could understand what is wrong and how it should be re-architected. There's still a lot of work to do in this area (there are some design notes and contradictory thoughts in doc/internals/h2.txt) but I thought that now that it's more or less working and that I'm going to break it and restart it from scratch differently, it could be nice that I share it for those curious who want to play with it a bit. DON'T PUT THIS IN PRODUCTION!!! There are a lot of unhandled errors, there are occasional leaks due to certain races not being caught etc. I'm not even going to put it myself in front of haproxy.org nor at home. It may start a fire in your house, attract UFOs full of man-eating aliens, or even make me temporarily smart, nothing you want to experience! The design for now consists in demultiplexing the H2 streams from the incoming connection, translating
Re: Experimental / broken HTTP/2 support
Thanks for the high praises! Let's also call out Dragan Dosen (he actually integrated mod_defender) and Christopher Faulet for the excellent groundwork on establishing SPOE as a basis for new additions. There will be more good things coming and we hope to continue to support such success stories as yours! Best regards, Andjelko On 08/18/2017 09:51 PM, Hemant Sabat @ Coscend wrote: > Congratulations, HAProxy community on implementing HTTP/2 support! > > Your reverse proxy load balancer has genuinely helped us build our company > from a "rank startup" that it was a few years ago into an "enterprise-grade > SLA-based startup". Your contributions have given us high-availability, > scalability, Web application security (through WAF), DDOS protection, > content-switching, reliability and performance. To name a few direct > contributors--people whose names popped up in our mailbox: > > Baptiste Assman's LetsEncrypt plugin and articles on reverse proxy, > Thierry Fournier's Web application firewall plugins (SPOE-ModSecurity, Mod > Defender), > Cyril Bonte's easy-to-use documentation, > Alaksandar Lazic's dockerfile and timely insights as well as > timely vectors from Bryan Talbot, Pavlos Parissis and Igor Cicimov, > Plus Willy Tarreau who started this load balancer proxy initiative. > > We will probably never know our indirect contributors...whose names did not > popup in our e-mails, but we utilized their contributions. > > Similar good Samaritans from a few other communities complemented your > contributions to help us scale this venture up. As our company grows > further, hope we can give something back to this and other communities. > > Thank you. > > Sincerely, > > Hemant K. Sabat > > Coscend Communications Solutions > www.Coscend.com > -- > Real-time, Interactive Video Collaboration, Tele-healthcare, Tele-education, > Telepresence Services, on the fly… > -- > CONFIDENTIALITY NOTICE: See 'Confidentiality Notice Regarding E-mail > Messages from Coscend Communications Solutions' posted at: > http://www.Coscend.com/Terms_and_Conditions.html > > -Original Message- > From: Willy Tarreau [mailto:w...@1wt.eu] > Sent: Friday, August 18, 2017 9:49 AM > To: haproxy@formilux.org > Subject: Experimental / broken HTTP/2 support > > ...well, I think everything is in the subject :-) > > Hi, by the way! > > I'm able to gateway http/2 traffic to www.haproxy.org and am getting logs to > prove it : > ><134>Aug 18 15:56:51 haproxy[6566]: 127.0.0.1:43740 > [18/Aug/2017:15:56:51.282] www~ www/ -1/13/0/-1/18 0 15 - - > 1/1/0/0/0 0/0 http=1 "" ><134>Aug 18 15:56:51 haproxy[6566]: 127.0.0.1:43746 > [18/Aug/2017:15:56:51.302] www~ www/www 0/0/58/18/104 200 36300 - - CD-- > 1/1/0/0/0 0/0 http=2 "GET / HTTP/1.1" ><134>Aug 18 15:56:51 haproxy[6566]: 127.0.0.1:43746 > [18/Aug/2017:15:56:51.415] www~ www/www 0/0/30/16/46 200 504 - - CD-- > 1/1/0/0/0 0/0 http=2 "GET /size.js HTTP/1.1" ><134>Aug 18 15:56:51 haproxy[6566]: 127.0.0.1:43746 > [18/Aug/2017:15:56:51.466] www~ www/www 0/0/30/16/46 200 215 - - CD-- > 12/12/11/11/0 0/0 http=2 "GET /size.css?1509x761 HTTP/1.1" ><134>Aug 18 15:56:51 haproxy[6566]: 127.0.0.1:43746 > [18/Aug/2017:15:56:51.491] www~ www/www 0/0/25/19/44 200 11198 - - CD-- > 13/13/12/12/0 0/0 http=2 "GET /img/HAProxy_mini_pub.gif HTTP/1.1" ><134>Aug 18 15:56:51 haproxy[6566]: 127.0.0.1:43746 > [18/Aug/2017:15:56:51.492] www~ www/www 0/0/26/19/45 200 10443 - - CD-- > 12/12/11/11/0 0/0 http=2 "GET /img/POM_mini_pub.gif HTTP/1.1" ><134>Aug 18 15:56:51 haproxy[6566]: 127.0.0.1:43746 > [18/Aug/2017:15:56:51.491] www~ www/www 0/0/28/19/47 200 7772 - - CD-- > 11/11/10/10/0 0/0 http=2 "GET /img/ALOHA_mini_pub.gif HTTP/1.1" ><134>Aug 18 15:56:51 haproxy[6566]: 127.0.0.1:43746 > [18/Aug/2017:15:56:51.491] www~ www/www 0/0/29/22/51 200 1731 - - CD-- > 10/10/9/9/0 0/0 http=2 "GET /img/btn_donate_SM_eur.gif HTTP/1.1" ><134>Aug 18 15:56:51 haproxy[6566]: 127.0.0.1:43746 > [18/Aug/2017:15:56:51.489] www~ www/www 0/0/29/24/53 200 3743 - - CD-- > 9/9/8/8/0 0/0 http=2 "GET /img/logo-med.png HTTP/1.1" ><134>Aug 18 15:56:51 haproxy[6566]: 127.0.0.1:43746 > [18/Aug/2017:15:56:51.490] www~ www/www 0/0/29/23/52 200 1729 - - CD-- > 8/8/7/7/0 0/0 http=2 "GET /img/btn_donate_SM_usd.gif HTTP/1.1" ><134>Aug 18 15:56:51 haproxy[6566]: 127.0.0.1:43746 &
Re: Experimental / broken HTTP/2 support
Hi Willy, Willy Tarreau wrote on 18.08.2017: > ...well, I think everything is in the subject :-) > Hi, by the way! > I'm able to gateway http/2 traffic to www.haproxy.org and am getting logs > to prove it : That's great ;-) ><134>Aug 18 15:56:51 haproxy[6566]: 127.0.0.1:43740 > [18/Aug/2017:15:56:51.282] www~ www/ -1/13/0/-1/18 0 15 - - > 1/1/0/0/0 0/0 http=1 "" ><134>Aug 18 15:56:51 haproxy[6566]: 127.0.0.1:43746 > [18/Aug/2017:15:56:51.302] www~ www/www 0/0/58/18/104 200 36300 - - > CD-- 1/1/0/0/0 0/0 http=2 "GET / HTTP/1.1" ><134>Aug 18 15:56:51 haproxy[6566]: 127.0.0.1:43746 > [18/Aug/2017:15:56:51.415] www~ www/www 0/0/30/16/46 200 504 - - CD-- > 1/1/0/0/0 0/0 http=2 "GET /size.js HTTP/1.1" ><134>Aug 18 15:56:51 haproxy[6566]: 127.0.0.1:43746 > [18/Aug/2017:15:56:51.466] www~ www/www 0/0/30/16/46 200 215 - - CD-- > 12/12/11/11/0 0/0 http=2 "GET /size.css?1509x761 HTTP/1.1" ><134>Aug 18 15:56:51 haproxy[6566]: 127.0.0.1:43746 > [18/Aug/2017:15:56:51.491] www~ www/www 0/0/25/19/44 200 11198 - - > CD-- 13/13/12/12/0 0/0 http=2 "GET /img/HAProxy_mini_pub.gif HTTP/1.1" ><134>Aug 18 15:56:51 haproxy[6566]: 127.0.0.1:43746 > [18/Aug/2017:15:56:51.492] www~ www/www 0/0/26/19/45 200 10443 - - > CD-- 12/12/11/11/0 0/0 http=2 "GET /img/POM_mini_pub.gif HTTP/1.1" ><134>Aug 18 15:56:51 haproxy[6566]: 127.0.0.1:43746 > [18/Aug/2017:15:56:51.491] www~ www/www 0/0/28/19/47 200 7772 - - CD-- > 11/11/10/10/0 0/0 http=2 "GET /img/ALOHA_mini_pub.gif HTTP/1.1" ><134>Aug 18 15:56:51 haproxy[6566]: 127.0.0.1:43746 > [18/Aug/2017:15:56:51.491] www~ www/www 0/0/29/22/51 200 1731 - - CD-- > 10/10/9/9/0 0/0 http=2 "GET /img/btn_donate_SM_eur.gif HTTP/1.1" ><134>Aug 18 15:56:51 haproxy[6566]: 127.0.0.1:43746 > [18/Aug/2017:15:56:51.489] www~ www/www 0/0/29/24/53 200 3743 - - CD-- > 9/9/8/8/0 0/0 http=2 "GET /img/logo-med.png HTTP/1.1" ><134>Aug 18 15:56:51 haproxy[6566]: 127.0.0.1:43746 > [18/Aug/2017:15:56:51.490] www~ www/www 0/0/29/23/52 200 1729 - - CD-- > 8/8/7/7/0 0/0 http=2 "GET /img/btn_donate_SM_usd.gif HTTP/1.1" ><134>Aug 18 15:56:51 haproxy[6566]: 127.0.0.1:43746 > [18/Aug/2017:15:56:51.500] www~ www/www 0/0/26/18/44 200 3220 - - CD-- > 7/7/6/6/0 0/0 http=2 "GET /img/haproxy-pmode.png HTTP/1.1" ><134>Aug 18 15:56:51 haproxy[6566]: 127.0.0.1:43746 > [18/Aug/2017:15:56:51.501] www~ www/www 0/0/26/18/44 200 2261 - - CD-- > 6/6/5/5/0 0/0 http=2 "GET /img/pwby.gif HTTP/1.1" ><134>Aug 18 15:56:51 haproxy[6566]: 127.0.0.1:43746 > [18/Aug/2017:15:56:51.492] www~ www/www 0/0/26/31/58 200 19247 - - > CD-- 5/5/4/4/0 0/0 http=2 "GET /img/World_IPv6_launch_banner_256.png HTTP/1.1" ><134>Aug 18 15:56:51 haproxy[6566]: 127.0.0.1:43746 > [18/Aug/2017:15:56:51.501] www~ www/www 0/0/25/24/49 200 396 - - CD-- > 4/4/3/3/0 0/0 http=2 "GET /img/fr-off.png HTTP/1.1" ><134>Aug 18 15:56:51 haproxy[6566]: 127.0.0.1:43746 > [18/Aug/2017:15:56:51.501] www~ www/www 0/0/25/25/50 200 441 - - CD-- > 3/3/2/2/0 0/0 http=2 "GET /img/en-off.png HTTP/1.1" ><134>Aug 18 15:56:51 haproxy[6566]: 127.0.0.1:43746 > [18/Aug/2017:15:56:51.514] www~ www/www 0/0/28/15/43 200 850 - - CD-- > 2/2/1/1/0 0/0 http=2 "GET /img/ipv6nok.gif HTTP/1.1" ><134>Aug 18 15:56:51 haproxy[6566]: 127.0.0.1:43746 > [18/Aug/2017:15:56:51.525] www~ www/www 0/0/30/232/262 200 376 - - > CD-- 1/1/0/0/0 0/0 http=2 "GET /img/ipv6back.png HTTP/1.1" ><134>Aug 18 15:57:11 haproxy[6566]: 127.0.0.1:43746 > [18/Aug/2017:15:56:51.300] www~ www/ -1/2/0/-1/20489 0 99131 - > - cD-- 0/0/0/0/0 0/0 http=1 "" > Look at the accept dates for the request, many of them are grouped, and > there's this "http=2" field in the log indicating the on-wire format. > But you'll also note all the "CD--" flags, the "" etc... > The code more or less works. There are still some race conditions that > will occasionally cause some requests to time out, especially if you > build with "-DDEBUG_H2" which will emit a lot of printf. > At least now with this code in place I could understand what is wrong > and how it should be re-architected. There's still a lot of work to do > in this area (there are some design notes and contradictory thoughts > in doc/internals/h2.txt) but I thought that now that it's more or less > working and that I'm going to break it and restart it from scratch > differently, it could be nice that I share it for those curious who > want to play with it a bit. > DON'T PUT THIS IN PRODUCTION!!! There are a lot of unhandled errors, > there are occasional leaks due to certain races not being caught etc. > I'm not even going to put it myself in front of haproxy.org nor at > home. It may start a fire in your house, attract UFOs full of man-eating > aliens, or even make me temporarily smart, nothing you want to experience! > The design for now consists in demultiplexing the H2 streams from > the incoming connection, translating them into H1 and processing H1 > requests just like before. That's why the logs still report "HTTP
RE: Experimental / broken HTTP/2 support
Congratulations, HAProxy community on implementing HTTP/2 support! Your reverse proxy load balancer has genuinely helped us build our company from a "rank startup" that it was a few years ago into an "enterprise-grade SLA-based startup". Your contributions have given us high-availability, scalability, Web application security (through WAF), DDOS protection, content-switching, reliability and performance. To name a few direct contributors--people whose names popped up in our mailbox: Baptiste Assman's LetsEncrypt plugin and articles on reverse proxy, Thierry Fournier's Web application firewall plugins (SPOE-ModSecurity, Mod Defender), Cyril Bonte's easy-to-use documentation, Alaksandar Lazic's dockerfile and timely insights as well as timely vectors from Bryan Talbot, Pavlos Parissis and Igor Cicimov, Plus Willy Tarreau who started this load balancer proxy initiative. We will probably never know our indirect contributors...whose names did not popup in our e-mails, but we utilized their contributions. Similar good Samaritans from a few other communities complemented your contributions to help us scale this venture up. As our company grows further, hope we can give something back to this and other communities. Thank you. Sincerely, Hemant K. Sabat Coscend Communications Solutions www.Coscend.com -- Real-time, Interactive Video Collaboration, Tele-healthcare, Tele-education, Telepresence Services, on the fly -- CONFIDENTIALITY NOTICE: See 'Confidentiality Notice Regarding E-mail Messages from Coscend Communications Solutions' posted at: http://www.Coscend.com/Terms_and_Conditions.html -Original Message- From: Willy Tarreau [mailto:w...@1wt.eu] Sent: Friday, August 18, 2017 9:49 AM To: haproxy@formilux.org Subject: Experimental / broken HTTP/2 support ...well, I think everything is in the subject :-) Hi, by the way! I'm able to gateway http/2 traffic to www.haproxy.org and am getting logs to prove it : <134>Aug 18 15:56:51 haproxy[6566]: 127.0.0.1:43740 [18/Aug/2017:15:56:51.282] www~ www/ -1/13/0/-1/18 0 15 - - 1/1/0/0/0 0/0 http=1 "" <134>Aug 18 15:56:51 haproxy[6566]: 127.0.0.1:43746 [18/Aug/2017:15:56:51.302] www~ www/www 0/0/58/18/104 200 36300 - - CD-- 1/1/0/0/0 0/0 http=2 "GET / HTTP/1.1" <134>Aug 18 15:56:51 haproxy[6566]: 127.0.0.1:43746 [18/Aug/2017:15:56:51.415] www~ www/www 0/0/30/16/46 200 504 - - CD-- 1/1/0/0/0 0/0 http=2 "GET /size.js HTTP/1.1" <134>Aug 18 15:56:51 haproxy[6566]: 127.0.0.1:43746 [18/Aug/2017:15:56:51.466] www~ www/www 0/0/30/16/46 200 215 - - CD-- 12/12/11/11/0 0/0 http=2 "GET /size.css?1509x761 HTTP/1.1" <134>Aug 18 15:56:51 haproxy[6566]: 127.0.0.1:43746 [18/Aug/2017:15:56:51.491] www~ www/www 0/0/25/19/44 200 11198 - - CD-- 13/13/12/12/0 0/0 http=2 "GET /img/HAProxy_mini_pub.gif HTTP/1.1" <134>Aug 18 15:56:51 haproxy[6566]: 127.0.0.1:43746 [18/Aug/2017:15:56:51.492] www~ www/www 0/0/26/19/45 200 10443 - - CD-- 12/12/11/11/0 0/0 http=2 "GET /img/POM_mini_pub.gif HTTP/1.1" <134>Aug 18 15:56:51 haproxy[6566]: 127.0.0.1:43746 [18/Aug/2017:15:56:51.491] www~ www/www 0/0/28/19/47 200 7772 - - CD-- 11/11/10/10/0 0/0 http=2 "GET /img/ALOHA_mini_pub.gif HTTP/1.1" <134>Aug 18 15:56:51 haproxy[6566]: 127.0.0.1:43746 [18/Aug/2017:15:56:51.491] www~ www/www 0/0/29/22/51 200 1731 - - CD-- 10/10/9/9/0 0/0 http=2 "GET /img/btn_donate_SM_eur.gif HTTP/1.1" <134>Aug 18 15:56:51 haproxy[6566]: 127.0.0.1:43746 [18/Aug/2017:15:56:51.489] www~ www/www 0/0/29/24/53 200 3743 - - CD-- 9/9/8/8/0 0/0 http=2 "GET /img/logo-med.png HTTP/1.1" <134>Aug 18 15:56:51 haproxy[6566]: 127.0.0.1:43746 [18/Aug/2017:15:56:51.490] www~ www/www 0/0/29/23/52 200 1729 - - CD-- 8/8/7/7/0 0/0 http=2 "GET /img/btn_donate_SM_usd.gif HTTP/1.1" <134>Aug 18 15:56:51 haproxy[6566]: 127.0.0.1:43746 [18/Aug/2017:15:56:51.500] www~ www/www 0/0/26/18/44 200 3220 - - CD-- 7/7/6/6/0 0/0 http=2 "GET /img/haproxy-pmode.png HTTP/1.1" <134>Aug 18 15:56:51 haproxy[6566]: 127.0.0.1:43746 [18/Aug/2017:15:56:51.501] www~ www/www 0/0/26/18/44 200 2261 - - CD-- 6/6/5/5/0 0/0 http=2 "GET /img/pwby.gif HTTP/1.1" <134>Aug 18 15:56:51 haproxy[6566]: 127.0.0.1:43746 [18/Aug/2017:15:56:51.492] www~ www/www 0/0/26/31/58 200 19247 - - CD-- 5/5/4/4/0 0/0 http=2 "GET /img/World_IPv6_launch_banner_256.png HTTP/1.1" <134>Aug 18 15:56:51 haproxy[6566]: 127.0.0.1:43746 [18/Aug/2017:15:56:51.501] www~ www/www 0/0/25/24/49 200 396 - - CD-- 4/4/3/3/0 0/0 http=2 "GET /img/fr-off.png HTTP/1.1" <134>Aug 18 15:56:51 haproxy[6566]: 127.0.0.1:43746 [18/Aug/2017:15:56:51.501] www~ www/ww
Experimental / broken HTTP/2 support
...well, I think everything is in the subject :-) Hi, by the way! I'm able to gateway http/2 traffic to www.haproxy.org and am getting logs to prove it : <134>Aug 18 15:56:51 haproxy[6566]: 127.0.0.1:43740 [18/Aug/2017:15:56:51.282] www~ www/ -1/13/0/-1/18 0 15 - - 1/1/0/0/0 0/0 http=1 "" <134>Aug 18 15:56:51 haproxy[6566]: 127.0.0.1:43746 [18/Aug/2017:15:56:51.302] www~ www/www 0/0/58/18/104 200 36300 - - CD-- 1/1/0/0/0 0/0 http=2 "GET / HTTP/1.1" <134>Aug 18 15:56:51 haproxy[6566]: 127.0.0.1:43746 [18/Aug/2017:15:56:51.415] www~ www/www 0/0/30/16/46 200 504 - - CD-- 1/1/0/0/0 0/0 http=2 "GET /size.js HTTP/1.1" <134>Aug 18 15:56:51 haproxy[6566]: 127.0.0.1:43746 [18/Aug/2017:15:56:51.466] www~ www/www 0/0/30/16/46 200 215 - - CD-- 12/12/11/11/0 0/0 http=2 "GET /size.css?1509x761 HTTP/1.1" <134>Aug 18 15:56:51 haproxy[6566]: 127.0.0.1:43746 [18/Aug/2017:15:56:51.491] www~ www/www 0/0/25/19/44 200 11198 - - CD-- 13/13/12/12/0 0/0 http=2 "GET /img/HAProxy_mini_pub.gif HTTP/1.1" <134>Aug 18 15:56:51 haproxy[6566]: 127.0.0.1:43746 [18/Aug/2017:15:56:51.492] www~ www/www 0/0/26/19/45 200 10443 - - CD-- 12/12/11/11/0 0/0 http=2 "GET /img/POM_mini_pub.gif HTTP/1.1" <134>Aug 18 15:56:51 haproxy[6566]: 127.0.0.1:43746 [18/Aug/2017:15:56:51.491] www~ www/www 0/0/28/19/47 200 7772 - - CD-- 11/11/10/10/0 0/0 http=2 "GET /img/ALOHA_mini_pub.gif HTTP/1.1" <134>Aug 18 15:56:51 haproxy[6566]: 127.0.0.1:43746 [18/Aug/2017:15:56:51.491] www~ www/www 0/0/29/22/51 200 1731 - - CD-- 10/10/9/9/0 0/0 http=2 "GET /img/btn_donate_SM_eur.gif HTTP/1.1" <134>Aug 18 15:56:51 haproxy[6566]: 127.0.0.1:43746 [18/Aug/2017:15:56:51.489] www~ www/www 0/0/29/24/53 200 3743 - - CD-- 9/9/8/8/0 0/0 http=2 "GET /img/logo-med.png HTTP/1.1" <134>Aug 18 15:56:51 haproxy[6566]: 127.0.0.1:43746 [18/Aug/2017:15:56:51.490] www~ www/www 0/0/29/23/52 200 1729 - - CD-- 8/8/7/7/0 0/0 http=2 "GET /img/btn_donate_SM_usd.gif HTTP/1.1" <134>Aug 18 15:56:51 haproxy[6566]: 127.0.0.1:43746 [18/Aug/2017:15:56:51.500] www~ www/www 0/0/26/18/44 200 3220 - - CD-- 7/7/6/6/0 0/0 http=2 "GET /img/haproxy-pmode.png HTTP/1.1" <134>Aug 18 15:56:51 haproxy[6566]: 127.0.0.1:43746 [18/Aug/2017:15:56:51.501] www~ www/www 0/0/26/18/44 200 2261 - - CD-- 6/6/5/5/0 0/0 http=2 "GET /img/pwby.gif HTTP/1.1" <134>Aug 18 15:56:51 haproxy[6566]: 127.0.0.1:43746 [18/Aug/2017:15:56:51.492] www~ www/www 0/0/26/31/58 200 19247 - - CD-- 5/5/4/4/0 0/0 http=2 "GET /img/World_IPv6_launch_banner_256.png HTTP/1.1" <134>Aug 18 15:56:51 haproxy[6566]: 127.0.0.1:43746 [18/Aug/2017:15:56:51.501] www~ www/www 0/0/25/24/49 200 396 - - CD-- 4/4/3/3/0 0/0 http=2 "GET /img/fr-off.png HTTP/1.1" <134>Aug 18 15:56:51 haproxy[6566]: 127.0.0.1:43746 [18/Aug/2017:15:56:51.501] www~ www/www 0/0/25/25/50 200 441 - - CD-- 3/3/2/2/0 0/0 http=2 "GET /img/en-off.png HTTP/1.1" <134>Aug 18 15:56:51 haproxy[6566]: 127.0.0.1:43746 [18/Aug/2017:15:56:51.514] www~ www/www 0/0/28/15/43 200 850 - - CD-- 2/2/1/1/0 0/0 http=2 "GET /img/ipv6nok.gif HTTP/1.1" <134>Aug 18 15:56:51 haproxy[6566]: 127.0.0.1:43746 [18/Aug/2017:15:56:51.525] www~ www/www 0/0/30/232/262 200 376 - - CD-- 1/1/0/0/0 0/0 http=2 "GET /img/ipv6back.png HTTP/1.1" <134>Aug 18 15:57:11 haproxy[6566]: 127.0.0.1:43746 [18/Aug/2017:15:56:51.300] www~ www/ -1/2/0/-1/20489 0 99131 - - cD-- 0/0/0/0/0 0/0 http=1 "" Look at the accept dates for the request, many of them are grouped, and there's this "http=2" field in the log indicating the on-wire format. But you'll also note all the "CD--" flags, the "" etc... The code more or less works. There are still some race conditions that will occasionally cause some requests to time out, especially if you build with "-DDEBUG_H2" which will emit a lot of printf. At least now with this code in place I could understand what is wrong and how it should be re-architected. There's still a lot of work to do in this area (there are some design notes and contradictory thoughts in doc/internals/h2.txt) but I thought that now that it's more or less working and that I'm going to break it and restart it from scratch differently, it could be nice that I share it for those curious who want to play with it a bit. DON'T PUT THIS IN PRODUCTION!!! There are a lot of unhandled errors, there are occasional leaks due to certain races not being caught etc. I'm not even going to put it myself in front of haproxy.org nor at home. It may start a fire in your house, attract UFOs full of man-eating aliens, or even make me temporarily smart, nothing you want to experience! The design for now consists in demultiplexing the H2 streams from the incoming connection, translating them into H1 and processing H1 requests just like before. That's why the logs still report "HTTP/1.1", it's what is presented into the version string. Among the things that are still limitations that could possibly be overcome before the 1.8 release, I can cite : - header field
