Re: X-Forwarded-For and HTTP2

[Willy Tarreau <[e-mail]>]

On Thu, Jul 09, 2015 at 01:54:59AM -0700, Fedor Indutny wrote:
> Aaah, sorry for this then. I got you wrong.

No problem.

> I see your logic about the protocol header, but it does add
> unnecessary complexity to the backend side. From my
> experience, this usually means stripping down default HTTP(2)
> parser and working with the TCP socket at first, and only after
> the parsing the protocol header execute the default HTTP code.

Normally it's done just after the accept() so that it doesn't
interfere with the parsing. For example I have no idea how to
parse SSL, yet I can parse the protocol before SSL does its job.

> This statement implies that backends usually run on some kind
> of existing platform like node.js, or anything else. And those
> platforms have protocol implementations, so why not use just it
> instead of adding PROXYLINE parsing code to them?

I see your point but then I'd propose different semantics : instead
of fiddling with HTTP/2 frames, maybe you'd want to propose something
similar to what the proxy protocol header does, but as a TLS extension
so that it continues to repeat the information it got on the other side
of the connection. Note I'm really meaning a connection here. I really
find it wrong to say something like "all these frames belong to the
same connection", I'd rather say "the connection I'm sending to you
has such properties", because I have no idea what the frames transported
inside look like nor if someone upstream has put another semantics on
their relation.

Willy