This will quickly fall off into computer geek land, so those who don’t care for such things may wish to scroll down.

I’m working on a web project that has to access some backend (legacy) systems.  Of course our corporate security people don’t allow direct access to these systems (and rightly so) from systems that are accessed from the internet.  They have created a couple of layers of firewalls, so that when you access one of our online applications, your request is proxied and redirected across a firewall into the hosting zone (not the actual names used by our security people).  Even though this zone is protected, it is still not trusted.  If a system needs access to something in the internal network, it has to go through an intermediary system which has been certified and approved for crossing the firewall.

Our application has been designed to use a Web Services interface to access the data that it requires.  We have put in place a set of these services on the internal network that will access the backend systems.  We’re using SOAP over HTTP for this.  Since the security folks won’t allow HTTP traffic across the firewall, we have to use another protocol (in this case it’s a bit of messaging middleware).  To prevent our application from having to know about all this, we created a “bridge” that takes an HTTP request and puts it into a message.  There is another application running on the internal network that dequeues the message, contacts the web service, and puts the result back into a message, which gets sent to the front-end of the bridge.  If this sounds like a very round-about way of doing things, it is, but we’re required to do things like this for security purposes (that and our bridge code is very careful to accept requests only from validated systems/users and to send the requests to validated target URLs; it won’t act as a standard HTTP proxy).

Anyway, the bridge code works fine in every instance except one.  If the web service throws an exception, the bridge was not passing it on to the caller.  After going back and forth through the Java code, it appears that this all comes down to a peculiarity of how Java handles URLs.  The URL requires a trailing slash (’/’), which had been left off in the configuration file that specifies the target URL.  Normally, this doesn’t seem to matter.  The SOAP client code doesn’t care, and a web browser wouldn’t either.  If that trailing slash isn’t there, a call to HttpURLConnection.getInputStream() will throw a FileNotFoundException (but only when there is a SOAP fault, which causes an HTTP 500 return code).

It’s one of those things that drive you crazy.  You search and search for a bug in the code only to find that it’s in the JDK and it can be fixed by a small change to the URL.  One of my team members has been looking at this all week and I finally got involved and spent most of today on it.

With computers, you really do have to sweat the small stuff.  Now I need to get away from this computer for a while to let my eyes uncross after reading code, scanning books and manuals, and searching online discussions all day.