BA372 - HTTP

BA372 - HyperText Transfer Protocol ( HTTP)

HTTP is a protocol: Stamper, D.A. (1999) Business Data Communications: "convention used for establishing (data) transmission rules." (p. 599).

Spainhour & Eckstein (p.379). "Hypertext Transfer Protocol is the language web clients and servers use to communicate with each other."

Protocol for letting Web clients (e.g., browsers) and Web servers communicate; client-server model.

Basic understanding is a must(!) for a basic understanding of how the Web works.

Some HTTP is "filtered back" to users through error message in browsers; e.g., 404 Error: File or Directory Not Found.

Created by Tim Berners-Lee.

Goverened by the W3C.

Newest version: HTTP 1.1.

Three parts to each HTTP client request and each HTTP server response:
1. Request or response line: specifies the contents of the request or the status of the response, respectively.
2. Headers (optional): specifies configurations, acceptable formats, and lots of other things the browser and the server want to tell each other; e.g., the date and time the file was last modified; whether the file may be cached or not, etc.
3. Body (optional): additional data; e.g., the actual data passed back from the HTTP server or any data the server must know in order to execute a request.
Example of an HTTP transaction:

HTTP client initializes transaction: http://classes.bus.oregonstate.edu/ba471/index.htm

Request line: <method> <document address> <HTTP version number>
GET classes.bus.oregonstate.edu/ba471/index.htm HTTP/1.1
- GET: request method (Get me the data represented by the URL).
- classes.bus.oregonstate.edu: domain name of the OSU COB web server (IP address: 128.193.76.45).
- ba471/index.htm: off of the server's document root folder, get me the index.htm file which is in the ba471 sub folder.
- HTTP/1.1: I, browser, speak HTTP 1.1. Please do not send me anything back more recent than HTTP 1.1.
Headers:

User-Agent: Mozilla/4.7(WinNT; I)
Accept: image/gif, image/jpeg, image/x-bitmap, text/html

Body: nothing (body content is optional).

HTTP server responds:

Response line: <HTTP version> <status code> <status description>

HTTP/1.1 200 OK

Response Code	Response Meaning
100 - 199	General information
200 - 299	Client request successful
300 - 399	Client request redirected, action necessary
400 - 499	Error; e.g., client request incomplete or file not found
500 - 599	Server errors

Headers:

Date: Thu. 25 May 2006 09:21:56 UTC
Server: Apache/1.3.12
Last-Modified: Wed. 24 May 2006 08:18:54 UTC
Content-Type: text/html
Content-Length: 6517

Problem: Let's look at some response headers sent by HTTP servers (command: wget -S <URL>, Windows version available from GNU).

Body: any content; most often HTML, XML or ordinary text.

HTTP is a so-called stateless protocol: each transaction is independent of the previous ones; i.e., the process has no memory!!.

Simplicity: browsers and servers do not need to keep information around.

Would get complex with multiple users.

Don't know how long info must be kept around.

The vast majority of HTTP transactions do not require state maintenance.

However, multistep conversations are not stateless; e.g., booking a flight, buying a book on the Web:

Example: buy a book on the Web:

Client issues request for information about book X.

Server replies with price and availability.

Client issues request to put the book in the shopping cart.

Problem: Can you devise one or more workarounds? Keep in mind that you are not allowed to change HTTP so that it can maintain state.

For each workaround think of advantages and disadvantages.

memory-to-go: The server passes all the information back to the client and forgets about the client. But at the next request, the client passes everything it received to the server again, plus any new information it must submit.

Rather than endowing either the client or the server with memory, we accumulate memory as we carry it back and forth between client and server.

How to pass this information back and forth?

From client to server:

GET method passes variable=value combinations in the URL;

http://www.sec.gov/cgi-bin/browse-edgar?company=&CIK=SUNW&filenum=&State=&SIC=&owner=include&action=getcompany

http://www.mapquest.com/maps/map.adp?formtype=address&=Nw%20Jasmine%20Pl&city=Corvallis&state=OR&zipcode=97330&country=US

http://www.google.com/search?hl=en&q=foo

POST method passes variable=value combinations in the body of the HTTP client request.

Note that browse-edgar, map.adp and search are programs(!!) that are invoked by the Web server.

It is these programs' task to 'grab hold' of the information passed in through GET or POST and process that information accordingly.

GET & POST & HTML forms:

The server can send the client an HTML form for collection of variable=value pairs.

e.g.; (excerpted) page source for http://www.teachengineering.com/search.php:

search_results.php is the program that the server will call.

Variables passed are simple and and_or (note how and_or is set to either or or and).

Notice how the HTTP request method is set to POST. Hence, the variable=value pairs are not echoed on the URL line of the browser.

From server to client:

The server can pass information in <input type="hidden"> tags in an HTML form.

These input fields, although part of the HTML page, won't be rendered on the client.

But because they are <input> tags, their values are being sent back to the server on submission of the form as variable=value pairs.

pass the buck: ask something else to do the memorizing:

Store memory client-side: cookies:

Server includes information to be remembered in the Set-cookie response header:

Set-Cookie: mysite.com_id=1234567890

If client is cookie enabled, cookie is stored in client's cookies file (persistent).

At next client request to the same IP/domain name, cookie information is included as Cookie request header(s):

Cookie: mysite.com_id=1234567890

Let's see who's giving us cookies:

wget -S www.ebay.com

wget -S www.amazon.com

Problem: what are some advantages/disadvantages of the cookie model?

Store memory server-side:

The program called by the server (passed in the URL) can organize server-side storage:

file system.

database.

Follow-up program calls would first do a lookup to 'restore' memory.

Problem: what are some advantages/disadvantages of the cookie model?

A few loose ends:

/cgi-bin/ in

http://www.sec.gov/cgi-bin/browse-edgar?company=&CIK=SUNW&filenum=&State=&SIC=&owner=include&action=getcompany

CGI or Common Gateway Interface: oldest way to call a secondary program from an HTTP server.

(CGI) Program can be written in any programming language.

CGI program is an independent executable.

HTTP server calls the program and passes it all input information:

GET: variable=value pairs are stored in the QUERY_STRING environment variable.

POST: variable=value pairs are in the body of the HTTP request; body is passed to CGI program on stdin.

HTTP server 'listens' to CGI program's stdout.

CGI program outputs:

Content-type: text/html HTTP response header.

An empty line to terminate the header(s).

Whatever must be passed in the body of the HTTP response; e.g., HTML.

Server's configuration file contains a directive to execute all requests for /cgi-bin/... programs as CGI.

Problem: what are some advantages/disadvantages of the CGI model?

No CGI privileges on ONID Web server.

Demo: foo.c & FOO on vapor.osuosl.org.