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 GET and POST requests. Responses to each of these requests need a header. It should be similar to the following:
HTTP/1.1 200 OK Connection: close Date: 4 Feb 2013 16:18:04 GMT Server: A Dynamic Server Last-Modified: 4 Feb 2013 16:18:04 GMT Content-length: 234 Content-Type: text/html
This header must contain a blank line at the end in order to conform to HTTP.
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 with a header "<h3>Post Data</h3>" followed by a <pre> tag containing the POST data. The POST data is everything in the request following the first blank line.
A starting point for a solution is provided for you in
When this file is unzipped it will create a NetBeans project.
All of the code is in the
Without any modification, the provided code should run without crashing, but it is not actually running as a server. Instead, it reads input from from a test file named "get" and sends its output to System.out. The "get" file contains text for a typical GET request. The output you should see is the skeleton of an HTML file. It just has an <html> and a minimal <body> tag. There is no response header and no information obtained from the request.
I recommend that you write the code for the server in stages and test it after each stage. I suggest four natural stages:
sendResponseHeader()method to generate the response header. Then when you run the program the response header should appear in the output.
processHeaderLines()to complete the handling of a GET request.
processEntityBody()method to handle a POST request.
run() method, the first line invokes the
To test your
processEntityBody() method, change that line
to invoke the
This sets up input to come from a test file named "put".
Output continues to go to System.out.
The "put" file contains text for a typical PUT request.
After changing the line of code, run your program again. The output should contain the added section for the request entity body.
socketIOmethod to create a server socket and a client socket and connect program input and output to the client socket's input and output. The code for doing this is similar to code in Oracle's Knock-Knock server in Writing a Client/Server Pair. Finally, change the first line in the
run()method to invoke
You can only easily test the handling of GET requests on your server.
To do this, run your program.
It will not terminate until it has responded to a request.
Give it a request by opening a browser to the URL
After the server has responded it will shut down and the browser
should display a page similar to A
Dynamic Web Page.
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.
The String class also has methods for string manipulation such as
The StringBuilder class is a great tool for building complex text.
Consult the Javadoc API specifications for more details.
You will validate your program in lab on the due date. At that time you should be prepared to demonstrate your servers response to GET and POST requests.
After your server has been demonstrated to the TA, you should also turn in a zipped project file.