A Simple NIO-based HTTP/HTTPS Server Example INTRODUCTION ============ This directory contains a simple HTTP/HTTPS server.

HTTP/HTTPS are two common network protocols that provide for data transfer, and are more fully described in RFC 2616 and RFC 2818 (Available at http://www.ietf.org ). HTTPS is essentially HTTP after the connection has been secured with SSL/TLS. TLS is the successor to SSL, and is described in RFC 2246. This server was written to demonstrate some of the functionality new to the Java 2 platform. The demo is not meant to be a full tutorial, and assumes the reader has some familiarity with the subject matter. In particular, it shows: New I/O (java.nio, java.nio.channels, java.util.regex, java.nio.charset) Introduced in version 1.4 of the platform, NIO was designed to overcome some of the scalability limitations found in the existing blocking java.net.* API's, and to address other concepts such as Regular Expression parsing and Character Sets. This server demonstrates: ByteBuffer Blocking and Non-Blocking I/O SocketChannel ServerSocketChannel Selector CharacterSet Pattern matching using Regular Expressions JSSE (javax.net.ssl) Introduced in version 1.4 of the platform, JSSE provides network security using SSL/TLS for java.net.Socket-based traffic. In version 1.5, the SSLEngine API was introduced which separates the SSL/TLS functionality from the underlying I/O model. By making this separation, applications can adapt I/O and compute strategies to best fit their circumstances. This server demonstrates: Using SSLEngine to create a HTTPS server Creating simple key material for use with HTTPS Concurrency Library (java.util.concurrent) Introduced in version 1.5 of the platform, the concurrency library provides a mechanism which decouples task submission from the mechanics of how each task will be run. This server demonstrates: A ThreadPool with a fixed number of threads, which is based on the number of available processors.

SETUP ===== The server must be built on version 1.5 (or later) of the platform. Invoking the following should be sufficient: % mkdir build % javac -source 1.5 -target 1.5 -d build *.java The following creates the document root: % mkdir root All documents should be placed in this directory. For HTTPS, the server authenticates itself to clients by using simple Public Key Infrastructure (PKI) credentials in the form of X509Certificates. You must create the server's credentials before attempting to run the server in "-secure" mode. The server is currently hardcoded to look for its credentials in a file called "testkeys". In this example, we'll create credentials for a fictional widget web site owned by the ubiquitous "Xyzzy, Inc.". When you run this in your own environment, replace "widgets.xyzzy.com" with the hostname of your server. The easiest way to create the SSL/TLS credentials is to use the java keytool, by doing the following: (<CR> represents your end-of-line key) % keytool -genkey -keyalg rsa -keystore testkeys -alias widgets Enter keystore password: passphrase What is your first and last name? [Unknown]: widgets.xyzzy.com<CR> What is the name of your organizational unit? [Unknown]: Consumer Widgets Group<CR> What is the name of your organization? [Unknown]: Xyzzy, Inc.<CR> What is the name of your City or Locality? [Unknown]: Arcata<CR> What is the name of your State or Province? [Unknown]: CA<CR> What is the two-letter country code for this unit? [Unknown]: US<CR> Is CN=widgets.xyzzy.com, OU=Consumer Widgets Group, O="Xyzzy, Inc.", L=Arcata, ST=CA, C=US correct? [no]: yes<CR> Enter key password for <mykey> (RETURN if same as keystore password): <CR> This directory also contain a very simple URL reader (URLDumper), which connects to a specified URL and places all output into a specified file. SERVER EXECUTION

================ % java -classpath build Server N1 Usage: Server <type> [options] type: B1 Blocking/Single-threaded Server BN Blocking/Multi-threaded Server BP Blocking/Pooled-thread Server N1 Nonblocking/Single-threaded Server N2 Nonblocking/Dual-threaded Server options: -port port default: 8000 -backlog backlog default: 1024 -secure default is insecure port number backlog encrypt with SSL/TLS

"http://" URLs should be used with insecure mode, and "https://" for secure mode. The "B*" servers use classic blocking I/O: in other words, calls to read()/write() will not return until the I/O operation has completed. The "N*" servers use non-blocking mode and Selectors to determine which Channels are ready to perform I/O. B1: B2: A single-threaded server which completely services each connection before moving to the next. A multi-threaded server which creates a new thread for each connection. This is not efficient for large numbers of connections. A multi-threaded server which creates a pool of threads for use by the server. The Thread pool decides how to schedule those threads. A single-threaded server. All accept() and read()/write() operations are performed by a single thread, but only after being selected for those operations by a Selector. A dual-threaded server which performs accept()s in one thread, and services requests in a second. Both threads use select().

BP:

N1:

N2:

CLIENT EXECUTION ================ You can test the server using any standard browser such as Internet Explorer or Mozilla, but since the browser will not trust the credentials you just created, you may need to accept the credentials via the browser's pop-up dialog box. Alternatively, to use the certificates using the simple included JSSE client URLDumper, export the server certificate into a new truststore, and then run the application using the new truststore. % keytool -export -keystore testkeys -alias widgets -file widgets.cer Enter keystore password: passphrase<CR>

Certificate stored in file <widgets.cer> % keytool -import -keystore trustCerts -alias widgetServer \ -file widgets.cer Enter keystore password: passphrase<CR> Owner: CN=widgets.xyzzy.com, OU=Consumer, O="xyzzy, inc.", L=Arcata, ST=CA, C=US Issuer: CN=widgets.xyzzy.com, OU=Consumer, O="xyzzy, inc.", L=Arcata, ST=CA, C=US Serial number: 4086cc7a Valid from: Wed Apr 21 12:33:14 PDT 2004 until: Tue Jul 20 12:33:14 PDT 2004 Certificate fingerprints: MD5: 39:71:42:CD:BF:0D:A9:8C:FB:8B:4A:CD:F8:6D:19:1F SHA1: 69:5D:38:E9:F4:6C:E5:A7:4C:EA:45:8E:FB:3E:F3:9A:84:01:6F:22 Trust this certificate? [no]: yes<CR> Certificate was added to keystore % java -classpath build -Djavax.net.ssl.trustStore=trustCerts \ -Djavax.net.ssl.TrustStorePassword=passphrase \ URLDumper https://widgets.xyzzy.com:8000/ outputFile NOTE: The server must be run with "-secure" in order to receive "https://" URLs. WARNING: This is just a simple example for code exposition, you should spend more time understanding PKI security concerns. SOURCE CODE OVERVIEW ==================== The main class is Server, which handles program startup, and is subclassed by the "B*" and "N*" server classes. Following a successful accept(), the "B*" variants each create a RequestServicer object to perform the actual request/reply operations. The primary differences between the different "B*" servers is how the RequestServicer is actually run: B1: RequestServicer.run() is directly called. BN: A new thread is started, and the thread calls RequestServicer.run(). BP: A ThreadPool is created, and the pool framework is given Runnable tasks to complete. In the "N*" variations, a Dispatcher object is created, which is responsible for performing the select, and then issuing the corresponding handler: N1: A single thread is used for all accept()/read()/write() operations N2: Similar to N1, but a separate thread is used for the accept() operations. In all cases, once the connection has been accepted, a ChannelIO object is created to handle all I/O. In the insecure case, the corresponding SocketChannel methods are directly called. However in the secure case, more manipulations are needed to first secure the channel, then encrypt/decrypt the data, and finally properly send any shutdown messages. ChannelIOSecure extends ChannelIO, and provides the secure variants of the corresponding ChannelIO calls.

RequestServicer and RequestHandler are the main drivers for the blocking and non-blocking variants, respectively. They are responsible for: Performing any initial handshaking Reading the request data All data is stored in a local buffer in the ChannelIO structure. Parsing the request The request data is obtained from the ChannelIO object, and is processed by Request class, which represents the parsed URI address. Locating/preparing/sending the data or reporting error conditions. A Reply object is created which represents the entire object to send, including the HTTP/HTTPS headers. Shutdown/closing the channel. CLOSING THOUGHTS ================ This example represents a simple server: it is not production quality. It was primarily meant to demonstrate the new APIs in versions 1.4 and 1.5 of the platform. This example could certainly be expanded to address other areas of concern: for example, assigning multiple threads to handle the selected Channels, or delegating SSLEngine tasks to multiple threads. There are so many ways to implement compute and I/O strategies, we encourage you to experiment and find what works best for your situation. To steal a phrase from many textbooks: "It is left as an exercise for the reader..."