HTTP/2 Gateway

Hi,

i’ve tried to use nginx as http/2 gateway for backends which only
supporting HTTP 1.1. If a backend is already HTTP/2 ready, than HTTP/2
should be used.

When i test my configuration (simple proxy_pass / upstream), the
connection
from nginx to the backend is always HTTP 1.1 (even if the backend
supports
HTTP/2).

Is there a possiblity to speak HTTP/2 also to the backends?

I’ve used “proxy_http_version 1.1” in my configuration (no other setting
(higher version or protocol auto-negotiation) available).

Regards,

Bjoern

Hello!

On Sun, Dec 06, 2015 at 03:00:23PM +0100, [email protected] wrote:

I’ve used “proxy_http_version 1.1” in my configuration (no other setting
(higher version or protocol auto-negotiation) available).

No, talking to backends using the HTTP/2 protocol is not supported
by proxy module.


Maxim D.
http://nginx.org/

Is HTTP/2 proxy support planned for the near future?

Nicholas

Hello!

On Fri, Dec 11, 2015 at 10:03:15PM +0000, Nicholas Capo wrote:

Is HTTP/2 proxy support planned for the near future?

Short answer:

No, there are no plans.

Long answer:

There is almost no sense to implement it, as the main HTTP/2
benefit is that it allows multiplexing many requests within a
single connection, thus [almost] removing the limit on number of
simalteneous requests - and there is no such limit when talking to
your own backends. Moreover, things may even become worse when
using HTTP/2 to backends, due to single TCP connection being used
instead of multiple ones.

On the other hand, implementing HTTP/2 protocol and request
multiplexing within a single connection in the upstream module
will require major changes to the upstream module.

Due to the above, there are no plans to implement HTTP/2 support
in the upstream module, at least in the foreseeable future. If
you still think that talking to backends via HTTP/2 is something
needed - feel free to provide patches.


Maxim D.
http://nginx.org/

“multiplexing” seems to be a good use case for upstream proxying. We
don’t
have control how fast end users adopting HTTP/2, so we may still have
tons
of HTTP/1.x requests coming in, but we can certainly upgrade upstream
servers that we control to support HTTP/2. If nginx upstream proxy
module
can also support HTTP/2, we will be able to take advantage of
“multiplexing” the connection between nginx and upstream.

Thanks!
Frank

On Monday 14 December 2015 09:57:02 Frank L. wrote:

“multiplexing” seems to be a good use case for upstream proxying. We don’t
have control how fast end users adopting HTTP/2, so we may still have tons
of HTTP/1.x requests coming in, but we can certainly upgrade upstream
servers that we control to support HTTP/2. If nginx upstream proxy module
can also support HTTP/2, we will be able to take advantage of
“multiplexing” the connection between nginx and upstream.

[…]

What’s the advantage?

wbr, Valentin V. Bartenev

Hello!

On Mon, Dec 14, 2015 at 09:57:02AM -0800, Frank L. wrote:

“multiplexing” seems to be a good use case for upstream proxying. We don’t
have control how fast end users adopting HTTP/2, so we may still have tons
of HTTP/1.x requests coming in, but we can certainly upgrade upstream
servers that we control to support HTTP/2. If nginx upstream proxy module
can also support HTTP/2, we will be able to take advantage of
“multiplexing” the connection between nginx and upstream.

As already said, “advantage” is mostly nonexistent when
considering connections between nginx and upstreams, or even
disadvantage in some cases. But if you think that it will be
beneficial - feel free to provide patches.


Maxim D.
http://nginx.org/

On Monday 14 December 2015 18:24:01 Nicholas Capo wrote:

My specific use case is to support an HTTP/2 application behind a load
balancer (reverse proxy).

Also as a backend LB between services that could use a long running HTTP/2
connection to do their communication.

Places where I need an LB, but also know that both ends would /prefer/ to
use HTTP/2.

Can you name such applications that are only able to talk HTTP/2?

HTTP/2 isn’t a better and shiny version of HTTP, it’s completely
different transport layer with a number of disadvantages as well.

wbr, Valentin V. Bartenev

I think what they are asking is to support the transport layer so that
they
don’t have to support both protocols on whatever endpoint they are
developing.

Maybe I’m wrong and someone has grand plans about multiplexing requests
to
an upstream with http/2, but I haven’t seen anyone ask for that
explicitly
yet.

On Tue, Dec 15, 2015 at 4:40 AM, Valentin V. Bartenev [email protected]

Can you name such applications that are only able to talk HTTP/2?

The developers I support would like to use GRPC [1] which is HTTP/2
only.
I need to provide an HA/LB system to support them.
I’m not saying this would be easy to implement, only that I need it :slight_smile:

Thank you for your help,

Nicholas

[1] GitHub - grpc/grpc: The C based gRPC (C++, Python, Ruby, Objective-C, PHP, C#)

My specific use case is to support an HTTP/2 application behind a load
balancer (reverse proxy).

Also as a backend LB between services that could use a long running
HTTP/2
connection to do their communication.

Places where I need an LB, but also know that both ends would /prefer/
to
use HTTP/2.

Nicholas

On Mon, Dec 14, 2015 at 12:15 PM Valentin V. Bartenev [email protected]