rfc2068.txt

穿越防火墙技术代码

    15.8 DNS Spoofing ......................................144
    15.9 Location Headers and Spoofing .....................144
   16 Acknowledgments.......................................144
   17 References............................................146
   18 Authors' Addresses....................................149
   19 Appendices............................................150
    19.1 Internet Media Type message/http ..................150
    19.2 Internet Media Type multipart/byteranges ..........150
    19.3 Tolerant Applications .............................151
    19.4 Differences Between HTTP Entities and
    MIME Entities...........................................152
     19.4.1 Conversion to Canonical Form ...................152
     19.4.2 Conversion of Date Formats .....................153
     19.4.3 Introduction of Content-Encoding ...............153
     19.4.4 No Content-Transfer-Encoding ...................153
     19.4.5 HTTP Header Fields in Multipart Body-Parts .....153
     19.4.6 Introduction of Transfer-Encoding ..............154
     19.4.7 MIME-Version ...................................154
    19.5 Changes from HTTP/1.0 .............................154
     19.5.1 Changes to Simplify Multi-homed Web Servers and
     Conserve IP Addresses .................................155
    19.6 Additional Features ...............................156
     19.6.1 Additional Request Methods .....................156
     19.6.2 Additional Header Field Definitions ............156
    19.7 Compatibility with Previous Versions ..............160
     19.7.1 Compatibility with HTTP/1.0 Persistent
     Connections............................................161











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


1 Introduction

1.1 Purpose

   The Hypertext Transfer Protocol (HTTP) is an application-level
   protocol for distributed, collaborative, hypermedia information
   systems. HTTP has been in use by the World-Wide Web global
   information initiative since 1990. The first version of HTTP,
   referred to as HTTP/0.9, was a simple protocol for raw data transfer
   across the Internet. HTTP/1.0, as defined by RFC 1945 [6], improved
   the protocol by allowing messages to be in the format of MIME-like
   messages, containing metainformation about the data transferred and
   modifiers on the request/response semantics. However, HTTP/1.0 does
   not sufficiently take into consideration the effects of hierarchical
   proxies, caching, the need for persistent connections, and virtual
   hosts. In addition, the proliferation of incompletely-implemented
   applications calling themselves "HTTP/1.0" has necessitated a
   protocol version change in order for two communicating applications
   to determine each other's true capabilities.

   This specification defines the protocol referred to as "HTTP/1.1".
   This protocol includes more stringent requirements than HTTP/1.0 in
   order to ensure reliable implementation of its features.

   Practical information systems require more functionality than simple
   retrieval, including search, front-end update, and annotation. HTTP
   allows an open-ended set of methods that indicate the purpose of a
   request. It builds on the discipline of reference provided by the
   Uniform Resource Identifier (URI) [3][20], as a location (URL) [4] or
   name (URN) , for indicating the resource to which a method is to be
   applied. Messages are passed in a format similar to that used by
   Internet mail as defined by the Multipurpose Internet Mail Extensions
   (MIME).

   HTTP is also used as a generic protocol for communication between
   user agents and proxies/gateways to other Internet systems, including
   those supported by the SMTP [16], NNTP [13], FTP [18], Gopher [2],
   and WAIS [10] protocols. In this way, HTTP allows basic hypermedia
   access to resources available from diverse applications.

1.2 Requirements

   This specification uses the same words as RFC 1123 [8] for defining
   the significance of each particular requirement. These words are:

   MUST
      This word or the adjective "required" means that the item is an
      absolute requirement of the specification.



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


   SHOULD
      This word or the adjective "recommended" means that there may
      exist valid reasons in particular circumstances to ignore this
      item, but the full implications should be understood and the case
      carefully weighed before choosing a different course.

   MAY
      This word or the adjective "optional" means that this item is
      truly optional. One vendor may choose to include the item because
      a particular marketplace requires it or because it enhances the
      product, for example; another vendor may omit the same item.

   An implementation is not compliant if it fails to satisfy one or more
   of the MUST requirements for the protocols it implements. An
   implementation that satisfies all the MUST and all the SHOULD
   requirements for its protocols is said to be "unconditionally
   compliant"; one that satisfies all the MUST requirements but not all
   the SHOULD requirements for its protocols is said to be
   "conditionally compliant."

1.3 Terminology

   This specification uses a number of terms to refer to the roles
   played by participants in, and objects of, the HTTP communication.

   connection
      A transport layer virtual circuit established between two programs
      for the purpose of communication.

   message
      The basic unit of HTTP communication, consisting of a structured
      sequence of octets matching the syntax defined in section 4 and
      transmitted via the connection.

   request
      An HTTP request message, as defined in section 5.

   response
      An HTTP response message, as defined in section 6.

   resource
      A network data object or service that can be identified by a URI,
      as defined in section 3.2. Resources may be available in multiple
      representations (e.g. multiple languages, data formats, size,
      resolutions) or vary in other ways.






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


   entity
      The information transferred as the payload of a request or
      response. An entity consists of metainformation in the form of
      entity-header fields and content in the form of an entity-body, as
      described in section 7.

   representation
      An entity included with a response that is subject to content
      negotiation, as described in section 12. There may exist multiple
      representations associated with a particular response status.

   content negotiation
      The mechanism for selecting the appropriate representation when
      servicing a request, as described in section 12. The
      representation of entities in any response can be negotiated
      (including error responses).

   variant
      A resource may have one, or more than one, representation(s)
      associated with it at any given instant. Each of these
      representations is termed a `variant.' Use of the term `variant'
      does not necessarily imply that the resource is subject to content
      negotiation.

   client
      A program that establishes connections for the purpose of sending
      requests.

   user agent
      The client which initiates a request. These are often browsers,
      editors, spiders (web-traversing robots), or other end user tools.

   server
      An application program that accepts connections in order to
      service requests by sending back responses. Any given program may
      be capable of being both a client and a server; our use of these
      terms refers only to the role being performed by the program for a
      particular connection, rather than to the program's capabilities
      in general.  Likewise, any server may act as an origin server,
      proxy, gateway, or tunnel, switching behavior based on the nature
      of each request.

   origin server
      The server on which a given resource resides or is to be created.







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


   proxy
      An intermediary program which acts as both a server and a client
      for the purpose of making requests on behalf of other clients.
      Requests are serviced internally or by passing them on, with
      possible translation, to other servers. A proxy must implement
      both the client and server requirements of this specification.

   gateway
      A server which acts as an intermediary for some other server.
      Unlike a proxy, a gateway receives requests as if it were the
      origin server for the requested resource; the requesting client
      may not be aware that it is communicating with a gateway.

   tunnel
      An intermediary program which is acting as a blind relay between
      two connections. Once active, a tunnel is not considered a party
      to the HTTP communication, though the tunnel may have been
      initiated by an HTTP request. The tunnel ceases to exist when both
      ends of the relayed connections are closed.

   cache
      A program's local store of response messages and the subsystem
      that controls its message storage, retrieval, and deletion. A
      cache stores cachable responses in order to reduce the response
      time and network bandwidth consumption on future, equivalent
      requests. Any client or server may include a cache, though a cache
      cannot be used by a server that is acting as a tunnel.

   cachable
      A response is cachable if a cache is allowed to store a copy of
      the response message for use in answering subsequent requests. The
      rules for determining the cachability of HTTP responses are
      defined in section 13. Even if a resource is cachable, there may
      be additional 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.






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


   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.

   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.