Hello! On Thu, Apr 24, 2014 at 04:37:31PM -0700, Quanah Gibson-Mount wrote:
> > > --On April 24, 2014 at 10:26:07 PM +0400 Maxim Dounin <mdou...@mdounin.ru> > wrote: > > >>Yes, that is true, but why only implement a partial solution? With CGN, > >>only logging the IP is fairly useless in all cases. To truly get useful > >>information going forward, the IP + PORT of the client should logged in > >>all cases. > > > >Access log certainly can be configured to provide enough > >enformation to match any given error log message to a port if > >needed. There is no need to implement anything, solution is > >already here. > > The error log currently only provides the IP. While I'm guessing you could > do things like correlate timestamps, it's still going to be a pain. Having > the port readily available everywhere makes tracking a specific user much > easier to do. Each error log message contains connection id. > >And, by asking about "why implement a partical solution" you are > >overlooking the fact that proposed solution is partial as well - > >it doesn't change c->addr_text to ensure proper logging in all > >places (this would be a bad idea for other reasons, but it's > >another question), but rather tries to hack on the http error > >logging code to introduce remote port logging. This is far from > >being a complete solution. > > I'm certainly willing to address any deficiencies, but I'd want to make sure > it would follow whatever you want in the product before investing more time > on it. ;) For now it meets the needs of our customer in Belgium who has to > start dealing with the legal requirements of client port logging sooner than > later. Fair enough. As I already said in my first messages, I tend to think that there are no changes needed here. -- Maxim Dounin http://nginx.org/ _______________________________________________ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel