Short for HyperText Transfer Protocol, the underlying protocol used

by the World Wide Web. HTTP defines how messages are formatted
and transmitted, and what actions Web servers and browsers should
take in response to various commands. For example, when you enter
a URL in your browser, this actually sends an HTTP command to the
Web server directing it to fetch and transmit the requested Web page.

The other main standard that controls how the World Wide Web
works is HTML, which covers how Web pages are formatted and
displayed.

HTTP is called a stateless protocol because each command is

executed independently, without any knowledge of the commands
that came before it. This is the main reason that it is difficult to
implement Web sites that react intelligently to user input. This
shortcoming of HTTP is being addressed in a number of new
technologies, including ActiveX, Java, JavaScript and cookies.

HTTP Protocol Overview

The HyperText Transfer Protocol (HTTP) is the de facto standard for

transferring World Wide Web documents, although it is designed to
be extensible to almost any document format. HTTP Version 1.1 is
documented in RFC 2068; version 1.0 (depricated) is documented in
RFC 1945.

HTTP operates over TCP connections, usually to port 80, though this
can be overridden and another port used. After a successful
connection, the client transmits a request message to the server,
which sends a reply message back. HTTP messages are human-
readable, and an HTTP server can be manually operated with a
command such as telnet server 80.

The simplest HTTP message is "GET url", to which the server replies
by sending the named document. If the document doesn't exist, the
server will probably send an HTML-encoded message stating this. I
say probably, because this simple method offers poor error handling
and has been deprecated in favor of the more elaborate scheme
outlined below.
A complete HTTP 1.0 message begins "GET url HTTP/1.0". The
addition of the third field indicates that full headers are being used.
The client may then send additional header fields, one per line,
terminating the message with a blank link. The server replies in a
similar vein, first with a series of header lines, then a blank line, then
the document proper.
Here a sample HTTP 1.0 exchange:
GET / HTTP/1.0 >
>
< HTTP/1.0 200 OK
< Date: Wed, 18 Sep 1996 20:18:59 GMT
< Server: Apache/1.0.0
< Content-type: text/html
< Content-length: 1579
< Last-modified: Mon, 22 Jul 1996 22:23:34 GMT
<
< HTML document
The use of full headers is preferred for several reasons:

• The first line of a server header includes a response code

indicating the success or failure of the operation.
• One of the server header fields will be Content-type:, which
specifies a MIME type to describe how the document should be
interpreted.
• If the document has moved, the server can specify its new
location with a Location: field, allowing the client to
transparently retry the request using the new URL.
• The Authorization: and WWW-Authenticate: fields allow access
controls to be placed on Web documents.
• The Referer: field allows the client to tell the server the URL of
the document that triggered this request, permitting savvy
servers to trace clients through a series of requests.

In addition to GET requests, clients can also send HEAD and POST
requests, of which POSTs are the most important. POSTs are used
for HTML forms and other operations that require the client to
transmit a block of data to the server. After sending the header and
the blank line, the client transmits the data. The header must have
included a Content-Length: field, which permits the server to
determine when all the data has been received.
 HTTP Properties

• A comprehensive addressing scheme

The HTTP protocol uses the concept of reference provided by
the Universal Resource Identifier (URI) as a location (URL) or
name (URN), for indicating the resource on which a method is
to be applied. When an HTML hyperlink is composed, the URL
(Uniform Resource Locator) is of the general form
http://host:port-number/path/file.html. More generally, a URL
reference is of the type service://host/file.file-extension and in
this way, the HTTP protocol can subsume the more basic
Internet services.
• Client-Server Architecture
The HTTP protocol is based on a request/response paradigm.
The communication generally takes place over a TCP/IP
connection on the Internet. The default port is 80, but other
ports can be used. This does not preclude the HTTP/1.0
protocol from being implemented on top of any other protocol
on the Internet, so long as reliability can be guaranteed.
• The HTTP protocol is connectionless and stateless
After the server has responded to the client's request, the
connection between client and server is dropped and forgotten.
There is no "memory" between client connections. The pure
HTTP server implementation treats every request as if it was
brand-new, i.e. without context.
• An extensible and open representation for data types
HTTP uses Internet Media Types (formerly referred to as
MIME Content-Types) to provide open and extensible data
typing and type negotiation. When the HTTP Server transmits
information back to the client, it includes a MIME-like (Multipart
Internet Mail Extension) header to inform the client what kind of
data follows the header. Translation then depends on the client
possessing the appropriate utility (image viewer, movie player,
etc.) corresponding to that data type.
HTTP

- HTTP (Hypertext Transfer Protocol) is the set of rules for

transferring files (text, graphic images, sound, video, and other multimedia
files) on the World Wide Web. As soon as a Web user opens their Web
browser, the user is indirectly making use of HTTP. HTTP is an application
protocol that runs on top of the TCP/IP suite of protocols (the foundation
protocols for the Internet).

HTTP concepts include (as the Hypertext part of the name

implies) the idea that files can contain references to other
files whose selection will elicit additional transfer requests.
Any Web server machine contains, in addition to the Web
page files it can serve, an HTTP daemon, a program that is
designed to wait for HTTP requests and handle them when
they arrive. Your Web browser is an HTTP client, sending
requests to server machines. When the browser user enters
file requests by either "opening" a Web file (typing in a
Uniform Resource Locator or URL) or clicking on a hypertext
link, the browser builds an HTTP request and sends it to the
Internet Protocol address (IP address) indicated by the URL.
The HTTP daemon in the destination server machine receives
the request and sends back the requested file or files
associated with the request. (A Web page often consists of
more than one file.)

A technical definition of the World Wide Web is: all the resources and users
on the Internet that are using the Hypertext Transfer Protocol (HTTP).

A broader definition comes from the organization that Web

inventor Tim Berners-Lee helped found, the World Wide Web
Consortium (W3C):

"The World Wide Web is the universe of network-

accessible information, an embodiment of human
knowledge."
 - A Web server is a program that, using the client/server model and
the World Wide Web's Hypertext Transfer Protocol (HTTP), serves the files
that form Web pages to Web users (whose computers contain HTTP clients
that forward their requests). Every computer on the Internet that contains a
Web site must have a Web server program. Two leading Web servers are
Apache, the most widely-installed Web server, and Microsoft's Internet
Information Server (IIS). Other Web servers include Novell's Web Server for
users of its NetWare operating system and IBM's family of Lotus Domino
servers, primarily for IBM's OS/390 and AS/400 customers.
A daemon (pronounced DEE-muhn) is a program that runs continuously and
exists for the purpose of handling periodic service requests that a computer
system expects to receive. The daemon program forwards the requests to
other programs (or processes) as appropriate. Each server of pages on the
Web has an HTTPD or Hypertext Transfer Protocol daemon that continually
waits for requests to come in from Web clients and their users.

In mythology, a daemon, according to Webster's, was "an

attendant power or spirit."

Daemon can be confused with demon, which has a different

but similar meaning. The New Hacker's Dictionary says that
a daemon is a program that runs by itself directly under the
operating system whereas a demon is part of a larger
application program.

1.4 Overall Operation

The HTTP protocol is a request/response protocol. A client

sends a request to the server in the form of a request
method, URI, and protocol version, followed by a MIME-like
message containing request modifiers, client information,
and possible body content over a connection with a server.
The server responds with a status line, including the
message's protocol version and a success or error code,
followed by a MIME-like message containing server
information, entity metainformation, and possible entity-
body content. The relationship between HTTP and MIME is
described in appendix 19.4.
Most HTTP communication is initiated by a user agent and
consists of a request to be applied to a resource on some
origin server. In the simplest case, this may be accomplished
via a single connection (v) between the user agent (UA) and
the origin server (O).
request chain ------------------------>
UA -------------------v------------------- O
<----------------------- response chain
A more complicated situation occurs when one or more
intermediaries are present in the request/response chain.
There are three common forms of intermediary: proxy,
gateway, and tunnel. A proxy is a forwarding agent,
receiving requests for a URI in its absolute form, rewriting all
or part of the message, and forwarding the reformatted
request toward the server identified by the URI. A gateway is
a receiving agent, acting as a layer above some other
server(s) and, if necessary, translating the requests to the
underlying server's protocol. A tunnel acts as a relay point
between two connections without changing the messages;
tunnels are used when the communication needs to pass
through an intermediary (such as a firewall) even when the
intermediary cannot understand the contents of the
messages.
request chain -------------------------------------->
UA -----v----- A -----v----- B -----v----- C -----v----- O
<------------------------------------- response chain
The figure above shows three intermediaries (A, B, and C)
between the user agent and origin server. A request or
response message that travels the whole chain will pass
through four separate connections. This distinction is
important because some HTTP communication options
may apply only to the connection with the nearest, non-
tunnel neighbor, only to the end-points of the chain, or to all
connections along the chain. Although the diagram is linear,
each participant may be engaged in multiple, simultaneous
communications. For example, B may be receiving requests
from many clients other than A, and/or forwarding requests
to servers other than C, at the same time that it is handling
A's request.
Any party to the communication which is not acting as a
tunnel may employ an internal cache for handling requests.
The effect of a cache is that the request/response chain is
shortened if one of the participants along the chain has a
cached response applicable to that request. The following
illustrates the resulting chain if B has a cached copy of an
earlier response from O (via C) for a request which has not
been cached by UA or A.
request chain ---------->
UA -----v----- A -----v----- B - - - - - - C - - - - - - O
<--------- response chain
Not all responses are usefully cacheable, and some requests
may contain modifiers which place special requirements on
cache behavior. HTTP requirements for cache behavior and
cacheable responses are defined in section 13.
In fact, there are a wide variety of architectures and
configurations of caches and proxies currently being
experimented with or deployed across the World Wide Web.
These systems include national hierarchies of proxy caches
to save transoceanic bandwidth, systems that broadcast or
multicast cache entries, organizations that distribute subsets
of cached data via CD-ROM, and so on. HTTP systems are
used in corporate intranets over high-bandwidth links, and
for access via PDAs with low-power radio links and
intermittent connectivity. The goal of HTTP/1.1 is to support
the wide diversity of configurations already deployed while
introducing protocol constructs that meet the needs of those
who build web applications that require high reliability and,
failing that, at least reliable indications of failure.
HTTP communication usually takes place over TCP/IP
connections. The default port is TCP 80 [19], but other ports
can be used. This does not preclude HTTP from being
implemented on top of any other protocol on the Internet, or
on other networks. HTTP only presumes a reliable transport;
any protocol that provides such guarantees can be used; the
mapping of the HTTP/1.1 request and response structures
onto the transport data units of the protocol in question is
outside the scope of this specification.
In HTTP/1.0, most implementations used a new connection
for each request/response exchange. In HTTP/1.1, a
connection may be used for one or more request/response
exchanges, although connections may be closed for a variety
of reasons (see section 8.1).
The HyperText Transfer Protocol (HTTP) is a
protocol (a set of rules that describe how
information is exchanged on a network) that allows
a web browser and a web server to "talk" to each
other using the ISO Latin1 alphabet, which is ASCII
with extensions for European languages.
HTTP is based on a request/response model. The
client connects to the server and sends a request to
the server. The request contains the following:
request method, URI, and protocol version. The
client then sends some header information. The
server's response includes the return of the protocol
version, status code, followed by a header that
contains server information, and then the requested
data. The connection is then closed.
The iPlanet Web Server 4.x supports HTTP 1.1.
Previous versions of the server supported HTTP 1.0.
The server is conditionally compliant with the HTTP
1.1 proposed standard, as approved by the Internet
Engineering Steering Group (IESG) and the Internet
Engineering Task Force (IETF) HTTP working group.
For more information on the criteria for being
conditionally compliant, see the Hypertext Transfer
Protocol—HTTP/1.1 specification (RFC 2068) at:

http://www.ietf.org/html.charters/http-
charter.html 

Requests
A request from a client to a server includes the
following information:

• Request method
• Request header
• Request data

Request Method
A client can request information using a number of
methods. The commonly used methods include the
following:

• GET—Requests the specified document

• HEAD—Requests only the header information
for the document
• POST—Requests that the server accept some
data from the client, such as form input for a
CGI program
• PUT—Replaces the contents of a server's
document with data from the client

Request Header
The client can send header fields to the server. Most
are optional. Some commonly used request headers
are shown in Table A.1.
Table A.1 Description
Common request
headers
Request header
Accept The file types the client can
accept.
Authorization Used if the client wants to
authenticate itself with a
server; information such as
the username and password
are included.
User-agent The name and version of the
client software.
Referer The URL of the document
where the user clicked on the
link.
Host The Internet host and port
number of the resource being
requested.
Request Data
If the client has made a POST or PUT request, it can
send data after the request header and a blank line.
If the client sends a GET or HEAD request, there is
no data to send; the client waits for the server's
response.

Responses
The server's response includes the following:

• Status code
• Response header
• Response data

Status Code
When a client makes a request, one item the server
sends back is a status code, which is a three-digit
numeric code. There are four categories of status
codes:

• Status codes in the 100-199 range indicate a

provisional response.
• Status codes in the 200-299 range indicate a
successful transaction.
• Status codes in the 300-399 range are
returned when the URL can't be retrieved
because the requested document has moved.
• Status codes in the 400-499 range indicate the
client has an error.
• Status codes of 500 and higher indicate that
the server can't perform the request, or an
error has occurred.

Table A.2 contains some common status codes.

Table A.2 Meaning
Common
HTTP status
codes
Status code
200 OK; successful transmission. This is
not an error.
302 Found. Redirection to a new URL.
The original URL has moved. This is
not an error; most browsers will get
the new page.
304 Use a local copy. If a browser
already has a page in its cache, and
the page is requested again, some
browsers (such as Netscape
Navigator) relay to the web server
the "last-modified" timestamp on
the browser's cached copy. If the
copy on the server is not newer
than the browser's copy, the server
returns a 304 code instead of
returning the page, reducing
unnecessary network traffic. This is
not an error.
401 Unauthorized. The user requested a
document but didn't provide a valid
username or password.
403 Forbidden. Access to this URL is
forbidden.
404 Not found. The document requested
isn't on the server. This code can
also be sent if the server has been
told to protect the document by
telling unauthorized people that it
doesn't exist.
 • Introducing HTTP
o HTTP Request Methods
o HTTP Communications
• HTTP Transactions
o Complex HTTP Transactions
o Sample HTTP Transaction
• HTTP Request Fields
• Internationalization
o Character Set Parameters
• HTTP Status Codes
• HTTP Reference

HyperText Transfer Protocol

Introducing HTTP

Web browsers and servers communicate with each other

using the HyperText Transfer Protocol (HTTP). The World Wide
Web has used HTTP since 1990.
Practical information systems require more functionality than
simple retrieval, including search, front-end update, and
annotation. HTTP allows an open-ended set of methods that
indicate the purpose of a request. It builds on the reference
provided by the Uniform Resource Identifier (URI), as a
location (URL), or name (URN), for indicating the resource on
which a method is to be applied.
This generic, object-oriented protocol accommodates
distributed, collaborative hypermedia information systems. A
feature of HTTP is the typing and negotiation of data
representation, allowing systems to be built independently of
the data being transferred.
HTTP is also used as a generic protocol for communication
between user agents and proxies/gateways to other Internet
protocols. Such Internet protocols include SMTP, NNTP, FTP,
Gopher, and WAIS that have already been in use on the
Internet. Through these protocols, HTTP, allows basic
hypermedia access to resources available from diverse
applications and simplifies the implementation of user
agents.
When sending a request to the server, the browser includes
a list of the file types it understands. The server can then
ensure that it transmits the document as one of those file
types. This means that servers and browsers can cope with
the existing mass of graphic formats such as GIF, TIFF, and
JPEG, to name but a few. You can also exchange all types of
data using HTTP. For example, you can exchange documents
that contain text, graphics, sound, and video.
The Web uses HTTP for many tasks, such as name servers
and distributed object management systems, through
extension of its request methods.

HTTP Request Methods

HTTP allows the use of an open-ended set of methods to

indicate the purpose of a request. It uses information
provided in the Uniform Resource Locator (URL) to find a
resource. HTTP passes messages in a format similar to that
used by Internet Mail and the Multipurpose Internet Mail
Extensions (MIME), the form used for Internet mail.
Every time a browser requests a document, it sends the
server a list of the MIME types it can support. The server
maps file types and file extensions to standard MIME data
types. In this manner, Web browsers and servers can
negotiate the file type that is transmitted between them.
MIME conventions include a major type name and then a
subtype name, separated by a slash, to identify file types.
For example, the file type for a text file in the HyperText
Markup Language (HTML) is identified as text/html, and a
.GIF image file is identified as image/gif.
HTML uses the MIME type text and the subtype html (written
as text/html). Web servers and browsers support many other
data types such as image/gif.
 See the chapter entitled Multipurpose Internet Mail
Extensions for more information.

HTTP Communications

HTTP communications employs a disciplined and consistent

system for referencing different resources through the use of
Uniform Resource Locators (URLs). See the earlier chapter in
this book and RFC 1738 for more information about URLs.
HTTP also:

• Enables users to navigate quickly and easily across a vast network of

multimedia resources.
• Accommodates several commands or methods to perform a variety of
tasks on an object identified by the URL, for instance, the GET,
HEAD, or POST commands:
o GET means retrieve whatever data the URI identifies. For
example, a URI might refer to a data-producing process, or a
script that can be run by that process. In this case the server
returns the data, not the source text of the script or process.
o HEAD means the same as GET except the server returns only
the document headers, it does not return the document body.
o POST creates a new object that the server links to the specified
object. The message identification field of the new object can
be set by the client or the server. The server assigns a URL to
the new object and sends the URL to the client. The new
document becomes the data part of the request. This document
is subordinate to the object specified in the request just like a
news article is subordinate to a newsgroup to which the article
is posted.

HTTP Transactions

All HTTP transactions take place over a TCP/IP connection

and usually through the default port 80. An HTTP transaction
consists of four phases. The following sequence outlines a
simple HTTP transaction.

Connection
In this phase, the browser attempts to connect with the Web
server. You can observe this happening on most browsers by
watching the status line for a message indicating that it is
connecting to the HTTP server.

Request

Once the connection between the browser and server

occurs, the browser sends a request to the server. This
request specifies:

• The protocol to use. The protocol can be any one of a number of

protocols such as HTTP, FTP, NNTP, Gopher, or WAIS.
• The object the client is looking for.
• How the client wants the server to respond. This is often the method
GET but could be any one of a number of other methods. The server
usually sends an error message if it cannot respond.
• The protocol version in use.
• Modifiers, client information, and the content of the request in a
MIME-like message.

You can use your Web browser to get information about the various
HTTP methods at:
http://www.w3.org/hypertext/WWW/Protocols/HTTP/Methods.html
Every time a browser requests a page, it sends the server a
list of the MIME types it can support.

Response

When the server fulfills the request it sends a response to

the client. At this stage, your browser might display a
"reading response" message on the status line. Again,
depending on your browser, you might see a "transferring"
message on the status line.
The server responds with a status line, including the
message’s protocol version and a success or error code,
followed by a MIME-like message containing server
information, entity meta information, and possible body
content.
The server tries to send only the MIME types the browser
supports. The server responds first with the MIME type of the
data that it is sending, then it sends the data.

Close

After the server sends the response, either the client, the
server, or both close the connection.
As shown in Figure 7, most HTTP communications are
initiated by a user agent and consist of a request to be
applied to a resource on some origin server. In the simplest
case, this may be accomplished through a single connection
between the user agent and the origin server.
Figure 7 Simple HTTP Communication Transaction

Complex HTTP Transactions

This allows hypermedia access to existing Internet protocols

like FTP (File Transfer Protocol), NNTP (Network News Transfer
Protocol), Gopher, and WAIS (Wide Area Information Server).
HTTP also allows communication between user agents and
gateways to go through a proxy server without any loss of
data.
A more complicated situation than described in the last
section occurs when one or more intermediaries are present
in the request/response chain. There are three common
forms of intermediary: proxy, gateway, and tunnel.
 • Proxy — A proxy is a forwarding agent, receiving requests for a URI
in its absolute form, rewriting all or parts of the message, and
forwarding the reformatted request toward the server identified by the
URI.
• Gateway — A gateway is a receiving agent, acting as a layer above
some other servers and, if necessary, translating the requests to the
underlying server's protocol.
• Tunnel — A tunnel acts as a relay point between two connections
without changing the messages; tunnels are used when the
communication needs to pass through an intermediary (such as a
firewall) even when the intermediary cannot understand the contents
of the messages.

In Figure 8, three intermediaries between the user agent and

origin server are shown. A request or response message that
travels the whole chain MUST pass through four separate
connections. This distinction is important because some
HTTP communication options could apply:

• Only to the connection with the nearest, non-tunnel neighbor

• Only to the end-points of the chain
• To all connections along the chain

Note that each participant could be engaged in multiple,

simultaneous communications. For example, B could be
receiving requests from many clients other than A,
forwarding requests to servers other than C, plus handle
requests from A.
Figure 8 Complex HTTP Communication Transaction
Any party to the communication that is not acting as a
tunnel can employ an internal cache for handling requests.
The effect of a cache is that the request/response chain is
shortened if one of the participants along the chain has a
cached response applicable to that request.
Figure 9 shows the resulting chain if B has a cached copy of
an earlier response from the Origin server (via C) for a
request that has not been cached by User Agent or A.
Figure 9 Complex HTTP Communication Transaction
With Caching

Not all responses are cacheable, and some requests might

contain modifiers that place special requirements on cache
behavior.

Sample HTTP Transaction

HTTP Request
Client : GET DEFAULT.HTM HTTP/1.0
Accept: text/plain
Accept: image/gif/
Accept: image/x-portable-bitmap
User-Agent: NCSA WinMosaic 1.0
HTTP Response
Server : HTTP/1.0 200 OK
MIME-Version: 1.0
Content-Type: text/html
Date: Thursday, 3-AUG-96 23:37:8 GMT
Content-Length: 1618
<TITLE>PURVEYOR ENCRYPT WEBSERVER</TITLE>

HTTP Request Fields

The client can send any one or more of the following header
lines in a HTTP protocol transaction. The list of headers is
terminated by an empty line. Table 5 lists some commonly
used header request fields. Note that the HTTP protocol lists
many more header fields. Refer to the URL
http://www.w3.org/hypertext/WWW/Protocols/ for
additional information.
Table 5 Commonly Used Header Request Fields
Header Description
From In Internet mail format, the name of the
requesting user. The Internet mail address in this
field does not have to correspond to the internet
host that issued the request.

For example, when a request is passed through a

gateway, then the original issuer's address should
be used.
Accept This field contains a list of Content-Type values
the client can accept in the response to this
request.

Example: Accept: text/plain, text/html

If no Accept field is present, then it is assumed

that text/plain and text/html are accepted. The set
given may vary from request to request from the
same user.
Accept- Similar to Accept, but lists the Content-Encoding
Encoding types which are acceptable in the response. For
example:
Accept-Encoding: x-compress or

Accept-Encoding: x-zip
Accept- Lists the Language values preferable in the
Language response. A response in an unspecified language
is not illegal.
User-Agent If present gives the software program used by the
original client. This is for statistical purposes and
to trace protocol violations.

For example: User-Agent: LII-Cello/1.0 libwww/2.5

Referer This optional header field allows the client to
specify, for the server's benefit, the address
( URI ) of the document from which the URI in the
request was obtained.

This allows a server to generate lists of back-links

to documents, for interest, logging, etc. It allows
bad links to be traced for maintenance. For
example,
Referer:
http://www.w3.org/hypertext/DataSources/Overvie
w.html
Authorization If this line is present, it contains authorization
information.
Basic scheme Password and IP address protection; part of the
WWW Common Library
User/Passwor Typically from a USER environment variable or
d prompted for, with an optional password
separated by a colon. Without a password, this
provides very low level security. With the
password, it provides a low-level security. For
example, Authorization: user fred:mypassword
Charge-To If present contains account information for the
costs of the application of the method requested.
If-Modified- This request header is used with the GET
Since command to make it conditional. If the requested
document has not changed since the time
specified in this field the document is not sent.
Instead, a Not Modified 304 reply is sent.
Pragma Pragma directives should be understood by
servers to which they are relevant, e.g. a proxy
server. Currently only one pragma is defined: no-
cache

When present, the proxy server should not return

a document from the cache even though it has
not expired, but it should always request the
document from the actual server.

Pragmas should be passed through by proxies

even though they might have significance to the
proxy itself. This is necessary in cases when the
request has to go through many proxies, and the
pragma should affect all of them.

Internationalization

A large portion of information available on the Web is in

English and the western-European writing system; however,
use of other writing systems and languages is increasing.
Organizations and standards groups are enhancing the Web
protocols, standards, and tools to meet global community
needs. Much of this work centers around language
negotiation and character set encoding.

Character Set Parameters

Documents transmitted with HTTP that are of type text/*

(text/html, text/plain, etc.) can have a charset parameter,
that specifies the character encoding of the document. The
default for text/html is ISO-8859-1; for other text documents
it is US-ASCII.
Any character encoding that has been registered with IANA
can be used. However, it may be too much to ask of a
browser to understand all of them.

HTTP Status Codes

The HTTP status codes fall into five categories. See Appendix
A for a list of the codes in each category. Basically, the
categories are:

• Informational (100 codes) — This class of status code indicates a

provisional response, consisting only of the Status-Line and optional
headers, and is terminated by an empty line. Since HTTP/1.0 did not
define any 1xx status codes, servers must not send a 1xx response to
an HTTP/1.0 client except under experimental conditions.
• Successful (200 codes) — This class of status code indicates that the
client's request was successfully received, understood, and accepted.
• Redirection (300 codes) — This class of status code indicates that
further action needs to be taken by the user agent in order to fulfill the
request. The action required may be carried out by the user agent
without interaction with the user if and only if the method used in the
second request is GET or HEAD.
• Client Error (400 codes) — The 4xx class of status code is intended
for cases in which the client seems to have erred. If the client has not
completed the request when a 4xx code is received, the client ceases
sending data to the server. Except when responding to a HEAD
request, the server includes an entity containing an explanation of the
error situation, and whether it is a temporary or permanent condition.
• Server Error (500 codes) — The 5xx class of status codes indicate
cases in which the server is aware that it has erred or is incapable of
performing the request. If the client has not completed the request
when it receives a 5xx code, it should immediately cease sending data
to the server. Except when responding to a HEAD request, the server
should include an entity containing an explanation of the error
situation, and whether it is a temporary or permanent condition.