Description
Objective –
To create a HTTP-based web server that handles multiple simultaneous requests from users.
Foreword –
Please take time to thoroughly read and understand the document. Only concepts, directions and
objectives will be provided in this document. The assignment will teach you the basics of network
programming, client/server communication message structures, and will provide a step toward building
high performance servers. You must work individually on this assignment; we will check for plagiarism.
Background –
What is a web-server?
A web server is a program that receives requests from a client and sends the processed result back to the
client as a response to the command. A client is usually a user trying to access the server using a web
browser (Google Chrome, Firefox).
The HTTP request consists of three substrings – request method, request URL, and request version. All
three parts should be separated by one or more white spaces.
The request method should be capital letters like “GET”, “HEAD”, and “POST”.
The request URL is a set of words which are case insensitive and separated by “/” and the server should
treat the URL as a relative path of the current document root directory.
The request version follows the rule like “HTTP/x,y” where x and y are numbers.
Here is an example to make things clearer –
If you type an URL like http://www.w3.org/Protocols/rfc1945/rfc1945 in a web browser, the web browser
will send an HTTP GET command to the server http://www.w3.org/ after establishing a TCP connection
with port 80 on the server. In this scenario, the format for the HTTP GET command received at the web
server is as follows:
GET /Protocols/rfc1945/rfc1945 HTTP/1.1
Based on the rules, we can identify three substrings like the following:
Request Method: GET
Request URI: /Protocols/rfc1945/rfc1945
Request Version: HTTP/1.1
Deliverables in detail:
Your server should start without any arguments: ./webserver
Your server should be running in a Forever running loop once it has started. You are expected
to exit out of the server gracefully (Either finish all the pending requests, timeouts and then exit
or just exit out bluntly closing the listen socket properly though) when pressing the escape
sequence (Ctrl + C or any key(s) of your choice).
In this assignment, the Web server will have a document root which would contain files with the
extension “.html” “.htm”, “.txt”, “.jpg”, “.gif”. When the web-server receives a HTTP request from a client
(from a web-browser such as chrome) for a particular file, it should open the file from this document root
and then send the file back to the client with proper header information. Header information is the
required to be sent along with the file so the web-browser would understand that the HTTP request was
successful and the response is being received. In all cases, the names of files in the Request URL should
be interpreted in the context of the current document root. If the server interprets the request (HTTP
GET) and the requested file exists on the specified location, the server needs to send both Content-Type
and Content-Length followed by an appropriate status code. The file content should be separated by a
carriage-return-line-feed (“\n”) from the header. For example, when the client requests an existing
“.html” file on the server, such a file exists in my server, so server replies with a 200 status code.
The Status Code “200” indicates that the requested file exists and the server is going to send the
processed data (the requested file) back to the client. The string next to Status Code “200” conveys the
information that the requested document that will follow in this reply. Usually, many Web servers use
“Document Follows” and “Ok” for that field.
Sample Header Format-
HTTP/1.1 200 Document Follows
Content-Type: <> #Tells about the type of content and the formatting of
Content-Length: <> #Numeric length value of the no. of bytes of
Default Page:
If the Request URL is the directory itself, the web server tries to find a default web page such as
“index.html” or “index.htm” on the requested directory. What this means is that when no file is
requested in the URL and just the directory is requested (Example: GET / HTTP/1.1 or GET /inside/
HTTP/1.1), then a default web-page should be displayed. This should be named either “index.html” and it
should be present in the corresponding directory of the Request URL. The default web page and
document root directory should be searched in the server configuration file present above. The server can
accept and search for the exact file listed on the DirectoryIndex. Remember this case only applies when a
folder is requested by the client without providing any specific filename. If the client sends a HTTP/1.0
request, the server must respond back with a HTTP/1.0 protocol in its reply, similarly for HTTP /1.1.
HTTP/1.0 and HTTP/1.1 protocols are what you will be supporting. HTTP/1.0 is described in RFC 1945. The
client browser will do the multiple requests automatically and nothing needs to be done in the server
other than sending correct responses.
Configuration File:
The Web server configuration file named “ws.conf” stores the initial parameters of the server which must
be read by the server when the server starts running. Also, the Content-Type associated with a filename
extension is stored in this file. The example of “ws.conf” file is as follows:
#service port number
Listen 8888
#document root
DocumentRoot “/home/sha2/www”
#default web page
DirectoryIndex index.html
#Content-Type which the server handles
.html text/html
.htm text/html
.txt text/plain
.gif image/gif
.jpg image/jpeg
.jpeg image/jpeg
#connection timeout – not needed if not doing the extra credit
Keep-Alive time 10
This file should be used to modify all configuration parameters of the web server. The server should read
from this file to get all the required configuration for its operation.
Handling Multiple Connections (Mandatory for CSCI4273/CSCI5273 and ECEN5273 students):
When the client receives a web page that contains a lot of embedded pictures, it repeatedly requests an
HTTP GET message for each object to the server. In such a case the server should be capable of serving
multiple requests at same point of time. This can be done using select(), fork(), or pthread() with
following approaches:
1. A multi-threaded approach that will spawn a new thread for each incoming connection. That is,
once the server accepts a connection, it will spawn a thread to parse the request, transmit the file, etc.
2. A multi-process approach that maintains a worker pool of active processes to hand requests off to
and from the main server.
Error Handling:
When the HTTP request results in an error then the web-server should respond to the client with an error
code. In this assignment, the following status codes should be used:
1. The response Status Code “400” represents that the request message is in a wrong format and
hence it cannot be responded by the server. It sends the client one of following messages
depending on the reason:
HTTP/1.1 400 Bad Request
400 Bad Request Reason: Invalid Method :<
or
400 Bad Request Reason: Invalid URL: <
or
400 Bad Request Reason: Invalid HTTP-Version: <
2. The response Status Code “404” informs the client that the requested URL doesn’t exist (file does
not exist in the document root). It results in the following message.
HTTP/1.1 404 Not Found
404 Not Found Reason URL does not exist :<
3. The response Status Code “501” represents that the requested file type is not supported by the
server and thus it cannot be delivered to the client. It results in the following message.
Supported Methods:
Only GET Method needs to be handled in your program. (if not implementing extra credit for
POST method). Other methods such as POST, HEAD, DELETE, OPTIONS etc.) need not be handled.
Please display an error message 501 Not Implemented when receiving methods which are not
supported.
HTTP/1.1 501 Not Implemented
501 Not Implemented <
4. All the other error messages can be treated as the “500 Internet Server Error” indicating that the
server experiences unexpected system errors. A 500 error is not the client’s fault and therefore
this error code conveys that it is reasonable for the client to retry the exact same request that
triggered this response, and hope to get a different response. It results in the following messages.
HTTP/1.1 500 Internal Server Error: cannot allocate memory
These messages in the exact format as shown above should be sent back to the client if any of the
above error occurs.
Pipelining: (Extra Credit: 10 points for CSCI4273, CSCI 5273 and ECEN 5273 students)
Next, add simple HTTP/1.1 support to your web server: support persistent connections and pipelining of
client requests. You will need to add a logic to your web server to determine when it will close a
“persistent” connection – say 10 seconds. That is, after the results of a single request are returned (e.g.,
index.html), the server should by default leave the connection open for some period of time, allowing the
client to reuse that connection socket (print your socket descriptor integer id to observe this) to make
subsequent requests. This timeout value needs to be configurable in the server.
The server must send its responses to those requests in the same order that the requests were received.
So, if there is a “Connection: Keep-alive” header in the request then a timer has to start pertaining to the
socket which had received this request. The server will keep that socket connection alive till the timeout
value ends. The server should close the socket connection only after the timeout period is over if no other
requests are received on that particular socket. If any subsequent requests arrive on that socket before
the timeout period
(essentially pipelined requests), the server should reset the timeout period for that socket back to the
timeout value and continue to wait to receive further requests. This timer will have a value of what was
read in the configuration file. If there was no “Connection: Keep-alive” in the request header, then the
socket will be closed immediately; the timer will never start for this case. For example, if the server
received this client request and the message is something like this:
GET /index.html HTTP/1.1
Host: localhost
Connection: Keep-alive
The response for this request should be something like the following:
HTTP/1.1 200 OK
Content-Type: <>
Content-Length: <>
Connection: Keep-alive
If there is no “Connection: Keep-alive” header in the request message, the server should close
the socket upon responding and reply with “Connection: Close” header line. If there is a
“Connection: close” header in the request message, the server should again close the socket
upon responding and reply with the same “Connection: Close” header line.
Example Scenario:
Consider a request is received by the server with the Keep-alive header. At this point a timer is
triggered. Now if another request from the same client socket is received after 2 seconds of the
first request, the server will process the new request and reset the timer be reset to 10 seconds
again. If no other request is received by the web-server within the 10 second timeout period, then the
socket connection is closed by the web-server.
Additional, POST method support (Extra Credit: 10 points for CSCI4273/5273 and ECEN 5273 students):
Implement your code to handle POST requests as well for ‘.html’ files. When you send the POST request,
you should handle it the same way you have handled GET and return the same web page as you returned
for the GET request. (In this case: the requested POST URL). But in this reply webpage, you should have an
added section with a header “
POST DATA
” followed by a
tag containing the POST data. The POST DATA is everything in the POST request following the first blank line. Other methods can remain unsupported through the 501 Not Implemented error code handling. Earn criteria: Should be able to see the POST data in the server’s response along with the requested URL’s contents. Example: Post request: Content-length defines no. of characters to be read after the blank line POST /www/sha2/index.html HTTP/1.1 Host: localhost Content-Length: 9POST DATA Sample post request made to webserver while testing through telnet: (echo -en "POST /index.html HTTP/1.1\r\nHost: localhost\r\nConnection: Keepalive\r\n\r\nPOSTDATA”; sleep 10) | telnet 127.0.0.1 8888 Sample response sent by webserver over telnet, Success response: Trying 127.0.0.1... Connected to 127.0.0.1. Escape character is '^]'. HTTP/1.1 200 OK Content-type: text/html Content-size:3391 POSTDATA
r\n\r\nGET /index.html HTTP/1.1\r\nHost: localhost\r\n\r\n"; sleep 10) | telnet
127.0.0.1 8888
Idle Response:
Trying 127.0.0.1...
Connected to localhost.lan.
Escape character is '^]'.
HTTP/1.1 200 OK
Date: Sun, 24 Sep 2017 17:51:58 GMT
Content-Length: 62
Connection: Keep-Alive
Content-Type: text/html
test
HTTP/1.1 200 OK
Date: Sun, 24 Sep 2017 17:51:58 GMT
Content-Length: 62
Connection: Keep-Alive
Content-Type: text/html
test
Helpful Links:
1. http://www.cs.dartmouth.edu/~campbell/cs50/socketprogramming.html Socket Programming -
TCP echo client and server with fork().
2. http://www.binarytides.com/server-client-example-c-sockets-linux/ : TCP echo client and server
with threads.
3. http://www.csc.villanova.edu/~mdamian/sockets/echoC.htm : Echo server-client code with
threads.
4. https://www.youtube.com/watch?v=eVYsIolL2gE : Basics of socket programming.
