Standards matter

Yesterday our java snippet code to retrieve resources from a web server stopped working on our testing environment. The only change was the url configured, someone had decided stop using ip numbers in configuration files (a right decision in my opinion) so the url change from http://192.168.34.15:1234/path/file.txt to http://machine_8.internaldomain.com:1234/path/file.txt.

Of course the etc/hosts file had been properly configured so machine_8.internaldomain.com resolve as 192.168.34.15 but our code raised the following exception "java.net.ConnectException: Connection refused: connect". Reviewing the logs I found the code trying open a connection to machine_8.internaldomain.com:80 where obviously no server was listening.

The java snippet code use the commons-httpclient library (version 3.1), so my first thought was we have to update the library (version 4.1) but it didn't work. After restoring the original version of the library and spend a couple of hours debugging, I found the problem in the library URI object implementation (org.apache.commons.httpclient.URI) and I managed to code a workaround.

When I was about to share the workaround in this blog, I decided to test it with the last version of the library, but one of the changes from version 3.1 to 4.x was the use of the own jdk URI object implementation (java.net.URI). Since the java.net.URI object was introduced in jdk 1.4 and I was testing with java 6, I couldn't believe there was a real bug in the jdk.

After another couples of hours testing and debugging I found the real problem (extracted from wikipedia):

   "Hostname labels may contain only the ASCII letters 'a' through 'z' (in a case-insensitive manner), the digits '0' through '9', and the hyphen ('-')"

So the problem was us not following the standards and using an illegal character (the underscore '_') in the hostname. After changing everything from "machine_8.internaldomain.com" to "machine-8.internaldomain.com" everything started to work again.