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