Re: X-Forwarded-For and HTTP2

It is not adding the XFF to every HEADERS frame that is costly,
it is parsing the protocol itself. Most of the TLS terminators at the
moment skip this stage and just do one client connection = one
backend connection.

With this in mind - adding parsing layer, and changing the frames
on the fly is very costly.

On Wed, Jul 8, 2015 at 11:17 AM, Willy Tarreau <w@1wt.eu <mailto:w@1wt.eu>> wrote:
On Wed, Jul 08, 2015 at 08:28:09AM +0000, Fedor Indutny wrote:
> Hello again!
>
> I have a question/suggestion with regards to HTTP2 spec, and TLS
> terminator implementations.
>
> When HTTP2 (or previously SPDY) is used under the TLS terminator,
> there is a big question about how the address of the original
> client should be sent to the back end.
>
> One of the ways is to add `x-forwarded-for` header for every
> request, but it requires parsing the underlying protocol (be it
> HTTP2, SPDY, or HTTP/1.1), which is rather costly.

Once you start working with a multiplexed protocol, processing
the headers is only a fraction of the total cost anyway. Dealing
with multiplexed frames still requires some advanced magics so I
wouldn't consider the addition of xff costly here.

> Another approach is to send (so called) proxyline. This is what
> [HAProxy][0], and stud ([hitch][1]) are doing at the moment. In
> a few words this means prefixing all decrypted data with a single
> line specifying the client's IP address and port (and sometimes
> more metadata, like TLS servername and other protocol-specific
> things).

Yes but it's only for protocol gateways where there's a 1:1 relation
between front and back connections. It was designed mainly for SSL
offloading gateways. It doesn't make sense to use this mechanism on
multiplexed protocols.

> And the third approach that is to the best of my knowledge is
> implemented only in [bud][2] TLS terminator - is to add special
> SPDY frame, asking the SPDY server to automatically add
> `x-forwarded-for` for every incoming connection.
>
> What I was wondering if this frame could be standardized, or at
> least if it might be possible to allocate the frame type for it.
> So that people may use it for their own purposes, without being
> afraid of the possible frame type conflicts.
>
> What are your thoughts on this?

In fact what could be done would be to send a frame as a preambule
for each stream indicating such information when relevant. That could
make sense if/when we start to extend the protocol to transport
something non-http with one connection per stream. But at this stage
we're only talking HTTP in the protocol frames so I don't see any
benefit in not using XFF (or the Forwarded header since it was
specified for this purpose).

Regards,
Willy