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