subject:"Experimental \/ broken HTTP\/2 support"

Re: Experimental / broken HTTP/2 support

2017-10-16 Thread Willy Tarreau

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

2017-10-16 Thread Aleksandar Lazic

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

2017-10-16 Thread Willy Tarreau

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

2017-10-16 Thread Sander Klein


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

2017-10-16 Thread Willy Tarreau

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

2017-10-16 Thread Pavlos Parissis

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

2017-10-16 Thread Aleksandar Lazic

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

2017-10-16 Thread Willy Tarreau

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

2017-10-16 Thread Pavlos Parissis

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

2017-10-16 Thread Sander Klein


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

2017-10-15 Thread Tim Jones

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 <aa...@loadbalancer.org>
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

2017-10-15 Thread Gibson, Brian (IMS)

PCoIP comes to mind but blast seems to have replaced the need.

Sent from Nine<http://www.9folders.com/>

From: Aaron West <aa...@loadbalancer.org>
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

2017-10-15 Thread Aaron West

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 Thread Илья Шипицин

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

2017-10-15 Thread 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 ;-)

Cheers,
Willy

Re: Experimental / broken HTTP/2 support

2017-10-15 Thread Aaron West

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

2017-10-15 Thread Willy Tarreau

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

2017-10-15 Thread Sander Klein


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,

Re: Experimental / broken HTTP/2 support

2017-08-21 Thread Andjelko Iharos

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
> [18/Aug/2017:15:56:51.500] www~ www/

Re: Experimental / broken HTTP/2 support

2017-08-19 Thread Aleksandar Lazic

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

RE: Experimental / broken HTTP/2 support

2017-08-18 Thread Hemant Sabat @ Coscend

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/www 0/0/25/25/50 200 441 - - CD--
3/3

Experimental / broken HTTP/2 support

2017-08-18 Thread Willy Tarreau

...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

Re: Experimental / broken HTTP/2 support

Re: Experimental / broken HTTP/2 support

Re: Experimental / broken HTTP/2 support

Re: Experimental / broken HTTP/2 support

Re: Experimental / broken HTTP/2 support

Re: Experimental / broken HTTP/2 support

Re: Experimental / broken HTTP/2 support

Re: Experimental / broken HTTP/2 support

Re: Experimental / broken HTTP/2 support

Re: Experimental / broken HTTP/2 support

RE: Experimental / broken HTTP/2 support

Re: Experimental / broken HTTP/2 support

Re: Experimental / broken HTTP/2 support

Re: Experimental / broken HTTP/2 support

Re: Experimental / broken HTTP/2 support

Re: Experimental / broken HTTP/2 support

Re: Experimental / broken HTTP/2 support

Re: Experimental / broken HTTP/2 support

Re: Experimental / broken HTTP/2 support

Re: Experimental / broken HTTP/2 support

RE: Experimental / broken HTTP/2 support

Experimental / broken HTTP/2 support

22 matches

Site Navigation

Mail list logo

Footer information