Willy,
Am 26.02.20 um 09:59 schrieb Willy Tarreau:
>>> However in many cases you could know the stream that requested the
>>> outgoing connection. That's what is used when you see that "remote"
>>> thing. In conn_si_send_proxy(), there's a test to see if the the
>>> first connection's conn_stream's owner is a stream_interface, and
>>> if so it uses si_opposite() to find the other side. From this
>>> stream interface you can get the requesting stream using si_strm().
>>
>> So I would do:
>>
>> struct stream *stream = si_strm(si_opposite(si));
>
> You can even do :
>
> struct stream *stream = si_strm(si);
>
> Because the chain looks like this :
>
> +------------------------+
> conn--mux--cs--| si[0] stream si[1] |--cs--mux--conn
> +------------------------+
> Front Back
>
> When you do si_opposite(si[1]) it gives you si[0] and conversely.
> Both are part of the same struct stream. Thus si_strm() returns
> the same stream for any of them.
Thank you. When I try this within `conn_si_send_proxy`it works as expected.
I have a question about the '} else if (!cs && conn->owner) {' case,
though. It was added within this commit:
https://github.com/haproxy/haproxy/commit/661167d136d5bf4ac40ac4fae450d66dd69a64df.
The comment says something about SSL handshakes. However I am unable to
trigger this condition. I tested with both SSL on the frontend bind line
and on the backend server. Do you happen to know when I might not yet
have a stream at the send proxy stage?
>> Asking differently: If I wanted to upstream my proposal (with the
>> explicit focus on unique IDs for TCP), how would you like to see it work?
>
> I don't know yet. I'm just a bit concerned about the risk of having
> something in TCP that disappears in HTTP if you do it for TCP only.
> Someone using this connection ID for logging (that's often the purpose)
> would only have it with TCP and would have to proceed differently for
> HTTP. So I'm still wondering if it wouldn't be better to rely on
> "proxy-v2-options" and decide what to send, and when the unique-id is
> specified there, then it's taken from the stream, regardless of the
> stream mode (tcp/http). Even if I consider that it doesn't make sense
Yes, my current implementation looks like that:
server example 127.0.0.1:8082 send-proxy-v2 proxy-v2-options unique-id
The 'explicit focus' is just that the user should not expect the IDs to
make sense when using HTTP/2 with multiple streams over a single
connections.
> to have this ID sent both on the connection and in a header, if there
> is a use case to having such an ID on a connection, we must still be
> sure that it doesn't become impossible to send it when in HTTP.
>
> Also maybe having a way to retrieve a received ID on a listener as a
> sample fetch so as to be able to build a unique-id header from it
> could be useful. Some users want to pass the same ID along a whole
> chain, and with this it would become possible at the TCP level, which
> is quite nice.
Yes, I plan to make adjustments for `accept-proxy` with a new sample
fetch as well.
Best regards
Tim Düsterhus
