HTTP: Request

After the connection has been made, the client sends a request for information to the server. For requests, a form of address known as Uniform Resource Identifier (URI) is used. At the moment, URIs are identical to Uniform Resource Locators (URLs) but there is a possibility that Uniform Resource Names (URNs) will be defined in the future, in which case URIs could be either URLs or URNs (CERN 1995).

There are two types of HTTP requests.

A simple request consists of a single line (CERN 1995):

GET URI

followed by a carriage return/linefeed pair, where the URI is a valid Uniform Resource Identifier as described above.

A full request consists of the following lines (Richmond 1995):

Type of request, address, and protocol version

METHOD URI Protocol

where METHOD is chosen from the list below, URI is a valid Uniform Resource Identifier as described above, and Protocol is a string describing the protocol version in use (e.g. HTTP/1.0)

Any special instructions

a message with special
instructions for the server, if any

This message is in MIME format (van Heyn 1995).

There are several methods defined for the full request:

GET

Retrieve the data referenced by the URI

The following is an example of a GET request (Richmond 1995):

GET /cgi-bin/post-query?org=CyberWeb%20SoftWare
&users=10000&browsers=lynx&browsers=cello&browsers=mosaic
&others=MacMosaic%2C%20WinMosaic
&contact=Alan%20Richmond%20Web@Stars.com HTTP/1.0
Accept: www/source
Accept: text/html
Accept: video/mpeg
Accept: image/gif
Accept: application/postscript
User-Agent:  Lynx/2.2  libwww/2.14
From:  Web@Stars.com
        * a blank line *

In this GET, the first line specifies the method and the URL; the next three lines specify contact information; the next five lines specify the types of files that the client can accept, the next two lines identify the client's browser and email address, and then finally a blank line.

HEAD

Retrieve document headers only (text between <head> and </head), not document body.

CHECKOUT

Perform a GET, but secure a lock on the resource to prevent its updating until a CHECKIN

SHOWMETHOD

Return a description of a method

PUT

Store information in an already existing URI. PUT might be used to replace a remote file with a new version. According to (Richmond 1995):

The fundamental difference between the POST and PUT requests is reflected in the different meaning of the Request-URI. The URI in a POST request identifies the resource that will handle the enclosed entity as an appendage. That resource may be a data-accepting process, a gateway to some other protocol, or a separate entity that accepts annotations. In contrast, the URI in a PUT request identifies the entity enclosed with the request.

DELETE

Delete the information at a given URL
On success, the server will return either "200 OK", "202 Accepted", or "204 No Content"; if there is an error, an error code will be returned (Richmond 1995).

POST

Create a new object with the specified URI The following is an example of a post from a Lynx user with address Web@Stars.com (Richmond 1995):

POST /cgi-bin/post-query HTTP/1.0
Accept: www/source
Accept: text/html
Accept: video/mpeg
Accept: image/gif
Accept: application/postscript
User-Agent:  Lynx/2.2  libwww/2.14
From:  Web@Stars.com
Content-type: application/x-www-form-urlencoded
Content-length: 150
	* a blank line *
org=CyberWeb%20SoftWare
&users=10000
&browsers=lynx

In this POST, the first line specifies the protocol; the next five lines specify the types of files that the client can accept, the next two lines identify the client's browser and email address, and then finally a description of the content, a statement of content size, a blank line, and the message itself.

The POST method might be used (for example) to post a note to a Usenet newsgroup.

CHECKIN

Performs a PUT and releases the lock on the object if one was set by CHECKOUT.