Tech-invite3GPPspaceIETFspace
96959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 2068

Hypertext Transfer Protocol -- HTTP/1.1

Pages: 162
Obsoleted by:  2616
Part 2 of 6 – Pages 21 to 49
First   Prev   Next

ToP   noToC   RFC2068 - Page 21   prevText
3.3 Date/Time Formats

3.3.1 Full Date

   HTTP applications have historically allowed three different formats
   for the representation of date/time stamps:

          Sun, 06 Nov 1994 08:49:37 GMT  ; RFC 822, updated by RFC 1123
          Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036
          Sun Nov  6 08:49:37 1994       ; ANSI C's asctime() format

   The first format is preferred as an Internet standard and represents
   a fixed-length subset of that defined by RFC 1123  (an update to RFC
   822).  The second format is in common use, but is based on the
   obsolete RFC 850 [12] date format and lacks a four-digit year.
   HTTP/1.1 clients and servers that parse the date value MUST accept
   all three formats (for compatibility with HTTP/1.0), though they MUST
   only generate the RFC 1123 format for representing HTTP-date values
   in header fields.

     Note: Recipients of date values are encouraged to be robust in
     accepting date values that may have been sent by non-HTTP
     applications, as is sometimes the case when retrieving or posting
     messages via proxies/gateways to SMTP or NNTP.

   All HTTP date/time stamps MUST be represented in Greenwich Mean Time
   (GMT), without exception. This is indicated in the first two formats
   by the inclusion of "GMT" as the three-letter abbreviation for time
   zone, and MUST be assumed when reading the asctime format.

          HTTP-date    = rfc1123-date | rfc850-date | asctime-date

          rfc1123-date = wkday "," SP date1 SP time SP "GMT"
          rfc850-date  = weekday "," SP date2 SP time SP "GMT"
          asctime-date = wkday SP date3 SP time SP 4DIGIT

          date1        = 2DIGIT SP month SP 4DIGIT
                         ; day month year (e.g., 02 Jun 1982)
          date2        = 2DIGIT "-" month "-" 2DIGIT
                         ; day-month-year (e.g., 02-Jun-82)
          date3        = month SP ( 2DIGIT | ( SP 1DIGIT ))
                         ; month day (e.g., Jun  2)

          time         = 2DIGIT ":" 2DIGIT ":" 2DIGIT
                         ; 00:00:00 - 23:59:59

          wkday        = "Mon" | "Tue" | "Wed"
                       | "Thu" | "Fri" | "Sat" | "Sun"
ToP   noToC   RFC2068 - Page 22
          weekday      = "Monday" | "Tuesday" | "Wednesday"
                       | "Thursday" | "Friday" | "Saturday" | "Sunday"

          month        = "Jan" | "Feb" | "Mar" | "Apr"
                       | "May" | "Jun" | "Jul" | "Aug"
                       | "Sep" | "Oct" | "Nov" | "Dec"

     Note: HTTP requirements for the date/time stamp format apply only
     to their usage within the protocol stream. Clients and servers are
     not required to use these formats for user presentation, request
     logging, etc.

3.3.2 Delta Seconds

   Some HTTP header fields allow a time value to be specified as an
   integer number of seconds, represented in decimal, after the time
   that the message was received.

          delta-seconds  = 1*DIGIT

3.4 Character Sets

   HTTP uses the same definition of the term "character set" as that
   described for MIME:

     The term "character set" is used in this document to refer to a
     method used with one or more tables to convert a sequence of octets
     into a sequence of characters. Note that unconditional conversion
     in the other direction is not required, in that not all characters
     may be available in a given character set and a character set may
     provide more than one sequence of octets to represent a particular
     character. This definition is intended to allow various kinds of
     character encodings, from simple single-table mappings such as US-
     ASCII to complex table switching methods such as those that use ISO
     2022's techniques. However, the definition associated with a MIME
     character set name MUST fully specify the mapping to be performed
     from octets to characters. In particular, use of external profiling
     information to determine the exact mapping is not permitted.

     Note: This use of the term "character set" is more commonly
     referred to as a "character encoding." However, since HTTP and MIME
     share the same registry, it is important that the terminology also
     be shared.
ToP   noToC   RFC2068 - Page 23
   HTTP character sets are identified by case-insensitive tokens. The
   complete set of tokens is defined by the IANA Character Set registry
   [19].

          charset = token

   Although HTTP allows an arbitrary token to be used as a charset
   value, any token that has a predefined value within the IANA
   Character Set registry MUST represent the character set defined by
   that registry.  Applications SHOULD limit their use of character sets
   to those defined by the IANA registry.

3.5 Content Codings

   Content coding values indicate an encoding transformation that has
   been or can be applied to an entity. Content codings are primarily
   used to allow a document to be compressed or otherwise usefully
   transformed without losing the identity of its underlying media type
   and without loss of information. Frequently, the entity is stored in
   coded form, transmitted directly, and only decoded by the recipient.

          content-coding   = token

   All content-coding values are case-insensitive. HTTP/1.1 uses
   content-coding values in the Accept-Encoding (section 14.3) and
   Content-Encoding (section 14.12) header fields. Although the value
   describes the content-coding, what is more important is that it
   indicates what decoding mechanism will be required to remove the
   encoding.

   The Internet Assigned Numbers Authority (IANA) acts as a registry for
   content-coding value tokens. Initially, the registry contains the
   following tokens:

   gzip An encoding format produced by the file compression program "gzip"
        (GNU zip) as described in RFC 1952 [25]. This format is a Lempel-
        Ziv coding (LZ77) with a 32 bit CRC.

   compress
        The encoding format produced by the common UNIX file compression
        program "compress". This format is an adaptive Lempel-Ziv-Welch
        coding (LZW).
ToP   noToC   RFC2068 - Page 24
     Note: Use of program names for the identification of encoding
     formats is not desirable and should be discouraged for future
     encodings. Their use here is representative of historical practice,
     not good design. For compatibility with previous implementations of
     HTTP, applications should consider "x-gzip" and "x-compress" to be
     equivalent to "gzip" and "compress" respectively.

   deflate The "zlib" format defined in RFC 1950[31] in combination with
        the "deflate" compression mechanism described in RFC 1951[29].

   New content-coding value tokens should be registered; to allow
   interoperability between clients and servers, specifications of the
   content coding algorithms needed to implement a new value should be
   publicly available and adequate for independent implementation, and
   conform to the purpose of content coding defined in this section.

3.6 Transfer Codings

   Transfer coding values are used to indicate an encoding
   transformation that has been, can be, or may need to be applied to an
   entity-body in order to ensure "safe transport" through the network.
   This differs from a content coding in that the transfer coding is a
   property of the message, not of the original entity.

          transfer-coding         = "chunked" | transfer-extension

          transfer-extension      = token

   All transfer-coding values are case-insensitive. HTTP/1.1 uses
   transfer coding values in the Transfer-Encoding header field (section
   14.40).

   Transfer codings are analogous to the Content-Transfer-Encoding
   values of MIME , which were designed to enable safe transport of
   binary data over a 7-bit transport service. However, safe transport
   has a different focus for an 8bit-clean transfer protocol. In HTTP,
   the only unsafe characteristic of message-bodies is the difficulty in
   determining the exact body length (section 7.2.2), or the desire to
   encrypt data over a shared transport.

   The chunked encoding modifies the body of a message in order to
   transfer it as a series of chunks, each with its own size indicator,
   followed by an optional footer containing entity-header fields. This
   allows dynamically-produced content to be transferred along with the
   information necessary for the recipient to verify that it has
   received the full message.
ToP   noToC   RFC2068 - Page 25
       Chunked-Body   = *chunk
                        "0" CRLF
                        footer
                        CRLF

       chunk          = chunk-size [ chunk-ext ] CRLF
                        chunk-data CRLF

       hex-no-zero    = <HEX excluding "0">

       chunk-size     = hex-no-zero *HEX
       chunk-ext      = *( ";" chunk-ext-name [ "=" chunk-ext-value ] )
       chunk-ext-name = token
       chunk-ext-val  = token | quoted-string
       chunk-data     = chunk-size(OCTET)

       footer         = *entity-header

   The chunked encoding is ended by a zero-sized chunk followed by the
   footer, which is terminated by an empty line. The purpose of the
   footer is to provide an efficient way to supply information about an
   entity that is generated dynamically; applications MUST NOT send
   header fields in the footer which are not explicitly defined as being
   appropriate for the footer, such as Content-MD5 or future extensions
   to HTTP for digital signatures or other facilities.

   An example process for decoding a Chunked-Body is presented in
   appendix 19.4.6.

   All HTTP/1.1 applications MUST be able to receive and decode the
   "chunked" transfer coding, and MUST ignore transfer coding extensions
   they do not understand. A server which receives an entity-body with a
   transfer-coding it does not understand SHOULD return 501
   (Unimplemented), and close the connection. A server MUST NOT send
   transfer-codings to an HTTP/1.0 client.

3.7 Media Types

   HTTP uses Internet Media Types  in the Content-Type (section 14.18)
   and Accept (section 14.1) header fields in order to provide open and
   extensible data typing and type negotiation.

          media-type     = type "/" subtype *( ";" parameter )
          type           = token
          subtype        = token

   Parameters may follow the type/subtype in the form of attribute/value
   pairs.
ToP   noToC   RFC2068 - Page 26
          parameter      = attribute "=" value
          attribute      = token
          value          = token | quoted-string

   The type, subtype, and parameter attribute names are case-
   insensitive.  Parameter values may or may not be case-sensitive,
   depending on the semantics of the parameter name. Linear white space
   (LWS) MUST NOT be used between the type and subtype, nor between an
   attribute and its value. User agents that recognize the media-type
   MUST process (or arrange to be processed by any external applications
   used to process that type/subtype by the user agent) the parameters
   for that MIME type as described by that type/subtype definition to
   the and inform the user of any problems discovered.

     Note: some older HTTP applications do not recognize media type
     parameters. When sending data to older HTTP applications,
     implementations should only use media type parameters when they are
     required by that type/subtype definition.

   Media-type values are registered with the Internet Assigned Number
   Authority (IANA). The media type registration process is outlined in
   RFC 2048 [17]. Use of non-registered media types is discouraged.

3.7.1 Canonicalization and Text Defaults

   Internet media types are registered with a canonical form. In
   general, an entity-body transferred via HTTP messages MUST be
   represented in the appropriate canonical form prior to its
   transmission; the exception is "text" types, as defined in the next
   paragraph.

   When in canonical form, media subtypes of the "text" type use CRLF as
   the text line break. HTTP relaxes this requirement and allows the
   transport of text media with plain CR or LF alone representing a line
   break when it is done consistently for an entire entity-body. HTTP
   applications MUST accept CRLF, bare CR, and bare LF as being
   representative of a line break in text media received via HTTP. In
   addition, if the text is represented in a character set that does not
   use octets 13 and 10 for CR and LF respectively, as is the case for
   some multi-byte character sets, HTTP allows the use of whatever octet
   sequences are defined by that character set to represent the
   equivalent of CR and LF for line breaks. This flexibility regarding
   line breaks applies only to text media in the entity-body; a bare CR
   or LF MUST NOT be substituted for CRLF within any of the HTTP control
   structures (such as header fields and multipart boundaries).

   If an entity-body is encoded with a Content-Encoding, the underlying
   data MUST be in a form defined above prior to being encoded.
ToP   noToC   RFC2068 - Page 27
   The "charset" parameter is used with some media types to define the
   character set (section 3.4) of the data. When no explicit charset
   parameter is provided by the sender, media subtypes of the "text"
   type are defined to have a default charset value of "ISO-8859-1" when
   received via HTTP. Data in character sets other than "ISO-8859-1" or
   its subsets MUST be labeled with an appropriate charset value.

   Some HTTP/1.0 software has interpreted a Content-Type header without
   charset parameter incorrectly to mean "recipient should guess."
   Senders wishing to defeat this behavior MAY include a charset
   parameter even when the charset is ISO-8859-1 and SHOULD do so when
   it is known that it will not confuse the recipient.

   Unfortunately, some older HTTP/1.0 clients did not deal properly with
   an explicit charset parameter. HTTP/1.1 recipients MUST respect the
   charset label provided by the sender; and those user agents that have
   a provision to "guess" a charset MUST use the charset from the
   content-type field if they support that charset, rather than the
   recipient's preference, when initially displaying a document.

3.7.2 Multipart Types

   MIME provides for a number of "multipart" types -- encapsulations of
   one or more entities within a single message-body. All multipart
   types share a common syntax, as defined in  MIME [7], and MUST
   include a boundary parameter as part of the media type value. The
   message body is itself a protocol element and MUST therefore use only
   CRLF to represent line breaks between body-parts. Unlike in MIME, the
   epilogue of any multipart message MUST be empty; HTTP applications
   MUST NOT transmit the epilogue (even if the original multipart
   contains an epilogue).

   In HTTP, multipart body-parts MAY contain header fields which are
   significant to the meaning of that part. A Content-Location header
   field (section 14.15) SHOULD be included in the body-part of each
   enclosed entity that can be identified by a URL.

   In general, an HTTP user agent SHOULD follow the same or similar
   behavior as a MIME user agent would upon receipt of a multipart type.
   If an application receives an unrecognized multipart subtype, the
   application MUST treat it as being equivalent to "multipart/mixed".

     Note: The "multipart/form-data" type has been specifically defined
     for carrying form data suitable for processing via the POST request
     method, as described in RFC 1867 [15].
ToP   noToC   RFC2068 - Page 28
3.8 Product Tokens

   Product tokens are used to allow communicating applications to
   identify themselves by software name and version. Most fields using
   product tokens also allow sub-products which form a significant part
   of the application to be listed, separated by whitespace. By
   convention, the products are listed in order of their significance
   for identifying the application.

          product         = token ["/" product-version]
          product-version = token

   Examples:

          User-Agent: CERN-LineMode/2.15 libwww/2.17b3
          Server: Apache/0.8.4

   Product tokens should be short and to the point -- use of them for
   advertising or other non-essential information is explicitly
   forbidden.  Although any token character may appear in a product-
   version, this token SHOULD only be used for a version identifier
   (i.e., successive versions of the same product SHOULD only differ in
   the product-version portion of the product value).

3.9 Quality Values

   HTTP content negotiation (section 12) uses short "floating point"
   numbers to indicate the relative importance ("weight") of various
   negotiable parameters. A weight is normalized to a real number in the
   range 0 through 1, where 0 is the minimum and 1 the maximum value.
   HTTP/1.1 applications MUST NOT generate more than three digits after
   the decimal point. User configuration of these values SHOULD also be
   limited in this fashion.

          qvalue         = ( "0" [ "." 0*3DIGIT ] )
                         | ( "1" [ "." 0*3("0") ] )

   "Quality values" is a misnomer, since these values merely represent
   relative degradation in desired quality.

3.10 Language Tags

   A language tag identifies a natural language spoken, written, or
   otherwise conveyed by human beings for communication of information
   to other human beings. Computer languages are explicitly excluded.
   HTTP uses language tags within the Accept-Language and Content-
   Language fields.
ToP   noToC   RFC2068 - Page 29
   The syntax and registry of HTTP language tags is the same as that
   defined by RFC 1766 [1]. In summary, a language tag is composed of 1
   or more parts: A primary language tag and a possibly empty series of
   subtags:

           language-tag  = primary-tag *( "-" subtag )

           primary-tag   = 1*8ALPHA
           subtag        = 1*8ALPHA

   Whitespace is not allowed within the tag and all tags are case-
   insensitive. The name space of language tags is administered by the
   IANA. Example tags include:

          en, en-US, en-cockney, i-cherokee, x-pig-latin

   where any two-letter primary-tag is an ISO 639 language abbreviation
   and any two-letter initial subtag is an ISO 3166 country code. (The
   last three tags above are not registered tags; all but the last are
   examples of tags which could be registered in future.)

3.11 Entity Tags

   Entity tags are used for comparing two or more entities from the same
   requested resource. HTTP/1.1 uses entity tags in the ETag (section
   14.20), If-Match (section 14.25), If-None-Match (section 14.26), and
   If-Range (section 14.27) header fields. The definition of how they
   are used and compared as cache validators is in section 13.3.3. An
   entity tag consists of an opaque quoted string, possibly prefixed by
   a weakness indicator.

         entity-tag = [ weak ] opaque-tag

         weak       = "W/"
         opaque-tag = quoted-string

   A "strong entity tag" may be shared by two entities of a resource
   only if they are equivalent by octet equality.

   A "weak entity tag," indicated by the "W/" prefix, may be shared by
   two entities of a resource only if the entities are equivalent and
   could be substituted for each other with no significant change in
   semantics. A weak entity tag can only be used for weak comparison.

   An entity tag MUST be unique across all versions of all entities
   associated with a particular resource. A given entity tag value may
   be used for entities obtained by requests on different URIs without
   implying anything about the equivalence of those entities.
ToP   noToC   RFC2068 - Page 30
3.12 Range Units

   HTTP/1.1 allows a client to request that only part (a range of) the
   response entity be included within the response. HTTP/1.1 uses range
   units in the Range (section 14.36) and Content-Range (section 14.17)
   header fields. An entity may be broken down into subranges according
   to various structural units.

         range-unit       = bytes-unit | other-range-unit

         bytes-unit       = "bytes"
         other-range-unit = token

The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1
   implementations may ignore ranges specified using other units.
   HTTP/1.1 has been designed to allow implementations of applications
   that do not depend on knowledge of ranges.

4 HTTP Message

4.1 Message Types

   HTTP messages consist of requests from client to server and responses
   from server to client.

          HTTP-message   = Request | Response     ; HTTP/1.1 messages

   Request (section 5) and Response (section 6) messages use the generic
   message format of RFC 822 [9] for transferring entities (the payload
   of the message). Both types of message consist of a start-line, one
   or more header fields (also known as "headers"), an empty line (i.e.,
   a line with nothing preceding the CRLF) indicating the end of the
   header fields, and an optional message-body.

           generic-message = start-line
                             *message-header
                             CRLF
                             [ message-body ]

           start-line      = Request-Line | Status-Line

   In the interest of robustness, servers SHOULD ignore any empty
   line(s) received where a Request-Line is expected. In other words, if
   the server is reading the protocol stream at the beginning of a
   message and receives a CRLF first, it should ignore the CRLF.
ToP   noToC   RFC2068 - Page 31
     Note: certain buggy HTTP/1.0 client implementations generate an
     extra CRLF's after a POST request. To restate what is explicitly
     forbidden by the BNF, an HTTP/1.1 client must not preface or follow
     a request with an extra CRLF.

4.2 Message Headers

   HTTP header fields, which include general-header (section 4.5),
   request-header (section 5.3), response-header (section 6.2), and
   entity-header (section 7.1) fields, follow the same generic format as
   that given in Section 3.1 of RFC 822 [9]. Each header field consists
   of a name followed by a colon (":") and the field value. Field names
   are case-insensitive. The field value may be preceded by any amount
   of LWS, though a single SP is preferred. Header fields can be
   extended over multiple lines by preceding each extra line with at
   least one SP or HT.  Applications SHOULD follow "common form" when
   generating HTTP constructs, since there might exist some
   implementations that fail to accept anything beyond the common forms.

          message-header = field-name ":" [ field-value ] CRLF

          field-name     = token
          field-value    = *( field-content | LWS )

          field-content  = <the OCTETs making up the field-value
                           and consisting of either *TEXT or combinations
                           of token, tspecials, and quoted-string>

   The order in which header fields with differing field names are
   received is not significant. However, it is "good practice" to send
   general-header fields first, followed by request-header or response-
   header fields, and ending with the entity-header fields.

   Multiple message-header fields with the same field-name may be
   present in a message if and only if the entire field-value for that
   header field is defined as a comma-separated list [i.e., #(values)].
   It MUST be possible to combine the multiple header fields into one
   "field-name: field-value" pair, without changing the semantics of the
   message, by appending each subsequent field-value to the first, each
   separated by a comma. The order in which header fields with the same
   field-name are received is therefore significant to the
   interpretation of the combined field value, and thus a proxy MUST NOT
   change the order of these field values when a message is forwarded.
ToP   noToC   RFC2068 - Page 32
4.3 Message Body

   The message-body (if any) of an HTTP message is used to carry the
   entity-body associated with the request or response. The message-body
   differs from the entity-body only when a transfer coding has been
   applied, as indicated by the Transfer-Encoding header field (section
   14.40).

          message-body = entity-body
                       | <entity-body encoded as per Transfer-Encoding>

   Transfer-Encoding MUST be used to indicate any transfer codings
   applied by an application to ensure safe and proper transfer of the
   message.  Transfer-Encoding is a property of the message, not of the
   entity, and thus can be added or removed by any application along the
   request/response chain.

   The rules for when a message-body is allowed in a message differ for
   requests and responses.

   The presence of a message-body in a request is signaled by the
   inclusion of a Content-Length or Transfer-Encoding header field in
   the request's message-headers. A message-body MAY be included in a
   request only when the request method (section 5.1.1) allows an
   entity-body.

   For response messages, whether or not a message-body is included with
   a message is dependent on both the request method and the response
   status code (section 6.1.1). All responses to the HEAD request method
   MUST NOT include a message-body, even though the presence of entity-
   header fields might lead one to believe they do. All 1xx
   (informational), 204 (no content), and 304 (not modified) responses
   MUST NOT include a message-body. All other responses do include a
   message-body, although it may be of zero length.

4.4 Message Length

   When a message-body is included with a message, the length of that
   body is determined by one of the following (in order of precedence):

   1. Any response message which MUST NOT include a message-body
     (such as the 1xx, 204, and 304 responses and any response to a HEAD
     request) is always terminated by the first empty line after the
     header fields, regardless of the entity-header fields present in the
     message.

   2. If a Transfer-Encoding header field (section 14.40) is present and
     indicates that the "chunked" transfer coding has been applied, then
ToP   noToC   RFC2068 - Page 33
     the length is defined by the chunked encoding (section 3.6).

   3. If a Content-Length header field (section 14.14) is present, its
     value in bytes represents the length of the message-body.

   4. If the message uses the media type "multipart/byteranges", which is
     self-delimiting, then that defines the length. This media type MUST
     NOT be used unless the sender knows that the recipient can parse it;
     the presence in a request of a Range header with multiple byte-range
     specifiers implies that the client can parse multipart/byteranges
     responses.

   5. By the server closing the connection. (Closing the connection
     cannot be used to indicate the end of a request body, since that
     would leave no possibility for the server to send back a response.)

   For compatibility with HTTP/1.0 applications, HTTP/1.1 requests
   containing a message-body MUST include a valid Content-Length header
   field unless the server is known to be HTTP/1.1 compliant. If a
   request contains a message-body and a Content-Length is not given,
   the server SHOULD respond with 400 (bad request) if it cannot
   determine the length of the message, or with 411 (length required) if
   it wishes to insist on receiving a valid Content-Length.

   All HTTP/1.1 applications that receive entities MUST accept the
   "chunked" transfer coding (section 3.6), thus allowing this mechanism
   to be used for messages when the message length cannot be determined
   in advance.

   Messages MUST NOT include both a Content-Length header field and the
   "chunked" transfer coding. If both are received, the Content-Length
   MUST be ignored.

   When a Content-Length is given in a message where a message-body is
   allowed, its field value MUST exactly match the number of OCTETs in
   the message-body. HTTP/1.1 user agents MUST notify the user when an
   invalid length is received and detected.
ToP   noToC   RFC2068 - Page 34
4.5 General Header Fields

   There are a few header fields which have general applicability for
   both request and response messages, but which do not apply to the
   entity being transferred. These header fields apply only to the
   message being transmitted.

          general-header = Cache-Control            ; Section 14.9
                         | Connection               ; Section 14.10
                         | Date                     ; Section 14.19
                         | Pragma                   ; Section 14.32
                         | Transfer-Encoding        ; Section 14.40
                         | Upgrade                  ; Section 14.41
                         | Via                      ; Section 14.44

   General-header field names can be extended reliably only in
   combination with a change in the protocol version. However, new or
   experimental header fields may be given the semantics of general
   header fields if all parties in the communication recognize them to
   be general-header fields.  Unrecognized header fields are treated as
   entity-header fields.

5 Request

   A request message from a client to a server includes, within the
   first line of that message, the method to be applied to the resource,
   the identifier of the resource, and the protocol version in use.

           Request       = Request-Line              ; Section 5.1
                           *( general-header         ; Section 4.5
                            | request-header         ; Section 5.3
                            | entity-header )        ; Section 7.1
                           CRLF
                           [ message-body ]          ; Section 7.2

5.1 Request-Line

   The Request-Line begins with a method token, followed by the
   Request-URI and the protocol version, and ending with CRLF. The
   elements are separated by SP characters. No CR or LF are allowed
   except in the final CRLF sequence.

          Request-Line   = Method SP Request-URI SP HTTP-Version CRLF
ToP   noToC   RFC2068 - Page 35
5.1.1 Method

   The Method token indicates the method to be performed on the resource
   identified by the Request-URI. The method is case-sensitive.

          Method         = "OPTIONS"                ; Section 9.2
                         | "GET"                    ; Section 9.3
                         | "HEAD"                   ; Section 9.4
                         | "POST"                   ; Section 9.5
                         | "PUT"                    ; Section 9.6
                         | "DELETE"                 ; Section 9.7
                         | "TRACE"                  ; Section 9.8
                         | extension-method

          extension-method = token

   The list of methods allowed by a resource can be specified in an
   Allow header field (section 14.7). The return code of the response
   always notifies the client whether a method is currently allowed on a
   resource, since the set of allowed methods can change dynamically.
   Servers SHOULD return the status code 405 (Method Not Allowed) if the
   method is known by the server but not allowed for the requested
   resource, and 501 (Not Implemented) if the method is unrecognized or
   not implemented by the server. The list of methods known by a server
   can be listed in a Public response-header field (section 14.35).

   The methods GET and HEAD MUST be supported by all general-purpose
   servers. All other methods are optional; however, if the above
   methods are implemented, they MUST be implemented with the same
   semantics as those specified in section 9.

5.1.2 Request-URI

   The Request-URI is a Uniform Resource Identifier (section 3.2) and
   identifies the resource upon which to apply the request.

          Request-URI    = "*" | absoluteURI | abs_path

   The three options for Request-URI are dependent on the nature of the
   request. The asterisk "*" means that the request does not apply to a
   particular resource, but to the server itself, and is only allowed
   when the method used does not necessarily apply to a resource. One
   example would be

          OPTIONS * HTTP/1.1

   The absoluteURI form is required when the request is being made to a
   proxy. The proxy is requested to forward the request or service it
ToP   noToC   RFC2068 - Page 36
   from a valid cache, and return the response. Note that the proxy MAY
   forward the request on to another proxy or directly to the server
   specified by the absoluteURI. In order to avoid request loops, a
   proxy MUST be able to recognize all of its server names, including
   any aliases, local variations, and the numeric IP address. An example
   Request-Line would be:

          GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1

   To allow for transition to absoluteURIs in all requests in future
   versions of HTTP, all HTTP/1.1 servers MUST accept the absoluteURI
   form in requests, even though HTTP/1.1 clients will only generate
   them in requests to proxies.

   The most common form of Request-URI is that used to identify a
   resource on an origin server or gateway. In this case the absolute
   path of the URI MUST be transmitted (see section 3.2.1, abs_path) as
   the Request-URI, and the network location of the URI (net_loc) MUST
   be transmitted in a Host header field. For example, a client wishing
   to retrieve the resource above directly from the origin server would
   create a TCP connection to port 80 of the host "www.w3.org" and send
   the lines:

          GET /pub/WWW/TheProject.html HTTP/1.1
          Host: www.w3.org

   followed by the remainder of the Request. Note that the absolute path
   cannot be empty; if none is present in the original URI, it MUST be
   given as "/" (the server root).

   If a proxy receives a request without any path in the Request-URI and
   the method specified is capable of supporting the asterisk form of
   request, then the last proxy on the request chain MUST forward the
   request with "*" as the final Request-URI. For example, the request

          OPTIONS http://www.ics.uci.edu:8001 HTTP/1.1

   would be forwarded by the proxy as

          OPTIONS * HTTP/1.1
          Host: www.ics.uci.edu:8001

   after connecting to port 8001 of host "www.ics.uci.edu".

   The Request-URI is transmitted in the format specified in section
   3.2.1.  The origin server MUST decode the Request-URI in order to
   properly interpret the request. Servers SHOULD respond to invalid
   Request-URIs with an appropriate status code.
ToP   noToC   RFC2068 - Page 37
   In requests that they forward, proxies MUST NOT rewrite the
   "abs_path" part of a Request-URI in any way except as noted above to
   replace a null abs_path with "*", no matter what the proxy does in
   its internal implementation.

     Note: The "no rewrite" rule prevents the proxy from changing the
     meaning of the request when the origin server is improperly using a
     non-reserved URL character for a reserved purpose. Implementers
     should be aware that some pre-HTTP/1.1 proxies have been known to
     rewrite the Request-URI.

5.2 The Resource Identified by a Request

   HTTP/1.1 origin servers SHOULD be aware that the exact resource
   identified by an Internet request is determined by examining both the
   Request-URI and the Host header field.

   An origin server that does not allow resources to differ by the
   requested host MAY ignore the Host header field value. (But see
   section 19.5.1 for other requirements on Host support in HTTP/1.1.)

   An origin server that does differentiate resources based on the host
   requested (sometimes referred to as virtual hosts or vanity
   hostnames) MUST use the following rules for determining the requested
   resource on an HTTP/1.1 request:

     1. If Request-URI is an absoluteURI, the host is part of the
        Request-URI. Any Host header field value in the request MUST be
        ignored.

     2. If the Request-URI is not an absoluteURI, and the request
        includes a Host header field, the host is determined by the Host
        header field value.

     3. If the host as determined by rule 1 or 2 is not a valid host on
        the server, the response MUST be a 400 (Bad Request) error
        message.

   Recipients of an HTTP/1.0 request that lacks a Host header field MAY
   attempt to use heuristics (e.g., examination of the URI path for
   something unique to a particular host) in order to determine what
   exact resource is being requested.

5.3 Request Header Fields

   The request-header fields allow the client to pass additional
   information about the request, and about the client itself, to the
   server. These fields act as request modifiers, with semantics
ToP   noToC   RFC2068 - Page 38
   equivalent to the parameters on a programming language method
   invocation.

          request-header = Accept                   ; Section 14.1
                         | Accept-Charset           ; Section 14.2
                         | Accept-Encoding          ; Section 14.3
                         | Accept-Language          ; Section 14.4
                         | Authorization            ; Section 14.8
                         | From                     ; Section 14.22
                         | Host                     ; Section 14.23
                         | If-Modified-Since        ; Section 14.24
                         | If-Match                 ; Section 14.25
                         | If-None-Match            ; Section 14.26
                         | If-Range                 ; Section 14.27
                         | If-Unmodified-Since      ; Section 14.28
                         | Max-Forwards             ; Section 14.31
                         | Proxy-Authorization      ; Section 14.34
                         | Range                    ; Section 14.36
                         | Referer                  ; Section 14.37
                         | User-Agent               ; Section 14.42

   Request-header field names can be extended reliably only in
   combination with a change in the protocol version. However, new or
   experimental header fields MAY be given the semantics of request-
   header fields if all parties in the communication recognize them to
   be request-header fields.  Unrecognized header fields are treated as
   entity-header fields.

6 Response

   After receiving and interpreting a request message, a server responds
   with an HTTP response message.

       Response      = Status-Line               ; Section 6.1
                       *( general-header         ; Section 4.5
                        | response-header        ; Section 6.2
                        | entity-header )        ; Section 7.1
                       CRLF
                       [ message-body ]          ; Section 7.2

6.1 Status-Line

   The first line of a Response message is the Status-Line, consisting
   of the protocol version followed by a numeric status code and its
   associated textual phrase, with each element separated by SP
   characters.  No CR or LF is allowed except in the final CRLF
   sequence.
ToP   noToC   RFC2068 - Page 39
       Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

6.1.1 Status Code and Reason Phrase

   The Status-Code element is a 3-digit integer result code of the
   attempt to understand and satisfy the request. These codes are fully
   defined in section 10. The Reason-Phrase is intended to give a short
   textual description of the Status-Code. The Status-Code is intended
   for use by automata and the Reason-Phrase is intended for the human
   user. The client is not required to examine or display the Reason-
   Phrase.

   The first digit of the Status-Code defines the class of response. The
   last two digits do not have any categorization role. There are 5
   values for the first digit:

     o  1xx: Informational - Request received, continuing process

     o  2xx: Success - The action was successfully received, understood,
        and accepted

     o  3xx: Redirection - Further action must be taken in order to
        complete the request

     o  4xx: Client Error - The request contains bad syntax or cannot be
        fulfilled

     o  5xx: Server Error - The server failed to fulfill an apparently
        valid request

   The individual values of the numeric status codes defined for
   HTTP/1.1, and an example set of corresponding Reason-Phrase's, are
   presented below. The reason phrases listed here are only recommended
   -- they may be replaced by local equivalents without affecting the
   protocol.

          Status-Code    = "100"   ; Continue
                         | "101"   ; Switching Protocols
                         | "200"   ; OK
                         | "201"   ; Created
                         | "202"   ; Accepted
                         | "203"   ; Non-Authoritative Information
                         | "204"   ; No Content
                         | "205"   ; Reset Content
                         | "206"   ; Partial Content
                         | "300"   ; Multiple Choices
                         | "301"   ; Moved Permanently
                         | "302"   ; Moved Temporarily
ToP   noToC   RFC2068 - Page 40
                         | "303"   ; See Other
                         | "304"   ; Not Modified
                         | "305"   ; Use Proxy
                         | "400"   ; Bad Request
                         | "401"   ; Unauthorized
                         | "402"   ; Payment Required
                         | "403"   ; Forbidden
                         | "404"   ; Not Found
                         | "405"   ; Method Not Allowed
                         | "406"   ; Not Acceptable
                         | "407"   ; Proxy Authentication Required
                         | "408"   ; Request Time-out
                         | "409"   ; Conflict
                         | "410"   ; Gone
                         | "411"   ; Length Required
                         | "412"   ; Precondition Failed
                         | "413"   ; Request Entity Too Large
                         | "414"   ; Request-URI Too Large
                         | "415"   ; Unsupported Media Type
                         | "500"   ; Internal Server Error
                         | "501"   ; Not Implemented
                         | "502"   ; Bad Gateway
                         | "503"   ; Service Unavailable
                         | "504"   ; Gateway Time-out
                         | "505"   ; HTTP Version not supported
                         | extension-code

          extension-code = 3DIGIT

          Reason-Phrase  = *<TEXT, excluding CR, LF>

   HTTP status codes are extensible. HTTP applications are not required
   to understand the meaning of all registered status codes, though such
   understanding is obviously desirable. However, applications MUST
   understand the class of any status code, as indicated by the first
   digit, and treat any unrecognized response as being equivalent to the
   x00 status code of that class, with the exception that an
   unrecognized response MUST NOT be cached. For example, if an
   unrecognized status code of 431 is received by the client, it can
   safely assume that there was something wrong with its request and
   treat the response as if it had received a 400 status code. In such
   cases, user agents SHOULD present to the user the entity returned
   with the response, since that entity is likely to include human-
   readable information which will explain the unusual status.
ToP   noToC   RFC2068 - Page 41
6.2 Response Header Fields

   The response-header fields allow the server to pass additional
   information about the response which cannot be placed in the Status-
   Line. These header fields give information about the server and about
   further access to the resource identified by the Request-URI.

          response-header = Age                     ; Section 14.6
                          | Location                ; Section 14.30
                          | Proxy-Authenticate      ; Section 14.33
                          | Public                  ; Section 14.35
                          | Retry-After             ; Section 14.38
                          | Server                  ; Section 14.39
                          | Vary                    ; Section 14.43
                          | Warning                 ; Section 14.45
                          | WWW-Authenticate        ; Section 14.46

   Response-header field names can be extended reliably only in
   combination with a change in the protocol version. However, new or
   experimental header fields MAY be given the semantics of response-
   header fields if all parties in the communication recognize them to
   be response-header fields. Unrecognized header fields are treated as
   entity-header fields.

7 Entity

   Request and Response messages MAY transfer an entity if not otherwise
   restricted by the request method or response status code. An entity
   consists of entity-header fields and an entity-body, although some
   responses will only include the entity-headers.

   In this section, both sender and recipient refer to either the client
   or the server, depending on who sends and who receives the entity.

7.1 Entity Header Fields

   Entity-header fields define optional metainformation about the
   entity-body or, if no body is present, about the resource identified
   by the request.
ToP   noToC   RFC2068 - Page 42
          entity-header  = Allow                    ; Section 14.7
                         | Content-Base             ; Section 14.11
                         | Content-Encoding         ; Section 14.12
                         | Content-Language         ; Section 14.13
                         | Content-Length           ; Section 14.14
                         | Content-Location         ; Section 14.15
                         | Content-MD5              ; Section 14.16
                         | Content-Range            ; Section 14.17
                         | Content-Type             ; Section 14.18
                         | ETag                     ; Section 14.20
                         | Expires                  ; Section 14.21
                         | Last-Modified            ; Section 14.29
                         | extension-header

          extension-header = message-header

   The extension-header mechanism allows additional entity-header fields
   to be defined without changing the protocol, but these fields cannot
   be assumed to be recognizable by the recipient. Unrecognized header
   fields SHOULD be ignored by the recipient and forwarded by proxies.

7.2 Entity Body

   The entity-body (if any) sent with an HTTP request or response is in
   a format and encoding defined by the entity-header fields.

          entity-body    = *OCTET

   An entity-body is only present in a message when a message-body is
   present, as described in section 4.3. The entity-body is obtained
   from the message-body by decoding any Transfer-Encoding that may have
   been applied to ensure safe and proper transfer of the message.

7.2.1 Type

   When an entity-body is included with a message, the data type of that
   body is determined via the header fields Content-Type and Content-
   Encoding. These define a two-layer, ordered encoding model:

          entity-body := Content-Encoding( Content-Type( data ) )

   Content-Type specifies the media type of the underlying data.
   Content-Encoding may be used to indicate any additional content
   codings applied to the data, usually for the purpose of data
   compression, that are a property of the requested resource. There is
   no default encoding.
ToP   noToC   RFC2068 - Page 43
   Any HTTP/1.1 message containing an entity-body SHOULD include a
   Content-Type header field defining the media type of that body. If
   and only if the media type is not given by a Content-Type field, the
   recipient MAY attempt to guess the media type via inspection of its
   content and/or the name extension(s) of the URL used to identify the
   resource. If the media type remains unknown, the recipient SHOULD
   treat it as type "application/octet-stream".

7.2.2 Length

   The length of an entity-body is the length of the message-body after
   any transfer codings have been removed. Section 4.4 defines how the
   length of a message-body is determined.

8 Connections

8.1 Persistent Connections

8.1.1 Purpose

   Prior to persistent connections, a separate TCP connection was
   established to fetch each URL, increasing the load on HTTP servers
   and causing congestion on the Internet. The use of inline images and
   other associated data often requires a client to make multiple
   requests of the same server in a short amount of time. Analyses of
   these performance problems are available [30][27]; analysis and
   results from a prototype implementation are in [26].

   Persistent HTTP connections have a number of advantages:

     o  By opening and closing fewer TCP connections, CPU time is saved,
        and memory used for TCP protocol control blocks is also saved.
     o  HTTP requests and responses can be pipelined on a connection.
        Pipelining allows a client to make multiple requests without
        waiting for each response, allowing a single TCP connection to be
        used much more efficiently, with much lower elapsed time.
     o  Network congestion is reduced by reducing the number of packets
        caused by TCP opens, and by allowing TCP sufficient time to
        determine the congestion state of the network.
     o  HTTP can evolve more gracefully; since errors can be reported
        without the penalty of closing the TCP connection. Clients using
        future versions of HTTP might optimistically try a new feature, but
        if communicating with an older server, retry with old semantics
        after an error is reported.

   HTTP implementations SHOULD implement persistent connections.
ToP   noToC   RFC2068 - Page 44
8.1.2 Overall Operation

   A significant difference between HTTP/1.1 and earlier versions of
   HTTP is that persistent connections are the default behavior of any
   HTTP connection. That is, unless otherwise indicated, the client may
   assume that the server will maintain a persistent connection.

   Persistent connections provide a mechanism by which a client and a
   server can signal the close of a TCP connection. This signaling takes
   place using the Connection header field. Once a close has been
   signaled, the client MUST not send any more requests on that
   connection.

8.1.2.1 Negotiation

   An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to
   maintain a persistent connection unless a Connection header including
   the connection-token "close" was sent in the request. If the server
   chooses to close the connection immediately after sending the
   response, it SHOULD send a Connection header including the
   connection-token close.

   An HTTP/1.1 client MAY expect a connection to remain open, but would
   decide to keep it open based on whether the response from a server
   contains a Connection header with the connection-token close. In case
   the client does not want to maintain a connection for more than that
   request, it SHOULD send a Connection header including the
   connection-token close.

   If either the client or the server sends the close token in the
   Connection header, that request becomes the last one for the
   connection.

   Clients and servers SHOULD NOT assume that a persistent connection is
   maintained for HTTP versions less than 1.1 unless it is explicitly
   signaled. See section 19.7.1 for more information on backwards
   compatibility with HTTP/1.0 clients.

   In order to remain persistent, all messages on the connection must
   have a self-defined message length (i.e., one not defined by closure
   of the connection), as described in section 4.4.

8.1.2.2 Pipelining

   A client that supports persistent connections MAY "pipeline" its
   requests (i.e., send multiple requests without waiting for each
   response). A server MUST send its responses to those requests in the
   same order that the requests were received.
ToP   noToC   RFC2068 - Page 45
   Clients which assume persistent connections and pipeline immediately
   after connection establishment SHOULD be prepared to retry their
   connection if the first pipelined attempt fails. If a client does
   such a retry, it MUST NOT pipeline before it knows the connection is
   persistent. Clients MUST also be prepared to resend their requests if
   the server closes the connection before sending all of the
   corresponding responses.

8.1.3 Proxy Servers

   It is especially important that proxies correctly implement the
   properties of the Connection header field as specified in 14.2.1.

   The proxy server MUST signal persistent connections separately with
   its clients and the origin servers (or other proxy servers) that it
   connects to. Each persistent connection applies to only one transport
   link.

   A proxy server MUST NOT establish a persistent connection with an
   HTTP/1.0 client.

8.1.4 Practical Considerations

   Servers will usually have some time-out value beyond which they will
   no longer maintain an inactive connection. Proxy servers might make
   this a higher value since it is likely that the client will be making
   more connections through the same server. The use of persistent
   connections places no requirements on the length of this time-out for
   either the client or the server.

   When a client or server wishes to time-out it SHOULD issue a graceful
   close on the transport connection. Clients and servers SHOULD both
   constantly watch for the other side of the transport close, and
   respond to it as appropriate. If a client or server does not detect
   the other side's close promptly it could cause unnecessary resource
   drain on the network.

   A client, server, or proxy MAY close the transport connection at any
   time. For example, a client MAY have started to send a new request at
   the same time that the server has decided to close the "idle"
   connection. From the server's point of view, the connection is being
   closed while it was idle, but from the client's point of view, a
   request is in progress.

   This means that clients, servers, and proxies MUST be able to recover
   from asynchronous close events. Client software SHOULD reopen the
   transport connection and retransmit the aborted request without user
   interaction so long as the request method is idempotent (see section
ToP   noToC   RFC2068 - Page 46
   9.1.2); other methods MUST NOT be automatically retried, although
   user agents MAY offer a human operator the choice of retrying the
   request.

   However, this automatic retry SHOULD NOT be repeated if the second
   request fails.

   Servers SHOULD always respond to at least one request per connection,
   if at all possible. Servers SHOULD NOT close a connection in the
   middle of transmitting a response, unless a network or client failure
   is suspected.

   Clients that use persistent connections SHOULD limit the number of
   simultaneous connections that they maintain to a given server. A
   single-user client SHOULD maintain AT MOST 2 connections with any
   server or proxy. A proxy SHOULD use up to 2*N connections to another
   server or proxy, where N is the number of simultaneously active
   users. These guidelines are intended to improve HTTP response times
   and avoid congestion of the Internet or other networks.

8.2 Message Transmission Requirements

General requirements:

o  HTTP/1.1 servers SHOULD maintain persistent connections and use
   TCP's flow control mechanisms to resolve temporary overloads,
   rather than terminating connections with the expectation that
   clients will retry. The latter technique can exacerbate network
   congestion.

o  An HTTP/1.1 (or later) client sending a message-body SHOULD monitor
   the network connection for an error status while it is transmitting
   the request. If the client sees an error status, it SHOULD
   immediately cease transmitting the body. If the body is being sent
   using a "chunked" encoding (section 3.6), a zero length chunk and
   empty footer MAY be used to prematurely mark the end of the
   message. If the body was preceded by a Content-Length header, the
   client MUST close the connection.

o  An HTTP/1.1 (or later) client MUST be prepared to accept a 100
   (Continue) status followed by a regular response.

o  An HTTP/1.1 (or later) server that receives a request from a
   HTTP/1.0 (or earlier) client MUST NOT transmit the 100 (continue)
   response; it SHOULD either wait for the request to be completed
   normally (thus avoiding an interrupted request) or close the
   connection prematurely.
ToP   noToC   RFC2068 - Page 47
   Upon receiving a method subject to these requirements from an
   HTTP/1.1 (or later) client, an HTTP/1.1 (or later) server MUST either
   respond with 100 (Continue) status and continue to read from the
   input stream, or respond with an error status. If it responds with an
   error status, it MAY close the transport (TCP) connection or it MAY
   continue to read and discard the rest of the request. It MUST NOT
   perform the requested method if it returns an error status.

   Clients SHOULD remember the version number of at least the most
   recently used server; if an HTTP/1.1 client has seen an HTTP/1.1 or
   later response from the server, and it sees the connection close
   before receiving any status from the server, the client SHOULD retry
   the request without user interaction so long as the request method is
   idempotent (see section 9.1.2); other methods MUST NOT be
   automatically retried, although user agents MAY offer a human
   operator the choice of retrying the request.. If the client does
   retry the request, the client

     o  MUST first send the request header fields, and then

     o  MUST wait for the server to respond with either a 100 (Continue)
        response, in which case the client should continue, or with an
        error status.

   If an HTTP/1.1 client has not seen an HTTP/1.1 or later response from
   the server, it should assume that the server implements HTTP/1.0 or
   older and will not use the 100 (Continue) response. If in this case
   the client sees the connection close before receiving any status from
   the server, the client SHOULD retry the request. If the client does
   retry the request to this HTTP/1.0 server, it should use the
   following "binary exponential backoff" algorithm to be assured of
   obtaining a reliable response:

  1. Initiate a new connection to the server

  2. Transmit the request-headers

  3. Initialize a variable R to the estimated round-trip time to the
     server (e.g., based on the time it took to establish the
     connection), or to a constant value of 5 seconds if the round-trip
     time is not available.

  4. Compute T = R * (2**N), where N is the number of previous retries
     of this request.

  5. Wait either for an error response from the server, or for T seconds
     (whichever comes first)
ToP   noToC   RFC2068 - Page 48
  6. If no error response is received, after T seconds transmit the body
     of the request.

  7. If client sees that the connection is closed prematurely, repeat
     from step 1 until the request is accepted, an error response is
     received, or the user becomes impatient and terminates the retry
     process.

   No matter what the server version, if an error status is received,
   the client

  o  MUST NOT continue and

  o  MUST close the connection if it has not completed sending the
     message.

   An HTTP/1.1 (or later) client that sees the connection close after
   receiving a 100 (Continue) but before receiving any other status
   SHOULD retry the request, and need not wait for 100 (Continue)
   response (but MAY do so if this simplifies the implementation).

9 Method Definitions

   The set of common methods for HTTP/1.1 is defined below. Although
   this set can be expanded, additional methods cannot be assumed to
   share the same semantics for separately extended clients and servers.

   The Host request-header field (section 14.23) MUST accompany all
   HTTP/1.1 requests.

9.1 Safe and Idempotent Methods

9.1.1 Safe Methods

   Implementers should be aware that the software represents the user in
   their interactions over the Internet, and should be careful to allow
   the user to be aware of any actions they may take which may have an
   unexpected significance to themselves or others.

   In particular, the convention has been established that the GET and
   HEAD methods should never have the significance of taking an action
   other than retrieval. These methods should be considered "safe." This
   allows user agents to represent other methods, such as POST, PUT and
   DELETE, in a special way, so that the user is made aware of the fact
   that a possibly unsafe action is being requested.

   Naturally, it is not possible to ensure that the server does not
   generate side-effects as a result of performing a GET request; in
ToP   noToC   RFC2068 - Page 49
   fact, some dynamic resources consider that a feature. The important
   distinction here is that the user did not request the side-effects,
   so therefore cannot be held accountable for them.

9.1.2 Idempotent Methods

   Methods may also have the property of "idempotence" in that (aside
   from error or expiration issues) the side-effects of  N > 0 identical
   requests is the same as for a single request. The methods GET, HEAD,
   PUT and DELETE share this property.

9.2 OPTIONS

   The OPTIONS method represents a request for information about the
   communication options available on the request/response chain
   identified by the Request-URI. This method allows the client to
   determine the options and/or requirements associated with a resource,
   or the capabilities of a server, without implying a resource action
   or initiating a resource retrieval.

   Unless the server's response is an error, the response MUST NOT
   include entity information other than what can be considered as
   communication options (e.g., Allow is appropriate, but Content-Type
   is not). Responses to this method are not cachable.

   If the Request-URI is an asterisk ("*"), the OPTIONS request is
   intended to apply to the server as a whole. A 200 response SHOULD
   include any header fields which indicate optional features
   implemented by the server (e.g., Public), including any extensions
   not defined by this specification, in addition to any applicable
   general or response-header fields. As described in section 5.1.2, an
   "OPTIONS *" request can be applied through a proxy by specifying the
   destination server in the Request-URI without any path information.

   If the Request-URI is not an asterisk, the OPTIONS request applies
   only to the options that are available when communicating with that
   resource.  A 200 response SHOULD include any header fields which
   indicate optional features implemented by the server and applicable
   to that resource (e.g., Allow), including any extensions not defined
   by this specification, in addition to any applicable general or
   response-header fields. If the OPTIONS request passes through a
   proxy, the proxy MUST edit the response to exclude those options
   which apply to a proxy's capabilities and which are known to be
   unavailable through that proxy.


(next page on part 3)

Next Section