RE: Experimental / broken HTTP/2 support

[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

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

+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

[Gibson, Brian (IMS)]

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

Sent from Nine

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

+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

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

[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

[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

[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

[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,