Re: X-Forwarded-For and HTTP2

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.

Strictly speaking, this is a sole purpose of having TLS terminator as a separate application. If one can afford to have it embedded - one does not need it at all, and may use `nginx` or something else that does HTTP(2) as well.

Prepending one frame using ALPN/NPN is very easy, parsing every possible protocol is something that many people do not want to have in a single-purpose tool. Especially, considering that there is no pros for them in re-framing incoming things.

Fedor.

On Thu, Jul 9, 2015 at 1:27 AM, Willy Tarreau <w@1wt.eu <mailto:w@1wt.eu>> wrote:
On Thu, Jul 09, 2015 at 02:43:17PM +0800, Mark Nottingham wrote:
>
> > On 9 Jul 2015, at 1:59 am, Mike Bishop <Michael.Bishop@microsoft.com <mailto:Michael.Bishop@microsoft.com>> wrote:
> >
> > But if the terminator is speaking HTTP/2 on both sides, is it muxing requests into fewer connections?
>
> My assumption was that this wasn't the use case; Fedor, is this correct?
>
> It's pretty common for load balancers, etc. to spread connections between a
> number of back-end servers, but not do any protocol processing (or only
> minimal processing). This is so that the LB doesn't become a SPOF.

Yes but then if we have 1 connection forwarded from end to end, the proxy
protocol header at the beginning of the TCP payload which is now supported
by haproxy, squid, varnish, nginx, stunnel, stud and others is enough and
low overhead.

Here we're talking about devices which would perform all the hard work of
dealing with TLS deciphering/ciphering, parsing the protocol frames but not
have any knowledge of the HTTP headers inside. That doesn't make much sense
to me given that the most complicated part is dealing with the framing (and
that was the reason many people objected against the binary protocol that
could not be produced anymore from shell scripts).

Thus I tend to think that such devices doing only 90% of the job have very
little reasons of ever being created. And as Amos said, adding this header
on the fly even without parsing the HTTP frames is not complicated at all.

> > A extension that adds "present on all requests" semantics would work if every client connection has a corresponding server connection, but that's not necessarily the case.
>
> Certainly, it's not *always* the case. I think the question is whether these
> devices are still useful with HTTP/2???

I think not. One of the goals seeked by HTTP/2 (and formerly by SPDY) was to
make it harder to implement half-assed devices which enforce their bogus
behaviour everywhere around them. I think at least this goal was reached and
we'll see correct protocol stacks because there's no benefit in doing half of
the job.

Willy