log in | register | forums


User accounts
Register new account
Forgot password
Forum stats
List of members
Search the forums

Advanced search
Recent discussions
- Gerph's live coding session on Youtube (News:1)
- Rougol June 2024 meeting on monday (News:1)
- WROCC June 2024 meeting - Mark Moxon dissects Lander (News:1)
- WROCC June 2024 meeting on wednesday - Mark Moxon on Lander (News:1)
- June developer 'fireside' chat is on saturday night (News:)
- May 2024 News Summary (News:5)
- Archive Edition 27:2 reviewed (News:)
- RISC OS 5.30 arrives (News:12)
- Rougol Talk May 2024 - Andy Vawer (News:)
- Rougol May 2024 meeting on monday with Andy Vawer (News:1)
Related articles
- Cookies: an introduction
- HTTP Status Code Definitions
- CGI Scripting
- WML Resources
- Network Programming on RISC OS
- PackMan in practice, part 2
- PackMan in practice
- Power Switching a RaspberryPi
- Video conversion on RISC OS
- Building the Dream 4 - Random city basics
Latest postings RSS Feeds
RSS 2.0 | 1.0 | 0.9
Atom 0.3
Misc RDF | CDF
View on Mastodon
Site Search
Article archives
The Icon Bar: News and features: HTTP: an introduction

HTTP: an introduction

Posted by Geoff Potter on 22:44, 29/6/2001 | , ,
The HTTP (or HyperText Transfer Protocol) is designed for two way communication between a web server and a client, usually a web browser.
It caters for downloading of files, submission of data, uploading of files, deleting of files, retrieving information about both individual files and the server. It has the potential to allow people to read versions in their own language, retrieve filetypes suitable for their browsers, allow multiple web sites to run on one computer, have a request 'bounced' through any number of proxy servers, offer to accept a cached version of a file, demand a new version of the file and even run over a secured connection.
Do not even consider basing any implementation of an HTTP client or server on this description - it is liable to be innacurate, misleading and is only intended as a basic overview. Base any implementation on the official HTTP Specification from W3C. If you wish to write a client on RISC OS, it is much better to use the Acorn URL modules, which include a transparent interface for fetching URIs of any supported protocol, rather than reimplementing a client at socket level.

How it works

At a basic level it works with one client and one server, with the client generating a request and in return receiving a response. Resquests for information are always generated by the client; it is thus a request/response protocol, rather than a broadcast protocol where the server initiates the transaction.
The protocol works by a client initiating a TCP/IP connection (via a standard socket) with a port (usually 80) on the server and then sending a request header, optionally accompanied by a request body. The server will respond with a response header, again optionally accompanied by a response body. In the event of a Keep-Alive or persistant connection, the connection may be kept open and another request sent by the client, otherwise the connection will be closed.

Request Headers

The request header takes the form of method (which could be GET, POST, PUT, OPTIONS, HEAD, DELETE, TRACE, CONNECT or an extension method) followed by a space, followed by the URI, followed by a space followed by the HTTP version followed by a CR LF. e.g.

GET / HTTP/1.1

This is followed by any number of request header lines, which take the form Header name followed by a colon followed by a space followed by the value and terminated by a CR LF. e.g.
Host: www.iconbar.com

Which coupled with the above would request the index page from iconbar.com. When the headers are finished, then the client sends a blank line again terminated by a CR LF to indicate that it has finished.
The server will now process the headers and act accordingly - if the request was a PUT or a POST request, it will read the amount of data specified in the Content-Length header first, otherwise it will move onto response headers.

Request Body

After the header has been sent for a POST or a PUT request, the client will send the appropriate data, the length of which has already been specified with a Content-Length header.

Response Headers

This starts by specifying the HTTP protocol version followed by a space, followed by a statuc code, followed by a textual description of the status code followed by CR LF. e.g.

HTTP/1.1 200 OK

The status codes are in grouped as follows:
  • 1xx: Informational - Request received, continuing process
  • 2xx: Success - The action was successfully received, understood, and accepted
  • 3xx: Redirection - Further action must be taken in order to complete the request
  • 4xx: Client Error - The request contains bad syntax or cannot be fulfilled
  • 5xx: Server Error - The server failed to fulfill an apparently valid request
This is then followed by any number of response header lines, dependant on the code. These follow the same format as request header lines.
The server should then supply the blank line terminated by CR LF to indicate the end of the header.
If the request is successful then the server will usually also supply a response body.

Response Body

After the header has server will send appropriate data, the length of which has already been specified with a Content-Length header. Exceptions may include when an error occurs (4xx, 5xx), response redirection (3xx), responses in the 1xx range or when the request didn't generate data, e.g a HEAD request which is only permitted to return the headers.

Commonly used methods


The GET method is probably the most commonly used and is used to fetch a request URI. It returns the response headers and the entity refered to by the URI. The returned data may be cacheable.


The HEAD method allows a client to verify whether data is still valid. It should return headers identical to those that would be returned by a GET response under the same conditions, but must not return the response body.


The POST method allows a client to post data to the server. This is generally used alongside the CGI protocol to process data from a form. The response should not be cacheable unless the reponse specifically includes a appropriate Expires or Cache-Control headers.

Commonly Used Status Codes

Status CodeExample Textual Description
300Multiple Choices
301Moved Permanently
400Bad Request
404Not Found
500Internal Server Error
501Not Implemented

Useful links

Log in to comment on this article

The Icon Bar: News and features: HTTP: an introduction