Your application’s Third Party libraries might issue external requests that you are not aware of. Some of them might even harm your application’s performance. There are multiple reasons for a library to establish connections with external services. Most obviously, any payment API will need to connect to an external server to fulfill the payment. It would be quite a surprise if a library like that worked without any external dependencies. On the other hand there are also services which we would not expect to require outbound connections. Mostly that applies to frameworks that should just make a developer’s life easier (logging, database access, scheduling, etc). Among all those, there are three possible categories I can think of:
Outbound External Requests: The Good, the Bad and the Ugly
This category holds payment APIs, captchas and the likes. They need to connect to external services to be able to do what we expect them to.
3rd party libraries that check for updates by themselves are not common behaviour. The quartz scheduling framework does so by default (also, it is the only library I am aware of doing so). The following log lines are just as regular to my projects as the quartz scheduler library itself:
2014-08-30 15:21:16 UpdateChecker [DEBUG] Checking for available updated version of Quartz… 2014-08-30 15:21:25 UpdateChecker [DEBUG] Quartz version update check failed: java.io.IOException: Server returned HTTP response code: 503 for URL: ...
The fix is easy but annoying. I have to apply it to every project utilizing the library. Either add this to the quartz.properties file:
or do this inside your code:
Properties properties = new Properties(); properties.setProperty(StdSchedulerFactory.PROP_SCHED_SKIP_UPDATE_CHECK, "true"); SchedulerFactory schedulerFactory = new StdSchedulerFactory(properties);
On the upside, startup time is not affected, as the check happens in the background about a minute after the library has been initialized. Anyway, libraries checking for updates (be it on startup, at runtime, or anytime else) is not good behavior. I use a plethora of libraries every day. None of them checks for updates on their own, and there is no need for them to. I have newsletters, tweets, coffee breaks, blogs and many other means of modern and traditional communication on my hands to keep me informed about new releases.
It wasn’t until I started using ruxit that I discovered that my carefully crafted application used to issue occassional web requests towards www.mybatis.org. It was quicly apparent that MyBatis was not submitting usage data or spying on my app’s data. It was all about a wrong DTD URL that caused the XML parser to not look up the DTD inside the .jar file but to request it from www.mybatis.org. The difference between wrong and right is very subtle.
<?xml version="1.0" encoding="UTF-8" ?> <!DOCTYPE configuration PUBLIC "-//mybatis.org//DTD Config 3.0//EN" "http://www.mybatis.org/dtd/mybatis-3-config.dtd">
The www. part of the URI causes the parser to look it up online instead of the .jar file. Depending on what caused the problem, there are usually multiple ways to fix the problem. For MyBatis you may find the fix and some more background information on the topic here and here. If you encounter a similar issue, you should really fix it. Fetching from an external source quickly renders into a serious issue once the source becomes unavailable.
How to Discover Unintentional Traffic
Discovering unintentional traffic by one of the many components of your application may not be an easy task. Especially, if you have to sniff your network connections manually for collecting the necessary data. ruxit comes in really handy here, as it lists your external depencies quite conveniently.
Who is depending on your services (or at least calling them)?
I have been developing enterprise applications for the last decade. Among the plethora of libraries I have used, only the two previously mentioned ever issued unwanted requests to external destinations (at least,as far as I know). From now on, I will know for sure. I recommend you to check your application for external communication once in a while. ruxit comes in very conveniently here as you don’t really have to spend money and it will hardly take an hour to get things up and running.