http11.txt

关于黑客的论坛的下载资料

Many HTTP/1.1 header field values consist of words separated by LWS or
special characters. These special characters MUST be in a quoted string
to be used within a parameter value.

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

       tspecials      = "(" | ")" | "<" | ">" | "@"
                      | "," | ";" | ":" | "\" | <">
                      | "/" | "[" | "]" | "?" | "="
                      | "{" | "}" | 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                                              [Page 16]



INTERNET-DRAFT            HTTP/1.1             Monday, August 12, 1996


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                                              [Page 17]



INTERNET-DRAFT            HTTP/1.1             Monday, August 12, 1996


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 | "/" )

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

Fielding, et al                                              [Page 18]



INTERNET-DRAFT            HTTP/1.1             Monday, August 12, 1996


       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.

       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

Fielding, et al                                              [Page 19]



INTERNET-DRAFT            HTTP/1.1             Monday, August 12, 1996


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


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.


Fielding, et al                                              [Page 20]



INTERNET-DRAFT            HTTP/1.1             Monday, August 12, 1996


  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"

       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