IT Infrastructure Practical Assignment 2 Instructions

Assignment Name: Hypertext Transfer Protocol (HTTP)

Hypertext Transfer protocol is known as the mechanism for delivering web pages. The JASPER applet supports the simulation of HTTP. URLs (Universal Resource Locators) are abstract represented as URL1, URL2… URLn, and likewise for DATA which represents web pages.

Below are some experiments you can go through to understand HTTP and its commands. The first two experiments will give a feel to using the simulator and simply relate to real scenarios. Subsequent experiments will be complex, yet still relating to real events.

Launching the HTTP Simulator

Ensure that your default browser supports Java applets. Note that you may need to run Java in low security for the Java applets in this exercise to work properly.
For access to all simulations, click on the rotating globe at this book’s Companion Web site at http://williamstallings.com/BusinessDataComm/BDC7e-student/.
Click the spinning globe icon, and then click on the link to the HTTP Simulator.
This will launch the HTTP Simulator applet along with a description of the main commands we will be using for our experiments.

Main Commands Description

HTTP supports a relatively modest suite of commands. The protocol simulator supports the following, most frequently used, HTTP commands.

Command	Description
GET	Get data for URL
HEAD	Get header for URL
POST	Append data to URL
PUT	Send data to URL

Response Codes

HTTP provides a range of response codes, each uniquely indicating the response to the corresponding command previously received. The protocol simulator here supports a limited range of HTTP response codes, as described below.

Code	Description
200 OK	Command completed successfully
301 MOVED	Requested URL has moved to another location
400 ERROR	The command encountered an error

Applet Interface

The applet graphical interface consists of the control panel (bottom left corner), the commands panel (bottom right), and the simulation view (top half).

The control panel consists of several buttons. Run will perform an automatic simulation of the protocol. Stop will halt the automatic simulation. Undo will revert back one step from the latest command. Redo will revert what undo does. Clear will clear off the current simulation, resulting in a clean simulation view. Load, Save and Print buttons are only available when the protocol simulator is launched in standalone mode, which are not available as we are using the applet mode.

The command panel displays the available commands at the current point of simulation. Clicking on one of the commands will progress the simulation seen in the simulation view.

Continue to Experiment #1 Instructions on the following page…

EXPERIMENT #1: RETRIEVING A WEB PAGE SUCCESSFULLY

This is the simplest example: fetching the data (which is the web page contents) of a particular URL (location). To do this the client will send a GET(url) command to the server, which will respond with a 200 response code along with the contents of the location specified in the GET command.

Click the Clear button to start a fresh simulation.
In the command panel, click on Client: GET(URL1) – get data for URL. You should be able to see in the simulation view a corresponding flow of this command from the client to the server via the medium. Notice that the available choices in the command panel change as the request is received at the server.
Now click the Server: 200 OK(DATA1) – send requested data. Similarly the simulation view reflects the response from server to the client.

The simulation is now complete for URL1. Observe the interaction between the client and server.

Capture a screenshot of your simulation that includes a date/time stamp or unique desktop element, and answer the following question.

Q1: In reality, what does the client represent? Relate the client/server interaction you observed in this experiment to a regular activity that occurs on the Internet.

EXPERIMENT #2: UNSUCCESSFUL RETRIEVAL OF A WEB PAGE

Repeat Experiment 1 again, but this time selecting Server: 400 Error(Code) – report requested data unavailable at the last step.

The simulation is now complete for URL1. Observe the interaction between the client and server.

Capture a screenshot of your simulation that includes a date/time stamp or unique desktop element, and answer the following question.

Q2: Identify a real scenario when this client and server interaction would occur.

Continue to Experiment #3 Instructions on the following page…

EXPERIMENT #3: REDIRECTION OF REQUESTED DATA

Repeat Step 1 and 2 of Experiment One, and then do the following

In command panel, select Server: 301 MOVED(URL2) – report moved URL.
Select Client: GET(URL2) – get data for new URL.
Select Server: 200 OK(DATA2) – send requested data.

Capture a screenshot of your simulation that includes a date/time stamp or unique desktop element, and answer the following question.

Q3: Observe the simulation and compare with the results in Experiment One. What is the difference in the flow, and what does it mean?

EXPERIMENT #4: POST INFORMATION TO WEB PAGES

It should be obvious that there are many types of interactions that a client might have with a web server. One such interaction is when a client appends data to the URL to be received by the server.

Start a new simulation similar to Experiment #1, but this time choose Client: POST(URL1, DATA1) for step 2.

Capture a screenshot of your simulation that includes a date/time stamp or unique desktop element, and answer the following question.

Q4: What is the key difference that you observe in the interaction?

Q5: Relate the client/server interaction you observed in this experiment to a regular activity that occurs on the Internet.

Submitting your work

In a new Word document, include your screenshots of the simulations for each experiment, along with your answers for each of the five questions. Save the file as Lastname_Firstname_Assignment #. Include your name in the assignment file itself and submit your file to Blackboard. Any assignment with screenshots that do not include a visible date and timestamp or a unique desktop element to identify the student’s work will not be accepted.