Hi Volodymyr, Yes, this is definitely something we are planning to do. There are a couple of reasons we have held off doing this: 1. You really want HAProxy 2.0 (also recently released) to get the full capabilities of HTTP/2 (See https://www.haproxy.com/blog/haproxy-2-0-and-beyond/#end-to-end-http-2). Prior to this, HTTP/2 connections from users were translated to HTTP/1.1 connections on the servers and/or had some open issues. 2. Another challenge is that none of the distributions (LTS versions) are shipping with HAProxy 1.9 or 2.0. Currently they all ship with 1.8. This means that operators would have to build images with a custom package or build of HAProxy in it. 3. This feature would bring in capabilities that only HAProxy 1.9/2.0 based amphora images would support. We have been talking in the weekly IRC and at the PTG about how we could handle "discovering" that an image has been build with a specific version of HAProxy prior to it being booted. I think the current leading idea is to tag the images in glance with a special tag/metadata that would allow us to query if there is a compatible image available for a feature a user is requesting. 4. No vendor provider drivers have requested or implemented HTTP/2 support in their drivers. 5. No one has come forward indicating that they can do the development work. (yet) As you can see we have a few issues to figure out and work on before HTTP/2 will be supported. So, definitely on the roadmap (updated), but I can't name which release will get it added. Michael On Mon, Jul 1, 2019 at 8:44 AM Volodymyr Litovka <doka.ua@gmx.com> wrote:

Dear colleagues,

- since haproxy supports HTTP/2 starting 1.9 (released on Dec 2018) for both frontends and backends - due to wide adoption of HTTP/2 (34% of all sites are now support HTTP/2 according to W3techs) - support for HTTP/2 is in all browsers and web-servers

whether Octavia team has plans to add support for HTTP/2 as well?

Thank you.

-- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison