rfc2068.txt

本书源码主要针对目前流行的FTP、HTTP、E-mail、Telnet、ICMP、Modem串口通信编程、拨号网络编程等内容进行详细的讲解

                         | "{" | "}" | SP | HT

   Comments can 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 ")">





Fielding, et. al.           Standards Track                    [Page 16]

RFC 2068                        HTTP/1.1                    January 1997


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

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

          qdtext         = <any TEXT except <">>

   The backslash character ("\") may be used as a single-character quoting
   mechanism only within quoted-string and comment constructs.

          quoted-pair    = "\" CHAR

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.

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

   Note that the major and minor numbers MUST 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 MUST be ignored by recipients and
   MUST NOT be sent.

   Applications sending Request or Response messages, as defined by this
   specification, MUST include an HTTP-Version of "HTTP/1.1". Use of
   this version number indicates that the sending application is at
   least conditionally compliant with this specification.

   The HTTP version of an application is the highest HTTP version for
   which the application is at least conditionally compliant.



Fielding, et. al.           Standards Track                    [Page 17]

RFC 2068                        HTTP/1.1                    January 1997


   Proxy and gateway applications must be careful when forwarding
   messages in protocol versions different from that of the application.
   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 actual version; if a higher
   version request is received, the proxy/gateway MUST either downgrade
   the request version, respond with an error, or switch to tunnel
   behavior. Requests with a version lower than that of the
   proxy/gateway's version MAY be upgraded before being forwarded; the
   proxy/gateway's response to that request MUST be in the same major
   version as the request.

     Note: Converting between versions of HTTP may involve modification
     of header fields required or forbidden by the versions involved.

3.2 Uniform Resource Identifiers

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

3.2.1 General Syntax

   URIs in HTTP can be represented in absolute form or relative to some
   known base URI, 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 | "/" )




Fielding, et. al.           Standards Track                    [Page 18]

RFC 2068                        HTTP/1.1                    January 1997


          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,
                           reserved, extra, safe, and unsafe>

   For definitive information on URL syntax and semantics, see RFC 1738
   [4] and RFC 1808 [11]. 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.

   The HTTP protocol does not place any a priori limit on the length of
   a URI. Servers MUST be able to handle the URI of any resource they
   serve, and SHOULD be able to handle URIs of unbounded length if they
   provide GET-based forms that could generate such URIs. A server
   SHOULD return 414 (Request-URI Too Long) status if a URI is longer
   than the server can handle (see section 10.4.15).

     Note: Servers should be cautious about depending on URI lengths
     above 255 bytes, because some older client or proxy implementations
     may not properly support these lengths.

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.










Fielding, et. al.           Standards Track                    [Page 19]

RFC 2068                        HTTP/1.1                    January 1997


          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. The use of IP addresses in URL's SHOULD
   be avoided whenever possible (see RFC 1900 [24]). If the abs_path is
   not present in the URL, it MUST be given as "/" when used as a
   Request-URI for a resource (section 5.1.2).

3.2.3 URI Comparison

   When comparing two URIs to decide if they match or not, a client
   SHOULD use a case-sensitive octet-by-octet comparison of the entire
   URIs, with these exceptions:

     o  A port that is empty or not given is equivalent to the default
        port for that URI;

     o  Comparisons of host names MUST be case-insensitive;

     o  Comparisons of scheme names MUST be case-insensitive;

     o  An empty abs_path is equivalent to an abs_path of "/".

   Characters other than those in the "reserved" and "unsafe" sets (see
   section 3.2) are equivalent to their ""%" HEX HEX" encodings.

   For example, the following three URIs are equivalent:

         http://abc.com:80/~smith/home.html
         http://ABC.com/%7Esmith/home.html
         http://ABC.com:/%7esmith/home.html












Fielding, et. al.           Standards Track                    [Page 20]

RFC 2068                        HTTP/1.1                    January 1997


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"