Re: AccessLogValve and IPv6 string representation (RFC 5952 section 4)
Nevermind. For some reason we had omitted this is already supported by the ipv6Canonical flag. RTFM! Manuel Dominguez Sarmiento > On 13 Apr 2020, at 20:46, Manuel Dominguez Sarmiento wrote: > > Hi, we are in the middle of a thorough review to fully support IPv6 across > our platform. It has come to our attention that Java does not fully conform > to RFC 5952 section 4 which deals with IPv6 zero compression (i.e. ::1 > instead of 0:0:0:0:0:0:0:1 for localhost). We have confirmed that Tomcat's > AccessLogValve is using the standard Java implementation. How can we > guarantee zero compression to be used in AccessLogValve? > > We are using Guava's InetAddresses.toAddrString() across our systems to deal > with this. We know we can use a custom AccessLogValve extending the standard > behaviour, but we were wondering whether there was any other solution, option > or flag around this. We've thought of using a custom request attribute to > hold the IP address, but this is not very elegant. In particular, we'd lose > the IP address if the filter we would use to set the request attribute is not > invoked for any reason. > > This is not minor, since we use access logs a lot to diagnose issues, and > cross-reference IP addresses with many other systems which are fully RFC > 5952-compliant. Having separate representations for the same IP address will > eventually lead to either trouble, misdiagnosis, missed records, etc. > > Any suggestions? > > Manuel Dominguez Sarmiento >
Re: AccessLogValve and IPv6 string representation (RFC 5952 section 4)
Am 2020-04-14 um 01:45 schrieb Manuel Dominguez Sarmiento: Hi, we are in the middle of a thorough review to fully support IPv6 across our platform. It has come to our attention that Java does not fully conform to RFC 5952 section 4 which deals with IPv6 zero compression (i.e. ::1 instead of 0:0:0:0:0:0:0:1 for localhost). We have confirmed that Tomcat's AccessLogValve is using the standard Java implementation. How can we guarantee zero compression to be used in AccessLogValve? Are you explicitly referring to: 4.2.1. Shorten as Much as Possible The use of the symbol "::" MUST be used to its maximum capability. For example, 2001:db8:0:0:0:0:2:1 must be shortened to 2001:db8::2:1. Likewise, 2001:db8::0:1 is not acceptable, because the symbol "::" could have been used to produce a shorter representation 2001:db8::1. Have you considered raising with net-...@openjdk.java.net? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
AccessLogValve and IPv6 string representation (RFC 5952 section 4)
Hi, we are in the middle of a thorough review to fully support IPv6 across our platform. It has come to our attention that Java does not fully conform to RFC 5952 section 4 which deals with IPv6 zero compression (i.e. ::1 instead of 0:0:0:0:0:0:0:1 for localhost). We have confirmed that Tomcat's AccessLogValve is using the standard Java implementation. How can we guarantee zero compression to be used in AccessLogValve? We are using Guava's InetAddresses.toAddrString() across our systems to deal with this. We know we can use a custom AccessLogValve extending the standard behaviour, but we were wondering whether there was any other solution, option or flag around this. We've thought of using a custom request attribute to hold the IP address, but this is not very elegant. In particular, we'd lose the IP address if the filter we would use to set the request attribute is not invoked for any reason. This is not minor, since we use access logs a lot to diagnose issues, and cross-reference IP addresses with many other systems which are fully RFC 5952-compliant. Having separate representations for the same IP address will eventually lead to either trouble, misdiagnosis, missed records, etc. Any suggestions? *Manuel Dominguez Sarmiento*
