2016-09-20 13:16 GMT+02:00 Dmitry Volyntsev <xeioex@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.

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.

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@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel