[PATCH] proxy-protocol dst variables and proxy-proxy-protocol

[Dmitry Volyntsev]

On 20.09.2016 15:50, Bjørnar Ness wrote:
> 2016-09-20 13:16 GMT+02:00 Dmitry Volyntsev <xeioex at nginx.com>:
>> Could you please clarify what a problem are you trying to solve? Any real
>> world scenario?
>
> Hello, Dmitry, thanks for responding.
>
> The first problem I am trying to solve is the case where we have:
>
> LB -> nginx_proxy -> (something_with_proxy_protocol_support)
>
> Here, if proxy_protocol is enabled on both listen and outgoing, it
> is logical to assume the user wants the incoming header passed
> on directly.

Transparent proxy protocol bypass sounds like a valid use case.

>
> Also, I want access to the _dst part of the proxy protocol to make
> decisions based on the original destination address, which is
> currently unavailable.

Why do you need to know the destination address? could you elaborate
what do you want to know on the 
"(something_with_proxy_protocol_support)" side?

If you have a fixed set of LBs you could configure a separate listen
in nginx configuration per each LB.

>
> I chose to expose both $proxy_protocol_(src|dst)_(addr|port) and keep
> backwards compability with the original $proxy_protocol_(addr|port),
> which I suggest removing since its naming is confusing wrt src/dst.
>
> Storing these as ngx_str_t can definately be discussed, atleast if
> you plan/want proxyprotocol v2 support. In that case it would
> perhaps make sense to use something like:
>
> struct proxy_protocol_data {
>      int socket_type;
>      struct sockaddr src;
>      struct sockaddr dst;
> }
>
> and in ngx_connection_t
>
> struct proxy_protocol_data *proxy_protocol;
>
> What do you think? I feel storing as strings makes sense until the need
> for v2 arises, also, it makes the proxy-proxy-protocol support simple.
>
>> http://nginx.org/en/docs/contributing_changes.html
>>> Try to make it clear why the suggested change is needed, and provide a use
>>> case, if possible.
>
> Thanks, I will keep to this standard in future updates.
>
> --
> Bj(/)rnar
>
> _______________________________________________
> nginx-devel mailing list
> nginx-devel at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel
>