Assignment 5 – CS176b – Computer Networks Winter 2000


Overview

In this assignment you will use sockets to implement a simple WWW client and WWW server that communicate using a restricted subset of HTTP. The main objective of the assignment is to give you some hands-on experience with the HTTP protocol.

You should write two programs, a server program (process) and a client program (process) that will communicate with each other in a connection-oriented manner using (SOCK_STREAM) sockets.

The client process should first contact the server process (after creating the socket, of course), and then issue some simple HTTP commands, namely GET, HEAD and LOG. You are strongly recommended to read our tutorials before implementing the above methods. Note that LOG is not an HTTP method, so you have to read its description at the end of this document.


Part I (implementation) 

For the basic part, you are asked to implement the basic form of GET, HEAD and LOG methods. Namely, your browser should be able to ask the Web server for a text document, and the Server should be able to send back the required document, if present (otherwise it should return a 404 file not found message)

Example:

[client asks for a page]

GET /test.html HTTP/1.0
 
[Server replies]
HTTP/1.0 200 OK
 
<HTML>
<HEAD>
<TITLE>Test HTML File</TITLE>
</HEAD>
<BODY>
<H1>This is an example HTML file</H1>
</BODY>
</HTML>

As you can see no additional header information is required. Pay special attention to the /n  character. It indicates the end of the header. Note that, since your client/server should be able to communicate with an actual Web Servers/browser you should process header information, even though you ignore it.

For instance, in the previous conversation you should expect something like that:
GET /test.html HTTP/1.0
Accept: text/html
Accept: text/plain
 
HTTP/1.0 200 OK
Date: Sun, 15 Oct 1995 23:41:06 GMT
Server: Apache/0.8.11
Content-type: text/html
Content-length: 113
Last-modified: Sun, 15 Oct 1995 23:38:54 GMT
 
<HTML>
<HEAD>
<TITLE>Test HTML File</TITLE>
</HEAD>
<BODY>
<H1>This is an example HTML file</H1>
</BODY>
</HTML>
 
No HTML parsing is required for this part.

Part II (extra points)

After the recent attacks, we decided to put an extra point section for those with the most comprehensive and up-to-date report on Web server attacks. The most common attacks are denial-of-service and malicious html tags/scripts. But these are not the only ones. From time to time, new security holes/bugs (concerning mainly the Microsoft's Web Server, called IIS), have shaken up the Internet community.

So, what you are expected to do is to find some very specific examples, and document these cases very thoroughly (in order to prove to us that you have understood them and not just copied/pasted them from a web site). Also they must be very recent, in the sense that they should refer to the latest versions of Web server/browsers (released after 06/06/98).

The LOG method

Basically it is identical to the HEAD method, plus it writes to a file the request that was issued by the client. The log file (the file in which you write the request should have the following format)

<IP of client> <request>(for Part I)

example:

150.140.128.23 "GET /csd/index.html HTTP/1.1"


Additional Notes: 

1.The RFC that defines the HTTP protocol is available to you, However, you do not need to print it (or even read it) for this assignment. Note that the RFC is 150 pages long! It would be much better for you to read the tutorials available at our web site.

2.We would strongly suggest that everyone begin by writing a client, and getting that client to work with an existing Web server. Then write a sequential server and test it with a WWW browser.

3.In writing your code, make sure to check for an error return from all system calls.

4.Note that read and write might return without having read or written the full number of bytes requested. In such a case, these calls will return a positive return value indicating the number of bytes actually read or written. If the number does not correspond with the number requested, be sure to loop back until all the data has been transferred.

5.Your processes should communicate using the reliable stream protocol SOCK_STREAM) and the Internet domain protocols (AF_INET).

6.Most of you will be running both the client and server on the same machine (e.g., by starting up the client and running it in the background, and then starting the server (or vice versa). Recall the use of the ampersand to start a process in the background. If you need to kill your server after you have started it, you can use the UNIX kill command. Use the UNIX ps command to find the process id of your server.

7.Make sure you close every socket that you use in your program. If you abort your program, the socket may still hang around and the next time you try and bind a new socket to the port ID you previously used (but never closed), you may get an error. Also, please be aware that port ID's, when bound to sockets, are system-wide values and thus other students may also be using the same port numbers.

C implementation: If your server is designed only to terminate upon receipt of a control-C from the keyboard or of a kill signal, then you will want to use the signal system call to make sure all sockets are closed before your server terminates. (A call to exit will insure that these sockets are closed gracefully before the server terminates.) Note that the signal system can be used to call a function that you designate to be executed as soon as a control-C or a kill signal is received. In the code fragment below, the user-supplied function cleanExit() will be called when a control-C or kill signal are received. The two calls to signal in the main routine let the OS know that cleanExit should be called on a control-C or a kill signal:

#include <signal.h>

........

main() {

........

signal(SIGTERM,cleanExit);

signal(SIGINT,cleanExit);

.......

}/* end of main */

void cleanExit()/* called on control-C or kill */

{

/* exit below will close open sockets*/

exit();/* all done, so die*/

}

For more info on UNIX Signals, read the page: UNIX singals .


Testing your client and server

You can test your client and server as follows:

Client: Your client can connect to any existing Web server. For instance you can connect to the HTTP server of our department (i.e., connect to port 80 on IP host 128.111.41.5) and try do download noframes.html page (by issuing the command GET /noframes.html HTTP/1.0 . Note that the HTTP server will return several lines of optional information. Here is how it should look like:

HTTP/1.1 200 OK

Server: Netscape-Enterprise/3.6 SP3

Date: Sat, 19 Feb 2000 00:44:30 GMT

Content-type: text/html

Link: <HTTP://www.cs.ucsb.edu/noframes.html?PageServices>; rel="PageServices"

Last-modified: Wed, 19 Jan 2000 16:22:42 GMT

Content-length: 5728

Accept-ranges: bytes

Connection: close

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">

<html xmlns:v="urn:schemas-microsoft-com:vml"

xmlns:o="urn:schemas-microsoft-com:office:office"

Server: Your server can be tested by using a Netscape (or other) browser to be the client for your server. If your server is on a machine machine-name, listening on port port-number, and you want to GET a file called file.html from this server, you would enter HTTP://machine-name.domain-name:port-number/file.html as the URL to open in your Netscape browser. This would cause Netscape to contact your server at port port-number and do a GET on file.html Note: Below a certain socket number you need the root password, which is why you'll need to run on a socket other than 80.


What to Turn in

When you turn in your assignment, you should include:

1) a hard-copy of your program listing containing in-line documentation, in class on due-date.
Soft copies also must be submitted, using the upload utility, before deadline. The file format will be announced soon.

Note: in-line documentation is ESSENTIAL, because not only makes your code readable but also proves that the code is yours!!!

2) a separate document of a page or so describing the overall program design, a verbal description of ``how it works'', and design tradeoffs considered and made.

Also briefly describe possible improvements and extensions to your program (and sketch how they might be made).

3) a separate description of the tests you ran on your program to convince yourself that it is indeed correct. Also describe any cases for which your program is known not to work correctly. This should include (at least):

4)For part (II)

A description of well known attacks, or secure holes that you have discovered. As it was mentioned earlier, do not put trivial or abstract stuff. We need concrete examples.


Assignment Grading

Late assignments will be penalized 7.34% a day.

Part I - 100 points

Works correctly:70 points (40 points client/ 30 points server)

Documentation: 15 points

Quality of design: 15 points

Part II – 20 points

The grading for this part will be totally objective.