CNT4713 – & Net-centric Computing

Description

CNT 4713 – Project 1
Overview:
This project develops a web status monitor (simplified version of uptimerobot.com) to
practice web programming and understand the web related protocols: HTTP and
TLS/SSL. You must implement your own HTTP client socket to interact with the web
server, and cannot use any existing HTTP client library. You may use an existing SSL
library to help implement the HTTPS client to earn extra credits. You may use Python3,
Java, C++, or C as the programming language.
Background:
The Hyper Text Transfer Protocol (HTTP) is a TCP based application layer protocol for the
World Wide Web. The HTTP RFC [1] is the official document that defines the protocol.
HTTP is explained in detail in Chapter 2.4 of the textbook.
The Transport Layer Security (TLS) (replacing the Secure Socket Layer (SSL) protocol) is a
security protocol that provides authentication and encryption to protect TCP traffic. The
TLS RFC [2] is the official document that defines the protocol. TLS/SSL is explained in
detail in Chapter 8.6 of the textbook.
Instructions:
The web monitor should start by typing:
monitor urls-file or
java monitor urls-file or
python monitor.py urls-file
where urls-file is the name of a text file that has the list of URLs to be monitored.
Your program should then fetch each URL, analyze the response from the web server,
and print the status in the terminal. Please make sure that your program name is
exactly “monitor”. Submissions will be graded by an automated script. Unrecognized
program names will result in a zero.
A production web monitor will repeatedly fetch the provided URLs for continuous status
monitoring. For easy grading, the web monitor developed in this project should exit
after fetching all the URLs once.
A program skeleton is provided in Canvas for you to get started. Detailed steps to
implement the web monitor are explained below.

2
1. Parse URL
The first step is to parse the URLs provided in urls-file. As explained in Chapter 2.2.1
of the textbook, a URL specifies the protocol, host, and path that will be needed to fetch
the URL. For the following example URL


• http:// Indicates that the protocol is HTTP, and hence the web server is
listening at the port 80. If the URL starts with https:// instead, the protocol
will be HTTPS, and the web server will be listening at the port 443;
• www.someSchool.edu is the host name, which will be translated to an IP
address where the web monitor should connect to;
• /someDepartment/picture.gif is path of the requested object on the
server, which must be presented in the HTTP request message sent to the server.
2. Establish TCP connection
Since HTTP is a TCP based application layer protocol, a TCP connection must be
established before HTTP messages can be exchanged. As explained above, the host
name and port number can be obtained from the URL. Note that the default server port
number is 80 for HTTP and 443 for HTTPS.
3. Network error
If the TCP connection cannot be established because of a network error, such as a dead
server, network outage, or timeout, the web monitor should report such an error. A
sample output for the network error is as follows.
URL: http://fiu.gov
Status: Network Error
If the TCP connection is established, but messages cannot be successfully sent or
received. The web monitor should report the network error in a similar way.
4. Construct HTTP request message
Once the TCP connection is established, the web monitor is ready to send the first HTTP
request message. The request message must follow the specified format for the server
to understand. The HTTP request format is explained in detail in Chapter 2.2.3 of the
textbook.
Again, if the HTTP request message cannot be successfully sent, a network error should
be reported.

3
5. Analyze HTTP response message
If the request message is correctly constructed, the web monitor will receive a HTTP
response message from the server, and then should report the URL status. The HTTP
response format is explained in detail in Chapter 2.2.3 of the textbook.
The HTTP response message contains a status code for the requested URL. In this
project, we will focus only on the following status codes:
• 2XX successful responses
• 3XX redirection messages
• 4XX client error messages
The web monitor should parse the status returned for each URL and print it. Sample
outputs of for the 2XX, 3XX, and 4XX statuses are as follows.
URL: http://inet.cs.fiu.edu/
Status: 200 OK
URL: http://google.com/
Status: 301 Moved Permanently
URL: http://google.com/404
Status: 404 Not Found
If the HTTP response message cannot be successfully received, a network error should
be reported.
5. Follow URL redirection
If the status code in the HTTP response message is 301 or 302, it means that the
requested object has been redirected permanently or temporarily to a new URL, which
is also presented in the HTTP response message. The web monitor should continue
fetching the redirected URL and report its status.
The following sample output shows that the original URL returns a 301 status, and the
redirected URL returns a 200 status.
URL: http://google.com/
Status: 301 Moved Permanently
Redirected URL: http://wwww.google.com/
Status: 200 OK
The following sample output shows that the original URL returns a 302 status, and the
redirected URL returns a 403 status.
URL: http://inet.cs.fiu.edu/temp/deny.html
Status: 302 Found