Re: X-Forwarded-For and HTTP2

Mark,

This is exactly the case I'm talking about. One client connection to one backend connection, no multiplexing in TLS terminator.

On Wed, Jul 8, 2015 at 11:43 PM, Mark Nottingham <mnot@mnot.net <mailto:mnot@mnot.net>> 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.


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


>  Once the terminator uses fewer connections on the back-end, each request needs to be separately marked again.  On the other hand, I could see browsers using that for the things they always send and never vary over the lifetime of a connection....
>
> The fact that HPACK was changed to be less stateful means that inserting a header can be a simple append to the HPACK frame -- you don't have to parse everything else in the frame, just tack your extra headers onto the end as non-indexed literals and adjust the frame length accordingly.  (You would have to handle the case where the incoming frame is a few bytes shy of the maximum; alternately, you could also do this by always dropping the END_HEADERS flag on the HEADERS frame and sticking the appended content in a CONTINUATION.)
>
> -----Original Message-----
> From: Mark Nottingham [mailto:mnot@mnot.net <mailto:mnot@mnot.net>]
> Sent: Wednesday, July 8, 2015 3:51 AM
> To: Fedor Indutny
> Cc: ietf-http-wg@w3.org <mailto:ietf-http-wg@w3.org>
> Subject: Re: X-Forwarded-For and HTTP2
>
> Hi Fedor,
>
>> On 8 Jul 2015, at 5:28 pm, Fedor Indutny <fedor@indutny.com <mailto: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 <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/ <http://www.haproxy.org/>
>> [1]: https://github.com/varnish/hitch <https://github.com/varnish/hitch>
>> [2]: https://github.com/indutny/bud <https://github.com/indutny/bud>
>>
>
> --
> Mark Nottingham   https://www.mnot.net/ <https://www.mnot.net/>
>
>
>
>
>
>

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