next up previous contents
Next: MIME (Multipurpose Internet Up: Hypertext Transfer Protocol Previous: Hypertext Transfer Protocol

The HTTP Protocol

   The request is sent with a first line containing the method to be
   applied to the object requested, the identifier of the object, and
   the protocol version in use, followed by further information
   encoded in the RFC822 header style. The format of the request is:

        Request           =     SimpleRequest | FullRequest

        SimpleRequest     =     GET <uri> CrLf

        FullRequest       =     Method UR ProtocolVersion CrLf
                                [*<HTRQ Header>]
                                [<CrLf> <data>]

        <Method>          =     <InitialAlpha>

        ProtocolVersion   =     HTTP/V1.0

        uri               =     <as defined in URL spec>

        <HTRQ Header>     =     <Fieldname> : <Value> <CrLf>

        <data>            =      MIME-conforming-message

The URI is the Uniform Resource Locator (URL) as defined in the specification, or may be (when it is defined) a Uniform Resource Name (URN) when a specification for this is settled, for servers which support URN resolution.

Unless the server is being used as a gateway, a partial URL shall be given with the assumptions of the protocol (HTTP:) and server (the server) being obvious.

The URI should be encoded using the escaping scheme described in the URL specification to a level such that (at least) spaces and control characters (decimal 0-31 and 128-159) do not appear unesacaped.

Note. The rest of an HTTP url after the host name and optional port number is completely opaque to the client: The client may make no deductions about the object from its URL.

Protocol Version

The Protocol/Version field defines the format of the rest of the request.. At the moment only HTRQ is defined .

If the protocol version is not specified, the server assumes that the browser uses HTTP version 0.9.

Uniform Resource Identifier

This is a string identifying the object. It contains no blanks. It may be a Uniform Resource Locator [ URL ] defining the address of an object as described in RFCxxxx, or it may be a representation of the name of an object (URN, Universal Resource Name) where that object has been registered in some name space. At the time of writing, no suitable naming system exists, but this protocol will accept such names so long as they are distinguishable from the existing URL name spaces.


Method field indicates the method to be performed on the object identified by the URL. More details are with the list of method names below .

Request Headers

These are RFC822 format headers with special field names given in the list below , as well as any other HTTP object headers or MIME headers.

Object Body

The content of an object is sent (depending on the method) with the request and/or the reply.


The Method field in HTTP indicates the method to be performed on the object identified by the URL. The method GET below is always supported, The list of other methods acceptable by the object are returned in response to either of these two requests.

This list may be extended from time to time by a process of registration with the design authority. Method names are case sensitive. Currently specified methods are as follows:

   The response from the server shall start with the following syntax
   (See also:  note on client tolerance ):
  <status line>   ::=    <http version>  <status code>  <reason line>
  <http version>  ::=    3*<digit>
  <status code>   ::=    3*<digit>
  <digit>         ::=    0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
  <reason line> ::=   * <printable>

  <http version>         identifies the HyperText Transfer Protocol
                         version being used by the server.  For the
                         version described by this document version it
                         is  "HTTP/1.0" (without the quotes).
  < status code >         gives the coded results of the attempt to
                         understand and satisfy the request. A three
                         digit ASCII decimal number.
  <reason string>         gives an explanation for a human reader,
                         except where noted for particular status
   Fields on the status line are delimited by a single blank (parsers

   should accept any amount of white space). The possible values of
   the status code are listed below .
Response headers

   The headers on returned objects those RFC822 format headers listed
   as object headers , as well as any MIME conforming headers, notably
   the Content-Type field.  Note that this specification doesnot
   define any headers particular to the response which are not also
   appropriate to any transmission of an object with a request.
Response data

   Additional information may follow, in the format of a MIME message
   body. The significance of the data depends on the status code.
   The Content-Type used for the data may be any Content-Type which
   the client has expressed his ability to accept, or text/plain, or
   text/html. That is, one can always assume that the client can
   handle text/plain and text/html.
Status codes

   The values of the numeric status code to HTTP requests are as
   follows. The data sections of messages Error, Forward and
   redirection responses may be used to contain human-readable
   diagnostic information.
   These codes indicate success. The body section if present is the
   object returned by the request. It is a MIME format object. It is
   in MIME format, and may only be in text/plain, text/html or one fo
   the formats specified as acceptable in the request.
    OK 200
   The request was fulfilled.
    CREATED 201
   Following a POST command, this indicates success, but the textual
   part of the response line indicates the URI by which the newly
   created document should be known.
    Accepted 202
   The request has been accepted for processing, but the processing
   has not been completed.  The request may or may not eventually be
   acted upon, as it may be disallowed when processing actually takes
   place. there is no facility for status returns from asynchronous
   operations such as this.

    Partial Information 203
   When received in the response to a GET command, this indicates that
   the returned metainformation is not a definitive set of the object
   from a server with a copy of the object, but is from a private
   overlaid web. This may include annotation information about the
   object, for example
   The 4xx codes are intended for cases in which the client seems to
   have erred, and the 5xx codes for the cases in which the server is
   aware that the server has erred.  It is impossible to distinguish
   these cases in general, so the difference is only informational.
   The body section may contain a document describing the error in
   human readable form. The document is in MIME format, and may only
   be in text/plain, text/html or one for the formats specified as
   acceptable in the request.
    Bad request 400
   The request had bad syntax or was inherently impossible to be
    Unauthorized 401
   The parameter to this message gives a specification of
   authorization schemes which are acceptable.  The client should
   retry the request with a suitable Authorization header.
    PaymentRequired 402
   The parameter to this message gives a specification of charging
   schemes acceptable.  The client may retry the request with a
   suitable ChargeTo header.
    Forbidden 403
   The request is for something forbidden. Authorization will not
    Not found 404
   The server has not found anything matching the URI given
    Internal Error 500
   The server encountered an unexpected condition which prevented it
   from fulfilling the request.
    Not implemented 501

   The server does not support the facility required.
   The codes in this section indicate action to be taken (normally
   automatically) by the client in order to fulfill the request.
    Moved 301
   The data requested has been assigned a new URI, the change is
   permanent. (N.B. this is an optimisation, which must,
   pragmatically, be included in this definition.  Browsers with link
   editing capability should automatically relink to the new reference,
   where possible)
   The response contains one or more header lines of the form
       URI: <url> String CrLf

   Which specify alternative addresses for the object in question.
   The String is an optional comment field. If the response is to
   indicate a set of variants which each correspond to the requested
   URI, then the multipart/alternative wrapping may be used to
   distinguish different sets
    Found 302
   The data requested actually resides under a different URL, however,
   the redirection may be altered on occasion (when making links to
   these kinds of document, the browser should default to using the
   Udi of the redirection document, but have the option of linking to
   the final document) as for "Forward".
   The response format is the same as for Moved .
    Method 303
        Method: <method> <url>

   Like the found response, this suggests that the client go try
   another network address.  In this case, a different method may be
   used too, rather than GET.
   The body-section contains the parameters to be used for the method.
    This allows a document to be a pointer to a complex query

next up previous contents
Next: MIME (Multipurpose Internet Up: Hypertext Transfer Protocol Previous: Hypertext Transfer Protocol

Jon Crowcroft
Wed May 10 11:46:29 BST 1995