Re: X-Forwarded-For and HTTP2

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,

Received on Thursday, 9 July 2015 08:47:49 UTC