- From: Fedor Indutny <fedor@indutny.com>
- Date: Thu, 09 Jul 2015 08:36:39 +0000
- To: Willy Tarreau <w@1wt.eu>
- Cc: Mark Nottingham <mnot@mnot.net>, Mike Bishop <Michael.Bishop@microsoft.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
- Message-Id: <CAEv2VfKNwdTPg0xSDk-Yor6Tn6hvnOadJ_vJPhQch6JOpwXv2w@mail.gmail.com>
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
Received on Thursday, 9 July 2015 09:26:43 UTC