http11.txt

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

  constraints on whether a cache can use the cached copy for a
  particular request.

first-hand
  A response is first-hand if it comes directly and without unnecessary
  delay from the origin server, perhaps via one or more proxies. A
  response is also first-hand if its validity has just been checked
  directly with the origin server.

explicit expiration time
  The time at which the origin server intends that an entity should no
  longer be returned by a cache without further validation.

heuristic expiration time
  An expiration time assigned by a cache when no explicit expiration
  time is available.

age
  The age of a response is the time since it was sent by, or
  successfully validated with, the origin server.

freshness lifetime
  The length of time between the generation of a response and its
  expiration time.

fresh
  A response is fresh if its age has not yet exceeded its freshness
  lifetime.

stale
  A response is stale if its age has passed its freshness lifetime.

Fielding, et al                                              [Page 11]



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


semantically transparent
  A cache behaves in a "semantically transparent" manner, with respect
  to a particular response, when its use affects neither the requesting
  client nor the origin server, except to improve performance. When a
  cache is semantically transparent, the client receives exactly the
  same response (except for hop-by-hop headers) that it would have
  received had its request been handled directly by the origin server.

validator
  A protocol element (e.g., an entity tag or a Last-Modified time) that
  is used to find out whether a cache entry is an equivalent copy of an
  entity.


1.4 Overall Operation

The HTTP protocol is a request/response protocol. A client sends a
request to the server in the form of a request method, URI, and protocol
version, followed by a MIME-like message containing request modifiers,
client information, and possible body content over a connection with a
server. The server responds with a status line, including the message's
protocol version and a success or error code, followed by a MIME-like
message containing server information, entity metainformation, and
possible entity-body content. The relationship between HTTP and MIME is
described in appendix 19.4.

Most HTTP communication is initiated by a user agent and consists of a
request to be applied to a resource on some origin server. In the
simplest case, this may be accomplished via a single connection (v)
between the user agent (UA) and the origin server (O).

          request chain ------------------------>
       UA -------------------v------------------- O
          <----------------------- response chain

A more complicated situation occurs when one or more intermediaries are
present in the request/response chain. There are three common forms of
intermediary: proxy, gateway, and tunnel. A proxy is a forwarding agent,
receiving requests for a URI in its absolute form, rewriting all or part
of the message, and forwarding the reformatted request toward the server
identified by the URI. A gateway is a receiving agent, acting as a layer
above some other server(s) and, if necessary, translating the requests
to the underlying server's protocol. A tunnel acts as a relay point
between two connections without changing the messages; tunnels are used
when the communication needs to pass through an intermediary (such as a
firewall) even when the intermediary cannot understand the contents of
the messages.

          request chain -------------------------------------->
       UA -----v----- A -----v----- B -----v----- C -----v----- O
          <------------------------------------- response chain

Fielding, et al                                              [Page 12]



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


The figure above shows three intermediaries (A, B, and C) between the
user agent and origin server. A request or response message that travels
the whole chain will pass through four separate connections. This
distinction is important because some HTTP communication options may
apply only to the connection with the nearest, non-tunnel neighbor, only
to the end-points of the chain, or to all connections along the chain.
Although the diagram is linear, each participant may be engaged in
multiple, simultaneous communications. For example, B may be receiving
requests from many clients other than A, and/or forwarding requests to
servers other than C, at the same time that it is handling A's request.

Any party to the communication which is not acting as a tunnel may
employ an internal cache for handling requests. The effect of a cache is
that the request/response chain is shortened if one of the participants
along the chain has a cached response applicable to that request. The
following illustrates the resulting chain if B has a cached copy of an
earlier response from O (via C) for a request which has not been cached
by UA or A.

          request chain ---------->
       UA -----v----- A -----v----- B - - - - - - C - - - - - - O
          <--------- response chain

Not all responses are usefully cachable, and some requests may contain
modifiers which place special requirements on cache behavior. HTTP
requirements for cache behavior and cachable responses are defined in
section 13.

In fact, there are a wide variety of architectures and configurations of
caches and proxies currently being experimented with or deployed across
the World Wide Web; these systems include national hierarchies of proxy
caches to save transoceanic bandwidth, systems that broadcast or
multicast cache entries, organizations that distribute subsets of cached
data via CD-ROM, and so on. HTTP systems are used in corporate intranets
over high-bandwidth links, and for access via PDAs with low-power radio
links and intermittent connectivity. The goal of HTTP/1.1 is to support
the wide diversity of configurations already deployed while introducing
protocol constructs that meet the needs of those who build web
applications that require high reliability and, failing that, at least
reliable indications of failure.

HTTP communication usually takes place over TCP/IP connections. The
default port is TCP 80, but other ports can be used. This does not
preclude HTTP from being implemented on top of any other protocol on the
Internet, or on other networks. HTTP only presumes a reliable transport;
any protocol that provides such guarantees can be used; the mapping of
the HTTP/1.1 request and response structures onto the transport data
units of the protocol in question is outside the scope of this
specification.



Fielding, et al                                              [Page 13]



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


In HTTP/1.0, most implementations used a new connection for each
request/response exchange. In HTTP/1.1, a connection may be used for one
or more request/response exchanges, although connections may be closed
for a variety of reasons (see section 8.1).


2 Notational Conventions and Generic Grammar


2.1 Augmented BNF

All of the mechanisms specified in this document are described in both
prose and an augmented Backus-Naur Form (BNF) similar to that used by
RFC 822 [9]. Implementers will need to be familiar with the notation in
order to understand this specification. The augmented BNF includes the
following constructs:

name = definition
     The name of a rule is simply the name itself (without any enclosing
     "<" and ">") and is separated from its definition by the equal "="
     character. Whitespace is only significant in that indentation of
     continuation lines is used to indicate a rule definition that spans
     more than one line. Certain basic rules are in uppercase, such as
     SP, LWS, HT, CRLF, DIGIT, ALPHA, etc. Angle brackets are used
     within definitions whenever their presence will facilitate
     discerning the use of rule names.

"literal"
     Quotation marks surround literal text. Unless stated otherwise, the
     text is case-insensitive.

rule1 | rule2
     Elements separated by a bar ("|") are alternatives, e.g., 
     "yes | no" will accept yes or no.

(rule1 rule2)
     Elements enclosed in parentheses are treated as a single element.
     Thus, "(elem (foo | bar) elem)" allows the token sequences
     "elem foo elem" and "elem bar elem".

*rule
     The character "*" preceding an element indicates repetition. The
     full form is "<n>*<m>element" indicating at least <n> and at most
     <m> occurrences of element. Default values are 0 and infinity so
     that "*(element)" allows any number, including zero; "1*element"
     requires at least one; and "1*2element" allows one or two.

[rule]
     Square brackets enclose optional elements; "[foo bar]" is
     equivalent to "*1(foo bar)".


Fielding, et al                                              [Page 14]



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


N rule
     Specific repetition: "<n>(element)" is equivalent to
     "<n>*<n>(element)"; that is, exactly <n> occurrences of (element).
     Thus 2DIGIT is a 2-digit number, and 3ALPHA is a string of three
     alphabetic characters.

#rule
     A construct "#" is defined, similar to "*", for defining lists of
     elements. The full form is "<n>#<m>element " indicating at least
     <n> and at most <m> elements, each separated by one or more commas
     (",") and optional linear whitespace (LWS). This makes the usual
     form of lists very easy; a rule such as
     "( *LWS element *( *LWS "," *LWS element )) " can be shown as
     "1#element". Wherever this construct is used, null elements are
     allowed, but do not contribute to the count of elements present.
     That is, "(element), , (element) " is permitted, but counts as only
     two elements. Therefore, where at least one element is required, at
     least one non-null element must be present. Default values are 0
     and infinity so that "#element" allows any number, including zero;
     "1#element" requires at least one; and "1#2element" allows one or
     two.

; comment
     A semi-colon, set off some distance to the right of rule text,
     starts a comment that continues to the end of line. This is a
     simple way of including useful notes in parallel with the
     specifications.

implied *LWS
     The grammar described by this specification is word-based. Except
     where noted otherwise, linear whitespace (LWS) can be included
     between any two adjacent words (token or quoted-string), and
     between adjacent tokens and delimiters (tspecials), without
     changing the interpretation of a field. At least one delimiter
     (tspecials) must exist between any two tokens, since they would
     otherwise be interpreted as a single token.


2.2 Basic Rules

The following rules are used throughout this specification to describe
basic parsing constructs. The US-ASCII coded character set is defined by
ANSI X3.4-1986 [21].

       OCTET          = <any 8-bit sequence of data>
       CHAR           = <any US-ASCII character (octets 0 - 127)>
       UPALPHA        = <any US-ASCII uppercase letter "A".."Z">
       LOALPHA        = <any US-ASCII lowercase letter "a".."z">
       ALPHA          = UPALPHA | LOALPHA
       DIGIT          = <any US-ASCII digit "0".."9">
       CTL            = <any US-ASCII control character

Fielding, et al                                              [Page 15]



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


                        (octets 0 - 31) and DEL (127)>
       CR             = <US-ASCII CR, carriage return (13)>
       LF             = <US-ASCII LF, linefeed (10)>
       SP             = <US-ASCII SP, space (32)>
       HT             = <US-ASCII HT, horizontal-tab (9)>
       <">            = <US-ASCII double-quote mark (34)>

HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all
protocol elements except the entity-body (see appendix 19.3 for tolerant
applications). The end-of-line marker within an entity-body is defined
by its associated media type, as described in section 3.7.

       CRLF           = CR LF

HTTP/1.1 headers can be folded onto multiple lines if the continuation
line begins with a space or horizontal tab. All linear white space,
including folding, has the same semantics as SP.

       LWS            = [CRLF] 1*( SP | HT )

The TEXT rule is only used for descriptive field contents and values
that are not intended to be interpreted by the message parser. Words of
*TEXT may contain characters from character sets other than ISO 8859-1
[22] only when encoded according to the rules of RFC 1522 [14].

       TEXT           = <any OCTET except CTLs,
                        but including LWS>

Hexadecimal numeric characters are used in several protocol elements.

       HEX            = "A" | "B" | "C" | "D" | "E" | "F"
                      | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT