2016-11-10 0:52 GMT+01:00 Maxim Dounin <mdou...@mdounin.ru>: > Hello! > > On Wed, Nov 09, 2016 at 08:52:14PM +0100, Bjørnar Ness wrote: > >> On Nov 9, 2016 19:20, "Maxim Dounin" <mdou...@mdounin.ru> wrote: > > The implementation of PROXY protocol in nginx basically mimics > what is available via X-Forwarded-For in http. > > Extending it with destination data may simplify some use cases. > But it will also complicate things and will make other use cases > less intuitive. It is also more or less clear that destination > can be identified using a separate destination within nginx > itself.n
It is true that the way proxy protocol support in nginx is currently implemented, it discards half of the information available, and only gives us access to the src part. I think this is strange "halfway" implementation anyway. > As previously said, I'm not convinced this should be merged, as > suggested changes have obvious downsides in common cases and only > beneficial for very specific use cases. When one uses proxy-protocol, one allways has something in front that generates it. Using multiple configurations (can be _lots_) and having to do configuration management/reloads/whatever, seems like going backwards. The overhead of this impl if proxy protocol is not used in listed is just a couple ptr's, and can for sure be reduced at the cost of more complex code. >> > If you have some ideas on how to properly support PROXY protocol >> > in mail - please comment on the relevant patch. >> >> Reason for mentioning it here, is the mail proxy-protocol patch has the >> functionality mentioned here as a dependency. Both exim and dovecot >> understands proxy-protocol, and I want to pass it on after the auth is done, >> hence proxy-proxy-protocol. > > Current question is: > > What "listen ... proxy_protocol" should mean in case of mail. In > other modules, it just means that PROXY protocol header is parsed > and appropriate variables are available for use. It would be good > to have similar meaning in mail, but there are realip module and > no variables in mail. But Auth module can get the variables passed via headers, which is certainly a usecase, also, to be able to send same proxy protocol header out as you get in, the proxy-proxy-protocol scenario, it needs to be stored somewhere. This will work seemlessly on both mail, http and stream when proxy-protocol is enabled in both listen and outgoing, think of it as a "transparent smart-proxy" :) > In the stream module similar problem was resolved by not > introducing "listen ... proxy_protocol" till variables support was > added, and by adding realip module at the same time. May be there > are better options. > > I certainly dislike what is currently suggested, that is, just > passing an address provided via PROXY protocol to backends via > XCLIENT. > > Introducing PROXY protocol to backends instead of XCLIENT looks > as a separate thing. I think adding more support for XCLIENT these days is not needed, as the software in common use today supports proxy protocol native. -- Bj(/)rnar _______________________________________________ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
