rfc2616.html

this gives details of the network programming

   14   Header Field Definitions ....................................100
   14.1  Accept .....................................................100
   14.2  Accept-Charset .............................................102
   14.3  Accept-Encoding ............................................102
   14.4  Accept-Language ............................................104
   14.5  Accept-Ranges ..............................................105
   14.6  Age ........................................................106
   14.7  Allow ......................................................106
   14.8  Authorization ..............................................107
   14.9  Cache-Control ..............................................108
   14.9.1   What is Cacheable .......................................109
   14.9.2   What May be Stored by Caches ............................110
   14.9.3   Modifications of the Basic Expiration Mechanism .........111
   14.9.4   Cache Revalidation and Reload Controls ..................113
   14.9.5   No-Transform Directive ..................................115
   14.9.6   Cache Control Extensions ................................116
   14.10   Connection ...............................................117
   14.11   Content-Encoding .........................................118
   14.12   Content-Language .........................................118
   14.13   Content-Length ...........................................119
   14.14   Content-Location .........................................120
   14.15   Content-MD5 ..............................................121
   14.16   Content-Range ............................................122
   14.17   Content-Type .............................................124
   14.18   Date .....................................................124
   14.18.1   Clockless Origin Server Operation ......................125
   14.19   ETag .....................................................126
   14.20   Expect ...................................................126
   14.21   Expires ..................................................127
   14.22   From .....................................................128



Fielding, et al.            Standards Track                     [Page 5]
<HR>
<A href="rfc2616.html">RFC 2616</A>                        HTTP/1.1                       June 1999


   14.23   Host .....................................................128
   14.24   If-Match .................................................129
   14.25   If-Modified-Since ........................................130
   14.26   If-None-Match ............................................132
   14.27   If-Range .................................................133
   14.28   If-Unmodified-Since ......................................134
   14.29   Last-Modified ............................................134
   14.30   Location .................................................135
   14.31   Max-Forwards .............................................136
   14.32   Pragma ...................................................136
   14.33   Proxy-Authenticate .......................................137
   14.34   Proxy-Authorization ......................................137
   14.35   Range ....................................................138
   14.35.1    Byte Ranges ...........................................138
   14.35.2    Range Retrieval Requests ..............................139
   14.36   Referer ..................................................140
   14.37   Retry-After ..............................................141
   14.38   Server ...................................................141
   14.39   TE .......................................................142
   14.40   Trailer ..................................................143
   14.41  Transfer-Encoding..........................................143
   14.42   Upgrade ..................................................144
   14.43   User-Agent ...............................................145
   14.44   Vary .....................................................145
   14.45   Via ......................................................146
   14.46   Warning ..................................................148
   14.47   WWW-Authenticate .........................................150
   15 Security Considerations .......................................150
   15.1      Personal Information....................................151
   15.1.1   Abuse of Server Log Information .........................151
   15.1.2   Transfer of Sensitive Information .......................151
   15.1.3   Encoding Sensitive Information in URI's .................152
   15.1.4   Privacy Issues Connected to Accept Headers ..............152
   15.2  Attacks Based On File and Path Names .......................153
   15.3  DNS Spoofing ...............................................154
   15.4  Location Headers and Spoofing ..............................154
   15.5  Content-Disposition Issues .................................154
   15.6  Authentication Credentials and Idle Clients ................155
   15.7  Proxies and Caching ........................................155
   15.7.1    Denial of Service Attacks on Proxies....................156
   16   Acknowledgments .............................................156
   17   References ..................................................158
   18   Authors' Addresses ..........................................162
   19   Appendices ..................................................164
   19.1  Internet Media Type message/http and application/http ......164
   19.2  Internet Media Type multipart/byteranges ...................165
   19.3  Tolerant Applications ......................................166
   19.4  Differences Between HTTP Entities and <A href="../../../../rfc.net/rfc2045.html">RFC 2045</A> Entities ....167



Fielding, et al.            Standards Track                     [Page 6]
<HR>
<A href="rfc2616.html">RFC 2616</A>                        HTTP/1.1                       June 1999


   19.4.1   MIME-Version ............................................167
   19.4.2   Conversion to Canonical Form ............................167
   19.4.3   Conversion of Date Formats ..............................168
   19.4.4   Introduction of Content-Encoding ........................168
   19.4.5   No Content-Transfer-Encoding ............................168
   19.4.6   Introduction of Transfer-Encoding .......................169
   19.4.7   MHTML and Line Length Limitations .......................169
   19.5  Additional Features ........................................169
   19.5.1   Content-Disposition .....................................170
   19.6  Compatibility with Previous Versions .......................170
   19.6.1   Changes from HTTP/1.0 ...................................171
   19.6.2   Compatibility with HTTP/1.0 Persistent Connections ......172
   19.6.3   Changes from <A href="../../../../rfc.net/rfc2068.html">RFC 2068</A> ...................................172
   20   Index .......................................................175
   21   Full Copyright Statement ....................................176

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 <A href="rfc1945.html">RFC 1945</A> [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, or 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 and headers that indicate the
   purpose of a request [47]. It builds on the discipline of reference
   provided by the Uniform Resource Identifier (URI) [3], as a location
   (URL) [4] or name (URN) [20], for indicating the resource to which a





Fielding, et al.            Standards Track                     [Page 7]
<HR>
<A href="rfc2616.html">RFC 2616</A>                        HTTP/1.1                       June 1999


   method is to be applied. Messages are passed in a format similar to
   that used by Internet mail [9] as defined by the Multipurpose
   Internet Mail Extensions (MIME) [7].

   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

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in <A href="../../../../rfc.net/rfc2119.html">RFC 2119</A> [34].

   An implementation is not compliant if it fails to satisfy one or more
   of the MUST or REQUIRED level requirements for the protocols it
   implements. An implementation that satisfies all the MUST or REQUIRED
   level and all the SHOULD level requirements for its protocols is said
   to be "unconditionally compliant"; one that satisfies all the MUST
   level requirements but not all the SHOULD level 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.








Fielding, et al.            Standards Track                     [Page 8]
<HR>
<A href="rfc2616.html">RFC 2616</A>                        HTTP/1.1                       June 1999


   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, and
      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.

   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 `varriant'.  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.




Fielding, et al.            Standards Track                     [Page 9]
<HR>
<A href="rfc2616.html">RFC 2616</A>                        HTTP/1.1                       June 1999