Re: X-Forwarded-For and HTTP2

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

Received on Wednesday, 8 July 2015 18:17:59 UTC