To start the httpserver app, run the jar file:
java -jar httpserver.jar
The server runs on port 8080, serving files from the current directory. These values can be changed via command line parameters.
java -jar httpserver.jar /path/to/docroot 7070
The server will return directoy listings as HTML pages with links to the contained files and directories. Clicking on the link for a directory will open the listing for this directory, clicking on the link for a file will initiate a download for the file.
File download is aided by a "Content-Disposition" header that includes the file name as well as a "Content-Length" header to enable progress monitoring.
Invalid paths will result in "404 Not Found" responses.
The server will return "Last-Modified" and "Etag" headers to fascilitate effective caching and therefore supports conditional requests via the "If-Match", "If-None-Match", and "If-Modified-Since" request headers.
The server supports HEAD requests.
The server only supports GET and HEAD requests. All other requests are answered with "501 Not Implemented".
Persistent (keep-alive) connections are not enabled, each request will contain the "Connection: close" header. (1)
The high-level processing of HTTP requests goes something like this.
- Open a listening TCP socket (HttpServer).
- Accept a connection and hand it to a thread for processing (HttpServerThread).
- Read and parse the request from the connection (HttpRequest).
- Select the type of response to send (HttpHandler).
- Build and send the response (HttpResponse).
- If the connection is persistent (1), repeat from step 3.
- Close the connection and end the thread.
A classical HTTP framework would define different handlers (views) for different URLs, called "Routing" or "Traversal". These handlers would then build the appropriate response. I used a simplified version of this due to the simple nature of this server. This implementation only uses one handler and defines different types of responses which contain the respective logic. It is the handler's responsibilty to select the correct response.
The HttpRequest object encapsulates all information about the request (method, path, headers). The HttpResponse objects encapsulate all information needed to send the reponse (status, headers) and implements a method to write the response to the socket.
The specific reponses (DirectoryResponse, FileResponse, StatusResponse) are sub-classes of HttpResponse. Since all information needed to build the response is found in the request and the filesystem, most of the logic is found in the constructors, setting response-specific headers. The subclasses implement writeBody which writes the response-specific body to the socket. The base class will suppress the body if needed (HEAD requests, NotModified responses).
The chosen implemenation is aimed to be closely aligned to the HTTP protocol so that the different elements (requests & responses, status & headers) are clear to anyone famliar with HTTP.
I took the basic structure of how to use ServerSocket, Socket and Thread from the respective JDK tutorial sample. All other code was conceived and written by me, sometimes taking hints from code snippets found in the JDK reference.
This was my first Java project in over ten years so a lot of my time was spent reading the JDK reference and the ocasional google search, as well as the HTTP specification. Due to that I decided to do without unit tests and proper javadoc which I would usually include.
(1) I had tried the implementation for persistent connections for file downloads but had to disable it again. The HTTP clients (curl, Chrome) were not able to detect the end of the response unless the connection was closed. I could not find if this is a bug in the implementation or if my understaning of how persistent connections are supposed to work is wrong. Also, I am aware that the current implementation is not complete with respect to the "Keep-Alive" header's parameters (timeout, max).