HTTP

Common language through which client browsers and web servers communicate
CGI is built on top of HTTP
Understanding HTTP provides the bigger picture for understanding how CGI operates

URLs

In addition to the location of a web resource, an URL can specify parameters to be passed with a page request
CGI scripts can access the parameter information and use it to build the returned page
Parameters are separated from the page location by a question mark (?)

Query string passes additional parameters to a CGI script
Sometimes referred to as search string or index
Parameters are passed with the request as name-value pairs, separated by ampersands (&)
```
month=july&week=3
```
Names and values are separated by an equals sign (=)
Query strings can also include data that is not formatted as name-value pairs
If a query string does not contain an equals sign, it is often referred to as an index

HTTP is not a secure protocol
Third parties can eavesdrop on HTTP transactions and record passwords, credit card numbers, etc.
Secure Sockets Layer (SSL) provides a secure communication channel that HTTP can operate across
SSL connections are created when an URL begins with "https" instead of "http"
Transparently managed by web servers

Each response is preceded by a request
All messages have a header-body structure
- Header contains meta-information
- Body contains content of the message

Format of HTTP messages based on email conventions
First line called request line in requests and status line in responses
Remainder contains name-value pairs (header fields)
If a header field has multiple values, they are separated by commas (could also use multiple header fields)
Field names are not case sensitive
Header fields don't have to appear in any special order
Header separated from content by a blank line

Intended only to receive resources
Should not have side-effects (i.e. alter information on the web server)
POST should be used for that purpose
If multiple requests are made for the same document
- GET returns a new copy
- POST returns a message that document is no longer available in cache
- GET could cause same request (e.g. an order) to be executed multiple times

Used to submit information that alters data stored on web server
Includes a body with submitted information formatted like a query string
Additional header fields required for length and type of content
POST used for various reasons
- Flawed belief that POST requests are more secure, because users cannot modify values in URL
- Responses cannot be bookmarked

Host
Target host name
Content-Length
Length of request content
Content-Type
MIME type of request (e.g. application/x-www-form-urlencoded)
Authentication
User namd and password of user requesting a resource from a restricted areas of the web site
User-Agent
Name, version, platform of client
Referer
URL that referred user to current resource (i.e. which contained link to this page)
Cookie
Name-value pair set on a previous response (typically by the server)
Accept
Categories of responses the browser is capable of understanding (see Content Negotiation)

Content-Base
Base URL for resolving relative URLS
Content-Length
Length of body
Content-Type
MIME type of body
Date
Date and time response was sent
ETag
Entity tag for requested resource (used for caching; analogous to hash or checksum)
Last-Modified
Date and time resource was last modified (inteded to support caching, but based on static files)
Location
New location for resource (redirects browser to new location)
Server
Name and version of web server
Set-Cookie
Name-value pair that browser should send back with future requests
WWW-Authenticate
Authorization scheme and realm (see Security)

We can think of a proxy as a combination of a simplified client and a server
Raises the problem of differentiating users who access web server from behind a firewall
Caching can cause problems for dynamic content (avoid by indicating that a response should not be cached)

Users access the Web using different languages, different character sets, different browsers
One representation of a document will not satisfy requirements of all these users
Content negotiation allows clients and servers to negotiate best possible format
Primary forms: language, character set, MIME type, encoding

Client sends header field indicating forms of content it accepts
Server responds by selecting one of these options by returning the resource in the appropriate format

Example header field for MIME type:

Accept: text/html,text/plain,image/jpeg,image/gif,*.*

Server are expected to examine the MIME types and return data in the format preferred by the browser
Order of MIME types determines their priority

Internationalization is another use where content negotiation plays an important role

Accept-Language and Accept-Charset header fields

Accept-Language: ru, en-gb, en
Accept-Charset: iso-8859-5, iso-8859-1

This example states the following preferences:
- Russian over English (UK) and English (American)
- Cyrillic character set over Western Roman