0.31 is mostly a bugfix release. There were a few nagging problems I really felt like needed to be corrected, and this release fixed them.
The one that users will probably appreciate most is that "http://www.blah.com/" and "http://www.blah.com/some/subdir/" will now automatically get "index.html" appended. This is the way most webservers work, and it's a nice convenience. Real easy change in the code too, all of three lines. Two lines if you don't include the closing brace on the if() statement.
But the one that was bugging me more was that the JWS wasn't always returning a correct Content-Type: header. It was hardwired to return text/html even if it was serving a .txt or .jpg file. As it turns out, the solution to this one was really easy. I quote from Simon Brown's blog entry on the subject:
FileNameMap from the java.net package is a simple interface which provides a mechanism to map between a file name and a MIME type string. It's not actually something that I've come across before, even though it's existed since version 1.1 of the JDK. However, with code like the following, you can get the MIME type using the default JDK mappings that are specified in the JAVA_HOME/lib/content-types.properties file.
FileNameMap fileNameMap = URLConnection.getFileNameMap();
String mimeType = fileNameMap.getContentTypeFor(someFileNa
There you have it. No need to maintain your own MIME types file, or any of the associated hassle. The Java libraries do it for you - as they quite often do. I'm quickly coming to love that aspect of Java very much. (But it does have a dark side. A reasonably intelligent person could pretty much hold the entire C stdio library in their head. Even a really smart person probably can't memorize the entire Java standard library as it is now. And it's constantly growing and changing, too.)
There were a couple of other little things too. I made JWS_LISTEN_PORT a private final in JWSServer, instead of a hardcoded value in the code. I also made JWSWorker's default constructor private because there's no (good) reason to waste memory and worker thread time with task queue entries that don't have an actual connection. I considered using the HTTP error messages from HttpURLConnection but it didn't seem like it would save many lines, and didn't look like it was going to make the code any clearer either.
Looking towards the future, I think I'm going to try and get CGI-BIN at least minimally working for release 0.4. Despite my gripes about the Java threading APIs, one nice thing about the JWS's new multi-threaded architecture is you only have to alter the run() method in JWSWorker if you want to change how request URIs are processed. None of the multithread stuff has to change to implement CGI. But CGI is still going to be a learning experience, because right now I have no clue how to spawn a shell command in Java.