On 20.09.2016 15:50, Bjørnar Ness wrote:
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?
Advertising
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@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel
