http11.txt

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

 14.27 If-Range .........................................115
 14.28 If-Unmodified-Since ..............................116
 14.29 Last-Modified ....................................116
 14.30 Location .........................................117
 14.31 Max-Forwards .....................................117
 14.32 Pragma ...........................................118
 14.33 Proxy-Authenticate ...............................118
 14.34 Proxy-Authorization ..............................119
 14.35 Public ...........................................119
 14.36 Range ............................................120
  14.36.1 Byte Ranges ...................................120
  14.36.2 Range Retrieval Requests ......................121
 14.37 Referer ..........................................122
 14.38 Retry-After ......................................123
 14.39 Server ...........................................123
 14.40 Transfer-Encoding ................................124
 14.41 Upgrade ..........................................124
 14.42 User-Agent .......................................125
 14.43 Vary .............................................125
 14.44 Via ..............................................127
 14.45 Warning ..........................................128
 14.46 WWW-Authenticate .................................130

15 Security Considerations...............................130
 15.1 Authentication of Clients .........................130
 15.2 Offering a Choice of Authentication Schemes .......131
 15.3 Abuse of Server Log Information ...................132
 15.4 Transfer of Sensitive Information .................132
 15.5 Attacks Based On File and Path Names ..............133
 15.6 Personal Information ..............................133
 15.7 Privacy Issues Connected to Accept Headers ........134
 15.8 DNS Spoofing ......................................134
 15.9 Location Headers and Spoofing .....................135

16 Acknowledgments.......................................135

17 References............................................136

18 Authors' Addresses....................................140

19 Appendices............................................141
 19.1 Internet Media Type message/http ..................141
 19.2 Internet Media Type multipart/byteranges ..........141
 19.3 Tolerant Applications .............................142

Fielding, et al                                               [Page 6]



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


 19.4 Differences Between HTTP Entities and RFC 1521 Entities   143
  19.4.1 Conversion to Canonical Form ...................143
  19.4.2 Conversion of Date Formats .....................144
  19.4.3 Introduction of Content-Encoding ...............144
  19.4.4 No Content-Transfer-Encoding ...................144
  19.4.5 HTTP Header Fields in Multipart Body-Parts .....144
  19.4.6 Introduction of Transfer-Encoding ..............144
  19.4.7 MIME-Version ...................................145
 19.5 Changes from HTTP/1.0 .............................145
  19.5.1 Changes to Simplify Multi-homed Web Servers and Conserve IP
  Addresses .............................................145
 19.6 Additional Features ...............................146
  19.6.1 Additional Request Methods .....................146
  19.6.2 Additional Header Field Definitions ............148
 19.7 Compatibility with Previous Versions ..............150
  19.7.1 Compatibility with HTTP/1.0 Persistent Connections151
 19.8 Notes to the RFC Editor and IANA ..................152
  19.8.1 Charset Registry ...............................152
  19.8.2 Content-coding Values ..........................153
  19.8.3 New Media Types Registered .....................153
  19.8.4 Possible Merge With Digest Authentication Draft 153































Fielding, et al                                               [Page 7]






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.

SHOULD
     This word or the adjective "recommended" means that there may exist

Fielding, et al                                               [Page 8]



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


     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.

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.



Fielding, et al                                               [Page 9]



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


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.

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.


Fielding, et al                                              [Page 10]



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


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