rfc1945.txt

RFC 的详细文档！

       HTTP-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 are received is not significant.
   However, it is "good practice" to send General-Header fields first,
   followed by Request-Header or Response-Header fields prior to the
   Entity-Header fields.

   Multiple HTTP-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.




Berners-Lee, et al           Informational                     [Page 22]

RFC 1945                        HTTP/1.0                        May 1996


4.3  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 headers apply only to the message
   being transmitted.

       General-Header = Date                     ; Section 10.6
                      | Pragma                   ; Section 10.12

   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. For
   backwards compatibility with the more limited HTTP/0.9 protocol,
   there are two valid formats for an HTTP request:

       Request        = Simple-Request | Full-Request

       Simple-Request = "GET" SP Request-URI CRLF

       Full-Request   = Request-Line             ; Section 5.1
                        *( General-Header        ; Section 4.3
                         | Request-Header        ; Section 5.2
                         | Entity-Header )       ; Section 7.1
                        CRLF
                        [ Entity-Body ]          ; Section 7.2

   If an HTTP/1.0 server receives a Simple-Request, it must respond with
   an HTTP/0.9 Simple-Response. An HTTP/1.0 client capable of receiving
   a Full-Response should never generate a Simple-Request.

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



Berners-Lee, et al           Informational                     [Page 23]

RFC 1945                        HTTP/1.0                        May 1996


   Note that the difference between a Simple-Request and the Request-
   Line of a Full-Request is the presence of the HTTP-Version field and
   the availability of methods other than GET.

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         = "GET"                    ; Section 8.1
                      | "HEAD"                   ; Section 8.2
                      | "POST"                   ; Section 8.3
                      | extension-method

       extension-method = token

   The list of methods acceptable by a specific resource can change
   dynamically; the client is notified through the return code of the
   response if a method is not allowed on a resource. Servers should
   return the status code 501 (not implemented) if the method is
   unrecognized or not implemented.

   The methods commonly used by HTTP/1.0 applications are fully defined
   in Section 8.

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 two options for Request-URI are dependent on the nature of the
   request.

   The absoluteURI form is only allowed when the request is being made
   to a proxy. The proxy is requested to forward the request and return
   the response. If the request is GET or HEAD and a prior response is
   cached, the proxy may use the cached message if it passes any
   restrictions in the Expires header field. 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.0




Berners-Lee, et al           Informational                     [Page 24]

RFC 1945                        HTTP/1.0                        May 1996


   The most common form of Request-URI is that used to identify a
   resource on an origin server or gateway. In this case, only the
   absolute path of the URI is transmitted (see Section 3.2.1,
   abs_path). 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 line:

       GET /pub/WWW/TheProject.html HTTP/1.0

   followed by the remainder of the Full-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).

   The Request-URI is transmitted as an encoded string, where some
   characters may be escaped using the "% HEX HEX" encoding defined by
   RFC 1738 [4]. The origin server must decode the Request-URI in order
   to properly interpret the request.

5.2  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
   equivalent to the parameters on a programming language method
   (procedure) invocation.

       Request-Header = Authorization            ; Section 10.2
                      | From                     ; Section 10.8
                      | If-Modified-Since        ; Section 10.9
                      | Referer                  ; Section 10.13
                      | User-Agent               ; Section 10.15

   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
   in the form of an HTTP response message.

       Response        = Simple-Response | Full-Response

       Simple-Response = [ Entity-Body ]




Berners-Lee, et al           Informational                     [Page 25]

RFC 1945                        HTTP/1.0                        May 1996


       Full-Response   = Status-Line             ; Section 6.1
                         *( General-Header       ; Section 4.3
                          | Response-Header      ; Section 6.2
                          | Entity-Header )      ; Section 7.1
                         CRLF
                         [ Entity-Body ]         ; Section 7.2

   A Simple-Response should only be sent in response to an HTTP/0.9
   Simple-Request or if the server only supports the more limited
   HTTP/0.9 protocol. If a client sends an HTTP/1.0 Full-Request and
   receives a response that does not begin with a Status-Line, it should
   assume that the response is a Simple-Response and parse it
   accordingly. Note that the Simple-Response consists only of the
   entity body and is terminated by the server closing the connection.

6.1  Status-Line

   The first line of a Full-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.

       Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

   Since a status line always begins with the protocol version and
   status code

       "HTTP/" 1*DIGIT "." 1*DIGIT SP 3DIGIT SP

   (e.g., "HTTP/1.0 200 "), the presence of that expression is
   sufficient to differentiate a Full-Response from a Simple-Response.
   Although the Simple-Response format may allow such an expression to
   occur at the beginning of an entity body, and thus cause a
   misinterpretation of the message if it was given in response to a
   Full-Request, most HTTP/0.9 servers are limited to responses of type
   "text/html" and therefore would never generate such a response.

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. 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.






Berners-Lee, et al           Informational                     [Page 26]

RFC 1945                        HTTP/1.0                        May 1996


   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 - Not used, but reserved for future use

      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.0, 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. These codes are fully defined in Section 9.

       Status-Code    = "200"   ; OK
                      | "201"   ; Created
                      | "202"   ; Accepted
                      | "204"   ; No Content
                      | "301"   ; Moved Permanently
                      | "302"   ; Moved Temporarily
                      | "304"   ; Not Modified
                      | "400"   ; Bad Request
                      | "401"   ; Unauthorized
                      | "403"   ; Forbidden
                      | "404"   ; Not Found
                      | "500"   ; Internal Server Error
                      | "501"   ; Not Implemented
                      | "502"   ; Bad Gateway
                      | "503"   ; Service Unavailable
                      | extension-code

       extension-code = 3DIGIT

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

   HTTP status codes are extensible, but the above codes are t