# ===========================================================================
#  Licensed Materials - Property of IBM
#  "Restricted Materials of IBM"
#  
#  IBM SDK, Java(tm) Technology Edition, v8
#  (C) Copyright IBM Corp. 2014, 2014. All Rights Reserved
# 
#  US Government Users Restricted Rights - Use, duplication or disclosure
#  restricted by GSA ADP Schedule Contract with IBM Corp.
# ===========================================================================
        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                port number
                    default:  8000
                -backlog backlog          backlog
                    default:  1024
                -secure                   encrypt with SSL/TLS
		    default is insecure

"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:	A single-threaded server which completely services each
	connection before moving to the next.

B2:	A multi-threaded server which creates a new thread for each
	connection.  This is not efficient for large numbers of
	connections.

BP:	A multi-threaded server which creates a pool of threads for use
	by the server.  The Thread pool decides how to schedule those
	threads.

N1:	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.

N2:	A dual-threaded server which performs accept()s in one thread, and
	services requests in a second.  Both threads use select().


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..."

