Well, maybe you won't win the "Dynamic Web Server of the Year" award - unless they have a booby prize - but it does illustrate some of the ideas involved in dynamic web pages. In a dynamic web page, the content is generated on the fly by a program running on the server. For real dynamic web pages, the program is invoked by the web server. In this assignment, the program is the web server itself.
In this assignment, you will write code for an HTTP server that generates a single dynamic web page (kiss that award goodbye). This web page will just display the HTTP request in a nice HTML format.
Your server should be capable of responding to HTTP HEAD, GET, and POST requests. The header should look like the following.
HTTP/1.1 200 OK Connection: close Date: 14 Feb 2003 13:30:54 GMT Server: None Last-Modified: 14 Feb 2003 13:30:54 GMT Content-Type: text/htmlThis header must contain a blank line at the end in order to conform to HTTP. This header is all that is returned through the output side of your server socket for a HEAD request.
For a GET request, you should return the header followed by the HTML content for the dynamic web page. This content should be formatted like A Dynamic Web Page. You can see the HTML code for this example by following the link and clicking on the "Page Source" menu item in the "View" menu of your browser. All of the data in the web page should come from the request except for the "A Dynamic Web Page" title and the date just below the title.
For a POST request, you should return the same web page as for the GET request with an added section "<h3>Post Data</h3>" followed by the POST data. The POST data is everything in the request following the first blank line.
I recommend that you write the code for the server in stages and test it after each stage. I suggest three natural stages:
In order to ensure that you do not forget to shut down your server when not in use, I suggest you write the server code to deal with one request and then shut down. Follow the examples in Lesson: All About Sockets URLs and URLConnection.
You can do initial testing by making telnet connections to your server. For a final test of the GET response, you can direct your web browser to the URL for your server. The URL consists of the machine name and port number, separated by a colon, followed by a file name. Real web servers use the file name to locate the appropriate web page or program that generates the web page. Your server will ignore the file name except for displaying it as part of the echoed header.
I haven't tried using the DataOutputStream for socket output as illustrated in the textbook. It is possible that that would result in incorrect character encoding, which will confuse a browser. I will vouch for the PrintStream which is used in Sun's tutorial examples.
The blank line after a client's request header must be recognized by your server. For most browsers, the connection is kept alive while waiting for a server response. This means that you will not encounter an end of file until after the server has responded.
In your server code, you will need to do a bit of string manipulation.
You can do string concatenation just by using a "+" operator.
The String class also has methods for string manipulation such as
equals(), indexOf(), startsWith(),
and substring().
Consult the Javadoc API specifications for more details.
For dates, you can use the expression
new Date().toGMTString().
This requires adding the import import java.util.*; at the top
of your server code file.
You will validate your program in lab on the due date or the following Monday. At that time you should be prepared to demonstrate your servers response to HEAD, GET, and POST requests. The HEAD response should be demonstrated using a telnet connection. The GET and POST responses can be demonstrated by going to the Set Server web page. When you click the "Submit" button on that web page it will take you to another web page where you can enter some random GET or POST data. When you click the "Send Request" button on that page it will contact your server. If you prefer, you can demonstrate GET and POST responses with a telnet connection.
After your server has been demonstrated to the TA, you should also turn in a copy of your server code. Your code should be organized and commented. If not, you may lose some points. [an error occurred while processing this directive]