Re: X-Forwarded-For and HTTP2

Hi Fedor,

> On 8 Jul 2015, at 5:28 pm, Fedor Indutny <fedor@indutny.com> 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.

Yup. BTW, there's also Forwarded <http://tools.ietf.org/html/rfc7239>, which is a bit more of a flexible format.


> 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).

*nod* I've been thinking we should have a discussion of that spec at some point.

> 
> 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.

Hmm. In the past there's been some reluctance to duplicate or supplement what might be consider application-layer information in the framing layer; doing so means there will need to be new APIs to expose it, potential confusion about precedence, etc. etc. 

Having the semantic of the frame mean "this header is present in all requests on this connection" might be an interesting workaround for that (provided that both sides support it, of course), and might be useful for other things too.

Cheers,


> 
> What are your thoughts on this?
> 
> Thank you,
> Fedor.
> 
> [0]: http://www.haproxy.org/
> [1]: https://github.com/varnish/hitch
> [2]: https://github.com/indutny/bud
> 

--
Mark Nottingham   https://www.mnot.net/

Received on Wednesday, 8 July 2015 10:51:45 UTC