rfc1945.txt

<VC++网络游戏建摸与实现>源代码


RFC 1945                        HTTP/1.0                        May 1996


       token          = 1*<any CHAR except CTLs or tspecials>

       tspecials      = "(" | ")" | "<" | ">" | "@"
                      | "," | ";" | ":" | "\" | <">
                      | "/" | "[" | "]" | "?" | "="
                      | "{" | "}" | SP | HT

   Comments may be included in some HTTP header fields by surrounding
   the comment text with parentheses. Comments are only allowed in
   fields containing "comment" as part of their field value definition.
   In all other fields, parentheses are considered part of the field
   value.

       comment        = "(" *( ctext | comment ) ")"
       ctext          = <any TEXT excluding "(" and ")">

   A string of text is parsed as a single word if it is quoted using
   double-quote marks.

       quoted-string  = ( <"> *(qdtext) <"> )

       qdtext         = <any CHAR except <"> and CTLs,
                        but including LWS>

   Single-character quoting using the backslash ("\") character is not
   permitted in HTTP/1.0.

3.  Protocol Parameters

3.1  HTTP Version

   HTTP uses a "<major>.<minor>" numbering scheme to indicate versions
   of the protocol. The protocol versioning policy is intended to allow
   the sender to indicate the format of a message and its capacity for
   understanding further HTTP communication, rather than the features
   obtained via that communication. No change is made to the version
   number for the addition of message components which do not affect
   communication behavior or which only add to extensible field values.
   The <minor> number is incremented when the changes made to the
   protocol add features which do not change the general message parsing
   algorithm, but which may add to the message semantics and imply
   additional capabilities of the sender. The <major> number is
   incremented when the format of a message within the protocol is
   changed.

   The version of an HTTP message is indicated by an HTTP-Version field
   in the first line of the message. If the protocol version is not
   specified, the recipient must assume that the message is in the



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


   simple HTTP/0.9 format.

       HTTP-Version   = "HTTP" "/" 1*DIGIT "." 1*DIGIT

   Note that the major and minor numbers should be treated as separate
   integers and that each may be incremented higher than a single digit.
   Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is
   lower than HTTP/12.3. Leading zeros should be ignored by recipients
   and never generated by senders.

   This document defines both the 0.9 and 1.0 versions of the HTTP
   protocol. Applications sending Full-Request or Full-Response
   messages, as defined by this specification, must include an HTTP-
   Version of "HTTP/1.0".

   HTTP/1.0 servers must:

      o recognize the format of the Request-Line for HTTP/0.9 and
        HTTP/1.0 requests;

      o understand any valid request in the format of HTTP/0.9 or
        HTTP/1.0;

      o respond appropriately with a message in the same protocol
        version used by the client.

   HTTP/1.0 clients must:

      o recognize the format of the Status-Line for HTTP/1.0 responses;

      o understand any valid response in the format of HTTP/0.9 or
        HTTP/1.0.

   Proxy and gateway applications must be careful in forwarding requests
   that are received in a format different than that of the
   application's native HTTP version. Since the protocol version
   indicates the protocol capability of the sender, a proxy/gateway must
   never send a message with a version indicator which is greater than
   its native version; if a higher version request is received, the
   proxy/gateway must either downgrade the request version or respond
   with an error. Requests with a version lower than that of the
   application's native format may be upgraded before being forwarded;
   the proxy/gateway's response to that request must follow the server
   requirements listed above.







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


3.2  Uniform Resource Identifiers

   URIs have been known by many names: WWW addresses, Universal Document
   Identifiers, Universal Resource Identifiers [2], and finally the
   combination of Uniform Resource Locators (URL) [4] and Names (URN)
   [16]. As far as HTTP is concerned, Uniform Resource Identifiers are
   simply formatted strings which identify--via name, location, or any
   other characteristic--a network resource.

3.2.1 General Syntax

   URIs in HTTP can be represented in absolute form or relative to some
   known base URI [9], depending upon the context of their use. The two
   forms are differentiated by the fact that absolute URIs always begin
   with a scheme name followed by a colon.

       URI            = ( absoluteURI | relativeURI ) [ "#" fragment ]

       absoluteURI    = scheme ":" *( uchar | reserved )

       relativeURI    = net_path | abs_path | rel_path

       net_path       = "//" net_loc [ abs_path ]
       abs_path       = "/" rel_path
       rel_path       = [ path ] [ ";" params ] [ "?" query ]

       path           = fsegment *( "/" segment )
       fsegment       = 1*pchar
       segment        = *pchar

       params         = param *( ";" param )
       param          = *( pchar | "/" )

       scheme         = 1*( ALPHA | DIGIT | "+" | "-" | "." )
       net_loc        = *( pchar | ";" | "?" )
       query          = *( uchar | reserved )
       fragment       = *( uchar | reserved )

       pchar          = uchar | ":" | "@" | "&" | "=" | "+"
       uchar          = unreserved | escape
       unreserved     = ALPHA | DIGIT | safe | extra | national

       escape         = "%" HEX HEX
       reserved       = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+"
       extra          = "!" | "*" | "'" | "(" | ")" | ","
       safe           = "$" | "-" | "_" | "."
       unsafe         = CTL | SP | <"> | "#" | "%" | "<" | ">"
       national       = <any OCTET excluding ALPHA, DIGIT,



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


                        reserved, extra, safe, and unsafe>

   For definitive information on URL syntax and semantics, see RFC 1738
   [4] and RFC 1808 [9]. The BNF above includes national characters not
   allowed in valid URLs as specified by RFC 1738, since HTTP servers
   are not restricted in the set of unreserved characters allowed to
   represent the rel_path part of addresses, and HTTP proxies may
   receive requests for URIs not defined by RFC 1738.

3.2.2 http URL

   The "http" scheme is used to locate network resources via the HTTP
   protocol. This section defines the scheme-specific syntax and
   semantics for http URLs.

       http_URL       = "http:" "//" host [ ":" port ] [ abs_path ]

       host           = <A legal Internet host domain name
                         or IP address (in dotted-decimal form),
                         as defined by Section 2.1 of RFC 1123>

       port           = *DIGIT

   If the port is empty or not given, port 80 is assumed. The semantics
   are that the identified resource is located at the server listening
   for TCP connections on that port of that host, and the Request-URI
   for the resource is abs_path. If the abs_path is not present in the
   URL, it must be given as "/" when used as a Request-URI (Section
   5.1.2).

      Note: Although the HTTP protocol is independent of the transport
      layer protocol, the http URL only identifies resources by their
      TCP location, and thus non-TCP resources must be identified by
      some other URI scheme.

   The canonical form for "http" URLs is obtained by converting any
   UPALPHA characters in host to their LOALPHA equivalent (hostnames are
   case-insensitive), eliding the [ ":" port ] if the port is 80, and
   replacing an empty abs_path with "/".

3.3  Date/Time Formats

   HTTP/1.0 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



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


   The first format is preferred as an Internet standard and represents
   a fixed-length subset of that defined by RFC 1123 [6] (an update to
   RFC 822 [7]). The second format is in common use, but is based on the
   obsolete RFC 850 [10] date format and lacks a four-digit year.
   HTTP/1.0 clients and servers that parse the date value should accept
   all three formats, though they must never generate the third
   (asctime) format.

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

   All HTTP/1.0 date/time stamps must be represented in Universal Time
   (UT), also known as 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 should 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"

       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



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


       presentation, request logging, etc.

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