Re: X-Forwarded-For and HTTP2

Continuing my thoughts:

Adding such logic to backend also makes it impossible to
run and test the backend without the TLS terminator, because
it will always expect the PROXYLINE from it.

This adds complexity to the staging infrastructure as well.

On Thu, Jul 9, 2015 at 1:54 AM, Fedor Indutny <fedor@indutny.com <mailto:fedor@indutny.com>> wrote:
Aaah, sorry for this then. I got you wrong.

I see your logic about the protocol header, but it does add
unnecessary complexity to the backend side. From my
experience, this usually means stripping down default HTTP(2)
parser and working with the TCP socket at first, and only after
the parsing the protocol header execute the default HTTP code.

This statement implies that backends usually run on some kind
of existing platform like node.js, or anything else. And those
platforms have protocol implementations, so why not use just it
instead of adding PROXYLINE parsing code to them?

On Thu, Jul 9, 2015 at 1:47 AM, Willy Tarreau <w@1wt.eu <mailto:w@1wt.eu>> wrote:
On Thu, Jul 09, 2015 at 01:35:49AM -0700, Fedor Indutny wrote:
> Willy,
>
> I don't think that those TLS terminators actually do the half of the job.
> There is no way on earth they could support every kind of underlying
> protocol at once. They are just following unix philosophy and doing one
> thing right at the time, offloading the rest of the work to the other
> application.

I think you misunderstand me. I'm not speaking about TLS terminators,
they're doing the job right and have no problem with HTTP/2 at all.
Some people already do use haproxy as a TLS termination which injects
the proxy header at the beginning of the connection to serve HTTP/2
and/or SPDY.

What I'm saying is that HTTP/2 is a multiplexed protocol and that the
dumb offloader which has no knowledge about the protocol won't process
frames inside the protocol thus it will not multiplex connections and
instead will maintain the one-to-one relation between front and back
connections. In this case, a proxy protocol header at the beginning of
each backend connection does the job perfectly. And I'm all in favor
of TLS offloading since I tend to consider this method to scale better
than the other ones by moving the heavy processing out of the smart
components, thus reducing the number of smart ones and keeping the
ability to take more centralized decisions.

For a TLS offloader to break the one-to-one relation (and not being
compatible with a simple protocol header), it would have to be able
to multiplex connections and for this to parse all HTTP/2 frames in
the protocol. *That* is the difficult part which doesn't make sense
*alone* without the ability to inject an HTTP/2 header.

So in short, for an offloading gateway :

    TLS ----> plain TCP  : 1:1 connections, protocol header is enough
    TLS ----> HTTP       : XFF works fine
    TLS ----> multiplexed HTTP/2 frames over TCP : doesn't make sense

Hoping this helps,
Willy