"Fossies" - the Fresh Open Source Software Archive

Member "libgcgi.a-0.9.5/doc/rfc2616.txt" (22 Jun 2002, 422279 Bytes) of package /linux/www/old/gcgi-0.9.5.tar.gz:


As a special service "Fossies" has tried to format the requested text file into HTML format (style: standard) with prefixed line numbers. Alternatively you can here view or download the uninterpreted source code file.

    1 
    2 
    3 
    4 
    5 
    6 
    7 Network Working Group                                      R. Fielding
    8 Request for Comments: 2616                                   UC Irvine
    9 Obsoletes: 2068                                              J. Gettys
   10 Category: Standards Track                                   Compaq/W3C
   11                                                               J. Mogul
   12                                                                 Compaq
   13                                                             H. Frystyk
   14                                                                W3C/MIT
   15                                                            L. Masinter
   16                                                                  Xerox
   17                                                               P. Leach
   18                                                              Microsoft
   19                                                         T. Berners-Lee
   20                                                                W3C/MIT
   21                                                              June 1999
   22 
   23 
   24                 Hypertext Transfer Protocol -- HTTP/1.1
   25 
   26 Status of this Memo
   27 
   28    This document specifies an Internet standards track protocol for the
   29    Internet community, and requests discussion and suggestions for
   30    improvements.  Please refer to the current edition of the "Internet
   31    Official Protocol Standards" (STD 1) for the standardization state
   32    and status of this protocol.  Distribution of this memo is unlimited.
   33 
   34 Copyright Notice
   35 
   36    Copyright (C) The Internet Society (1999).  All Rights Reserved.
   37 
   38 Abstract
   39 
   40    The Hypertext Transfer Protocol (HTTP) is an application-level
   41    protocol for distributed, collaborative, hypermedia information
   42    systems. It is a generic, stateless, protocol which can be used for
   43    many tasks beyond its use for hypertext, such as name servers and
   44    distributed object management systems, through extension of its
   45    request methods, error codes and headers [47]. A feature of HTTP is
   46    the typing and negotiation of data representation, allowing systems
   47    to be built independently of the data being transferred.
   48 
   49    HTTP has been in use by the World-Wide Web global information
   50    initiative since 1990. This specification defines the protocol
   51    referred to as "HTTP/1.1", and is an update to RFC 2068 [33].
   52 
   53 
   54 
   55 
   56 
   57 
   58 Fielding, et al.            Standards Track                     [Page 1]
   59 
   60 RFC 2616                        HTTP/1.1                       June 1999
   61 
   62 
   63 Table of Contents
   64 
   65    1   Introduction ...................................................7
   66    1.1    Purpose......................................................7
   67    1.2   Requirements .................................................8
   68    1.3   Terminology ..................................................8
   69    1.4   Overall Operation ...........................................12
   70    2   Notational Conventions and Generic Grammar ....................14
   71    2.1   Augmented BNF ...............................................14
   72    2.2   Basic Rules .................................................15
   73    3   Protocol Parameters ...........................................17
   74    3.1   HTTP Version ................................................17
   75    3.2   Uniform Resource Identifiers ................................18
   76    3.2.1    General Syntax ...........................................19
   77    3.2.2    http URL .................................................19
   78    3.2.3    URI Comparison ...........................................20
   79    3.3   Date/Time Formats ...........................................20
   80    3.3.1    Full Date ................................................20
   81    3.3.2    Delta Seconds ............................................21
   82    3.4   Character Sets ..............................................21
   83    3.4.1    Missing Charset ..........................................22
   84    3.5   Content Codings .............................................23
   85    3.6   Transfer Codings ............................................24
   86    3.6.1    Chunked Transfer Coding ..................................25
   87    3.7   Media Types .................................................26
   88    3.7.1    Canonicalization and Text Defaults .......................27
   89    3.7.2    Multipart Types ..........................................27
   90    3.8   Product Tokens ..............................................28
   91    3.9   Quality Values ..............................................29
   92    3.10  Language Tags ...............................................29
   93    3.11  Entity Tags .................................................30
   94    3.12  Range Units .................................................30
   95    4   HTTP Message ..................................................31
   96    4.1   Message Types ...............................................31
   97    4.2   Message Headers .............................................31
   98    4.3   Message Body ................................................32
   99    4.4   Message Length ..............................................33
  100    4.5   General Header Fields .......................................34
  101    5   Request .......................................................35
  102    5.1   Request-Line ................................................35
  103    5.1.1    Method ...................................................36
  104    5.1.2    Request-URI ..............................................36
  105    5.2   The Resource Identified by a Request ........................38
  106    5.3   Request Header Fields .......................................38
  107    6   Response ......................................................39
  108    6.1   Status-Line .................................................39
  109    6.1.1    Status Code and Reason Phrase ............................39
  110    6.2   Response Header Fields ......................................41
  111 
  112 
  113 
  114 Fielding, et al.            Standards Track                     [Page 2]
  115 
  116 RFC 2616                        HTTP/1.1                       June 1999
  117 
  118 
  119    7   Entity ........................................................42
  120    7.1   Entity Header Fields ........................................42
  121    7.2   Entity Body .................................................43
  122    7.2.1    Type .....................................................43
  123    7.2.2    Entity Length ............................................43
  124    8   Connections ...................................................44
  125    8.1   Persistent Connections ......................................44
  126    8.1.1    Purpose ..................................................44
  127    8.1.2    Overall Operation ........................................45
  128    8.1.3    Proxy Servers ............................................46
  129    8.1.4    Practical Considerations .................................46
  130    8.2   Message Transmission Requirements ...........................47
  131    8.2.1    Persistent Connections and Flow Control ..................47
  132    8.2.2    Monitoring Connections for Error Status Messages .........48
  133    8.2.3    Use of the 100 (Continue) Status .........................48
  134    8.2.4    Client Behavior if Server Prematurely Closes Connection ..50
  135    9   Method Definitions ............................................51
  136    9.1   Safe and Idempotent Methods .................................51
  137    9.1.1    Safe Methods .............................................51
  138    9.1.2    Idempotent Methods .......................................51
  139    9.2   OPTIONS .....................................................52
  140    9.3   GET .........................................................53
  141    9.4   HEAD ........................................................54
  142    9.5   POST ........................................................54
  143    9.6   PUT .........................................................55
  144    9.7   DELETE ......................................................56
  145    9.8   TRACE .......................................................56
  146    9.9   CONNECT .....................................................57
  147    10   Status Code Definitions ......................................57
  148    10.1  Informational 1xx ...........................................57
  149    10.1.1   100 Continue .............................................58
  150    10.1.2   101 Switching Protocols ..................................58
  151    10.2  Successful 2xx ..............................................58
  152    10.2.1   200 OK ...................................................58
  153    10.2.2   201 Created ..............................................59
  154    10.2.3   202 Accepted .............................................59
  155    10.2.4   203 Non-Authoritative Information ........................59
  156    10.2.5   204 No Content ...........................................60
  157    10.2.6   205 Reset Content ........................................60
  158    10.2.7   206 Partial Content ......................................60
  159    10.3  Redirection 3xx .............................................61
  160    10.3.1   300 Multiple Choices .....................................61
  161    10.3.2   301 Moved Permanently ....................................62
  162    10.3.3   302 Found ................................................62
  163    10.3.4   303 See Other ............................................63
  164    10.3.5   304 Not Modified .........................................63
  165    10.3.6   305 Use Proxy ............................................64
  166    10.3.7   306 (Unused) .............................................64
  167 
  168 
  169 
  170 Fielding, et al.            Standards Track                     [Page 3]
  171 
  172 RFC 2616                        HTTP/1.1                       June 1999
  173 
  174 
  175    10.3.8   307 Temporary Redirect ...................................65
  176    10.4  Client Error 4xx ............................................65
  177    10.4.1    400 Bad Request .........................................65
  178    10.4.2    401 Unauthorized ........................................66
  179    10.4.3    402 Payment Required ....................................66
  180    10.4.4    403 Forbidden ...........................................66
  181    10.4.5    404 Not Found ...........................................66
  182    10.4.6    405 Method Not Allowed ..................................66
  183    10.4.7    406 Not Acceptable ......................................67
  184    10.4.8    407 Proxy Authentication Required .......................67
  185    10.4.9    408 Request Timeout .....................................67
  186    10.4.10   409 Conflict ............................................67
  187    10.4.11   410 Gone ................................................68
  188    10.4.12   411 Length Required .....................................68
  189    10.4.13   412 Precondition Failed .................................68
  190    10.4.14   413 Request Entity Too Large ............................69
  191    10.4.15   414 Request-URI Too Long ................................69
  192    10.4.16   415 Unsupported Media Type ..............................69
  193    10.4.17   416 Requested Range Not Satisfiable .....................69
  194    10.4.18   417 Expectation Failed ..................................70
  195    10.5  Server Error 5xx ............................................70
  196    10.5.1   500 Internal Server Error ................................70
  197    10.5.2   501 Not Implemented ......................................70
  198    10.5.3   502 Bad Gateway ..........................................70
  199    10.5.4   503 Service Unavailable ..................................70
  200    10.5.5   504 Gateway Timeout ......................................71
  201    10.5.6   505 HTTP Version Not Supported ...........................71
  202    11   Access Authentication ........................................71
  203    12   Content Negotiation ..........................................71
  204    12.1  Server-driven Negotiation ...................................72
  205    12.2  Agent-driven Negotiation ....................................73
  206    12.3  Transparent Negotiation .....................................74
  207    13   Caching in HTTP ..............................................74
  208    13.1.1   Cache Correctness ........................................75
  209    13.1.2   Warnings .................................................76
  210    13.1.3   Cache-control Mechanisms .................................77
  211    13.1.4   Explicit User Agent Warnings .............................78
  212    13.1.5   Exceptions to the Rules and Warnings .....................78
  213    13.1.6   Client-controlled Behavior ...............................79
  214    13.2  Expiration Model ............................................79
  215    13.2.1   Server-Specified Expiration ..............................79
  216    13.2.2   Heuristic Expiration .....................................80
  217    13.2.3   Age Calculations .........................................80
  218    13.2.4   Expiration Calculations ..................................83
  219    13.2.5   Disambiguating Expiration Values .........................84
  220    13.2.6   Disambiguating Multiple Responses ........................84
  221    13.3  Validation Model ............................................85
  222    13.3.1   Last-Modified Dates ......................................86
  223 
  224 
  225 
  226 Fielding, et al.            Standards Track                     [Page 4]
  227 
  228 RFC 2616                        HTTP/1.1                       June 1999
  229 
  230 
  231    13.3.2   Entity Tag Cache Validators ..............................86
  232    13.3.3   Weak and Strong Validators ...............................86
  233    13.3.4   Rules for When to Use Entity Tags and Last-Modified Dates.89
  234    13.3.5   Non-validating Conditionals ..............................90
  235    13.4  Response Cacheability .......................................91
  236    13.5  Constructing Responses From Caches ..........................92
  237    13.5.1   End-to-end and Hop-by-hop Headers ........................92
  238    13.5.2   Non-modifiable Headers ...................................92
  239    13.5.3   Combining Headers ........................................94
  240    13.5.4   Combining Byte Ranges ....................................95
  241    13.6  Caching Negotiated Responses ................................95
  242    13.7  Shared and Non-Shared Caches ................................96
  243    13.8  Errors or Incomplete Response Cache Behavior ................97
  244    13.9  Side Effects of GET and HEAD ................................97
  245    13.10   Invalidation After Updates or Deletions ...................97
  246    13.11   Write-Through Mandatory ...................................98
  247    13.12   Cache Replacement .........................................99
  248    13.13   History Lists .............................................99
  249    14   Header Field Definitions ....................................100
  250    14.1  Accept .....................................................100
  251    14.2  Accept-Charset .............................................102
  252    14.3  Accept-Encoding ............................................102
  253    14.4  Accept-Language ............................................104
  254    14.5  Accept-Ranges ..............................................105
  255    14.6  Age ........................................................106
  256    14.7  Allow ......................................................106
  257    14.8  Authorization ..............................................107
  258    14.9  Cache-Control ..............................................108
  259    14.9.1   What is Cacheable .......................................109
  260    14.9.2   What May be Stored by Caches ............................110
  261    14.9.3   Modifications of the Basic Expiration Mechanism .........111
  262    14.9.4   Cache Revalidation and Reload Controls ..................113
  263    14.9.5   No-Transform Directive ..................................115
  264    14.9.6   Cache Control Extensions ................................116
  265    14.10   Connection ...............................................117
  266    14.11   Content-Encoding .........................................118
  267    14.12   Content-Language .........................................118
  268    14.13   Content-Length ...........................................119
  269    14.14   Content-Location .........................................120
  270    14.15   Content-MD5 ..............................................121
  271    14.16   Content-Range ............................................122
  272    14.17   Content-Type .............................................124
  273    14.18   Date .....................................................124
  274    14.18.1   Clockless Origin Server Operation ......................125
  275    14.19   ETag .....................................................126
  276    14.20   Expect ...................................................126
  277    14.21   Expires ..................................................127
  278    14.22   From .....................................................128
  279 
  280 
  281 
  282 Fielding, et al.            Standards Track                     [Page 5]
  283 
  284 RFC 2616                        HTTP/1.1                       June 1999
  285 
  286 
  287    14.23   Host .....................................................128
  288    14.24   If-Match .................................................129
  289    14.25   If-Modified-Since ........................................130
  290    14.26   If-None-Match ............................................132
  291    14.27   If-Range .................................................133
  292    14.28   If-Unmodified-Since ......................................134
  293    14.29   Last-Modified ............................................134
  294    14.30   Location .................................................135
  295    14.31   Max-Forwards .............................................136
  296    14.32   Pragma ...................................................136
  297    14.33   Proxy-Authenticate .......................................137
  298    14.34   Proxy-Authorization ......................................137
  299    14.35   Range ....................................................138
  300    14.35.1    Byte Ranges ...........................................138
  301    14.35.2    Range Retrieval Requests ..............................139
  302    14.36   Referer ..................................................140
  303    14.37   Retry-After ..............................................141
  304    14.38   Server ...................................................141
  305    14.39   TE .......................................................142
  306    14.40   Trailer ..................................................143
  307    14.41  Transfer-Encoding..........................................143
  308    14.42   Upgrade ..................................................144
  309    14.43   User-Agent ...............................................145
  310    14.44   Vary .....................................................145
  311    14.45   Via ......................................................146
  312    14.46   Warning ..................................................148
  313    14.47   WWW-Authenticate .........................................150
  314    15 Security Considerations .......................................150
  315    15.1      Personal Information....................................151
  316    15.1.1   Abuse of Server Log Information .........................151
  317    15.1.2   Transfer of Sensitive Information .......................151
  318    15.1.3   Encoding Sensitive Information in URI's .................152
  319    15.1.4   Privacy Issues Connected to Accept Headers ..............152
  320    15.2  Attacks Based On File and Path Names .......................153
  321    15.3  DNS Spoofing ...............................................154
  322    15.4  Location Headers and Spoofing ..............................154
  323    15.5  Content-Disposition Issues .................................154
  324    15.6  Authentication Credentials and Idle Clients ................155
  325    15.7  Proxies and Caching ........................................155
  326    15.7.1    Denial of Service Attacks on Proxies....................156
  327    16   Acknowledgments .............................................156
  328    17   References ..................................................158
  329    18   Authors' Addresses ..........................................162
  330    19   Appendices ..................................................164
  331    19.1  Internet Media Type message/http and application/http ......164
  332    19.2  Internet Media Type multipart/byteranges ...................165
  333    19.3  Tolerant Applications ......................................166
  334    19.4  Differences Between HTTP Entities and RFC 2045 Entities ....167
  335 
  336 
  337 
  338 Fielding, et al.            Standards Track                     [Page 6]
  339 
  340 RFC 2616                        HTTP/1.1                       June 1999
  341 
  342 
  343    19.4.1   MIME-Version ............................................167
  344    19.4.2   Conversion to Canonical Form ............................167
  345    19.4.3   Conversion of Date Formats ..............................168
  346    19.4.4   Introduction of Content-Encoding ........................168
  347    19.4.5   No Content-Transfer-Encoding ............................168
  348    19.4.6   Introduction of Transfer-Encoding .......................169
  349    19.4.7   MHTML and Line Length Limitations .......................169
  350    19.5  Additional Features ........................................169
  351    19.5.1   Content-Disposition .....................................170
  352    19.6  Compatibility with Previous Versions .......................170
  353    19.6.1   Changes from HTTP/1.0 ...................................171
  354    19.6.2   Compatibility with HTTP/1.0 Persistent Connections ......172
  355    19.6.3   Changes from RFC 2068 ...................................172
  356    20   Index .......................................................175
  357    21   Full Copyright Statement ....................................176
  358 
  359 1 Introduction
  360 
  361 1.1 Purpose
  362 
  363    The Hypertext Transfer Protocol (HTTP) is an application-level
  364    protocol for distributed, collaborative, hypermedia information
  365    systems. HTTP has been in use by the World-Wide Web global
  366    information initiative since 1990. The first version of HTTP,
  367    referred to as HTTP/0.9, was a simple protocol for raw data transfer
  368    across the Internet. HTTP/1.0, as defined by RFC 1945 [6], improved
  369    the protocol by allowing messages to be in the format of MIME-like
  370    messages, containing metainformation about the data transferred and
  371    modifiers on the request/response semantics. However, HTTP/1.0 does
  372    not sufficiently take into consideration the effects of hierarchical
  373    proxies, caching, the need for persistent connections, or virtual
  374    hosts. In addition, the proliferation of incompletely-implemented
  375    applications calling themselves "HTTP/1.0" has necessitated a
  376    protocol version change in order for two communicating applications
  377    to determine each other's true capabilities.
  378 
  379    This specification defines the protocol referred to as "HTTP/1.1".
  380    This protocol includes more stringent requirements than HTTP/1.0 in
  381    order to ensure reliable implementation of its features.
  382 
  383    Practical information systems require more functionality than simple
  384    retrieval, including search, front-end update, and annotation. HTTP
  385    allows an open-ended set of methods and headers that indicate the
  386    purpose of a request [47]. It builds on the discipline of reference
  387    provided by the Uniform Resource Identifier (URI) [3], as a location
  388    (URL) [4] or name (URN) [20], for indicating the resource to which a
  389 
  390 
  391 
  392 
  393 
  394 Fielding, et al.            Standards Track                     [Page 7]
  395 
  396 RFC 2616                        HTTP/1.1                       June 1999
  397 
  398 
  399    method is to be applied. Messages are passed in a format similar to
  400    that used by Internet mail [9] as defined by the Multipurpose
  401    Internet Mail Extensions (MIME) [7].
  402 
  403    HTTP is also used as a generic protocol for communication between
  404    user agents and proxies/gateways to other Internet systems, including
  405    those supported by the SMTP [16], NNTP [13], FTP [18], Gopher [2],
  406    and WAIS [10] protocols. In this way, HTTP allows basic hypermedia
  407    access to resources available from diverse applications.
  408 
  409 1.2 Requirements
  410 
  411    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  412    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  413    document are to be interpreted as described in RFC 2119 [34].
  414 
  415    An implementation is not compliant if it fails to satisfy one or more
  416    of the MUST or REQUIRED level requirements for the protocols it
  417    implements. An implementation that satisfies all the MUST or REQUIRED
  418    level and all the SHOULD level requirements for its protocols is said
  419    to be "unconditionally compliant"; one that satisfies all the MUST
  420    level requirements but not all the SHOULD level requirements for its
  421    protocols is said to be "conditionally compliant."
  422 
  423 1.3 Terminology
  424 
  425    This specification uses a number of terms to refer to the roles
  426    played by participants in, and objects of, the HTTP communication.
  427 
  428    connection
  429       A transport layer virtual circuit established between two programs
  430       for the purpose of communication.
  431 
  432    message
  433       The basic unit of HTTP communication, consisting of a structured
  434       sequence of octets matching the syntax defined in section 4 and
  435       transmitted via the connection.
  436 
  437    request
  438       An HTTP request message, as defined in section 5.
  439 
  440    response
  441       An HTTP response message, as defined in section 6.
  442 
  443 
  444 
  445 
  446 
  447 
  448 
  449 
  450 Fielding, et al.            Standards Track                     [Page 8]
  451 
  452 RFC 2616                        HTTP/1.1                       June 1999
  453 
  454 
  455    resource
  456       A network data object or service that can be identified by a URI,
  457       as defined in section 3.2. Resources may be available in multiple
  458       representations (e.g. multiple languages, data formats, size, and
  459       resolutions) or vary in other ways.
  460 
  461    entity
  462       The information transferred as the payload of a request or
  463       response. An entity consists of metainformation in the form of
  464       entity-header fields and content in the form of an entity-body, as
  465       described in section 7.
  466 
  467    representation
  468       An entity included with a response that is subject to content
  469       negotiation, as described in section 12. There may exist multiple
  470       representations associated with a particular response status.
  471 
  472    content negotiation
  473       The mechanism for selecting the appropriate representation when
  474       servicing a request, as described in section 12. The
  475       representation of entities in any response can be negotiated
  476       (including error responses).
  477 
  478    variant
  479       A resource may have one, or more than one, representation(s)
  480       associated with it at any given instant. Each of these
  481       representations is termed a `varriant'.  Use of the term `variant'
  482       does not necessarily imply that the resource is subject to content
  483       negotiation.
  484 
  485    client
  486       A program that establishes connections for the purpose of sending
  487       requests.
  488 
  489    user agent
  490       The client which initiates a request. These are often browsers,
  491       editors, spiders (web-traversing robots), or other end user tools.
  492 
  493    server
  494       An application program that accepts connections in order to
  495       service requests by sending back responses. Any given program may
  496       be capable of being both a client and a server; our use of these
  497       terms refers only to the role being performed by the program for a
  498       particular connection, rather than to the program's capabilities
  499       in general. Likewise, any server may act as an origin server,
  500       proxy, gateway, or tunnel, switching behavior based on the nature
  501       of each request.
  502 
  503 
  504 
  505 
  506 Fielding, et al.            Standards Track                     [Page 9]
  507 
  508 RFC 2616                        HTTP/1.1                       June 1999
  509 
  510 
  511    origin server
  512       The server on which a given resource resides or is to be created.
  513 
  514    proxy
  515       An intermediary program which acts as both a server and a client
  516       for the purpose of making requests on behalf of other clients.
  517       Requests are serviced internally or by passing them on, with
  518       possible translation, to other servers. A proxy MUST implement
  519       both the client and server requirements of this specification. A
  520       "transparent proxy" is a proxy that does not modify the request or
  521       response beyond what is required for proxy authentication and
  522       identification. A "non-transparent proxy" is a proxy that modifies
  523       the request or response in order to provide some added service to
  524       the user agent, such as group annotation services, media type
  525       transformation, protocol reduction, or anonymity filtering. Except
  526       where either transparent or non-transparent behavior is explicitly
  527       stated, the HTTP proxy requirements apply to both types of
  528       proxies.
  529 
  530    gateway
  531       A server which acts as an intermediary for some other server.
  532       Unlike a proxy, a gateway receives requests as if it were the
  533       origin server for the requested resource; the requesting client
  534       may not be aware that it is communicating with a gateway.
  535 
  536    tunnel
  537       An intermediary program which is acting as a blind relay between
  538       two connections. Once active, a tunnel is not considered a party
  539       to the HTTP communication, though the tunnel may have been
  540       initiated by an HTTP request. The tunnel ceases to exist when both
  541       ends of the relayed connections are closed.
  542 
  543    cache
  544       A program's local store of response messages and the subsystem
  545       that controls its message storage, retrieval, and deletion. A
  546       cache stores cacheable responses in order to reduce the response
  547       time and network bandwidth consumption on future, equivalent
  548       requests. Any client or server may include a cache, though a cache
  549       cannot be used by a server that is acting as a tunnel.
  550 
  551    cacheable
  552       A response is cacheable if a cache is allowed to store a copy of
  553       the response message for use in answering subsequent requests. The
  554       rules for determining the cacheability of HTTP responses are
  555       defined in section 13. Even if a resource is cacheable, there may
  556       be additional constraints on whether a cache can use the cached
  557       copy for a particular request.
  558 
  559 
  560 
  561 
  562 Fielding, et al.            Standards Track                    [Page 10]
  563 
  564 RFC 2616                        HTTP/1.1                       June 1999
  565 
  566 
  567    first-hand
  568       A response is first-hand if it comes directly and without
  569       unnecessary delay from the origin server, perhaps via one or more
  570       proxies. A response is also first-hand if its validity has just
  571       been checked directly with the origin server.
  572 
  573    explicit expiration time
  574       The time at which the origin server intends that an entity should
  575       no longer be returned by a cache without further validation.
  576 
  577    heuristic expiration time
  578       An expiration time assigned by a cache when no explicit expiration
  579       time is available.
  580 
  581    age
  582       The age of a response is the time since it was sent by, or
  583       successfully validated with, the origin server.
  584 
  585    freshness lifetime
  586       The length of time between the generation of a response and its
  587       expiration time.
  588 
  589    fresh
  590       A response is fresh if its age has not yet exceeded its freshness
  591       lifetime.
  592 
  593    stale
  594       A response is stale if its age has passed its freshness lifetime.
  595 
  596    semantically transparent
  597       A cache behaves in a "semantically transparent" manner, with
  598       respect to a particular response, when its use affects neither the
  599       requesting client nor the origin server, except to improve
  600       performance. When a cache is semantically transparent, the client
  601       receives exactly the same response (except for hop-by-hop headers)
  602       that it would have received had its request been handled directly
  603       by the origin server.
  604 
  605    validator
  606       A protocol element (e.g., an entity tag or a Last-Modified time)
  607       that is used to find out whether a cache entry is an equivalent
  608       copy of an entity.
  609 
  610    upstream/downstream
  611       Upstream and downstream describe the flow of a message: all
  612       messages flow from upstream to downstream.
  613 
  614 
  615 
  616 
  617 
  618 Fielding, et al.            Standards Track                    [Page 11]
  619 
  620 RFC 2616                        HTTP/1.1                       June 1999
  621 
  622 
  623    inbound/outbound
  624       Inbound and outbound refer to the request and response paths for
  625       messages: "inbound" means "traveling toward the origin server",
  626       and "outbound" means "traveling toward the user agent"
  627 
  628 1.4 Overall Operation
  629 
  630    The HTTP protocol is a request/response protocol. A client sends a
  631    request to the server in the form of a request method, URI, and
  632    protocol version, followed by a MIME-like message containing request
  633    modifiers, client information, and possible body content over a
  634    connection with a server. The server responds with a status line,
  635    including the message's protocol version and a success or error code,
  636    followed by a MIME-like message containing server information, entity
  637    metainformation, and possible entity-body content. The relationship
  638    between HTTP and MIME is described in appendix 19.4.
  639 
  640    Most HTTP communication is initiated by a user agent and consists of
  641    a request to be applied to a resource on some origin server. In the
  642    simplest case, this may be accomplished via a single connection (v)
  643    between the user agent (UA) and the origin server (O).
  644 
  645           request chain ------------------------>
  646        UA -------------------v------------------- O
  647           <----------------------- response chain
  648 
  649    A more complicated situation occurs when one or more intermediaries
  650    are present in the request/response chain. There are three common
  651    forms of intermediary: proxy, gateway, and tunnel. A proxy is a
  652    forwarding agent, receiving requests for a URI in its absolute form,
  653    rewriting all or part of the message, and forwarding the reformatted
  654    request toward the server identified by the URI. A gateway is a
  655    receiving agent, acting as a layer above some other server(s) and, if
  656    necessary, translating the requests to the underlying server's
  657    protocol. A tunnel acts as a relay point between two connections
  658    without changing the messages; tunnels are used when the
  659    communication needs to pass through an intermediary (such as a
  660    firewall) even when the intermediary cannot understand the contents
  661    of the messages.
  662 
  663           request chain -------------------------------------->
  664        UA -----v----- A -----v----- B -----v----- C -----v----- O
  665           <------------------------------------- response chain
  666 
  667    The figure above shows three intermediaries (A, B, and C) between the
  668    user agent and origin server. A request or response message that
  669    travels the whole chain will pass through four separate connections.
  670    This distinction is important because some HTTP communication options
  671 
  672 
  673 
  674 Fielding, et al.            Standards Track                    [Page 12]
  675 
  676 RFC 2616                        HTTP/1.1                       June 1999
  677 
  678 
  679    may apply only to the connection with the nearest, non-tunnel
  680    neighbor, only to the end-points of the chain, or to all connections
  681    along the chain. Although the diagram is linear, each participant may
  682    be engaged in multiple, simultaneous communications. For example, B
  683    may be receiving requests from many clients other than A, and/or
  684    forwarding requests to servers other than C, at the same time that it
  685    is handling A's request.
  686 
  687    Any party to the communication which is not acting as a tunnel may
  688    employ an internal cache for handling requests. The effect of a cache
  689    is that the request/response chain is shortened if one of the
  690    participants along the chain has a cached response applicable to that
  691    request. The following illustrates the resulting chain if B has a
  692    cached copy of an earlier response from O (via C) for a request which
  693    has not been cached by UA or A.
  694 
  695           request chain ---------->
  696        UA -----v----- A -----v----- B - - - - - - C - - - - - - O
  697           <--------- response chain
  698 
  699    Not all responses are usefully cacheable, and some requests may
  700    contain modifiers which place special requirements on cache behavior.
  701    HTTP requirements for cache behavior and cacheable responses are
  702    defined in section 13.
  703 
  704    In fact, there are a wide variety of architectures and configurations
  705    of caches and proxies currently being experimented with or deployed
  706    across the World Wide Web. These systems include national hierarchies
  707    of proxy caches to save transoceanic bandwidth, systems that
  708    broadcast or multicast cache entries, organizations that distribute
  709    subsets of cached data via CD-ROM, and so on. HTTP systems are used
  710    in corporate intranets over high-bandwidth links, and for access via
  711    PDAs with low-power radio links and intermittent connectivity. The
  712    goal of HTTP/1.1 is to support the wide diversity of configurations
  713    already deployed while introducing protocol constructs that meet the
  714    needs of those who build web applications that require high
  715    reliability and, failing that, at least reliable indications of
  716    failure.
  717 
  718    HTTP communication usually takes place over TCP/IP connections. The
  719    default port is TCP 80 [19], but other ports can be used. This does
  720    not preclude HTTP from being implemented on top of any other protocol
  721    on the Internet, or on other networks. HTTP only presumes a reliable
  722    transport; any protocol that provides such guarantees can be used;
  723    the mapping of the HTTP/1.1 request and response structures onto the
  724    transport data units of the protocol in question is outside the scope
  725    of this specification.
  726 
  727 
  728 
  729 
  730 Fielding, et al.            Standards Track                    [Page 13]
  731 
  732 RFC 2616                        HTTP/1.1                       June 1999
  733 
  734 
  735    In HTTP/1.0, most implementations used a new connection for each
  736    request/response exchange. In HTTP/1.1, a connection may be used for
  737    one or more request/response exchanges, although connections may be
  738    closed for a variety of reasons (see section 8.1).
  739 
  740 2 Notational Conventions and Generic Grammar
  741 
  742 2.1 Augmented BNF
  743 
  744    All of the mechanisms specified in this document are described in
  745    both prose and an augmented Backus-Naur Form (BNF) similar to that
  746    used by RFC 822 [9]. Implementors will need to be familiar with the
  747    notation in order to understand this specification. The augmented BNF
  748    includes the following constructs:
  749 
  750    name = definition
  751       The name of a rule is simply the name itself (without any
  752       enclosing "<" and ">") and is separated from its definition by the
  753       equal "=" character. White space is only significant in that
  754       indentation of continuation lines is used to indicate a rule
  755       definition that spans more than one line. Certain basic rules are
  756       in uppercase, such as SP, LWS, HT, CRLF, DIGIT, ALPHA, etc. Angle
  757       brackets are used within definitions whenever their presence will
  758       facilitate discerning the use of rule names.
  759 
  760    "literal"
  761       Quotation marks surround literal text. Unless stated otherwise,
  762       the text is case-insensitive.
  763 
  764    rule1 | rule2
  765       Elements separated by a bar ("|") are alternatives, e.g., "yes |
  766       no" will accept yes or no.
  767 
  768    (rule1 rule2)
  769       Elements enclosed in parentheses are treated as a single element.
  770       Thus, "(elem (foo | bar) elem)" allows the token sequences "elem
  771       foo elem" and "elem bar elem".
  772 
  773    *rule
  774       The character "*" preceding an element indicates repetition. The
  775       full form is "<n>*<m>element" indicating at least <n> and at most
  776       <m> occurrences of element. Default values are 0 and infinity so
  777       that "*(element)" allows any number, including zero; "1*element"
  778       requires at least one; and "1*2element" allows one or two.
  779 
  780    [rule]
  781       Square brackets enclose optional elements; "[foo bar]" is
  782       equivalent to "*1(foo bar)".
  783 
  784 
  785 
  786 Fielding, et al.            Standards Track                    [Page 14]
  787 
  788 RFC 2616                        HTTP/1.1                       June 1999
  789 
  790 
  791    N rule
  792       Specific repetition: "<n>(element)" is equivalent to
  793       "<n>*<n>(element)"; that is, exactly <n> occurrences of (element).
  794       Thus 2DIGIT is a 2-digit number, and 3ALPHA is a string of three
  795       alphabetic characters.
  796 
  797    #rule
  798       A construct "#" is defined, similar to "*", for defining lists of
  799       elements. The full form is "<n>#<m>element" indicating at least
  800       <n> and at most <m> elements, each separated by one or more commas
  801       (",") and OPTIONAL linear white space (LWS). This makes the usual
  802       form of lists very easy; a rule such as
  803          ( *LWS element *( *LWS "," *LWS element ))
  804       can be shown as
  805          1#element
  806       Wherever this construct is used, null elements are allowed, but do
  807       not contribute to the count of elements present. That is,
  808       "(element), , (element) " is permitted, but counts as only two
  809       elements. Therefore, where at least one element is required, at
  810       least one non-null element MUST be present. Default values are 0
  811       and infinity so that "#element" allows any number, including zero;
  812       "1#element" requires at least one; and "1#2element" allows one or
  813       two.
  814 
  815    ; comment
  816       A semi-colon, set off some distance to the right of rule text,
  817       starts a comment that continues to the end of line. This is a
  818       simple way of including useful notes in parallel with the
  819       specifications.
  820 
  821    implied *LWS
  822       The grammar described by this specification is word-based. Except
  823       where noted otherwise, linear white space (LWS) can be included
  824       between any two adjacent words (token or quoted-string), and
  825       between adjacent words and separators, without changing the
  826       interpretation of a field. At least one delimiter (LWS and/or
  827 
  828       separators) MUST exist between any two tokens (for the definition
  829       of "token" below), since they would otherwise be interpreted as a
  830       single token.
  831 
  832 2.2 Basic Rules
  833 
  834    The following rules are used throughout this specification to
  835    describe basic parsing constructs. The US-ASCII coded character set
  836    is defined by ANSI X3.4-1986 [21].
  837 
  838 
  839 
  840 
  841 
  842 Fielding, et al.            Standards Track                    [Page 15]
  843 
  844 RFC 2616                        HTTP/1.1                       June 1999
  845 
  846 
  847        OCTET          = <any 8-bit sequence of data>
  848        CHAR           = <any US-ASCII character (octets 0 - 127)>
  849        UPALPHA        = <any US-ASCII uppercase letter "A".."Z">
  850        LOALPHA        = <any US-ASCII lowercase letter "a".."z">
  851        ALPHA          = UPALPHA | LOALPHA
  852        DIGIT          = <any US-ASCII digit "0".."9">
  853        CTL            = <any US-ASCII control character
  854                         (octets 0 - 31) and DEL (127)>
  855        CR             = <US-ASCII CR, carriage return (13)>
  856        LF             = <US-ASCII LF, linefeed (10)>
  857        SP             = <US-ASCII SP, space (32)>
  858        HT             = <US-ASCII HT, horizontal-tab (9)>
  859        <">            = <US-ASCII double-quote mark (34)>
  860 
  861    HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all
  862    protocol elements except the entity-body (see appendix 19.3 for
  863    tolerant applications). The end-of-line marker within an entity-body
  864    is defined by its associated media type, as described in section 3.7.
  865 
  866        CRLF           = CR LF
  867 
  868    HTTP/1.1 header field values can be folded onto multiple lines if the
  869    continuation line begins with a space or horizontal tab. All linear
  870    white space, including folding, has the same semantics as SP. A
  871    recipient MAY replace any linear white space with a single SP before
  872    interpreting the field value or forwarding the message downstream.
  873 
  874        LWS            = [CRLF] 1*( SP | HT )
  875 
  876    The TEXT rule is only used for descriptive field contents and values
  877    that are not intended to be interpreted by the message parser. Words
  878    of *TEXT MAY contain characters from character sets other than ISO-
  879    8859-1 [22] only when encoded according to the rules of RFC 2047
  880    [14].
  881 
  882        TEXT           = <any OCTET except CTLs,
  883                         but including LWS>
  884 
  885    A CRLF is allowed in the definition of TEXT only as part of a header
  886    field continuation. It is expected that the folding LWS will be
  887    replaced with a single SP before interpretation of the TEXT value.
  888 
  889    Hexadecimal numeric characters are used in several protocol elements.
  890 
  891        HEX            = "A" | "B" | "C" | "D" | "E" | "F"
  892                       | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT
  893 
  894 
  895 
  896 
  897 
  898 Fielding, et al.            Standards Track                    [Page 16]
  899 
  900 RFC 2616                        HTTP/1.1                       June 1999
  901 
  902 
  903    Many HTTP/1.1 header field values consist of words separated by LWS
  904    or special characters. These special characters MUST be in a quoted
  905    string to be used within a parameter value (as defined in section
  906    3.6).
  907 
  908        token          = 1*<any CHAR except CTLs or separators>
  909        separators     = "(" | ")" | "<" | ">" | "@"
  910                       | "," | ";" | ":" | "\" | <">
  911                       | "/" | "[" | "]" | "?" | "="
  912                       | "{" | "}" | SP | HT
  913 
  914    Comments can be included in some HTTP header fields by surrounding
  915    the comment text with parentheses. Comments are only allowed in
  916    fields containing "comment" as part of their field value definition.
  917    In all other fields, parentheses are considered part of the field
  918    value.
  919 
  920        comment        = "(" *( ctext | quoted-pair | comment ) ")"
  921        ctext          = <any TEXT excluding "(" and ")">
  922 
  923    A string of text is parsed as a single word if it is quoted using
  924    double-quote marks.
  925 
  926        quoted-string  = ( <"> *(qdtext | quoted-pair ) <"> )
  927        qdtext         = <any TEXT except <">>
  928 
  929    The backslash character ("\") MAY be used as a single-character
  930    quoting mechanism only within quoted-string and comment constructs.
  931 
  932        quoted-pair    = "\" CHAR
  933 
  934 3 Protocol Parameters
  935 
  936 3.1 HTTP Version
  937 
  938    HTTP uses a "<major>.<minor>" numbering scheme to indicate versions
  939    of the protocol. The protocol versioning policy is intended to allow
  940    the sender to indicate the format of a message and its capacity for
  941    understanding further HTTP communication, rather than the features
  942    obtained via that communication. No change is made to the version
  943    number for the addition of message components which do not affect
  944    communication behavior or which only add to extensible field values.
  945    The <minor> number is incremented when the changes made to the
  946    protocol add features which do not change the general message parsing
  947    algorithm, but which may add to the message semantics and imply
  948    additional capabilities of the sender. The <major> number is
  949    incremented when the format of a message within the protocol is
  950    changed. See RFC 2145 [36] for a fuller explanation.
  951 
  952 
  953 
  954 Fielding, et al.            Standards Track                    [Page 17]
  955 
  956 RFC 2616                        HTTP/1.1                       June 1999
  957 
  958 
  959    The version of an HTTP message is indicated by an HTTP-Version field
  960    in the first line of the message.
  961 
  962        HTTP-Version   = "HTTP" "/" 1*DIGIT "." 1*DIGIT
  963 
  964    Note that the major and minor numbers MUST be treated as separate
  965    integers and that each MAY be incremented higher than a single digit.
  966    Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is
  967    lower than HTTP/12.3. Leading zeros MUST be ignored by recipients and
  968    MUST NOT be sent.
  969 
  970    An application that sends a request or response message that includes
  971    HTTP-Version of "HTTP/1.1" MUST be at least conditionally compliant
  972    with this specification. Applications that are at least conditionally
  973    compliant with this specification SHOULD use an HTTP-Version of
  974    "HTTP/1.1" in their messages, and MUST do so for any message that is
  975    not compatible with HTTP/1.0. For more details on when to send
  976    specific HTTP-Version values, see RFC 2145 [36].
  977 
  978    The HTTP version of an application is the highest HTTP version for
  979    which the application is at least conditionally compliant.
  980 
  981    Proxy and gateway applications need to be careful when forwarding
  982    messages in protocol versions different from that of the application.
  983    Since the protocol version indicates the protocol capability of the
  984    sender, a proxy/gateway MUST NOT send a message with a version
  985    indicator which is greater than its actual version. If a higher
  986    version request is received, the proxy/gateway MUST either downgrade
  987    the request version, or respond with an error, or switch to tunnel
  988    behavior.
  989 
  990    Due to interoperability problems with HTTP/1.0 proxies discovered
  991    since the publication of RFC 2068[33], caching proxies MUST, gateways
  992    MAY, and tunnels MUST NOT upgrade the request to the highest version
  993    they support. The proxy/gateway's response to that request MUST be in
  994    the same major version as the request.
  995 
  996       Note: Converting between versions of HTTP may involve modification
  997       of header fields required or forbidden by the versions involved.
  998 
  999 3.2 Uniform Resource Identifiers
 1000 
 1001    URIs have been known by many names: WWW addresses, Universal Document
 1002    Identifiers, Universal Resource Identifiers [3], and finally the
 1003    combination of Uniform Resource Locators (URL) [4] and Names (URN)
 1004    [20]. As far as HTTP is concerned, Uniform Resource Identifiers are
 1005    simply formatted strings which identify--via name, location, or any
 1006    other characteristic--a resource.
 1007 
 1008 
 1009 
 1010 Fielding, et al.            Standards Track                    [Page 18]
 1011 
 1012 RFC 2616                        HTTP/1.1                       June 1999
 1013 
 1014 
 1015 3.2.1 General Syntax
 1016 
 1017    URIs in HTTP can be represented in absolute form or relative to some
 1018    known base URI [11], depending upon the context of their use. The two
 1019    forms are differentiated by the fact that absolute URIs always begin
 1020    with a scheme name followed by a colon. For definitive information on
 1021    URL syntax and semantics, see "Uniform Resource Identifiers (URI):
 1022    Generic Syntax and Semantics," RFC 2396 [42] (which replaces RFCs
 1023    1738 [4] and RFC 1808 [11]). This specification adopts the
 1024    definitions of "URI-reference", "absoluteURI", "relativeURI", "port",
 1025    "host","abs_path", "rel_path", and "authority" from that
 1026    specification.
 1027 
 1028    The HTTP protocol does not place any a priori limit on the length of
 1029    a URI. Servers MUST be able to handle the URI of any resource they
 1030    serve, and SHOULD be able to handle URIs of unbounded length if they
 1031    provide GET-based forms that could generate such URIs. A server
 1032    SHOULD return 414 (Request-URI Too Long) status if a URI is longer
 1033    than the server can handle (see section 10.4.15).
 1034 
 1035       Note: Servers ought to be cautious about depending on URI lengths
 1036       above 255 bytes, because some older client or proxy
 1037       implementations might not properly support these lengths.
 1038 
 1039 3.2.2 http URL
 1040 
 1041    The "http" scheme is used to locate network resources via the HTTP
 1042    protocol. This section defines the scheme-specific syntax and
 1043    semantics for http URLs.
 1044 
 1045    http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]
 1046 
 1047    If the port is empty or not given, port 80 is assumed. The semantics
 1048    are that the identified resource is located at the server listening
 1049    for TCP connections on that port of that host, and the Request-URI
 1050    for the resource is abs_path (section 5.1.2). The use of IP addresses
 1051    in URLs SHOULD be avoided whenever possible (see RFC 1900 [24]). If
 1052    the abs_path is not present in the URL, it MUST be given as "/" when
 1053    used as a Request-URI for a resource (section 5.1.2). If a proxy
 1054    receives a host name which is not a fully qualified domain name, it
 1055    MAY add its domain to the host name it received. If a proxy receives
 1056    a fully qualified domain name, the proxy MUST NOT change the host
 1057    name.
 1058 
 1059 
 1060 
 1061 
 1062 
 1063 
 1064 
 1065 
 1066 Fielding, et al.            Standards Track                    [Page 19]
 1067 
 1068 RFC 2616                        HTTP/1.1                       June 1999
 1069 
 1070 
 1071 3.2.3 URI Comparison
 1072 
 1073    When comparing two URIs to decide if they match or not, a client
 1074    SHOULD use a case-sensitive octet-by-octet comparison of the entire
 1075    URIs, with these exceptions:
 1076 
 1077       - A port that is empty or not given is equivalent to the default
 1078         port for that URI-reference;
 1079 
 1080         - Comparisons of host names MUST be case-insensitive;
 1081 
 1082         - Comparisons of scheme names MUST be case-insensitive;
 1083 
 1084         - An empty abs_path is equivalent to an abs_path of "/".
 1085 
 1086    Characters other than those in the "reserved" and "unsafe" sets (see
 1087    RFC 2396 [42]) are equivalent to their ""%" HEX HEX" encoding.
 1088 
 1089    For example, the following three URIs are equivalent:
 1090 
 1091       http://abc.com:80/~smith/home.html
 1092       http://ABC.com/%7Esmith/home.html
 1093       http://ABC.com:/%7esmith/home.html
 1094 
 1095 3.3 Date/Time Formats
 1096 
 1097 3.3.1 Full Date
 1098 
 1099    HTTP applications have historically allowed three different formats
 1100    for the representation of date/time stamps:
 1101 
 1102       Sun, 06 Nov 1994 08:49:37 GMT  ; RFC 822, updated by RFC 1123
 1103       Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036
 1104       Sun Nov  6 08:49:37 1994       ; ANSI C's asctime() format
 1105 
 1106    The first format is preferred as an Internet standard and represents
 1107    a fixed-length subset of that defined by RFC 1123 [8] (an update to
 1108    RFC 822 [9]). The second format is in common use, but is based on the
 1109    obsolete RFC 850 [12] date format and lacks a four-digit year.
 1110    HTTP/1.1 clients and servers that parse the date value MUST accept
 1111    all three formats (for compatibility with HTTP/1.0), though they MUST
 1112    only generate the RFC 1123 format for representing HTTP-date values
 1113    in header fields. See section 19.3 for further information.
 1114 
 1115       Note: Recipients of date values are encouraged to be robust in
 1116       accepting date values that may have been sent by non-HTTP
 1117       applications, as is sometimes the case when retrieving or posting
 1118       messages via proxies/gateways to SMTP or NNTP.
 1119 
 1120 
 1121 
 1122 Fielding, et al.            Standards Track                    [Page 20]
 1123 
 1124 RFC 2616                        HTTP/1.1                       June 1999
 1125 
 1126 
 1127    All HTTP date/time stamps MUST be represented in Greenwich Mean Time
 1128    (GMT), without exception. For the purposes of HTTP, GMT is exactly
 1129    equal to UTC (Coordinated Universal Time). This is indicated in the
 1130    first two formats by the inclusion of "GMT" as the three-letter
 1131    abbreviation for time zone, and MUST be assumed when reading the
 1132    asctime format. HTTP-date is case sensitive and MUST NOT include
 1133    additional LWS beyond that specifically included as SP in the
 1134    grammar.
 1135 
 1136        HTTP-date    = rfc1123-date | rfc850-date | asctime-date
 1137        rfc1123-date = wkday "," SP date1 SP time SP "GMT"
 1138        rfc850-date  = weekday "," SP date2 SP time SP "GMT"
 1139        asctime-date = wkday SP date3 SP time SP 4DIGIT
 1140        date1        = 2DIGIT SP month SP 4DIGIT
 1141                       ; day month year (e.g., 02 Jun 1982)
 1142        date2        = 2DIGIT "-" month "-" 2DIGIT
 1143                       ; day-month-year (e.g., 02-Jun-82)
 1144        date3        = month SP ( 2DIGIT | ( SP 1DIGIT ))
 1145                       ; month day (e.g., Jun  2)
 1146        time         = 2DIGIT ":" 2DIGIT ":" 2DIGIT
 1147                       ; 00:00:00 - 23:59:59
 1148        wkday        = "Mon" | "Tue" | "Wed"
 1149                     | "Thu" | "Fri" | "Sat" | "Sun"
 1150        weekday      = "Monday" | "Tuesday" | "Wednesday"
 1151                     | "Thursday" | "Friday" | "Saturday" | "Sunday"
 1152        month        = "Jan" | "Feb" | "Mar" | "Apr"
 1153                     | "May" | "Jun" | "Jul" | "Aug"
 1154                     | "Sep" | "Oct" | "Nov" | "Dec"
 1155 
 1156       Note: HTTP requirements for the date/time stamp format apply only
 1157       to their usage within the protocol stream. Clients and servers are
 1158       not required to use these formats for user presentation, request
 1159       logging, etc.
 1160 
 1161 3.3.2 Delta Seconds
 1162 
 1163    Some HTTP header fields allow a time value to be specified as an
 1164    integer number of seconds, represented in decimal, after the time
 1165    that the message was received.
 1166 
 1167        delta-seconds  = 1*DIGIT
 1168 
 1169 3.4 Character Sets
 1170 
 1171    HTTP uses the same definition of the term "character set" as that
 1172    described for MIME:
 1173 
 1174 
 1175 
 1176 
 1177 
 1178 Fielding, et al.            Standards Track                    [Page 21]
 1179 
 1180 RFC 2616                        HTTP/1.1                       June 1999
 1181 
 1182 
 1183    The term "character set" is used in this document to refer to a
 1184    method used with one or more tables to convert a sequence of octets
 1185    into a sequence of characters. Note that unconditional conversion in
 1186    the other direction is not required, in that not all characters may
 1187    be available in a given character set and a character set may provide
 1188    more than one sequence of octets to represent a particular character.
 1189    This definition is intended to allow various kinds of character
 1190    encoding, from simple single-table mappings such as US-ASCII to
 1191    complex table switching methods such as those that use ISO-2022's
 1192    techniques. However, the definition associated with a MIME character
 1193    set name MUST fully specify the mapping to be performed from octets
 1194    to characters. In particular, use of external profiling information
 1195    to determine the exact mapping is not permitted.
 1196 
 1197       Note: This use of the term "character set" is more commonly
 1198       referred to as a "character encoding." However, since HTTP and
 1199       MIME share the same registry, it is important that the terminology
 1200       also be shared.
 1201 
 1202    HTTP character sets are identified by case-insensitive tokens. The
 1203    complete set of tokens is defined by the IANA Character Set registry
 1204    [19].
 1205 
 1206        charset = token
 1207 
 1208    Although HTTP allows an arbitrary token to be used as a charset
 1209    value, any token that has a predefined value within the IANA
 1210    Character Set registry [19] MUST represent the character set defined
 1211    by that registry. Applications SHOULD limit their use of character
 1212    sets to those defined by the IANA registry.
 1213 
 1214    Implementors should be aware of IETF character set requirements [38]
 1215    [41].
 1216 
 1217 3.4.1 Missing Charset
 1218 
 1219    Some HTTP/1.0 software has interpreted a Content-Type header without
 1220    charset parameter incorrectly to mean "recipient should guess."
 1221    Senders wishing to defeat this behavior MAY include a charset
 1222    parameter even when the charset is ISO-8859-1 and SHOULD do so when
 1223    it is known that it will not confuse the recipient.
 1224 
 1225    Unfortunately, some older HTTP/1.0 clients did not deal properly with
 1226    an explicit charset parameter. HTTP/1.1 recipients MUST respect the
 1227    charset label provided by the sender; and those user agents that have
 1228    a provision to "guess" a charset MUST use the charset from the
 1229 
 1230 
 1231 
 1232 
 1233 
 1234 Fielding, et al.            Standards Track                    [Page 22]
 1235 
 1236 RFC 2616                        HTTP/1.1                       June 1999
 1237 
 1238 
 1239    content-type field if they support that charset, rather than the
 1240    recipient's preference, when initially displaying a document. See
 1241    section 3.7.1.
 1242 
 1243 3.5 Content Codings
 1244 
 1245    Content coding values indicate an encoding transformation that has
 1246    been or can be applied to an entity. Content codings are primarily
 1247    used to allow a document to be compressed or otherwise usefully
 1248    transformed without losing the identity of its underlying media type
 1249    and without loss of information. Frequently, the entity is stored in
 1250    coded form, transmitted directly, and only decoded by the recipient.
 1251 
 1252        content-coding   = token
 1253 
 1254    All content-coding values are case-insensitive. HTTP/1.1 uses
 1255    content-coding values in the Accept-Encoding (section 14.3) and
 1256    Content-Encoding (section 14.11) header fields. Although the value
 1257    describes the content-coding, what is more important is that it
 1258    indicates what decoding mechanism will be required to remove the
 1259    encoding.
 1260 
 1261    The Internet Assigned Numbers Authority (IANA) acts as a registry for
 1262    content-coding value tokens. Initially, the registry contains the
 1263    following tokens:
 1264 
 1265    gzip An encoding format produced by the file compression program
 1266         "gzip" (GNU zip) as described in RFC 1952 [25]. This format is a
 1267         Lempel-Ziv coding (LZ77) with a 32 bit CRC.
 1268 
 1269    compress
 1270         The encoding format produced by the common UNIX file compression
 1271         program "compress". This format is an adaptive Lempel-Ziv-Welch
 1272         coding (LZW).
 1273 
 1274         Use of program names for the identification of encoding formats
 1275         is not desirable and is discouraged for future encodings. Their
 1276         use here is representative of historical practice, not good
 1277         design. For compatibility with previous implementations of HTTP,
 1278         applications SHOULD consider "x-gzip" and "x-compress" to be
 1279         equivalent to "gzip" and "compress" respectively.
 1280 
 1281    deflate
 1282         The "zlib" format defined in RFC 1950 [31] in combination with
 1283         the "deflate" compression mechanism described in RFC 1951 [29].
 1284 
 1285 
 1286 
 1287 
 1288 
 1289 
 1290 Fielding, et al.            Standards Track                    [Page 23]
 1291 
 1292 RFC 2616                        HTTP/1.1                       June 1999
 1293 
 1294 
 1295    identity
 1296         The default (identity) encoding; the use of no transformation
 1297         whatsoever. This content-coding is used only in the Accept-
 1298         Encoding header, and SHOULD NOT be used in the Content-Encoding
 1299         header.
 1300 
 1301    New content-coding value tokens SHOULD be registered; to allow
 1302    interoperability between clients and servers, specifications of the
 1303    content coding algorithms needed to implement a new value SHOULD be
 1304    publicly available and adequate for independent implementation, and
 1305    conform to the purpose of content coding defined in this section.
 1306 
 1307 3.6 Transfer Codings
 1308 
 1309    Transfer-coding values are used to indicate an encoding
 1310    transformation that has been, can be, or may need to be applied to an
 1311    entity-body in order to ensure "safe transport" through the network.
 1312    This differs from a content coding in that the transfer-coding is a
 1313    property of the message, not of the original entity.
 1314 
 1315        transfer-coding         = "chunked" | transfer-extension
 1316        transfer-extension      = token *( ";" parameter )
 1317 
 1318    Parameters are in  the form of attribute/value pairs.
 1319 
 1320        parameter               = attribute "=" value
 1321        attribute               = token
 1322        value                   = token | quoted-string
 1323 
 1324    All transfer-coding values are case-insensitive. HTTP/1.1 uses
 1325    transfer-coding values in the TE header field (section 14.39) and in
 1326    the Transfer-Encoding header field (section 14.41).
 1327 
 1328    Whenever a transfer-coding is applied to a message-body, the set of
 1329    transfer-codings MUST include "chunked", unless the message is
 1330    terminated by closing the connection. When the "chunked" transfer-
 1331    coding is used, it MUST be the last transfer-coding applied to the
 1332    message-body. The "chunked" transfer-coding MUST NOT be applied more
 1333    than once to a message-body. These rules allow the recipient to
 1334    determine the transfer-length of the message (section 4.4).
 1335 
 1336    Transfer-codings are analogous to the Content-Transfer-Encoding
 1337    values of MIME [7], which were designed to enable safe transport of
 1338    binary data over a 7-bit transport service. However, safe transport
 1339    has a different focus for an 8bit-clean transfer protocol. In HTTP,
 1340    the only unsafe characteristic of message-bodies is the difficulty in
 1341    determining the exact body length (section 7.2.2), or the desire to
 1342    encrypt data over a shared transport.
 1343 
 1344 
 1345 
 1346 Fielding, et al.            Standards Track                    [Page 24]
 1347 
 1348 RFC 2616                        HTTP/1.1                       June 1999
 1349 
 1350 
 1351    The Internet Assigned Numbers Authority (IANA) acts as a registry for
 1352    transfer-coding value tokens. Initially, the registry contains the
 1353    following tokens: "chunked" (section 3.6.1), "identity" (section
 1354    3.6.2), "gzip" (section 3.5), "compress" (section 3.5), and "deflate"
 1355    (section 3.5).
 1356 
 1357    New transfer-coding value tokens SHOULD be registered in the same way
 1358    as new content-coding value tokens (section 3.5).
 1359 
 1360    A server which receives an entity-body with a transfer-coding it does
 1361    not understand SHOULD return 501 (Unimplemented), and close the
 1362    connection. A server MUST NOT send transfer-codings to an HTTP/1.0
 1363    client.
 1364 
 1365 3.6.1 Chunked Transfer Coding
 1366 
 1367    The chunked encoding modifies the body of a message in order to
 1368    transfer it as a series of chunks, each with its own size indicator,
 1369    followed by an OPTIONAL trailer containing entity-header fields. This
 1370    allows dynamically produced content to be transferred along with the
 1371    information necessary for the recipient to verify that it has
 1372    received the full message.
 1373 
 1374        Chunked-Body   = *chunk
 1375                         last-chunk
 1376                         trailer
 1377                         CRLF
 1378 
 1379        chunk          = chunk-size [ chunk-extension ] CRLF
 1380                         chunk-data CRLF
 1381        chunk-size     = 1*HEX
 1382        last-chunk     = 1*("0") [ chunk-extension ] CRLF
 1383 
 1384        chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
 1385        chunk-ext-name = token
 1386        chunk-ext-val  = token | quoted-string
 1387        chunk-data     = chunk-size(OCTET)
 1388        trailer        = *(entity-header CRLF)
 1389 
 1390    The chunk-size field is a string of hex digits indicating the size of
 1391    the chunk. The chunked encoding is ended by any chunk whose size is
 1392    zero, followed by the trailer, which is terminated by an empty line.
 1393 
 1394    The trailer allows the sender to include additional HTTP header
 1395    fields at the end of the message. The Trailer header field can be
 1396    used to indicate which header fields are included in a trailer (see
 1397    section 14.40).
 1398 
 1399 
 1400 
 1401 
 1402 Fielding, et al.            Standards Track                    [Page 25]
 1403 
 1404 RFC 2616                        HTTP/1.1                       June 1999
 1405 
 1406 
 1407    A server using chunked transfer-coding in a response MUST NOT use the
 1408    trailer for any header fields unless at least one of the following is
 1409    true:
 1410 
 1411    a)the request included a TE header field that indicates "trailers" is
 1412      acceptable in the transfer-coding of the  response, as described in
 1413      section 14.39; or,
 1414 
 1415    b)the server is the origin server for the response, the trailer
 1416      fields consist entirely of optional metadata, and the recipient
 1417      could use the message (in a manner acceptable to the origin server)
 1418      without receiving this metadata.  In other words, the origin server
 1419      is willing to accept the possibility that the trailer fields might
 1420      be silently discarded along the path to the client.
 1421 
 1422    This requirement prevents an interoperability failure when the
 1423    message is being received by an HTTP/1.1 (or later) proxy and
 1424    forwarded to an HTTP/1.0 recipient. It avoids a situation where
 1425    compliance with the protocol would have necessitated a possibly
 1426    infinite buffer on the proxy.
 1427 
 1428    An example process for decoding a Chunked-Body is presented in
 1429    appendix 19.4.6.
 1430 
 1431    All HTTP/1.1 applications MUST be able to receive and decode the
 1432    "chunked" transfer-coding, and MUST ignore chunk-extension extensions
 1433    they do not understand.
 1434 
 1435 3.7 Media Types
 1436 
 1437    HTTP uses Internet Media Types [17] in the Content-Type (section
 1438    14.17) and Accept (section 14.1) header fields in order to provide
 1439    open and extensible data typing and type negotiation.
 1440 
 1441        media-type     = type "/" subtype *( ";" parameter )
 1442        type           = token
 1443        subtype        = token
 1444 
 1445    Parameters MAY follow the type/subtype in the form of attribute/value
 1446    pairs (as defined in section 3.6).
 1447 
 1448    The type, subtype, and parameter attribute names are case-
 1449    insensitive. Parameter values might or might not be case-sensitive,
 1450    depending on the semantics of the parameter name. Linear white space
 1451    (LWS) MUST NOT be used between the type and subtype, nor between an
 1452    attribute and its value. The presence or absence of a parameter might
 1453    be significant to the processing of a media-type, depending on its
 1454    definition within the media type registry.
 1455 
 1456 
 1457 
 1458 Fielding, et al.            Standards Track                    [Page 26]
 1459 
 1460 RFC 2616                        HTTP/1.1                       June 1999
 1461 
 1462 
 1463    Note that some older HTTP applications do not recognize media type
 1464    parameters. When sending data to older HTTP applications,
 1465    implementations SHOULD only use media type parameters when they are
 1466    required by that type/subtype definition.
 1467 
 1468    Media-type values are registered with the Internet Assigned Number
 1469    Authority (IANA [19]). The media type registration process is
 1470    outlined in RFC 1590 [17]. Use of non-registered media types is
 1471    discouraged.
 1472 
 1473 3.7.1 Canonicalization and Text Defaults
 1474 
 1475    Internet media types are registered with a canonical form. An
 1476    entity-body transferred via HTTP messages MUST be represented in the
 1477    appropriate canonical form prior to its transmission except for
 1478    "text" types, as defined in the next paragraph.
 1479 
 1480    When in canonical form, media subtypes of the "text" type use CRLF as
 1481    the text line break. HTTP relaxes this requirement and allows the
 1482    transport of text media with plain CR or LF alone representing a line
 1483    break when it is done consistently for an entire entity-body. HTTP
 1484    applications MUST accept CRLF, bare CR, and bare LF as being
 1485    representative of a line break in text media received via HTTP. In
 1486    addition, if the text is represented in a character set that does not
 1487    use octets 13 and 10 for CR and LF respectively, as is the case for
 1488    some multi-byte character sets, HTTP allows the use of whatever octet
 1489    sequences are defined by that character set to represent the
 1490    equivalent of CR and LF for line breaks. This flexibility regarding
 1491    line breaks applies only to text media in the entity-body; a bare CR
 1492    or LF MUST NOT be substituted for CRLF within any of the HTTP control
 1493    structures (such as header fields and multipart boundaries).
 1494 
 1495    If an entity-body is encoded with a content-coding, the underlying
 1496    data MUST be in a form defined above prior to being encoded.
 1497 
 1498    The "charset" parameter is used with some media types to define the
 1499    character set (section 3.4) of the data. When no explicit charset
 1500    parameter is provided by the sender, media subtypes of the "text"
 1501    type are defined to have a default charset value of "ISO-8859-1" when
 1502    received via HTTP. Data in character sets other than "ISO-8859-1" or
 1503    its subsets MUST be labeled with an appropriate charset value. See
 1504    section 3.4.1 for compatibility problems.
 1505 
 1506 3.7.2 Multipart Types
 1507 
 1508    MIME provides for a number of "multipart" types -- encapsulations of
 1509    one or more entities within a single message-body. All multipart
 1510    types share a common syntax, as defined in section 5.1.1 of RFC 2046
 1511 
 1512 
 1513 
 1514 Fielding, et al.            Standards Track                    [Page 27]
 1515 
 1516 RFC 2616                        HTTP/1.1                       June 1999
 1517 
 1518 
 1519    [40], and MUST include a boundary parameter as part of the media type
 1520    value. The message body is itself a protocol element and MUST
 1521    therefore use only CRLF to represent line breaks between body-parts.
 1522    Unlike in RFC 2046, the epilogue of any multipart message MUST be
 1523    empty; HTTP applications MUST NOT transmit the epilogue (even if the
 1524    original multipart contains an epilogue). These restrictions exist in
 1525    order to preserve the self-delimiting nature of a multipart message-
 1526    body, wherein the "end" of the message-body is indicated by the
 1527    ending multipart boundary.
 1528 
 1529    In general, HTTP treats a multipart message-body no differently than
 1530    any other media type: strictly as payload. The one exception is the
 1531    "multipart/byteranges" type (appendix 19.2) when it appears in a 206
 1532    (Partial Content) response, which will be interpreted by some HTTP
 1533    caching mechanisms as described in sections 13.5.4 and 14.16. In all
 1534    other cases, an HTTP user agent SHOULD follow the same or similar
 1535    behavior as a MIME user agent would upon receipt of a multipart type.
 1536    The MIME header fields within each body-part of a multipart message-
 1537    body do not have any significance to HTTP beyond that defined by
 1538    their MIME semantics.
 1539 
 1540    In general, an HTTP user agent SHOULD follow the same or similar
 1541    behavior as a MIME user agent would upon receipt of a multipart type.
 1542    If an application receives an unrecognized multipart subtype, the
 1543    application MUST treat it as being equivalent to "multipart/mixed".
 1544 
 1545       Note: The "multipart/form-data" type has been specifically defined
 1546       for carrying form data suitable for processing via the POST
 1547       request method, as described in RFC 1867 [15].
 1548 
 1549 3.8 Product Tokens
 1550 
 1551    Product tokens are used to allow communicating applications to
 1552    identify themselves by software name and version. Most fields using
 1553    product tokens also allow sub-products which form a significant part
 1554    of the application to be listed, separated by white space. By
 1555    convention, the products are listed in order of their significance
 1556    for identifying the application.
 1557 
 1558        product         = token ["/" product-version]
 1559        product-version = token
 1560 
 1561    Examples:
 1562 
 1563        User-Agent: CERN-LineMode/2.15 libwww/2.17b3
 1564        Server: Apache/0.8.4
 1565 
 1566 
 1567 
 1568 
 1569 
 1570 Fielding, et al.            Standards Track                    [Page 28]
 1571 
 1572 RFC 2616                        HTTP/1.1                       June 1999
 1573 
 1574 
 1575    Product tokens SHOULD be short and to the point. They MUST NOT be
 1576    used for advertising or other non-essential information. Although any
 1577    token character MAY appear in a product-version, this token SHOULD
 1578    only be used for a version identifier (i.e., successive versions of
 1579    the same product SHOULD only differ in the product-version portion of
 1580    the product value).
 1581 
 1582 3.9 Quality Values
 1583 
 1584    HTTP content negotiation (section 12) uses short "floating point"
 1585    numbers to indicate the relative importance ("weight") of various
 1586    negotiable parameters.  A weight is normalized to a real number in
 1587    the range 0 through 1, where 0 is the minimum and 1 the maximum
 1588    value. If a parameter has a quality value of 0, then content with
 1589    this parameter is `not acceptable' for the client. HTTP/1.1
 1590    applications MUST NOT generate more than three digits after the
 1591    decimal point. User configuration of these values SHOULD also be
 1592    limited in this fashion.
 1593 
 1594        qvalue         = ( "0" [ "." 0*3DIGIT ] )
 1595                       | ( "1" [ "." 0*3("0") ] )
 1596 
 1597    "Quality values" is a misnomer, since these values merely represent
 1598    relative degradation in desired quality.
 1599 
 1600 3.10 Language Tags
 1601 
 1602    A language tag identifies a natural language spoken, written, or
 1603    otherwise conveyed by human beings for communication of information
 1604    to other human beings. Computer languages are explicitly excluded.
 1605    HTTP uses language tags within the Accept-Language and Content-
 1606    Language fields.
 1607 
 1608    The syntax and registry of HTTP language tags is the same as that
 1609    defined by RFC 1766 [1]. In summary, a language tag is composed of 1
 1610    or more parts: A primary language tag and a possibly empty series of
 1611    subtags:
 1612 
 1613         language-tag  = primary-tag *( "-" subtag )
 1614         primary-tag   = 1*8ALPHA
 1615         subtag        = 1*8ALPHA
 1616 
 1617    White space is not allowed within the tag and all tags are case-
 1618    insensitive. The name space of language tags is administered by the
 1619    IANA. Example tags include:
 1620 
 1621        en, en-US, en-cockney, i-cherokee, x-pig-latin
 1622 
 1623 
 1624 
 1625 
 1626 Fielding, et al.            Standards Track                    [Page 29]
 1627 
 1628 RFC 2616                        HTTP/1.1                       June 1999
 1629 
 1630 
 1631    where any two-letter primary-tag is an ISO-639 language abbreviation
 1632    and any two-letter initial subtag is an ISO-3166 country code. (The
 1633    last three tags above are not registered tags; all but the last are
 1634    examples of tags which could be registered in future.)
 1635 
 1636 3.11 Entity Tags
 1637 
 1638    Entity tags are used for comparing two or more entities from the same
 1639    requested resource. HTTP/1.1 uses entity tags in the ETag (section
 1640    14.19), If-Match (section 14.24), If-None-Match (section 14.26), and
 1641    If-Range (section 14.27) header fields. The definition of how they
 1642    are used and compared as cache validators is in section 13.3.3. An
 1643    entity tag consists of an opaque quoted string, possibly prefixed by
 1644    a weakness indicator.
 1645 
 1646       entity-tag = [ weak ] opaque-tag
 1647       weak       = "W/"
 1648       opaque-tag = quoted-string
 1649 
 1650    A "strong entity tag" MAY be shared by two entities of a resource
 1651    only if they are equivalent by octet equality.
 1652 
 1653    A "weak entity tag," indicated by the "W/" prefix, MAY be shared by
 1654    two entities of a resource only if the entities are equivalent and
 1655    could be substituted for each other with no significant change in
 1656    semantics. A weak entity tag can only be used for weak comparison.
 1657 
 1658    An entity tag MUST be unique across all versions of all entities
 1659    associated with a particular resource. A given entity tag value MAY
 1660    be used for entities obtained by requests on different URIs. The use
 1661    of the same entity tag value in conjunction with entities obtained by
 1662    requests on different URIs does not imply the equivalence of those
 1663    entities.
 1664 
 1665 3.12 Range Units
 1666 
 1667    HTTP/1.1 allows a client to request that only part (a range of) the
 1668    response entity be included within the response. HTTP/1.1 uses range
 1669    units in the Range (section 14.35) and Content-Range (section 14.16)
 1670    header fields. An entity can be broken down into subranges according
 1671    to various structural units.
 1672 
 1673       range-unit       = bytes-unit | other-range-unit
 1674       bytes-unit       = "bytes"
 1675       other-range-unit = token
 1676 
 1677    The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1
 1678    implementations MAY ignore ranges specified using other units.
 1679 
 1680 
 1681 
 1682 Fielding, et al.            Standards Track                    [Page 30]
 1683 
 1684 RFC 2616                        HTTP/1.1                       June 1999
 1685 
 1686 
 1687    HTTP/1.1 has been designed to allow implementations of applications
 1688    that do not depend on knowledge of ranges.
 1689 
 1690 4 HTTP Message
 1691 
 1692 4.1 Message Types
 1693 
 1694    HTTP messages consist of requests from client to server and responses
 1695    from server to client.
 1696 
 1697        HTTP-message   = Request | Response     ; HTTP/1.1 messages
 1698 
 1699    Request (section 5) and Response (section 6) messages use the generic
 1700    message format of RFC 822 [9] for transferring entities (the payload
 1701    of the message). Both types of message consist of a start-line, zero
 1702    or more header fields (also known as "headers"), an empty line (i.e.,
 1703    a line with nothing preceding the CRLF) indicating the end of the
 1704    header fields, and possibly a message-body.
 1705 
 1706         generic-message = start-line
 1707                           *(message-header CRLF)
 1708                           CRLF
 1709                           [ message-body ]
 1710         start-line      = Request-Line | Status-Line
 1711 
 1712    In the interest of robustness, servers SHOULD ignore any empty
 1713    line(s) received where a Request-Line is expected. In other words, if
 1714    the server is reading the protocol stream at the beginning of a
 1715    message and receives a CRLF first, it should ignore the CRLF.
 1716 
 1717    Certain buggy HTTP/1.0 client implementations generate extra CRLF's
 1718    after a POST request. To restate what is explicitly forbidden by the
 1719    BNF, an HTTP/1.1 client MUST NOT preface or follow a request with an
 1720    extra CRLF.
 1721 
 1722 4.2 Message Headers
 1723 
 1724    HTTP header fields, which include general-header (section 4.5),
 1725    request-header (section 5.3), response-header (section 6.2), and
 1726    entity-header (section 7.1) fields, follow the same generic format as
 1727    that given in Section 3.1 of RFC 822 [9]. Each header field consists
 1728    of a name followed by a colon (":") and the field value. Field names
 1729    are case-insensitive. The field value MAY be preceded by any amount
 1730    of LWS, though a single SP is preferred. Header fields can be
 1731    extended over multiple lines by preceding each extra line with at
 1732    least one SP or HT. Applications ought to follow "common form", where
 1733    one is known or indicated, when generating HTTP constructs, since
 1734    there might exist some implementations that fail to accept anything
 1735 
 1736 
 1737 
 1738 Fielding, et al.            Standards Track                    [Page 31]
 1739 
 1740 RFC 2616                        HTTP/1.1                       June 1999
 1741 
 1742 
 1743    beyond the common forms.
 1744 
 1745        message-header = field-name ":" [ field-value ]
 1746        field-name     = token
 1747        field-value    = *( field-content | LWS )
 1748        field-content  = <the OCTETs making up the field-value
 1749                         and consisting of either *TEXT or combinations
 1750                         of token, separators, and quoted-string>
 1751 
 1752    The field-content does not include any leading or trailing LWS:
 1753    linear white space occurring before the first non-whitespace
 1754    character of the field-value or after the last non-whitespace
 1755    character of the field-value. Such leading or trailing LWS MAY be
 1756    removed without changing the semantics of the field value. Any LWS
 1757    that occurs between field-content MAY be replaced with a single SP
 1758    before interpreting the field value or forwarding the message
 1759    downstream.
 1760 
 1761    The order in which header fields with differing field names are
 1762    received is not significant. However, it is "good practice" to send
 1763    general-header fields first, followed by request-header or response-
 1764    header fields, and ending with the entity-header fields.
 1765 
 1766    Multiple message-header fields with the same field-name MAY be
 1767    present in a message if and only if the entire field-value for that
 1768    header field is defined as a comma-separated list [i.e., #(values)].
 1769    It MUST be possible to combine the multiple header fields into one
 1770    "field-name: field-value" pair, without changing the semantics of the
 1771    message, by appending each subsequent field-value to the first, each
 1772    separated by a comma. The order in which header fields with the same
 1773    field-name are received is therefore significant to the
 1774    interpretation of the combined field value, and thus a proxy MUST NOT
 1775    change the order of these field values when a message is forwarded.
 1776 
 1777 4.3 Message Body
 1778 
 1779    The message-body (if any) of an HTTP message is used to carry the
 1780    entity-body associated with the request or response. The message-body
 1781    differs from the entity-body only when a transfer-coding has been
 1782    applied, as indicated by the Transfer-Encoding header field (section
 1783    14.41).
 1784 
 1785        message-body = entity-body
 1786                     | <entity-body encoded as per Transfer-Encoding>
 1787 
 1788    Transfer-Encoding MUST be used to indicate any transfer-codings
 1789    applied by an application to ensure safe and proper transfer of the
 1790    message. Transfer-Encoding is a property of the message, not of the
 1791 
 1792 
 1793 
 1794 Fielding, et al.            Standards Track                    [Page 32]
 1795 
 1796 RFC 2616                        HTTP/1.1                       June 1999
 1797 
 1798 
 1799    entity, and thus MAY be added or removed by any application along the
 1800    request/response chain. (However, section 3.6 places restrictions on
 1801    when certain transfer-codings may be used.)
 1802 
 1803    The rules for when a message-body is allowed in a message differ for
 1804    requests and responses.
 1805 
 1806    The presence of a message-body in a request is signaled by the
 1807    inclusion of a Content-Length or Transfer-Encoding header field in
 1808    the request's message-headers. A message-body MUST NOT be included in
 1809    a request if the specification of the request method (section 5.1.1)
 1810    does not allow sending an entity-body in requests. A server SHOULD
 1811    read and forward a message-body on any request; if the request method
 1812    does not include defined semantics for an entity-body, then the
 1813    message-body SHOULD be ignored when handling the request.
 1814 
 1815    For response messages, whether or not a message-body is included with
 1816    a message is dependent on both the request method and the response
 1817    status code (section 6.1.1). All responses to the HEAD request method
 1818    MUST NOT include a message-body, even though the presence of entity-
 1819    header fields might lead one to believe they do. All 1xx
 1820    (informational), 204 (no content), and 304 (not modified) responses
 1821    MUST NOT include a message-body. All other responses do include a
 1822    message-body, although it MAY be of zero length.
 1823 
 1824 4.4 Message Length
 1825 
 1826    The transfer-length of a message is the length of the message-body as
 1827    it appears in the message; that is, after any transfer-codings have
 1828    been applied. When a message-body is included with a message, the
 1829    transfer-length of that body is determined by one of the following
 1830    (in order of precedence):
 1831 
 1832    1.Any response message which "MUST NOT" include a message-body (such
 1833      as the 1xx, 204, and 304 responses and any response to a HEAD
 1834      request) is always terminated by the first empty line after the
 1835      header fields, regardless of the entity-header fields present in
 1836      the message.
 1837 
 1838    2.If a Transfer-Encoding header field (section 14.41) is present and
 1839      has any value other than "identity", then the transfer-length is
 1840      defined by use of the "chunked" transfer-coding (section 3.6),
 1841      unless the message is terminated by closing the connection.
 1842 
 1843    3.If a Content-Length header field (section 14.13) is present, its
 1844      decimal value in OCTETs represents both the entity-length and the
 1845      transfer-length. The Content-Length header field MUST NOT be sent
 1846      if these two lengths are different (i.e., if a Transfer-Encoding
 1847 
 1848 
 1849 
 1850 Fielding, et al.            Standards Track                    [Page 33]
 1851 
 1852 RFC 2616                        HTTP/1.1                       June 1999
 1853 
 1854 
 1855      header field is present). If a message is received with both a
 1856      Transfer-Encoding header field and a Content-Length header field,
 1857      the latter MUST be ignored.
 1858 
 1859    4.If the message uses the media type "multipart/byteranges", and the
 1860      ransfer-length is not otherwise specified, then this self-
 1861      elimiting media type defines the transfer-length. This media type
 1862      UST NOT be used unless the sender knows that the recipient can arse
 1863      it; the presence in a request of a Range header with ultiple byte-
 1864      range specifiers from a 1.1 client implies that the lient can parse
 1865      multipart/byteranges responses.
 1866 
 1867        A range header might be forwarded by a 1.0 proxy that does not
 1868        understand multipart/byteranges; in this case the server MUST
 1869        delimit the message using methods defined in items 1,3 or 5 of
 1870        this section.
 1871 
 1872    5.By the server closing the connection. (Closing the connection
 1873      cannot be used to indicate the end of a request body, since that
 1874      would leave no possibility for the server to send back a response.)
 1875 
 1876    For compatibility with HTTP/1.0 applications, HTTP/1.1 requests
 1877    containing a message-body MUST include a valid Content-Length header
 1878    field unless the server is known to be HTTP/1.1 compliant. If a
 1879    request contains a message-body and a Content-Length is not given,
 1880    the server SHOULD respond with 400 (bad request) if it cannot
 1881    determine the length of the message, or with 411 (length required) if
 1882    it wishes to insist on receiving a valid Content-Length.
 1883 
 1884    All HTTP/1.1 applications that receive entities MUST accept the
 1885    "chunked" transfer-coding (section 3.6), thus allowing this mechanism
 1886    to be used for messages when the message length cannot be determined
 1887    in advance.
 1888 
 1889    Messages MUST NOT include both a Content-Length header field and a
 1890    non-identity transfer-coding. If the message does include a non-
 1891    identity transfer-coding, the Content-Length MUST be ignored.
 1892 
 1893    When a Content-Length is given in a message where a message-body is
 1894    allowed, its field value MUST exactly match the number of OCTETs in
 1895    the message-body. HTTP/1.1 user agents MUST notify the user when an
 1896    invalid length is received and detected.
 1897 
 1898 4.5 General Header Fields
 1899 
 1900    There are a few header fields which have general applicability for
 1901    both request and response messages, but which do not apply to the
 1902    entity being transferred. These header fields apply only to the
 1903 
 1904 
 1905 
 1906 Fielding, et al.            Standards Track                    [Page 34]
 1907 
 1908 RFC 2616                        HTTP/1.1                       June 1999
 1909 
 1910 
 1911    message being transmitted.
 1912 
 1913        general-header = Cache-Control            ; Section 14.9
 1914                       | Connection               ; Section 14.10
 1915                       | Date                     ; Section 14.18
 1916                       | Pragma                   ; Section 14.32
 1917                       | Trailer                  ; Section 14.40
 1918                       | Transfer-Encoding        ; Section 14.41
 1919                       | Upgrade                  ; Section 14.42
 1920                       | Via                      ; Section 14.45
 1921                       | Warning                  ; Section 14.46
 1922 
 1923    General-header field names can be extended reliably only in
 1924    combination with a change in the protocol version. However, new or
 1925    experimental header fields may be given the semantics of general
 1926    header fields if all parties in the communication recognize them to
 1927    be general-header fields. Unrecognized header fields are treated as
 1928    entity-header fields.
 1929 
 1930 5 Request
 1931 
 1932    A request message from a client to a server includes, within the
 1933    first line of that message, the method to be applied to the resource,
 1934    the identifier of the resource, and the protocol version in use.
 1935 
 1936         Request       = Request-Line              ; Section 5.1
 1937                         *(( general-header        ; Section 4.5
 1938                          | request-header         ; Section 5.3
 1939                          | entity-header ) CRLF)  ; Section 7.1
 1940                         CRLF
 1941                         [ message-body ]          ; Section 4.3
 1942 
 1943 5.1 Request-Line
 1944 
 1945    The Request-Line begins with a method token, followed by the
 1946    Request-URI and the protocol version, and ending with CRLF. The
 1947    elements are separated by SP characters. No CR or LF is allowed
 1948    except in the final CRLF sequence.
 1949 
 1950         Request-Line   = Method SP Request-URI SP HTTP-Version CRLF
 1951 
 1952 
 1953 
 1954 
 1955 
 1956 
 1957 
 1958 
 1959 
 1960 
 1961 
 1962 Fielding, et al.            Standards Track                    [Page 35]
 1963 
 1964 RFC 2616                        HTTP/1.1                       June 1999
 1965 
 1966 
 1967 5.1.1 Method
 1968 
 1969    The Method  token indicates the method to be performed on the
 1970    resource identified by the Request-URI. The method is case-sensitive.
 1971 
 1972        Method         = "OPTIONS"                ; Section 9.2
 1973                       | "GET"                    ; Section 9.3
 1974                       | "HEAD"                   ; Section 9.4
 1975                       | "POST"                   ; Section 9.5
 1976                       | "PUT"                    ; Section 9.6
 1977                       | "DELETE"                 ; Section 9.7
 1978                       | "TRACE"                  ; Section 9.8
 1979                       | "CONNECT"                ; Section 9.9
 1980                       | extension-method
 1981        extension-method = token
 1982 
 1983    The list of methods allowed by a resource can be specified in an
 1984    Allow header field (section 14.7). The return code of the response
 1985    always notifies the client whether a method is currently allowed on a
 1986    resource, since the set of allowed methods can change dynamically. An
 1987    origin server SHOULD return the status code 405 (Method Not Allowed)
 1988    if the method is known by the origin server but not allowed for the
 1989    requested resource, and 501 (Not Implemented) if the method is
 1990    unrecognized or not implemented by the origin server. The methods GET
 1991    and HEAD MUST be supported by all general-purpose servers. All other
 1992    methods are OPTIONAL; however, if the above methods are implemented,
 1993    they MUST be implemented with the same semantics as those specified
 1994    in section 9.
 1995 
 1996 5.1.2 Request-URI
 1997 
 1998    The Request-URI is a Uniform Resource Identifier (section 3.2) and
 1999    identifies the resource upon which to apply the request.
 2000 
 2001        Request-URI    = "*" | absoluteURI | abs_path | authority
 2002 
 2003    The four options for Request-URI are dependent on the nature of the
 2004    request. The asterisk "*" means that the request does not apply to a
 2005    particular resource, but to the server itself, and is only allowed
 2006    when the method used does not necessarily apply to a resource. One
 2007    example would be
 2008 
 2009        OPTIONS * HTTP/1.1
 2010 
 2011    The absoluteURI form is REQUIRED when the request is being made to a
 2012    proxy. The proxy is requested to forward the request or service it
 2013    from a valid cache, and return the response. Note that the proxy MAY
 2014    forward the request on to another proxy or directly to the server
 2015 
 2016 
 2017 
 2018 Fielding, et al.            Standards Track                    [Page 36]
 2019 
 2020 RFC 2616                        HTTP/1.1                       June 1999
 2021 
 2022 
 2023    specified by the absoluteURI. In order to avoid request loops, a
 2024    proxy MUST be able to recognize all of its server names, including
 2025    any aliases, local variations, and the numeric IP address. An example
 2026    Request-Line would be:
 2027 
 2028        GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1
 2029 
 2030    To allow for transition to absoluteURIs in all requests in future
 2031    versions of HTTP, all HTTP/1.1 servers MUST accept the absoluteURI
 2032    form in requests, even though HTTP/1.1 clients will only generate
 2033    them in requests to proxies.
 2034 
 2035    The authority form is only used by the CONNECT method (section 9.9).
 2036 
 2037    The most common form of Request-URI is that used to identify a
 2038    resource on an origin server or gateway. In this case the absolute
 2039    path of the URI MUST be transmitted (see section 3.2.1, abs_path) as
 2040    the Request-URI, and the network location of the URI (authority) MUST
 2041    be transmitted in a Host header field. For example, a client wishing
 2042    to retrieve the resource above directly from the origin server would
 2043    create a TCP connection to port 80 of the host "www.w3.org" and send
 2044    the lines:
 2045 
 2046        GET /pub/WWW/TheProject.html HTTP/1.1
 2047        Host: www.w3.org
 2048 
 2049    followed by the remainder of the Request. Note that the absolute path
 2050    cannot be empty; if none is present in the original URI, it MUST be
 2051    given as "/" (the server root).
 2052 
 2053    The Request-URI is transmitted in the format specified in section
 2054    3.2.1. If the Request-URI is encoded using the "% HEX HEX" encoding
 2055    [42], the origin server MUST decode the Request-URI in order to
 2056    properly interpret the request. Servers SHOULD respond to invalid
 2057    Request-URIs with an appropriate status code.
 2058 
 2059    A transparent proxy MUST NOT rewrite the "abs_path" part of the
 2060    received Request-URI when forwarding it to the next inbound server,
 2061    except as noted above to replace a null abs_path with "/".
 2062 
 2063       Note: The "no rewrite" rule prevents the proxy from changing the
 2064       meaning of the request when the origin server is improperly using
 2065       a non-reserved URI character for a reserved purpose.  Implementors
 2066       should be aware that some pre-HTTP/1.1 proxies have been known to
 2067       rewrite the Request-URI.
 2068 
 2069 
 2070 
 2071 
 2072 
 2073 
 2074 Fielding, et al.            Standards Track                    [Page 37]
 2075 
 2076 RFC 2616                        HTTP/1.1                       June 1999
 2077 
 2078 
 2079 5.2 The Resource Identified by a Request
 2080 
 2081    The exact resource identified by an Internet request is determined by
 2082    examining both the Request-URI and the Host header field.
 2083 
 2084    An origin server that does not allow resources to differ by the
 2085    requested host MAY ignore the Host header field value when
 2086    determining the resource identified by an HTTP/1.1 request. (But see
 2087    section 19.6.1.1 for other requirements on Host support in HTTP/1.1.)
 2088 
 2089    An origin server that does differentiate resources based on the host
 2090    requested (sometimes referred to as virtual hosts or vanity host
 2091    names) MUST use the following rules for determining the requested
 2092    resource on an HTTP/1.1 request:
 2093 
 2094    1. If Request-URI is an absoluteURI, the host is part of the
 2095      Request-URI. Any Host header field value in the request MUST be
 2096      ignored.
 2097 
 2098    2. If the Request-URI is not an absoluteURI, and the request includes
 2099      a Host header field, the host is determined by the Host header
 2100      field value.
 2101 
 2102    3. If the host as determined by rule 1 or 2 is not a valid host on
 2103      the server, the response MUST be a 400 (Bad Request) error message.
 2104 
 2105    Recipients of an HTTP/1.0 request that lacks a Host header field MAY
 2106    attempt to use heuristics (e.g., examination of the URI path for
 2107    something unique to a particular host) in order to determine what
 2108    exact resource is being requested.
 2109 
 2110 5.3 Request Header Fields
 2111 
 2112    The request-header fields allow the client to pass additional
 2113    information about the request, and about the client itself, to the
 2114    server. These fields act as request modifiers, with semantics
 2115    equivalent to the parameters on a programming language method
 2116    invocation.
 2117 
 2118        request-header = Accept                   ; Section 14.1
 2119                       | Accept-Charset           ; Section 14.2
 2120                       | Accept-Encoding          ; Section 14.3
 2121                       | Accept-Language          ; Section 14.4
 2122                       | Authorization            ; Section 14.8
 2123                       | Expect                   ; Section 14.20
 2124                       | From                     ; Section 14.22
 2125                       | Host                     ; Section 14.23
 2126                       | If-Match                 ; Section 14.24
 2127 
 2128 
 2129 
 2130 Fielding, et al.            Standards Track                    [Page 38]
 2131 
 2132 RFC 2616                        HTTP/1.1                       June 1999
 2133 
 2134 
 2135                       | If-Modified-Since        ; Section 14.25
 2136                       | If-None-Match            ; Section 14.26
 2137                       | If-Range                 ; Section 14.27
 2138                       | If-Unmodified-Since      ; Section 14.28
 2139                       | Max-Forwards             ; Section 14.31
 2140                       | Proxy-Authorization      ; Section 14.34
 2141                       | Range                    ; Section 14.35
 2142                       | Referer                  ; Section 14.36
 2143                       | TE                       ; Section 14.39
 2144                       | User-Agent               ; Section 14.43
 2145 
 2146    Request-header field names can be extended reliably only in
 2147    combination with a change in the protocol version. However, new or
 2148    experimental header fields MAY be given the semantics of request-
 2149    header fields if all parties in the communication recognize them to
 2150    be request-header fields. Unrecognized header fields are treated as
 2151    entity-header fields.
 2152 
 2153 6 Response
 2154 
 2155    After receiving and interpreting a request message, a server responds
 2156    with an HTTP response message.
 2157 
 2158        Response      = Status-Line               ; Section 6.1
 2159                        *(( general-header        ; Section 4.5
 2160                         | response-header        ; Section 6.2
 2161                         | entity-header ) CRLF)  ; Section 7.1
 2162                        CRLF
 2163                        [ message-body ]          ; Section 7.2
 2164 
 2165 6.1 Status-Line
 2166 
 2167    The first line of a Response message is the Status-Line, consisting
 2168    of the protocol version followed by a numeric status code and its
 2169    associated textual phrase, with each element separated by SP
 2170    characters. No CR or LF is allowed except in the final CRLF sequence.
 2171 
 2172        Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
 2173 
 2174 6.1.1 Status Code and Reason Phrase
 2175 
 2176    The Status-Code element is a 3-digit integer result code of the
 2177    attempt to understand and satisfy the request. These codes are fully
 2178    defined in section 10. The Reason-Phrase is intended to give a short
 2179    textual description of the Status-Code. The Status-Code is intended
 2180    for use by automata and the Reason-Phrase is intended for the human
 2181    user. The client is not required to examine or display the Reason-
 2182    Phrase.
 2183 
 2184 
 2185 
 2186 Fielding, et al.            Standards Track                    [Page 39]
 2187 
 2188 RFC 2616                        HTTP/1.1                       June 1999
 2189 
 2190 
 2191    The first digit of the Status-Code defines the class of response. The
 2192    last two digits do not have any categorization role. There are 5
 2193    values for the first digit:
 2194 
 2195       - 1xx: Informational - Request received, continuing process
 2196 
 2197       - 2xx: Success - The action was successfully received,
 2198         understood, and accepted
 2199 
 2200       - 3xx: Redirection - Further action must be taken in order to
 2201         complete the request
 2202 
 2203       - 4xx: Client Error - The request contains bad syntax or cannot
 2204         be fulfilled
 2205 
 2206       - 5xx: Server Error - The server failed to fulfill an apparently
 2207         valid request
 2208 
 2209    The individual values of the numeric status codes defined for
 2210    HTTP/1.1, and an example set of corresponding Reason-Phrase's, are
 2211    presented below. The reason phrases listed here are only
 2212    recommendations -- they MAY be replaced by local equivalents without
 2213    affecting the protocol.
 2214 
 2215       Status-Code    =
 2216             "100"  ; Section 10.1.1: Continue
 2217           | "101"  ; Section 10.1.2: Switching Protocols
 2218           | "200"  ; Section 10.2.1: OK
 2219           | "201"  ; Section 10.2.2: Created
 2220           | "202"  ; Section 10.2.3: Accepted
 2221           | "203"  ; Section 10.2.4: Non-Authoritative Information
 2222           | "204"  ; Section 10.2.5: No Content
 2223           | "205"  ; Section 10.2.6: Reset Content
 2224           | "206"  ; Section 10.2.7: Partial Content
 2225           | "300"  ; Section 10.3.1: Multiple Choices
 2226           | "301"  ; Section 10.3.2: Moved Permanently
 2227           | "302"  ; Section 10.3.3: Found
 2228           | "303"  ; Section 10.3.4: See Other
 2229           | "304"  ; Section 10.3.5: Not Modified
 2230           | "305"  ; Section 10.3.6: Use Proxy
 2231           | "307"  ; Section 10.3.8: Temporary Redirect
 2232           | "400"  ; Section 10.4.1: Bad Request
 2233           | "401"  ; Section 10.4.2: Unauthorized
 2234           | "402"  ; Section 10.4.3: Payment Required
 2235           | "403"  ; Section 10.4.4: Forbidden
 2236           | "404"  ; Section 10.4.5: Not Found
 2237           | "405"  ; Section 10.4.6: Method Not Allowed
 2238           | "406"  ; Section 10.4.7: Not Acceptable
 2239 
 2240 
 2241 
 2242 Fielding, et al.            Standards Track                    [Page 40]
 2243 
 2244 RFC 2616                        HTTP/1.1                       June 1999
 2245 
 2246 
 2247           | "407"  ; Section 10.4.8: Proxy Authentication Required
 2248           | "408"  ; Section 10.4.9: Request Time-out
 2249           | "409"  ; Section 10.4.10: Conflict
 2250           | "410"  ; Section 10.4.11: Gone
 2251           | "411"  ; Section 10.4.12: Length Required
 2252           | "412"  ; Section 10.4.13: Precondition Failed
 2253           | "413"  ; Section 10.4.14: Request Entity Too Large
 2254           | "414"  ; Section 10.4.15: Request-URI Too Large
 2255           | "415"  ; Section 10.4.16: Unsupported Media Type
 2256           | "416"  ; Section 10.4.17: Requested range not satisfiable
 2257           | "417"  ; Section 10.4.18: Expectation Failed
 2258           | "500"  ; Section 10.5.1: Internal Server Error
 2259           | "501"  ; Section 10.5.2: Not Implemented
 2260           | "502"  ; Section 10.5.3: Bad Gateway
 2261           | "503"  ; Section 10.5.4: Service Unavailable
 2262           | "504"  ; Section 10.5.5: Gateway Time-out
 2263           | "505"  ; Section 10.5.6: HTTP Version not supported
 2264           | extension-code
 2265 
 2266       extension-code = 3DIGIT
 2267       Reason-Phrase  = *<TEXT, excluding CR, LF>
 2268 
 2269    HTTP status codes are extensible. HTTP applications are not required
 2270    to understand the meaning of all registered status codes, though such
 2271    understanding is obviously desirable. However, applications MUST
 2272    understand the class of any status code, as indicated by the first
 2273    digit, and treat any unrecognized response as being equivalent to the
 2274    x00 status code of that class, with the exception that an
 2275    unrecognized response MUST NOT be cached. For example, if an
 2276    unrecognized status code of 431 is received by the client, it can
 2277    safely assume that there was something wrong with its request and
 2278    treat the response as if it had received a 400 status code. In such
 2279    cases, user agents SHOULD present to the user the entity returned
 2280    with the response, since that entity is likely to include human-
 2281    readable information which will explain the unusual status.
 2282 
 2283 6.2 Response Header Fields
 2284 
 2285    The response-header fields allow the server to pass additional
 2286    information about the response which cannot be placed in the Status-
 2287    Line. These header fields give information about the server and about
 2288    further access to the resource identified by the Request-URI.
 2289 
 2290        response-header = Accept-Ranges           ; Section 14.5
 2291                        | Age                     ; Section 14.6
 2292                        | ETag                    ; Section 14.19
 2293                        | Location                ; Section 14.30
 2294                        | Proxy-Authenticate      ; Section 14.33
 2295 
 2296 
 2297 
 2298 Fielding, et al.            Standards Track                    [Page 41]
 2299 
 2300 RFC 2616                        HTTP/1.1                       June 1999
 2301 
 2302 
 2303                        | Retry-After             ; Section 14.37
 2304                        | Server                  ; Section 14.38
 2305                        | Vary                    ; Section 14.44
 2306                        | WWW-Authenticate        ; Section 14.47
 2307 
 2308    Response-header field names can be extended reliably only in
 2309    combination with a change in the protocol version. However, new or
 2310    experimental header fields MAY be given the semantics of response-
 2311    header fields if all parties in the communication recognize them to
 2312    be response-header fields. Unrecognized header fields are treated as
 2313    entity-header fields.
 2314 
 2315 7 Entity
 2316 
 2317    Request and Response messages MAY transfer an entity if not otherwise
 2318    restricted by the request method or response status code. An entity
 2319    consists of entity-header fields and an entity-body, although some
 2320    responses will only include the entity-headers.
 2321 
 2322    In this section, both sender and recipient refer to either the client
 2323    or the server, depending on who sends and who receives the entity.
 2324 
 2325 7.1 Entity Header Fields
 2326 
 2327    Entity-header fields define metainformation about the entity-body or,
 2328    if no body is present, about the resource identified by the request.
 2329    Some of this metainformation is OPTIONAL; some might be REQUIRED by
 2330    portions of this specification.
 2331 
 2332        entity-header  = Allow                    ; Section 14.7
 2333                       | Content-Encoding         ; Section 14.11
 2334                       | Content-Language         ; Section 14.12
 2335                       | Content-Length           ; Section 14.13
 2336                       | Content-Location         ; Section 14.14
 2337                       | Content-MD5              ; Section 14.15
 2338                       | Content-Range            ; Section 14.16
 2339                       | Content-Type             ; Section 14.17
 2340                       | Expires                  ; Section 14.21
 2341                       | Last-Modified            ; Section 14.29
 2342                       | extension-header
 2343 
 2344        extension-header = message-header
 2345 
 2346    The extension-header mechanism allows additional entity-header fields
 2347    to be defined without changing the protocol, but these fields cannot
 2348    be assumed to be recognizable by the recipient. Unrecognized header
 2349    fields SHOULD be ignored by the recipient and MUST be forwarded by
 2350    transparent proxies.
 2351 
 2352 
 2353 
 2354 Fielding, et al.            Standards Track                    [Page 42]
 2355 
 2356 RFC 2616                        HTTP/1.1                       June 1999
 2357 
 2358 
 2359 7.2 Entity Body
 2360 
 2361    The entity-body (if any) sent with an HTTP request or response is in
 2362    a format and encoding defined by the entity-header fields.
 2363 
 2364        entity-body    = *OCTET
 2365 
 2366    An entity-body is only present in a message when a message-body is
 2367    present, as described in section 4.3. The entity-body is obtained
 2368    from the message-body by decoding any Transfer-Encoding that might
 2369    have been applied to ensure safe and proper transfer of the message.
 2370 
 2371 7.2.1 Type
 2372 
 2373    When an entity-body is included with a message, the data type of that
 2374    body is determined via the header fields Content-Type and Content-
 2375    Encoding. These define a two-layer, ordered encoding model:
 2376 
 2377        entity-body := Content-Encoding( Content-Type( data ) )
 2378 
 2379    Content-Type specifies the media type of the underlying data.
 2380    Content-Encoding may be used to indicate any additional content
 2381    codings applied to the data, usually for the purpose of data
 2382    compression, that are a property of the requested resource. There is
 2383    no default encoding.
 2384 
 2385    Any HTTP/1.1 message containing an entity-body SHOULD include a
 2386    Content-Type header field defining the media type of that body. If
 2387    and only if the media type is not given by a Content-Type field, the
 2388    recipient MAY attempt to guess the media type via inspection of its
 2389    content and/or the name extension(s) of the URI used to identify the
 2390    resource. If the media type remains unknown, the recipient SHOULD
 2391    treat it as type "application/octet-stream".
 2392 
 2393 7.2.2 Entity Length
 2394 
 2395    The entity-length of a message is the length of the message-body
 2396    before any transfer-codings have been applied. Section 4.4 defines
 2397    how the transfer-length of a message-body is determined.
 2398 
 2399 
 2400 
 2401 
 2402 
 2403 
 2404 
 2405 
 2406 
 2407 
 2408 
 2409 
 2410 Fielding, et al.            Standards Track                    [Page 43]
 2411 
 2412 RFC 2616                        HTTP/1.1                       June 1999
 2413 
 2414 
 2415 8 Connections
 2416 
 2417 8.1 Persistent Connections
 2418 
 2419 8.1.1 Purpose
 2420 
 2421    Prior to persistent connections, a separate TCP connection was
 2422    established to fetch each URL, increasing the load on HTTP servers
 2423    and causing congestion on the Internet. The use of inline images and
 2424    other associated data often require a client to make multiple
 2425    requests of the same server in a short amount of time. Analysis of
 2426    these performance problems and results from a prototype
 2427    implementation are available [26] [30]. Implementation experience and
 2428    measurements of actual HTTP/1.1 (RFC 2068) implementations show good
 2429    results [39]. Alternatives have also been explored, for example,
 2430    T/TCP [27].
 2431 
 2432    Persistent HTTP connections have a number of advantages:
 2433 
 2434       - By opening and closing fewer TCP connections, CPU time is saved
 2435         in routers and hosts (clients, servers, proxies, gateways,
 2436         tunnels, or caches), and memory used for TCP protocol control
 2437         blocks can be saved in hosts.
 2438 
 2439       - HTTP requests and responses can be pipelined on a connection.
 2440         Pipelining allows a client to make multiple requests without
 2441         waiting for each response, allowing a single TCP connection to
 2442         be used much more efficiently, with much lower elapsed time.
 2443 
 2444       - Network congestion is reduced by reducing the number of packets
 2445         caused by TCP opens, and by allowing TCP sufficient time to
 2446         determine the congestion state of the network.
 2447 
 2448       - Latency on subsequent requests is reduced since there is no time
 2449         spent in TCP's connection opening handshake.
 2450 
 2451       - HTTP can evolve more gracefully, since errors can be reported
 2452         without the penalty of closing the TCP connection. Clients using
 2453         future versions of HTTP might optimistically try a new feature,
 2454         but if communicating with an older server, retry with old
 2455         semantics after an error is reported.
 2456 
 2457    HTTP implementations SHOULD implement persistent connections.
 2458 
 2459 
 2460 
 2461 
 2462 
 2463 
 2464 
 2465 
 2466 Fielding, et al.            Standards Track                    [Page 44]
 2467 
 2468 RFC 2616                        HTTP/1.1                       June 1999
 2469 
 2470 
 2471 8.1.2 Overall Operation
 2472 
 2473    A significant difference between HTTP/1.1 and earlier versions of
 2474    HTTP is that persistent connections are the default behavior of any
 2475    HTTP connection. That is, unless otherwise indicated, the client
 2476    SHOULD assume that the server will maintain a persistent connection,
 2477    even after error responses from the server.
 2478 
 2479    Persistent connections provide a mechanism by which a client and a
 2480    server can signal the close of a TCP connection. This signaling takes
 2481    place using the Connection header field (section 14.10). Once a close
 2482    has been signaled, the client MUST NOT send any more requests on that
 2483    connection.
 2484 
 2485 8.1.2.1 Negotiation
 2486 
 2487    An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to
 2488    maintain a persistent connection unless a Connection header including
 2489    the connection-token "close" was sent in the request. If the server
 2490    chooses to close the connection immediately after sending the
 2491    response, it SHOULD send a Connection header including the
 2492    connection-token close.
 2493 
 2494    An HTTP/1.1 client MAY expect a connection to remain open, but would
 2495    decide to keep it open based on whether the response from a server
 2496    contains a Connection header with the connection-token close. In case
 2497    the client does not want to maintain a connection for more than that
 2498    request, it SHOULD send a Connection header including the
 2499    connection-token close.
 2500 
 2501    If either the client or the server sends the close token in the
 2502    Connection header, that request becomes the last one for the
 2503    connection.
 2504 
 2505    Clients and servers SHOULD NOT assume that a persistent connection is
 2506    maintained for HTTP versions less than 1.1 unless it is explicitly
 2507    signaled. See section 19.6.2 for more information on backward
 2508    compatibility with HTTP/1.0 clients.
 2509 
 2510    In order to remain persistent, all messages on the connection MUST
 2511    have a self-defined message length (i.e., one not defined by closure
 2512    of the connection), as described in section 4.4.
 2513 
 2514 
 2515 
 2516 
 2517 
 2518 
 2519 
 2520 
 2521 
 2522 Fielding, et al.            Standards Track                    [Page 45]
 2523 
 2524 RFC 2616                        HTTP/1.1                       June 1999
 2525 
 2526 
 2527 8.1.2.2 Pipelining
 2528 
 2529    A client that supports persistent connections MAY "pipeline" its
 2530    requests (i.e., send multiple requests without waiting for each
 2531    response). A server MUST send its responses to those requests in the
 2532    same order that the requests were received.
 2533 
 2534    Clients which assume persistent connections and pipeline immediately
 2535    after connection establishment SHOULD be prepared to retry their
 2536    connection if the first pipelined attempt fails. If a client does
 2537    such a retry, it MUST NOT pipeline before it knows the connection is
 2538    persistent. Clients MUST also be prepared to resend their requests if
 2539    the server closes the connection before sending all of the
 2540    corresponding responses.
 2541 
 2542    Clients SHOULD NOT pipeline requests using non-idempotent methods or
 2543    non-idempotent sequences of methods (see section 9.1.2). Otherwise, a
 2544    premature termination of the transport connection could lead to
 2545    indeterminate results. A client wishing to send a non-idempotent
 2546    request SHOULD wait to send that request until it has received the
 2547    response status for the previous request.
 2548 
 2549 8.1.3 Proxy Servers
 2550 
 2551    It is especially important that proxies correctly implement the
 2552    properties of the Connection header field as specified in section
 2553    14.10.
 2554 
 2555    The proxy server MUST signal persistent connections separately with
 2556    its clients and the origin servers (or other proxy servers) that it
 2557    connects to. Each persistent connection applies to only one transport
 2558    link.
 2559 
 2560    A proxy server MUST NOT establish a HTTP/1.1 persistent connection
 2561    with an HTTP/1.0 client (but see RFC 2068 [33] for information and
 2562    discussion of the problems with the Keep-Alive header implemented by
 2563    many HTTP/1.0 clients).
 2564 
 2565 8.1.4 Practical Considerations
 2566 
 2567    Servers will usually have some time-out value beyond which they will
 2568    no longer maintain an inactive connection. Proxy servers might make
 2569    this a higher value since it is likely that the client will be making
 2570    more connections through the same server. The use of persistent
 2571    connections places no requirements on the length (or existence) of
 2572    this time-out for either the client or the server.
 2573 
 2574 
 2575 
 2576 
 2577 
 2578 Fielding, et al.            Standards Track                    [Page 46]
 2579 
 2580 RFC 2616                        HTTP/1.1                       June 1999
 2581 
 2582 
 2583    When a client or server wishes to time-out it SHOULD issue a graceful
 2584    close on the transport connection. Clients and servers SHOULD both
 2585    constantly watch for the other side of the transport close, and
 2586    respond to it as appropriate. If a client or server does not detect
 2587    the other side's close promptly it could cause unnecessary resource
 2588    drain on the network.
 2589 
 2590    A client, server, or proxy MAY close the transport connection at any
 2591    time. For example, a client might have started to send a new request
 2592    at the same time that the server has decided to close the "idle"
 2593    connection. From the server's point of view, the connection is being
 2594    closed while it was idle, but from the client's point of view, a
 2595    request is in progress.
 2596 
 2597    This means that clients, servers, and proxies MUST be able to recover
 2598    from asynchronous close events. Client software SHOULD reopen the
 2599    transport connection and retransmit the aborted sequence of requests
 2600    without user interaction so long as the request sequence is
 2601    idempotent (see section 9.1.2). Non-idempotent methods or sequences
 2602    MUST NOT be automatically retried, although user agents MAY offer a
 2603    human operator the choice of retrying the request(s). Confirmation by
 2604    user-agent software with semantic understanding of the application
 2605    MAY substitute for user confirmation. The automatic retry SHOULD NOT
 2606    be repeated if the second sequence of requests fails.
 2607 
 2608    Servers SHOULD always respond to at least one request per connection,
 2609    if at all possible. Servers SHOULD NOT close a connection in the
 2610    middle of transmitting a response, unless a network or client failure
 2611    is suspected.
 2612 
 2613    Clients that use persistent connections SHOULD limit the number of
 2614    simultaneous connections that they maintain to a given server. A
 2615    single-user client SHOULD NOT maintain more than 2 connections with
 2616    any server or proxy. A proxy SHOULD use up to 2*N connections to
 2617    another server or proxy, where N is the number of simultaneously
 2618    active users. These guidelines are intended to improve HTTP response
 2619    times and avoid congestion.
 2620 
 2621 8.2 Message Transmission Requirements
 2622 
 2623 8.2.1 Persistent Connections and Flow Control
 2624 
 2625    HTTP/1.1 servers SHOULD maintain persistent connections and use TCP's
 2626    flow control mechanisms to resolve temporary overloads, rather than
 2627    terminating connections with the expectation that clients will retry.
 2628    The latter technique can exacerbate network congestion.
 2629 
 2630 
 2631 
 2632 
 2633 
 2634 Fielding, et al.            Standards Track                    [Page 47]
 2635 
 2636 RFC 2616                        HTTP/1.1                       June 1999
 2637 
 2638 
 2639 8.2.2 Monitoring Connections for Error Status Messages
 2640 
 2641    An HTTP/1.1 (or later) client sending a message-body SHOULD monitor
 2642    the network connection for an error status while it is transmitting
 2643    the request. If the client sees an error status, it SHOULD
 2644    immediately cease transmitting the body. If the body is being sent
 2645    using a "chunked" encoding (section 3.6), a zero length chunk and
 2646    empty trailer MAY be used to prematurely mark the end of the message.
 2647    If the body was preceded by a Content-Length header, the client MUST
 2648    close the connection.
 2649 
 2650 8.2.3 Use of the 100 (Continue) Status
 2651 
 2652    The purpose of the 100 (Continue) status (see section 10.1.1) is to
 2653    allow a client that is sending a request message with a request body
 2654    to determine if the origin server is willing to accept the request
 2655    (based on the request headers) before the client sends the request
 2656    body. In some cases, it might either be inappropriate or highly
 2657    inefficient for the client to send the body if the server will reject
 2658    the message without looking at the body.
 2659 
 2660    Requirements for HTTP/1.1 clients:
 2661 
 2662       - If a client will wait for a 100 (Continue) response before
 2663         sending the request body, it MUST send an Expect request-header
 2664         field (section 14.20) with the "100-continue" expectation.
 2665 
 2666       - A client MUST NOT send an Expect request-header field (section
 2667         14.20) with the "100-continue" expectation if it does not intend
 2668         to send a request body.
 2669 
 2670    Because of the presence of older implementations, the protocol allows
 2671    ambiguous situations in which a client may send "Expect: 100-
 2672    continue" without receiving either a 417 (Expectation Failed) status
 2673    or a 100 (Continue) status. Therefore, when a client sends this
 2674    header field to an origin server (possibly via a proxy) from which it
 2675    has never seen a 100 (Continue) status, the client SHOULD NOT wait
 2676    for an indefinite period before sending the request body.
 2677 
 2678    Requirements for HTTP/1.1 origin servers:
 2679 
 2680       - Upon receiving a request which includes an Expect request-header
 2681         field with the "100-continue" expectation, an origin server MUST
 2682         either respond with 100 (Continue) status and continue to read
 2683         from the input stream, or respond with a final status code. The
 2684         origin server MUST NOT wait for the request body before sending
 2685         the 100 (Continue) response. If it responds with a final status
 2686         code, it MAY close the transport connection or it MAY continue
 2687 
 2688 
 2689 
 2690 Fielding, et al.            Standards Track                    [Page 48]
 2691 
 2692 RFC 2616                        HTTP/1.1                       June 1999
 2693 
 2694 
 2695         to read and discard the rest of the request.  It MUST NOT
 2696         perform the requested method if it returns a final status code.
 2697 
 2698       - An origin server SHOULD NOT send a 100 (Continue) response if
 2699         the request message does not include an Expect request-header
 2700         field with the "100-continue" expectation, and MUST NOT send a
 2701         100 (Continue) response if such a request comes from an HTTP/1.0
 2702         (or earlier) client. There is an exception to this rule: for
 2703         compatibility with RFC 2068, a server MAY send a 100 (Continue)
 2704         status in response to an HTTP/1.1 PUT or POST request that does
 2705         not include an Expect request-header field with the "100-
 2706         continue" expectation. This exception, the purpose of which is
 2707         to minimize any client processing delays associated with an
 2708         undeclared wait for 100 (Continue) status, applies only to
 2709         HTTP/1.1 requests, and not to requests with any other HTTP-
 2710         version value.
 2711 
 2712       - An origin server MAY omit a 100 (Continue) response if it has
 2713         already received some or all of the request body for the
 2714         corresponding request.
 2715 
 2716       - An origin server that sends a 100 (Continue) response MUST
 2717         ultimately send a final status code, once the request body is
 2718         received and processed, unless it terminates the transport
 2719         connection prematurely.
 2720 
 2721       - If an origin server receives a request that does not include an
 2722         Expect request-header field with the "100-continue" expectation,
 2723         the request includes a request body, and the server responds
 2724         with a final status code before reading the entire request body
 2725         from the transport connection, then the server SHOULD NOT close
 2726         the transport connection until it has read the entire request,
 2727         or until the client closes the connection. Otherwise, the client
 2728         might not reliably receive the response message. However, this
 2729         requirement is not be construed as preventing a server from
 2730         defending itself against denial-of-service attacks, or from
 2731         badly broken client implementations.
 2732 
 2733    Requirements for HTTP/1.1 proxies:
 2734 
 2735       - If a proxy receives a request that includes an Expect request-
 2736         header field with the "100-continue" expectation, and the proxy
 2737         either knows that the next-hop server complies with HTTP/1.1 or
 2738         higher, or does not know the HTTP version of the next-hop
 2739         server, it MUST forward the request, including the Expect header
 2740         field.
 2741 
 2742 
 2743 
 2744 
 2745 
 2746 Fielding, et al.            Standards Track                    [Page 49]
 2747 
 2748 RFC 2616                        HTTP/1.1                       June 1999
 2749 
 2750 
 2751       - If the proxy knows that the version of the next-hop server is
 2752         HTTP/1.0 or lower, it MUST NOT forward the request, and it MUST
 2753         respond with a 417 (Expectation Failed) status.
 2754 
 2755       - Proxies SHOULD maintain a cache recording the HTTP version
 2756         numbers received from recently-referenced next-hop servers.
 2757 
 2758       - A proxy MUST NOT forward a 100 (Continue) response if the
 2759         request message was received from an HTTP/1.0 (or earlier)
 2760         client and did not include an Expect request-header field with
 2761         the "100-continue" expectation. This requirement overrides the
 2762         general rule for forwarding of 1xx responses (see section 10.1).
 2763 
 2764 8.2.4 Client Behavior if Server Prematurely Closes Connection
 2765 
 2766    If an HTTP/1.1 client sends a request which includes a request body,
 2767    but which does not include an Expect request-header field with the
 2768    "100-continue" expectation, and if the client is not directly
 2769    connected to an HTTP/1.1 origin server, and if the client sees the
 2770    connection close before receiving any status from the server, the
 2771    client SHOULD retry the request.  If the client does retry this
 2772    request, it MAY use the following "binary exponential backoff"
 2773    algorithm to be assured of obtaining a reliable response:
 2774 
 2775       1. Initiate a new connection to the server
 2776 
 2777       2. Transmit the request-headers
 2778 
 2779       3. Initialize a variable R to the estimated round-trip time to the
 2780          server (e.g., based on the time it took to establish the
 2781          connection), or to a constant value of 5 seconds if the round-
 2782          trip time is not available.
 2783 
 2784       4. Compute T = R * (2**N), where N is the number of previous
 2785          retries of this request.
 2786 
 2787       5. Wait either for an error response from the server, or for T
 2788          seconds (whichever comes first)
 2789 
 2790       6. If no error response is received, after T seconds transmit the
 2791          body of the request.
 2792 
 2793       7. If client sees that the connection is closed prematurely,
 2794          repeat from step 1 until the request is accepted, an error
 2795          response is received, or the user becomes impatient and
 2796          terminates the retry process.
 2797 
 2798 
 2799 
 2800 
 2801 
 2802 Fielding, et al.            Standards Track                    [Page 50]
 2803 
 2804 RFC 2616                        HTTP/1.1                       June 1999
 2805 
 2806 
 2807    If at any point an error status is received, the client
 2808 
 2809       - SHOULD NOT continue and
 2810 
 2811       - SHOULD close the connection if it has not completed sending the
 2812         request message.
 2813 
 2814 9 Method Definitions
 2815 
 2816    The set of common methods for HTTP/1.1 is defined below. Although
 2817    this set can be expanded, additional methods cannot be assumed to
 2818    share the same semantics for separately extended clients and servers.
 2819 
 2820    The Host request-header field (section 14.23) MUST accompany all
 2821    HTTP/1.1 requests.
 2822 
 2823 9.1 Safe and Idempotent Methods
 2824 
 2825 9.1.1 Safe Methods
 2826 
 2827    Implementors should be aware that the software represents the user in
 2828    their interactions over the Internet, and should be careful to allow
 2829    the user to be aware of any actions they might take which may have an
 2830    unexpected significance to themselves or others.
 2831 
 2832    In particular, the convention has been established that the GET and
 2833    HEAD methods SHOULD NOT have the significance of taking an action
 2834    other than retrieval. These methods ought to be considered "safe".
 2835    This allows user agents to represent other methods, such as POST, PUT
 2836    and DELETE, in a special way, so that the user is made aware of the
 2837    fact that a possibly unsafe action is being requested.
 2838 
 2839    Naturally, it is not possible to ensure that the server does not
 2840    generate side-effects as a result of performing a GET request; in
 2841    fact, some dynamic resources consider that a feature. The important
 2842    distinction here is that the user did not request the side-effects,
 2843    so therefore cannot be held accountable for them.
 2844 
 2845 9.1.2 Idempotent Methods
 2846 
 2847    Methods can also have the property of "idempotence" in that (aside
 2848    from error or expiration issues) the side-effects of N > 0 identical
 2849    requests is the same as for a single request. The methods GET, HEAD,
 2850    PUT and DELETE share this property. Also, the methods OPTIONS and
 2851    TRACE SHOULD NOT have side effects, and so are inherently idempotent.
 2852 
 2853 
 2854 
 2855 
 2856 
 2857 
 2858 Fielding, et al.            Standards Track                    [Page 51]
 2859 
 2860 RFC 2616                        HTTP/1.1                       June 1999
 2861 
 2862 
 2863    However, it is possible that a sequence of several requests is non-
 2864    idempotent, even if all of the methods executed in that sequence are
 2865    idempotent. (A sequence is idempotent if a single execution of the
 2866    entire sequence always yields a result that is not changed by a
 2867    reexecution of all, or part, of that sequence.) For example, a
 2868    sequence is non-idempotent if its result depends on a value that is
 2869    later modified in the same sequence.
 2870 
 2871    A sequence that never has side effects is idempotent, by definition
 2872    (provided that no concurrent operations are being executed on the
 2873    same set of resources).
 2874 
 2875 9.2 OPTIONS
 2876 
 2877    The OPTIONS method represents a request for information about the
 2878    communication options available on the request/response chain
 2879    identified by the Request-URI. This method allows the client to
 2880    determine the options and/or requirements associated with a resource,
 2881    or the capabilities of a server, without implying a resource action
 2882    or initiating a resource retrieval.
 2883 
 2884    Responses to this method are not cacheable.
 2885 
 2886    If the OPTIONS request includes an entity-body (as indicated by the
 2887    presence of Content-Length or Transfer-Encoding), then the media type
 2888    MUST be indicated by a Content-Type field. Although this
 2889    specification does not define any use for such a body, future
 2890    extensions to HTTP might use the OPTIONS body to make more detailed
 2891    queries on the server. A server that does not support such an
 2892    extension MAY discard the request body.
 2893 
 2894    If the Request-URI is an asterisk ("*"), the OPTIONS request is
 2895    intended to apply to the server in general rather than to a specific
 2896    resource. Since a server's communication options typically depend on
 2897    the resource, the "*" request is only useful as a "ping" or "no-op"
 2898    type of method; it does nothing beyond allowing the client to test
 2899    the capabilities of the server. For example, this can be used to test
 2900    a proxy for HTTP/1.1 compliance (or lack thereof).
 2901 
 2902    If the Request-URI is not an asterisk, the OPTIONS request applies
 2903    only to the options that are available when communicating with that
 2904    resource.
 2905 
 2906    A 200 response SHOULD include any header fields that indicate
 2907    optional features implemented by the server and applicable to that
 2908    resource (e.g., Allow), possibly including extensions not defined by
 2909    this specification. The response body, if any, SHOULD also include
 2910    information about the communication options. The format for such a
 2911 
 2912 
 2913 
 2914 Fielding, et al.            Standards Track                    [Page 52]
 2915 
 2916 RFC 2616                        HTTP/1.1                       June 1999
 2917 
 2918 
 2919    body is not defined by this specification, but might be defined by
 2920    future extensions to HTTP. Content negotiation MAY be used to select
 2921    the appropriate response format. If no response body is included, the
 2922    response MUST include a Content-Length field with a field-value of
 2923    "0".
 2924 
 2925    The Max-Forwards request-header field MAY be used to target a
 2926    specific proxy in the request chain. When a proxy receives an OPTIONS
 2927    request on an absoluteURI for which request forwarding is permitted,
 2928    the proxy MUST check for a Max-Forwards field. If the Max-Forwards
 2929    field-value is zero ("0"), the proxy MUST NOT forward the message;
 2930    instead, the proxy SHOULD respond with its own communication options.
 2931    If the Max-Forwards field-value is an integer greater than zero, the
 2932    proxy MUST decrement the field-value when it forwards the request. If
 2933    no Max-Forwards field is present in the request, then the forwarded
 2934    request MUST NOT include a Max-Forwards field.
 2935 
 2936 9.3 GET
 2937 
 2938    The GET method means retrieve whatever information (in the form of an
 2939    entity) is identified by the Request-URI. If the Request-URI refers
 2940    to a data-producing process, it is the produced data which shall be
 2941    returned as the entity in the response and not the source text of the
 2942    process, unless that text happens to be the output of the process.
 2943 
 2944    The semantics of the GET method change to a "conditional GET" if the
 2945    request message includes an If-Modified-Since, If-Unmodified-Since,
 2946    If-Match, If-None-Match, or If-Range header field. A conditional GET
 2947    method requests that the entity be transferred only under the
 2948    circumstances described by the conditional header field(s). The
 2949    conditional GET method is intended to reduce unnecessary network
 2950    usage by allowing cached entities to be refreshed without requiring
 2951    multiple requests or transferring data already held by the client.
 2952 
 2953    The semantics of the GET method change to a "partial GET" if the
 2954    request message includes a Range header field. A partial GET requests
 2955    that only part of the entity be transferred, as described in section
 2956    14.35. The partial GET method is intended to reduce unnecessary
 2957    network usage by allowing partially-retrieved entities to be
 2958    completed without transferring data already held by the client.
 2959 
 2960    The response to a GET request is cacheable if and only if it meets
 2961    the requirements for HTTP caching described in section 13.
 2962 
 2963    See section 15.1.3 for security considerations when used for forms.
 2964 
 2965 
 2966 
 2967 
 2968 
 2969 
 2970 Fielding, et al.            Standards Track                    [Page 53]
 2971 
 2972 RFC 2616                        HTTP/1.1                       June 1999
 2973 
 2974 
 2975 9.4 HEAD
 2976 
 2977    The HEAD method is identical to GET except that the server MUST NOT
 2978    return a message-body in the response. The metainformation contained
 2979    in the HTTP headers in response to a HEAD request SHOULD be identical
 2980    to the information sent in response to a GET request. This method can
 2981    be used for obtaining metainformation about the entity implied by the
 2982    request without transferring the entity-body itself. This method is
 2983    often used for testing hypertext links for validity, accessibility,
 2984    and recent modification.
 2985 
 2986    The response to a HEAD request MAY be cacheable in the sense that the
 2987    information contained in the response MAY be used to update a
 2988    previously cached entity from that resource. If the new field values
 2989    indicate that the cached entity differs from the current entity (as
 2990    would be indicated by a change in Content-Length, Content-MD5, ETag
 2991    or Last-Modified), then the cache MUST treat the cache entry as
 2992    stale.
 2993 
 2994 9.5 POST
 2995 
 2996    The POST method is used to request that the origin server accept the
 2997    entity enclosed in the request as a new subordinate of the resource
 2998    identified by the Request-URI in the Request-Line. POST is designed
 2999    to allow a uniform method to cover the following functions:
 3000 
 3001       - Annotation of existing resources;
 3002 
 3003       - Posting a message to a bulletin board, newsgroup, mailing list,
 3004         or similar group of articles;
 3005 
 3006       - Providing a block of data, such as the result of submitting a
 3007         form, to a data-handling process;
 3008 
 3009       - Extending a database through an append operation.
 3010 
 3011    The actual function performed by the POST method is determined by the
 3012    server and is usually dependent on the Request-URI. The posted entity
 3013    is subordinate to that URI in the same way that a file is subordinate
 3014    to a directory containing it, a news article is subordinate to a
 3015    newsgroup to which it is posted, or a record is subordinate to a
 3016    database.
 3017 
 3018    The action performed by the POST method might not result in a
 3019    resource that can be identified by a URI. In this case, either 200
 3020    (OK) or 204 (No Content) is the appropriate response status,
 3021    depending on whether or not the response includes an entity that
 3022    describes the result.
 3023 
 3024 
 3025 
 3026 Fielding, et al.            Standards Track                    [Page 54]
 3027 
 3028 RFC 2616                        HTTP/1.1                       June 1999
 3029 
 3030 
 3031    If a resource has been created on the origin server, the response
 3032    SHOULD be 201 (Created) and contain an entity which describes the
 3033    status of the request and refers to the new resource, and a Location
 3034    header (see section 14.30).
 3035 
 3036    Responses to this method are not cacheable, unless the response
 3037    includes appropriate Cache-Control or Expires header fields. However,
 3038    the 303 (See Other) response can be used to direct the user agent to
 3039    retrieve a cacheable resource.
 3040 
 3041    POST requests MUST obey the message transmission requirements set out
 3042    in section 8.2.
 3043 
 3044    See section 15.1.3 for security considerations.
 3045 
 3046 9.6 PUT
 3047 
 3048    The PUT method requests that the enclosed entity be stored under the
 3049    supplied Request-URI. If the Request-URI refers to an already
 3050    existing resource, the enclosed entity SHOULD be considered as a
 3051    modified version of the one residing on the origin server. If the
 3052    Request-URI does not point to an existing resource, and that URI is
 3053    capable of being defined as a new resource by the requesting user
 3054    agent, the origin server can create the resource with that URI. If a
 3055    new resource is created, the origin server MUST inform the user agent
 3056    via the 201 (Created) response. If an existing resource is modified,
 3057    either the 200 (OK) or 204 (No Content) response codes SHOULD be sent
 3058    to indicate successful completion of the request. If the resource
 3059    could not be created or modified with the Request-URI, an appropriate
 3060    error response SHOULD be given that reflects the nature of the
 3061    problem. The recipient of the entity MUST NOT ignore any Content-*
 3062    (e.g. Content-Range) headers that it does not understand or implement
 3063    and MUST return a 501 (Not Implemented) response in such cases.
 3064 
 3065    If the request passes through a cache and the Request-URI identifies
 3066    one or more currently cached entities, those entries SHOULD be
 3067    treated as stale. Responses to this method are not cacheable.
 3068 
 3069    The fundamental difference between the POST and PUT requests is
 3070    reflected in the different meaning of the Request-URI. The URI in a
 3071    POST request identifies the resource that will handle the enclosed
 3072    entity. That resource might be a data-accepting process, a gateway to
 3073    some other protocol, or a separate entity that accepts annotations.
 3074    In contrast, the URI in a PUT request identifies the entity enclosed
 3075    with the request -- the user agent knows what URI is intended and the
 3076    server MUST NOT attempt to apply the request to some other resource.
 3077    If the server desires that the request be applied to a different URI,
 3078 
 3079 
 3080 
 3081 
 3082 Fielding, et al.            Standards Track                    [Page 55]
 3083 
 3084 RFC 2616                        HTTP/1.1                       June 1999
 3085 
 3086 
 3087    it MUST send a 301 (Moved Permanently) response; the user agent MAY
 3088    then make its own decision regarding whether or not to redirect the
 3089    request.
 3090 
 3091    A single resource MAY be identified by many different URIs. For
 3092    example, an article might have a URI for identifying "the current
 3093    version" which is separate from the URI identifying each particular
 3094    version. In this case, a PUT request on a general URI might result in
 3095    several other URIs being defined by the origin server.
 3096 
 3097    HTTP/1.1 does not define how a PUT method affects the state of an
 3098    origin server.
 3099 
 3100    PUT requests MUST obey the message transmission requirements set out
 3101    in section 8.2.
 3102 
 3103    Unless otherwise specified for a particular entity-header, the
 3104    entity-headers in the PUT request SHOULD be applied to the resource
 3105    created or modified by the PUT.
 3106 
 3107 9.7 DELETE
 3108 
 3109    The DELETE method requests that the origin server delete the resource
 3110    identified by the Request-URI. This method MAY be overridden by human
 3111    intervention (or other means) on the origin server. The client cannot
 3112    be guaranteed that the operation has been carried out, even if the
 3113    status code returned from the origin server indicates that the action
 3114    has been completed successfully. However, the server SHOULD NOT
 3115    indicate success unless, at the time the response is given, it
 3116    intends to delete the resource or move it to an inaccessible
 3117    location.
 3118 
 3119    A successful response SHOULD be 200 (OK) if the response includes an
 3120    entity describing the status, 202 (Accepted) if the action has not
 3121    yet been enacted, or 204 (No Content) if the action has been enacted
 3122    but the response does not include an entity.
 3123 
 3124    If the request passes through a cache and the Request-URI identifies
 3125    one or more currently cached entities, those entries SHOULD be
 3126    treated as stale. Responses to this method are not cacheable.
 3127 
 3128 9.8 TRACE
 3129 
 3130    The TRACE method is used to invoke a remote, application-layer loop-
 3131    back of the request message. The final recipient of the request
 3132    SHOULD reflect the message received back to the client as the
 3133    entity-body of a 200 (OK) response. The final recipient is either the
 3134 
 3135 
 3136 
 3137 
 3138 Fielding, et al.            Standards Track                    [Page 56]
 3139 
 3140 RFC 2616                        HTTP/1.1                       June 1999
 3141 
 3142 
 3143    origin server or the first proxy or gateway to receive a Max-Forwards
 3144    value of zero (0) in the request (see section 14.31). A TRACE request
 3145    MUST NOT include an entity.
 3146 
 3147    TRACE allows the client to see what is being received at the other
 3148    end of the request chain and use that data for testing or diagnostic
 3149    information. The value of the Via header field (section 14.45) is of
 3150    particular interest, since it acts as a trace of the request chain.
 3151    Use of the Max-Forwards header field allows the client to limit the
 3152    length of the request chain, which is useful for testing a chain of
 3153    proxies forwarding messages in an infinite loop.
 3154 
 3155    If the request is valid, the response SHOULD contain the entire
 3156    request message in the entity-body, with a Content-Type of
 3157    "message/http". Responses to this method MUST NOT be cached.
 3158 
 3159 9.9 CONNECT
 3160 
 3161    This specification reserves the method name CONNECT for use with a
 3162    proxy that can dynamically switch to being a tunnel (e.g. SSL
 3163    tunneling [44]).
 3164 
 3165 10 Status Code Definitions
 3166 
 3167    Each Status-Code is described below, including a description of which
 3168    method(s) it can follow and any metainformation required in the
 3169    response.
 3170 
 3171 10.1 Informational 1xx
 3172 
 3173    This class of status code indicates a provisional response,
 3174    consisting only of the Status-Line and optional headers, and is
 3175    terminated by an empty line. There are no required headers for this
 3176    class of status code. Since HTTP/1.0 did not define any 1xx status
 3177    codes, servers MUST NOT send a 1xx response to an HTTP/1.0 client
 3178    except under experimental conditions.
 3179 
 3180    A client MUST be prepared to accept one or more 1xx status responses
 3181    prior to a regular response, even if the client does not expect a 100
 3182    (Continue) status message. Unexpected 1xx status responses MAY be
 3183    ignored by a user agent.
 3184 
 3185    Proxies MUST forward 1xx responses, unless the connection between the
 3186    proxy and its client has been closed, or unless the proxy itself
 3187    requested the generation of the 1xx response. (For example, if a
 3188 
 3189 
 3190 
 3191 
 3192 
 3193 
 3194 Fielding, et al.            Standards Track                    [Page 57]
 3195 
 3196 RFC 2616                        HTTP/1.1                       June 1999
 3197 
 3198 
 3199    proxy adds a "Expect: 100-continue" field when it forwards a request,
 3200    then it need not forward the corresponding 100 (Continue)
 3201    response(s).)
 3202 
 3203 10.1.1 100 Continue
 3204 
 3205    The client SHOULD continue with its request. This interim response is
 3206    used to inform the client that the initial part of the request has
 3207    been received and has not yet been rejected by the server. The client
 3208    SHOULD continue by sending the remainder of the request or, if the
 3209    request has already been completed, ignore this response. The server
 3210    MUST send a final response after the request has been completed. See
 3211    section 8.2.3 for detailed discussion of the use and handling of this
 3212    status code.
 3213 
 3214 10.1.2 101 Switching Protocols
 3215 
 3216    The server understands and is willing to comply with the client's
 3217    request, via the Upgrade message header field (section 14.42), for a
 3218    change in the application protocol being used on this connection. The
 3219    server will switch protocols to those defined by the response's
 3220    Upgrade header field immediately after the empty line which
 3221    terminates the 101 response.
 3222 
 3223    The protocol SHOULD be switched only when it is advantageous to do
 3224    so. For example, switching to a newer version of HTTP is advantageous
 3225    over older versions, and switching to a real-time, synchronous
 3226    protocol might be advantageous when delivering resources that use
 3227    such features.
 3228 
 3229 10.2 Successful 2xx
 3230 
 3231    This class of status code indicates that the client's request was
 3232    successfully received, understood, and accepted.
 3233 
 3234 10.2.1 200 OK
 3235 
 3236    The request has succeeded. The information returned with the response
 3237    is dependent on the method used in the request, for example:
 3238 
 3239    GET    an entity corresponding to the requested resource is sent in
 3240           the response;
 3241 
 3242    HEAD   the entity-header fields corresponding to the requested
 3243           resource are sent in the response without any message-body;
 3244 
 3245    POST   an entity describing or containing the result of the action;
 3246 
 3247 
 3248 
 3249 
 3250 Fielding, et al.            Standards Track                    [Page 58]
 3251 
 3252 RFC 2616                        HTTP/1.1                       June 1999
 3253 
 3254 
 3255    TRACE  an entity containing the request message as received by the
 3256           end server.
 3257 
 3258 10.2.2 201 Created
 3259 
 3260    The request has been fulfilled and resulted in a new resource being
 3261    created. The newly created resource can be referenced by the URI(s)
 3262    returned in the entity of the response, with the most specific URI
 3263    for the resource given by a Location header field. The response
 3264    SHOULD include an entity containing a list of resource
 3265    characteristics and location(s) from which the user or user agent can
 3266    choose the one most appropriate. The entity format is specified by
 3267    the media type given in the Content-Type header field. The origin
 3268    server MUST create the resource before returning the 201 status code.
 3269    If the action cannot be carried out immediately, the server SHOULD
 3270    respond with 202 (Accepted) response instead.
 3271 
 3272    A 201 response MAY contain an ETag response header field indicating
 3273    the current value of the entity tag for the requested variant just
 3274    created, see section 14.19.
 3275 
 3276 10.2.3 202 Accepted
 3277 
 3278    The request has been accepted for processing, but the processing has
 3279    not been completed.  The request might or might not eventually be
 3280    acted upon, as it might be disallowed when processing actually takes
 3281    place. There is no facility for re-sending a status code from an
 3282    asynchronous operation such as this.
 3283 
 3284    The 202 response is intentionally non-committal. Its purpose is to
 3285    allow a server to accept a request for some other process (perhaps a
 3286    batch-oriented process that is only run once per day) without
 3287    requiring that the user agent's connection to the server persist
 3288    until the process is completed. The entity returned with this
 3289    response SHOULD include an indication of the request's current status
 3290    and either a pointer to a status monitor or some estimate of when the
 3291    user can expect the request to be fulfilled.
 3292 
 3293 10.2.4 203 Non-Authoritative Information
 3294 
 3295    The returned metainformation in the entity-header is not the
 3296    definitive set as available from the origin server, but is gathered
 3297    from a local or a third-party copy. The set presented MAY be a subset
 3298    or superset of the original version. For example, including local
 3299    annotation information about the resource might result in a superset
 3300    of the metainformation known by the origin server. Use of this
 3301    response code is not required and is only appropriate when the
 3302    response would otherwise be 200 (OK).
 3303 
 3304 
 3305 
 3306 Fielding, et al.            Standards Track                    [Page 59]
 3307 
 3308 RFC 2616                        HTTP/1.1                       June 1999
 3309 
 3310 
 3311 10.2.5 204 No Content
 3312 
 3313    The server has fulfilled the request but does not need to return an
 3314    entity-body, and might want to return updated metainformation. The
 3315    response MAY include new or updated metainformation in the form of
 3316    entity-headers, which if present SHOULD be associated with the
 3317    requested variant.
 3318 
 3319    If the client is a user agent, it SHOULD NOT change its document view
 3320    from that which caused the request to be sent. This response is
 3321    primarily intended to allow input for actions to take place without
 3322    causing a change to the user agent's active document view, although
 3323    any new or updated metainformation SHOULD be applied to the document
 3324    currently in the user agent's active view.
 3325 
 3326    The 204 response MUST NOT include a message-body, and thus is always
 3327    terminated by the first empty line after the header fields.
 3328 
 3329 10.2.6 205 Reset Content
 3330 
 3331    The server has fulfilled the request and the user agent SHOULD reset
 3332    the document view which caused the request to be sent. This response
 3333    is primarily intended to allow input for actions to take place via
 3334    user input, followed by a clearing of the form in which the input is
 3335    given so that the user can easily initiate another input action. The
 3336    response MUST NOT include an entity.
 3337 
 3338 10.2.7 206 Partial Content
 3339 
 3340    The server has fulfilled the partial GET request for the resource.
 3341    The request MUST have included a Range header field (section 14.35)
 3342    indicating the desired range, and MAY have included an If-Range
 3343    header field (section 14.27) to make the request conditional.
 3344 
 3345    The response MUST include the following header fields:
 3346 
 3347       - Either a Content-Range header field (section 14.16) indicating
 3348         the range included with this response, or a multipart/byteranges
 3349         Content-Type including Content-Range fields for each part. If a
 3350         Content-Length header field is present in the response, its
 3351         value MUST match the actual number of OCTETs transmitted in the
 3352         message-body.
 3353 
 3354       - Date
 3355 
 3356       - ETag and/or Content-Location, if the header would have been sent
 3357         in a 200 response to the same request
 3358 
 3359 
 3360 
 3361 
 3362 Fielding, et al.            Standards Track                    [Page 60]
 3363 
 3364 RFC 2616                        HTTP/1.1                       June 1999
 3365 
 3366 
 3367       - Expires, Cache-Control, and/or Vary, if the field-value might
 3368         differ from that sent in any previous response for the same
 3369         variant
 3370 
 3371    If the 206 response is the result of an If-Range request that used a
 3372    strong cache validator (see section 13.3.3), the response SHOULD NOT
 3373    include other entity-headers. If the response is the result of an
 3374    If-Range request that used a weak validator, the response MUST NOT
 3375    include other entity-headers; this prevents inconsistencies between
 3376    cached entity-bodies and updated headers. Otherwise, the response
 3377    MUST include all of the entity-headers that would have been returned
 3378    with a 200 (OK) response to the same request.
 3379 
 3380    A cache MUST NOT combine a 206 response with other previously cached
 3381    content if the ETag or Last-Modified headers do not match exactly,
 3382    see 13.5.4.
 3383 
 3384    A cache that does not support the Range and Content-Range headers
 3385    MUST NOT cache 206 (Partial) responses.
 3386 
 3387 10.3 Redirection 3xx
 3388 
 3389    This class of status code indicates that further action needs to be
 3390    taken by the user agent in order to fulfill the request.  The action
 3391    required MAY be carried out by the user agent without interaction
 3392    with the user if and only if the method used in the second request is
 3393    GET or HEAD. A client SHOULD detect infinite redirection loops, since
 3394    such loops generate network traffic for each redirection.
 3395 
 3396       Note: previous versions of this specification recommended a
 3397       maximum of five redirections. Content developers should be aware
 3398       that there might be clients that implement such a fixed
 3399       limitation.
 3400 
 3401 10.3.1 300 Multiple Choices
 3402 
 3403    The requested resource corresponds to any one of a set of
 3404    representations, each with its own specific location, and agent-
 3405    driven negotiation information (section 12) is being provided so that
 3406    the user (or user agent) can select a preferred representation and
 3407    redirect its request to that location.
 3408 
 3409    Unless it was a HEAD request, the response SHOULD include an entity
 3410    containing a list of resource characteristics and location(s) from
 3411    which the user or user agent can choose the one most appropriate. The
 3412    entity format is specified by the media type given in the Content-
 3413    Type header field. Depending upon the format and the capabilities of
 3414 
 3415 
 3416 
 3417 
 3418 Fielding, et al.            Standards Track                    [Page 61]
 3419 
 3420 RFC 2616                        HTTP/1.1                       June 1999
 3421 
 3422 
 3423    the user agent, selection of the most appropriate choice MAY be
 3424    performed automatically. However, this specification does not define
 3425    any standard for such automatic selection.
 3426 
 3427    If the server has a preferred choice of representation, it SHOULD
 3428    include the specific URI for that representation in the Location
 3429    field; user agents MAY use the Location field value for automatic
 3430    redirection. This response is cacheable unless indicated otherwise.
 3431 
 3432 10.3.2 301 Moved Permanently
 3433 
 3434    The requested resource has been assigned a new permanent URI and any
 3435    future references to this resource SHOULD use one of the returned
 3436    URIs.  Clients with link editing capabilities ought to automatically
 3437    re-link references to the Request-URI to one or more of the new
 3438    references returned by the server, where possible. This response is
 3439    cacheable unless indicated otherwise.
 3440 
 3441    The new permanent URI SHOULD be given by the Location field in the
 3442    response. Unless the request method was HEAD, the entity of the
 3443    response SHOULD contain a short hypertext note with a hyperlink to
 3444    the new URI(s).
 3445 
 3446    If the 301 status code is received in response to a request other
 3447    than GET or HEAD, the user agent MUST NOT automatically redirect the
 3448    request unless it can be confirmed by the user, since this might
 3449    change the conditions under which the request was issued.
 3450 
 3451       Note: When automatically redirecting a POST request after
 3452       receiving a 301 status code, some existing HTTP/1.0 user agents
 3453       will erroneously change it into a GET request.
 3454 
 3455 10.3.3 302 Found
 3456 
 3457    The requested resource resides temporarily under a different URI.
 3458    Since the redirection might be altered on occasion, the client SHOULD
 3459    continue to use the Request-URI for future requests.  This response
 3460    is only cacheable if indicated by a Cache-Control or Expires header
 3461    field.
 3462 
 3463    The temporary URI SHOULD be given by the Location field in the
 3464    response. Unless the request method was HEAD, the entity of the
 3465    response SHOULD contain a short hypertext note with a hyperlink to
 3466    the new URI(s).
 3467 
 3468 
 3469 
 3470 
 3471 
 3472 
 3473 
 3474 Fielding, et al.            Standards Track                    [Page 62]
 3475 
 3476 RFC 2616                        HTTP/1.1                       June 1999
 3477 
 3478 
 3479    If the 302 status code is received in response to a request other
 3480    than GET or HEAD, the user agent MUST NOT automatically redirect the
 3481    request unless it can be confirmed by the user, since this might
 3482    change the conditions under which the request was issued.
 3483 
 3484       Note: RFC 1945 and RFC 2068 specify that the client is not allowed
 3485       to change the method on the redirected request.  However, most
 3486       existing user agent implementations treat 302 as if it were a 303
 3487       response, performing a GET on the Location field-value regardless
 3488       of the original request method. The status codes 303 and 307 have
 3489       been added for servers that wish to make unambiguously clear which
 3490       kind of reaction is expected of the client.
 3491 
 3492 10.3.4 303 See Other
 3493 
 3494    The response to the request can be found under a different URI and
 3495    SHOULD be retrieved using a GET method on that resource. This method
 3496    exists primarily to allow the output of a POST-activated script to
 3497    redirect the user agent to a selected resource. The new URI is not a
 3498    substitute reference for the originally requested resource. The 303
 3499    response MUST NOT be cached, but the response to the second
 3500    (redirected) request might be cacheable.
 3501 
 3502    The different URI SHOULD be given by the Location field in the
 3503    response. Unless the request method was HEAD, the entity of the
 3504    response SHOULD contain a short hypertext note with a hyperlink to
 3505    the new URI(s).
 3506 
 3507       Note: Many pre-HTTP/1.1 user agents do not understand the 303
 3508       status. When interoperability with such clients is a concern, the
 3509       302 status code may be used instead, since most user agents react
 3510       to a 302 response as described here for 303.
 3511 
 3512 10.3.5 304 Not Modified
 3513 
 3514    If the client has performed a conditional GET request and access is
 3515    allowed, but the document has not been modified, the server SHOULD
 3516    respond with this status code. The 304 response MUST NOT contain a
 3517    message-body, and thus is always terminated by the first empty line
 3518    after the header fields.
 3519 
 3520    The response MUST include the following header fields:
 3521 
 3522       - Date, unless its omission is required by section 14.18.1
 3523 
 3524 
 3525 
 3526 
 3527 
 3528 
 3529 
 3530 Fielding, et al.            Standards Track                    [Page 63]
 3531 
 3532 RFC 2616                        HTTP/1.1                       June 1999
 3533 
 3534 
 3535    If a clockless origin server obeys these rules, and proxies and
 3536    clients add their own Date to any response received without one (as
 3537    already specified by [RFC 2068], section 14.19), caches will operate
 3538    correctly.
 3539 
 3540       - ETag and/or Content-Location, if the header would have been sent
 3541         in a 200 response to the same request
 3542 
 3543       - Expires, Cache-Control, and/or Vary, if the field-value might
 3544         differ from that sent in any previous response for the same
 3545         variant
 3546 
 3547    If the conditional GET used a strong cache validator (see section
 3548    13.3.3), the response SHOULD NOT include other entity-headers.
 3549    Otherwise (i.e., the conditional GET used a weak validator), the
 3550    response MUST NOT include other entity-headers; this prevents
 3551    inconsistencies between cached entity-bodies and updated headers.
 3552 
 3553    If a 304 response indicates an entity not currently cached, then the
 3554    cache MUST disregard the response and repeat the request without the
 3555    conditional.
 3556 
 3557    If a cache uses a received 304 response to update a cache entry, the
 3558    cache MUST update the entry to reflect any new field values given in
 3559    the response.
 3560 
 3561 10.3.6 305 Use Proxy
 3562 
 3563    The requested resource MUST be accessed through the proxy given by
 3564    the Location field. The Location field gives the URI of the proxy.
 3565    The recipient is expected to repeat this single request via the
 3566    proxy. 305 responses MUST only be generated by origin servers.
 3567 
 3568       Note: RFC 2068 was not clear that 305 was intended to redirect a
 3569       single request, and to be generated by origin servers only.  Not
 3570       observing these limitations has significant security consequences.
 3571 
 3572 10.3.7 306 (Unused)
 3573 
 3574    The 306 status code was used in a previous version of the
 3575    specification, is no longer used, and the code is reserved.
 3576 
 3577 
 3578 
 3579 
 3580 
 3581 
 3582 
 3583 
 3584 
 3585 
 3586 Fielding, et al.            Standards Track                    [Page 64]
 3587 
 3588 RFC 2616                        HTTP/1.1                       June 1999
 3589 
 3590 
 3591 10.3.8 307 Temporary Redirect
 3592 
 3593    The requested resource resides temporarily under a different URI.
 3594    Since the redirection MAY be altered on occasion, the client SHOULD
 3595    continue to use the Request-URI for future requests.  This response
 3596    is only cacheable if indicated by a Cache-Control or Expires header
 3597    field.
 3598 
 3599    The temporary URI SHOULD be given by the Location field in the
 3600    response. Unless the request method was HEAD, the entity of the
 3601    response SHOULD contain a short hypertext note with a hyperlink to
 3602    the new URI(s) , since many pre-HTTP/1.1 user agents do not
 3603    understand the 307 status. Therefore, the note SHOULD contain the
 3604    information necessary for a user to repeat the original request on
 3605    the new URI.
 3606 
 3607    If the 307 status code is received in response to a request other
 3608    than GET or HEAD, the user agent MUST NOT automatically redirect the
 3609    request unless it can be confirmed by the user, since this might
 3610    change the conditions under which the request was issued.
 3611 
 3612 10.4 Client Error 4xx
 3613 
 3614    The 4xx class of status code is intended for cases in which the
 3615    client seems to have erred. Except when responding to a HEAD request,
 3616    the server SHOULD include an entity containing an explanation of the
 3617    error situation, and whether it is a temporary or permanent
 3618    condition. These status codes are applicable to any request method.
 3619    User agents SHOULD display any included entity to the user.
 3620 
 3621    If the client is sending data, a server implementation using TCP
 3622    SHOULD be careful to ensure that the client acknowledges receipt of
 3623    the packet(s) containing the response, before the server closes the
 3624    input connection. If the client continues sending data to the server
 3625    after the close, the server's TCP stack will send a reset packet to
 3626    the client, which may erase the client's unacknowledged input buffers
 3627    before they can be read and interpreted by the HTTP application.
 3628 
 3629 10.4.1 400 Bad Request
 3630 
 3631    The request could not be understood by the server due to malformed
 3632    syntax. The client SHOULD NOT repeat the request without
 3633    modifications.
 3634 
 3635 
 3636 
 3637 
 3638 
 3639 
 3640 
 3641 
 3642 Fielding, et al.            Standards Track                    [Page 65]
 3643 
 3644 RFC 2616                        HTTP/1.1                       June 1999
 3645 
 3646 
 3647 10.4.2 401 Unauthorized
 3648 
 3649    The request requires user authentication. The response MUST include a
 3650    WWW-Authenticate header field (section 14.47) containing a challenge
 3651    applicable to the requested resource. The client MAY repeat the
 3652    request with a suitable Authorization header field (section 14.8). If
 3653    the request already included Authorization credentials, then the 401
 3654    response indicates that authorization has been refused for those
 3655    credentials. If the 401 response contains the same challenge as the
 3656    prior response, and the user agent has already attempted
 3657    authentication at least once, then the user SHOULD be presented the
 3658    entity that was given in the response, since that entity might
 3659    include relevant diagnostic information. HTTP access authentication
 3660    is explained in "HTTP Authentication: Basic and Digest Access
 3661    Authentication" [43].
 3662 
 3663 10.4.3 402 Payment Required
 3664 
 3665    This code is reserved for future use.
 3666 
 3667 10.4.4 403 Forbidden
 3668 
 3669    The server understood the request, but is refusing to fulfill it.
 3670    Authorization will not help and the request SHOULD NOT be repeated.
 3671    If the request method was not HEAD and the server wishes to make
 3672    public why the request has not been fulfilled, it SHOULD describe the
 3673    reason for the refusal in the entity.  If the server does not wish to
 3674    make this information available to the client, the status code 404
 3675    (Not Found) can be used instead.
 3676 
 3677 10.4.5 404 Not Found
 3678 
 3679    The server has not found anything matching the Request-URI. No
 3680    indication is given of whether the condition is temporary or
 3681    permanent. The 410 (Gone) status code SHOULD be used if the server
 3682    knows, through some internally configurable mechanism, that an old
 3683    resource is permanently unavailable and has no forwarding address.
 3684    This status code is commonly used when the server does not wish to
 3685    reveal exactly why the request has been refused, or when no other
 3686    response is applicable.
 3687 
 3688 10.4.6 405 Method Not Allowed
 3689 
 3690    The method specified in the Request-Line is not allowed for the
 3691    resource identified by the Request-URI. The response MUST include an
 3692    Allow header containing a list of valid methods for the requested
 3693    resource.
 3694 
 3695 
 3696 
 3697 
 3698 Fielding, et al.            Standards Track                    [Page 66]
 3699 
 3700 RFC 2616                        HTTP/1.1                       June 1999
 3701 
 3702 
 3703 10.4.7 406 Not Acceptable
 3704 
 3705    The resource identified by the request is only capable of generating
 3706    response entities which have content characteristics not acceptable
 3707    according to the accept headers sent in the request.
 3708 
 3709    Unless it was a HEAD request, the response SHOULD include an entity
 3710    containing a list of available entity characteristics and location(s)
 3711    from which the user or user agent can choose the one most
 3712    appropriate. The entity format is specified by the media type given
 3713    in the Content-Type header field. Depending upon the format and the
 3714    capabilities of the user agent, selection of the most appropriate
 3715    choice MAY be performed automatically. However, this specification
 3716    does not define any standard for such automatic selection.
 3717 
 3718       Note: HTTP/1.1 servers are allowed to return responses which are
 3719       not acceptable according to the accept headers sent in the
 3720       request. In some cases, this may even be preferable to sending a
 3721       406 response. User agents are encouraged to inspect the headers of
 3722       an incoming response to determine if it is acceptable.
 3723 
 3724    If the response could be unacceptable, a user agent SHOULD
 3725    temporarily stop receipt of more data and query the user for a
 3726    decision on further actions.
 3727 
 3728 10.4.8 407 Proxy Authentication Required
 3729 
 3730    This code is similar to 401 (Unauthorized), but indicates that the
 3731    client must first authenticate itself with the proxy. The proxy MUST
 3732    return a Proxy-Authenticate header field (section 14.33) containing a
 3733    challenge applicable to the proxy for the requested resource. The
 3734    client MAY repeat the request with a suitable Proxy-Authorization
 3735    header field (section 14.34). HTTP access authentication is explained
 3736    in "HTTP Authentication: Basic and Digest Access Authentication"
 3737    [43].
 3738 
 3739 10.4.9 408 Request Timeout
 3740 
 3741    The client did not produce a request within the time that the server
 3742    was prepared to wait. The client MAY repeat the request without
 3743    modifications at any later time.
 3744 
 3745 10.4.10 409 Conflict
 3746 
 3747    The request could not be completed due to a conflict with the current
 3748    state of the resource. This code is only allowed in situations where
 3749    it is expected that the user might be able to resolve the conflict
 3750    and resubmit the request. The response body SHOULD include enough
 3751 
 3752 
 3753 
 3754 Fielding, et al.            Standards Track                    [Page 67]
 3755 
 3756 RFC 2616                        HTTP/1.1                       June 1999
 3757 
 3758 
 3759    information for the user to recognize the source of the conflict.
 3760    Ideally, the response entity would include enough information for the
 3761    user or user agent to fix the problem; however, that might not be
 3762    possible and is not required.
 3763 
 3764    Conflicts are most likely to occur in response to a PUT request. For
 3765    example, if versioning were being used and the entity being PUT
 3766    included changes to a resource which conflict with those made by an
 3767    earlier (third-party) request, the server might use the 409 response
 3768    to indicate that it can't complete the request. In this case, the
 3769    response entity would likely contain a list of the differences
 3770    between the two versions in a format defined by the response
 3771    Content-Type.
 3772 
 3773 10.4.11 410 Gone
 3774 
 3775    The requested resource is no longer available at the server and no
 3776    forwarding address is known. This condition is expected to be
 3777    considered permanent. Clients with link editing capabilities SHOULD
 3778    delete references to the Request-URI after user approval. If the
 3779    server does not know, or has no facility to determine, whether or not
 3780    the condition is permanent, the status code 404 (Not Found) SHOULD be
 3781    used instead. This response is cacheable unless indicated otherwise.
 3782 
 3783    The 410 response is primarily intended to assist the task of web
 3784    maintenance by notifying the recipient that the resource is
 3785    intentionally unavailable and that the server owners desire that
 3786    remote links to that resource be removed. Such an event is common for
 3787    limited-time, promotional services and for resources belonging to
 3788    individuals no longer working at the server's site. It is not
 3789    necessary to mark all permanently unavailable resources as "gone" or
 3790    to keep the mark for any length of time -- that is left to the
 3791    discretion of the server owner.
 3792 
 3793 10.4.12 411 Length Required
 3794 
 3795    The server refuses to accept the request without a defined Content-
 3796    Length. The client MAY repeat the request if it adds a valid
 3797    Content-Length header field containing the length of the message-body
 3798    in the request message.
 3799 
 3800 10.4.13 412 Precondition Failed
 3801 
 3802    The precondition given in one or more of the request-header fields
 3803    evaluated to false when it was tested on the server. This response
 3804    code allows the client to place preconditions on the current resource
 3805    metainformation (header field data) and thus prevent the requested
 3806    method from being applied to a resource other than the one intended.
 3807 
 3808 
 3809 
 3810 Fielding, et al.            Standards Track                    [Page 68]
 3811 
 3812 RFC 2616                        HTTP/1.1                       June 1999
 3813 
 3814 
 3815 10.4.14 413 Request Entity Too Large
 3816 
 3817    The server is refusing to process a request because the request
 3818    entity is larger than the server is willing or able to process. The
 3819    server MAY close the connection to prevent the client from continuing
 3820    the request.
 3821 
 3822    If the condition is temporary, the server SHOULD include a Retry-
 3823    After header field to indicate that it is temporary and after what
 3824    time the client MAY try again.
 3825 
 3826 10.4.15 414 Request-URI Too Long
 3827 
 3828    The server is refusing to service the request because the Request-URI
 3829    is longer than the server is willing to interpret. This rare
 3830    condition is only likely to occur when a client has improperly
 3831    converted a POST request to a GET request with long query
 3832    information, when the client has descended into a URI "black hole" of
 3833    redirection (e.g., a redirected URI prefix that points to a suffix of
 3834    itself), or when the server is under attack by a client attempting to
 3835    exploit security holes present in some servers using fixed-length
 3836    buffers for reading or manipulating the Request-URI.
 3837 
 3838 10.4.16 415 Unsupported Media Type
 3839 
 3840    The server is refusing to service the request because the entity of
 3841    the request is in a format not supported by the requested resource
 3842    for the requested method.
 3843 
 3844 10.4.17 416 Requested Range Not Satisfiable
 3845 
 3846    A server SHOULD return a response with this status code if a request
 3847    included a Range request-header field (section 14.35), and none of
 3848    the range-specifier values in this field overlap the current extent
 3849    of the selected resource, and the request did not include an If-Range
 3850    request-header field. (For byte-ranges, this means that the first-
 3851    byte-pos of all of the byte-range-spec values were greater than the
 3852    current length of the selected resource.)
 3853 
 3854    When this status code is returned for a byte-range request, the
 3855    response SHOULD include a Content-Range entity-header field
 3856    specifying the current length of the selected resource (see section
 3857    14.16). This response MUST NOT use the multipart/byteranges content-
 3858    type.
 3859 
 3860 
 3861 
 3862 
 3863 
 3864 
 3865 
 3866 Fielding, et al.            Standards Track                    [Page 69]
 3867 
 3868 RFC 2616                        HTTP/1.1                       June 1999
 3869 
 3870 
 3871 10.4.18 417 Expectation Failed
 3872 
 3873    The expectation given in an Expect request-header field (see section
 3874    14.20) could not be met by this server, or, if the server is a proxy,
 3875    the server has unambiguous evidence that the request could not be met
 3876    by the next-hop server.
 3877 
 3878 10.5 Server Error 5xx
 3879 
 3880    Response status codes beginning with the digit "5" indicate cases in
 3881    which the server is aware that it has erred or is incapable of
 3882    performing the request. Except when responding to a HEAD request, the
 3883    server SHOULD include an entity containing an explanation of the
 3884    error situation, and whether it is a temporary or permanent
 3885    condition. User agents SHOULD display any included entity to the
 3886    user. These response codes are applicable to any request method.
 3887 
 3888 10.5.1 500 Internal Server Error
 3889 
 3890    The server encountered an unexpected condition which prevented it
 3891    from fulfilling the request.
 3892 
 3893 10.5.2 501 Not Implemented
 3894 
 3895    The server does not support the functionality required to fulfill the
 3896    request. This is the appropriate response when the server does not
 3897    recognize the request method and is not capable of supporting it for
 3898    any resource.
 3899 
 3900 10.5.3 502 Bad Gateway
 3901 
 3902    The server, while acting as a gateway or proxy, received an invalid
 3903    response from the upstream server it accessed in attempting to
 3904    fulfill the request.
 3905 
 3906 10.5.4 503 Service Unavailable
 3907 
 3908    The server is currently unable to handle the request due to a
 3909    temporary overloading or maintenance of the server. The implication
 3910    is that this is a temporary condition which will be alleviated after
 3911    some delay. If known, the length of the delay MAY be indicated in a
 3912    Retry-After header. If no Retry-After is given, the client SHOULD
 3913    handle the response as it would for a 500 response.
 3914 
 3915       Note: The existence of the 503 status code does not imply that a
 3916       server must use it when becoming overloaded. Some servers may wish
 3917       to simply refuse the connection.
 3918 
 3919 
 3920 
 3921 
 3922 Fielding, et al.            Standards Track                    [Page 70]
 3923 
 3924 RFC 2616                        HTTP/1.1                       June 1999
 3925 
 3926 
 3927 10.5.5 504 Gateway Timeout
 3928 
 3929    The server, while acting as a gateway or proxy, did not receive a
 3930    timely response from the upstream server specified by the URI (e.g.
 3931    HTTP, FTP, LDAP) or some other auxiliary server (e.g. DNS) it needed
 3932    to access in attempting to complete the request.
 3933 
 3934       Note: Note to implementors: some deployed proxies are known to
 3935       return 400 or 500 when DNS lookups time out.
 3936 
 3937 10.5.6 505 HTTP Version Not Supported
 3938 
 3939    The server does not support, or refuses to support, the HTTP protocol
 3940    version that was used in the request message. The server is
 3941    indicating that it is unable or unwilling to complete the request
 3942    using the same major version as the client, as described in section
 3943    3.1, other than with this error message. The response SHOULD contain
 3944    an entity describing why that version is not supported and what other
 3945    protocols are supported by that server.
 3946 
 3947 11 Access Authentication
 3948 
 3949    HTTP provides several OPTIONAL challenge-response authentication
 3950    mechanisms which can be used by a server to challenge a client
 3951    request and by a client to provide authentication information. The
 3952    general framework for access authentication, and the specification of
 3953    "basic" and "digest" authentication, are specified in "HTTP
 3954    Authentication: Basic and Digest Access Authentication" [43]. This
 3955    specification adopts the definitions of "challenge" and "credentials"
 3956    from that specification.
 3957 
 3958 12 Content Negotiation
 3959 
 3960    Most HTTP responses include an entity which contains information for
 3961    interpretation by a human user. Naturally, it is desirable to supply
 3962    the user with the "best available" entity corresponding to the
 3963    request. Unfortunately for servers and caches, not all users have the
 3964    same preferences for what is "best," and not all user agents are
 3965    equally capable of rendering all entity types. For that reason, HTTP
 3966    has provisions for several mechanisms for "content negotiation" --
 3967    the process of selecting the best representation for a given response
 3968    when there are multiple representations available.
 3969 
 3970       Note: This is not called "format negotiation" because the
 3971       alternate representations may be of the same media type, but use
 3972       different capabilities of that type, be in different languages,
 3973       etc.
 3974 
 3975 
 3976 
 3977 
 3978 Fielding, et al.            Standards Track                    [Page 71]
 3979 
 3980 RFC 2616                        HTTP/1.1                       June 1999
 3981 
 3982 
 3983    Any response containing an entity-body MAY be subject to negotiation,
 3984    including error responses.
 3985 
 3986    There are two kinds of content negotiation which are possible in
 3987    HTTP: server-driven and agent-driven negotiation. These two kinds of
 3988    negotiation are orthogonal and thus may be used separately or in
 3989    combination. One method of combination, referred to as transparent
 3990    negotiation, occurs when a cache uses the agent-driven negotiation
 3991    information provided by the origin server in order to provide
 3992    server-driven negotiation for subsequent requests.
 3993 
 3994 12.1 Server-driven Negotiation
 3995 
 3996    If the selection of the best representation for a response is made by
 3997    an algorithm located at the server, it is called server-driven
 3998    negotiation. Selection is based on the available representations of
 3999    the response (the dimensions over which it can vary; e.g. language,
 4000    content-coding, etc.) and the contents of particular header fields in
 4001    the request message or on other information pertaining to the request
 4002    (such as the network address of the client).
 4003 
 4004    Server-driven negotiation is advantageous when the algorithm for
 4005    selecting from among the available representations is difficult to
 4006    describe to the user agent, or when the server desires to send its
 4007    "best guess" to the client along with the first response (hoping to
 4008    avoid the round-trip delay of a subsequent request if the "best
 4009    guess" is good enough for the user). In order to improve the server's
 4010    guess, the user agent MAY include request header fields (Accept,
 4011    Accept-Language, Accept-Encoding, etc.) which describe its
 4012    preferences for such a response.
 4013 
 4014    Server-driven negotiation has disadvantages:
 4015 
 4016       1. It is impossible for the server to accurately determine what
 4017          might be "best" for any given user, since that would require
 4018          complete knowledge of both the capabilities of the user agent
 4019          and the intended use for the response (e.g., does the user want
 4020          to view it on screen or print it on paper?).
 4021 
 4022       2. Having the user agent describe its capabilities in every
 4023          request can be both very inefficient (given that only a small
 4024          percentage of responses have multiple representations) and a
 4025          potential violation of the user's privacy.
 4026 
 4027       3. It complicates the implementation of an origin server and the
 4028          algorithms for generating responses to a request.
 4029 
 4030 
 4031 
 4032 
 4033 
 4034 Fielding, et al.            Standards Track                    [Page 72]
 4035 
 4036 RFC 2616                        HTTP/1.1                       June 1999
 4037 
 4038 
 4039       4. It may limit a public cache's ability to use the same response
 4040          for multiple user's requests.
 4041 
 4042    HTTP/1.1 includes the following request-header fields for enabling
 4043    server-driven negotiation through description of user agent
 4044    capabilities and user preferences: Accept (section 14.1), Accept-
 4045    Charset (section 14.2), Accept-Encoding (section 14.3), Accept-
 4046    Language (section 14.4), and User-Agent (section 14.43). However, an
 4047    origin server is not limited to these dimensions and MAY vary the
 4048    response based on any aspect of the request, including information
 4049    outside the request-header fields or within extension header fields
 4050    not defined by this specification.
 4051 
 4052    The Vary  header field can be used to express the parameters the
 4053    server uses to select a representation that is subject to server-
 4054    driven negotiation. See section 13.6 for use of the Vary header field
 4055    by caches and section 14.44 for use of the Vary header field by
 4056    servers.
 4057 
 4058 12.2 Agent-driven Negotiation
 4059 
 4060    With agent-driven negotiation, selection of the best representation
 4061    for a response is performed by the user agent after receiving an
 4062    initial response from the origin server. Selection is based on a list
 4063    of the available representations of the response included within the
 4064    header fields or entity-body of the initial response, with each
 4065    representation identified by its own URI. Selection from among the
 4066    representations may be performed automatically (if the user agent is
 4067    capable of doing so) or manually by the user selecting from a
 4068    generated (possibly hypertext) menu.
 4069 
 4070    Agent-driven negotiation is advantageous when the response would vary
 4071    over commonly-used dimensions (such as type, language, or encoding),
 4072    when the origin server is unable to determine a user agent's
 4073    capabilities from examining the request, and generally when public
 4074    caches are used to distribute server load and reduce network usage.
 4075 
 4076    Agent-driven negotiation suffers from the disadvantage of needing a
 4077    second request to obtain the best alternate representation. This
 4078    second request is only efficient when caching is used. In addition,
 4079    this specification does not define any mechanism for supporting
 4080    automatic selection, though it also does not prevent any such
 4081    mechanism from being developed as an extension and used within
 4082    HTTP/1.1.
 4083 
 4084 
 4085 
 4086 
 4087 
 4088 
 4089 
 4090 Fielding, et al.            Standards Track                    [Page 73]
 4091 
 4092 RFC 2616                        HTTP/1.1                       June 1999
 4093 
 4094 
 4095    HTTP/1.1 defines the 300 (Multiple Choices) and 406 (Not Acceptable)
 4096    status codes for enabling agent-driven negotiation when the server is
 4097    unwilling or unable to provide a varying response using server-driven
 4098    negotiation.
 4099 
 4100 12.3 Transparent Negotiation
 4101 
 4102    Transparent negotiation is a combination of both server-driven and
 4103    agent-driven negotiation. When a cache is supplied with a form of the
 4104    list of available representations of the response (as in agent-driven
 4105    negotiation) and the dimensions of variance are completely understood
 4106    by the cache, then the cache becomes capable of performing server-
 4107    driven negotiation on behalf of the origin server for subsequent
 4108    requests on that resource.
 4109 
 4110    Transparent negotiation has the advantage of distributing the
 4111    negotiation work that would otherwise be required of the origin
 4112    server and also removing the second request delay of agent-driven
 4113    negotiation when the cache is able to correctly guess the right
 4114    response.
 4115 
 4116    This specification does not define any mechanism for transparent
 4117    negotiation, though it also does not prevent any such mechanism from
 4118    being developed as an extension that could be used within HTTP/1.1.
 4119 
 4120 13 Caching in HTTP
 4121 
 4122    HTTP is typically used for distributed information systems, where
 4123    performance can be improved by the use of response caches. The
 4124    HTTP/1.1 protocol includes a number of elements intended to make
 4125    caching work as well as possible. Because these elements are
 4126    inextricable from other aspects of the protocol, and because they
 4127    interact with each other, it is useful to describe the basic caching
 4128    design of HTTP separately from the detailed descriptions of methods,
 4129    headers, response codes, etc.
 4130 
 4131    Caching would be useless if it did not significantly improve
 4132    performance. The goal of caching in HTTP/1.1 is to eliminate the need
 4133    to send requests in many cases, and to eliminate the need to send
 4134    full responses in many other cases. The former reduces the number of
 4135    network round-trips required for many operations; we use an
 4136    "expiration" mechanism for this purpose (see section 13.2). The
 4137    latter reduces network bandwidth requirements; we use a "validation"
 4138    mechanism for this purpose (see section 13.3).
 4139 
 4140    Requirements for performance, availability, and disconnected
 4141    operation require us to be able to relax the goal of semantic
 4142    transparency. The HTTP/1.1 protocol allows origin servers, caches,
 4143 
 4144 
 4145 
 4146 Fielding, et al.            Standards Track                    [Page 74]
 4147 
 4148 RFC 2616                        HTTP/1.1                       June 1999
 4149 
 4150 
 4151    and clients to explicitly reduce transparency when necessary.
 4152    However, because non-transparent operation may confuse non-expert
 4153    users, and might be incompatible with certain server applications
 4154    (such as those for ordering merchandise), the protocol requires that
 4155    transparency be relaxed
 4156 
 4157       - only by an explicit protocol-level request when relaxed by
 4158         client or origin server
 4159 
 4160       - only with an explicit warning to the end user when relaxed by
 4161         cache or client
 4162 
 4163    Therefore, the HTTP/1.1 protocol provides these important elements:
 4164 
 4165       1. Protocol features that provide full semantic transparency when
 4166          this is required by all parties.
 4167 
 4168       2. Protocol features that allow an origin server or user agent to
 4169          explicitly request and control non-transparent operation.
 4170 
 4171       3. Protocol features that allow a cache to attach warnings to
 4172          responses that do not preserve the requested approximation of
 4173          semantic transparency.
 4174 
 4175    A basic principle is that it must be possible for the clients to
 4176    detect any potential relaxation of semantic transparency.
 4177 
 4178       Note: The server, cache, or client implementor might be faced with
 4179       design decisions not explicitly discussed in this specification.
 4180       If a decision might affect semantic transparency, the implementor
 4181       ought to err on the side of maintaining transparency unless a
 4182       careful and complete analysis shows significant benefits in
 4183       breaking transparency.
 4184 
 4185 13.1.1 Cache Correctness
 4186 
 4187    A correct cache MUST respond to a request with the most up-to-date
 4188    response held by the cache that is appropriate to the request (see
 4189    sections 13.2.5, 13.2.6, and 13.12) which meets one of the following
 4190    conditions:
 4191 
 4192       1. It has been checked for equivalence with what the origin server
 4193          would have returned by revalidating the response with the
 4194          origin server (section 13.3);
 4195 
 4196 
 4197 
 4198 
 4199 
 4200 
 4201 
 4202 Fielding, et al.            Standards Track                    [Page 75]
 4203 
 4204 RFC 2616                        HTTP/1.1                       June 1999
 4205 
 4206 
 4207       2. It is "fresh enough" (see section 13.2). In the default case,
 4208          this means it meets the least restrictive freshness requirement
 4209          of the client, origin server, and cache (see section 14.9); if
 4210          the origin server so specifies, it is the freshness requirement
 4211          of the origin server alone.
 4212 
 4213          If a stored response is not "fresh enough" by the most
 4214          restrictive freshness requirement of both the client and the
 4215          origin server, in carefully considered circumstances the cache
 4216          MAY still return the response with the appropriate Warning
 4217          header (see section 13.1.5 and 14.46), unless such a response
 4218          is prohibited (e.g., by a "no-store" cache-directive, or by a
 4219          "no-cache" cache-request-directive; see section 14.9).
 4220 
 4221       3. It is an appropriate 304 (Not Modified), 305 (Proxy Redirect),
 4222          or error (4xx or 5xx) response message.
 4223 
 4224    If the cache can not communicate with the origin server, then a
 4225    correct cache SHOULD respond as above if the response can be
 4226    correctly served from the cache; if not it MUST return an error or
 4227    warning indicating that there was a communication failure.
 4228 
 4229    If a cache receives a response (either an entire response, or a 304
 4230    (Not Modified) response) that it would normally forward to the
 4231    requesting client, and the received response is no longer fresh, the
 4232    cache SHOULD forward it to the requesting client without adding a new
 4233    Warning (but without removing any existing Warning headers). A cache
 4234    SHOULD NOT attempt to revalidate a response simply because that
 4235    response became stale in transit; this might lead to an infinite
 4236    loop. A user agent that receives a stale response without a Warning
 4237    MAY display a warning indication to the user.
 4238 
 4239 13.1.2 Warnings
 4240 
 4241    Whenever a cache returns a response that is neither first-hand nor
 4242    "fresh enough" (in the sense of condition 2 in section 13.1.1), it
 4243    MUST attach a warning to that effect, using a Warning general-header.
 4244    The Warning header and the currently defined warnings are described
 4245    in section 14.46. The warning allows clients to take appropriate
 4246    action.
 4247 
 4248    Warnings MAY be used for other purposes, both cache-related and
 4249    otherwise. The use of a warning, rather than an error status code,
 4250    distinguish these responses from true failures.
 4251 
 4252    Warnings are assigned three digit warn-codes. The first digit
 4253    indicates whether the Warning MUST or MUST NOT be deleted from a
 4254    stored cache entry after a successful revalidation:
 4255 
 4256 
 4257 
 4258 Fielding, et al.            Standards Track                    [Page 76]
 4259 
 4260 RFC 2616                        HTTP/1.1                       June 1999
 4261 
 4262 
 4263    1xx  Warnings that describe the freshness or revalidation status of
 4264      the response, and so MUST be deleted after a successful
 4265      revalidation. 1XX warn-codes MAY be generated by a cache only when
 4266      validating a cached entry. It MUST NOT be generated by clients.
 4267 
 4268    2xx  Warnings that describe some aspect of the entity body or entity
 4269      headers that is not rectified by a revalidation (for example, a
 4270      lossy compression of the entity bodies) and which MUST NOT be
 4271      deleted after a successful revalidation.
 4272 
 4273    See section 14.46 for the definitions of the codes themselves.
 4274 
 4275    HTTP/1.0 caches will cache all Warnings in responses, without
 4276    deleting the ones in the first category. Warnings in responses that
 4277    are passed to HTTP/1.0 caches carry an extra warning-date field,
 4278    which prevents a future HTTP/1.1 recipient from believing an
 4279    erroneously cached Warning.
 4280 
 4281    Warnings also carry a warning text. The text MAY be in any
 4282    appropriate natural language (perhaps based on the client's Accept
 4283    headers), and include an OPTIONAL indication of what character set is
 4284    used.
 4285 
 4286    Multiple warnings MAY be attached to a response (either by the origin
 4287    server or by a cache), including multiple warnings with the same code
 4288    number. For example, a server might provide the same warning with
 4289    texts in both English and Basque.
 4290 
 4291    When multiple warnings are attached to a response, it might not be
 4292    practical or reasonable to display all of them to the user. This
 4293    version of HTTP does not specify strict priority rules for deciding
 4294    which warnings to display and in what order, but does suggest some
 4295    heuristics.
 4296 
 4297 13.1.3 Cache-control Mechanisms
 4298 
 4299    The basic cache mechanisms in HTTP/1.1 (server-specified expiration
 4300    times and validators) are implicit directives to caches. In some
 4301    cases, a server or client might need to provide explicit directives
 4302    to the HTTP caches. We use the Cache-Control header for this purpose.
 4303 
 4304    The Cache-Control header allows a client or server to transmit a
 4305    variety of directives in either requests or responses. These
 4306    directives typically override the default caching algorithms. As a
 4307    general rule, if there is any apparent conflict between header
 4308    values, the most restrictive interpretation is applied (that is, the
 4309    one that is most likely to preserve semantic transparency). However,
 4310 
 4311 
 4312 
 4313 
 4314 Fielding, et al.            Standards Track                    [Page 77]
 4315 
 4316 RFC 2616                        HTTP/1.1                       June 1999
 4317 
 4318 
 4319    in some cases, cache-control directives are explicitly specified as
 4320    weakening the approximation of semantic transparency (for example,
 4321    "max-stale" or "public").
 4322 
 4323    The cache-control directives are described in detail in section 14.9.
 4324 
 4325 13.1.4 Explicit User Agent Warnings
 4326 
 4327    Many user agents make it possible for users to override the basic
 4328    caching mechanisms. For example, the user agent might allow the user
 4329    to specify that cached entities (even explicitly stale ones) are
 4330    never validated. Or the user agent might habitually add "Cache-
 4331    Control: max-stale=3600" to every request. The user agent SHOULD NOT
 4332    default to either non-transparent behavior, or behavior that results
 4333    in abnormally ineffective caching, but MAY be explicitly configured
 4334    to do so by an explicit action of the user.
 4335 
 4336    If the user has overridden the basic caching mechanisms, the user
 4337    agent SHOULD explicitly indicate to the user whenever this results in
 4338    the display of information that might not meet the server's
 4339    transparency requirements (in particular, if the displayed entity is
 4340    known to be stale). Since the protocol normally allows the user agent
 4341    to determine if responses are stale or not, this indication need only
 4342    be displayed when this actually happens. The indication need not be a
 4343    dialog box; it could be an icon (for example, a picture of a rotting
 4344    fish) or some other indicator.
 4345 
 4346    If the user has overridden the caching mechanisms in a way that would
 4347    abnormally reduce the effectiveness of caches, the user agent SHOULD
 4348    continually indicate this state to the user (for example, by a
 4349    display of a picture of currency in flames) so that the user does not
 4350    inadvertently consume excess resources or suffer from excessive
 4351    latency.
 4352 
 4353 13.1.5 Exceptions to the Rules and Warnings
 4354 
 4355    In some cases, the operator of a cache MAY choose to configure it to
 4356    return stale responses even when not requested by clients. This
 4357    decision ought not be made lightly, but may be necessary for reasons
 4358    of availability or performance, especially when the cache is poorly
 4359    connected to the origin server. Whenever a cache returns a stale
 4360    response, it MUST mark it as such (using a Warning header) enabling
 4361    the client software to alert the user that there might be a potential
 4362    problem.
 4363 
 4364 
 4365 
 4366 
 4367 
 4368 
 4369 
 4370 Fielding, et al.            Standards Track                    [Page 78]
 4371 
 4372 RFC 2616                        HTTP/1.1                       June 1999
 4373 
 4374 
 4375    It also allows the user agent to take steps to obtain a first-hand or
 4376    fresh response. For this reason, a cache SHOULD NOT return a stale
 4377    response if the client explicitly requests a first-hand or fresh one,
 4378    unless it is impossible to comply for technical or policy reasons.
 4379 
 4380 13.1.6 Client-controlled Behavior
 4381 
 4382    While the origin server (and to a lesser extent, intermediate caches,
 4383    by their contribution to the age of a response) are the primary
 4384    source of expiration information, in some cases the client might need
 4385    to control a cache's decision about whether to return a cached
 4386    response without validating it. Clients do this using several
 4387    directives of the Cache-Control header.
 4388 
 4389    A client's request MAY specify the maximum age it is willing to
 4390    accept of an unvalidated response; specifying a value of zero forces
 4391    the cache(s) to revalidate all responses. A client MAY also specify
 4392    the minimum time remaining before a response expires. Both of these
 4393    options increase constraints on the behavior of caches, and so cannot
 4394    further relax the cache's approximation of semantic transparency.
 4395 
 4396    A client MAY also specify that it will accept stale responses, up to
 4397    some maximum amount of staleness. This loosens the constraints on the
 4398    caches, and so might violate the origin server's specified
 4399    constraints on semantic transparency, but might be necessary to
 4400    support disconnected operation, or high availability in the face of
 4401    poor connectivity.
 4402 
 4403 13.2 Expiration Model
 4404 
 4405 13.2.1 Server-Specified Expiration
 4406 
 4407    HTTP caching works best when caches can entirely avoid making
 4408    requests to the origin server. The primary mechanism for avoiding
 4409    requests is for an origin server to provide an explicit expiration
 4410    time in the future, indicating that a response MAY be used to satisfy
 4411    subsequent requests. In other words, a cache can return a fresh
 4412    response without first contacting the server.
 4413 
 4414    Our expectation is that servers will assign future explicit
 4415    expiration times to responses in the belief that the entity is not
 4416    likely to change, in a semantically significant way, before the
 4417    expiration time is reached. This normally preserves semantic
 4418    transparency, as long as the server's expiration times are carefully
 4419    chosen.
 4420 
 4421 
 4422 
 4423 
 4424 
 4425 
 4426 Fielding, et al.            Standards Track                    [Page 79]
 4427 
 4428 RFC 2616                        HTTP/1.1                       June 1999
 4429 
 4430 
 4431    The expiration mechanism applies only to responses taken from a cache
 4432    and not to first-hand responses forwarded immediately to the
 4433    requesting client.
 4434 
 4435    If an origin server wishes to force a semantically transparent cache
 4436    to validate every request, it MAY assign an explicit expiration time
 4437    in the past. This means that the response is always stale, and so the
 4438    cache SHOULD validate it before using it for subsequent requests. See
 4439    section 14.9.4 for a more restrictive way to force revalidation.
 4440 
 4441    If an origin server wishes to force any HTTP/1.1 cache, no matter how
 4442    it is configured, to validate every request, it SHOULD use the "must-
 4443    revalidate" cache-control directive (see section 14.9).
 4444 
 4445    Servers specify explicit expiration times using either the Expires
 4446    header, or the max-age directive of the Cache-Control header.
 4447 
 4448    An expiration time cannot be used to force a user agent to refresh
 4449    its display or reload a resource; its semantics apply only to caching
 4450    mechanisms, and such mechanisms need only check a resource's
 4451    expiration status when a new request for that resource is initiated.
 4452    See section 13.13 for an explanation of the difference between caches
 4453    and history mechanisms.
 4454 
 4455 13.2.2 Heuristic Expiration
 4456 
 4457    Since origin servers do not always provide explicit expiration times,
 4458    HTTP caches typically assign heuristic expiration times, employing
 4459    algorithms that use other header values (such as the Last-Modified
 4460    time) to estimate a plausible expiration time. The HTTP/1.1
 4461    specification does not provide specific algorithms, but does impose
 4462    worst-case constraints on their results. Since heuristic expiration
 4463    times might compromise semantic transparency, they ought to used
 4464    cautiously, and we encourage origin servers to provide explicit
 4465    expiration times as much as possible.
 4466 
 4467 13.2.3 Age Calculations
 4468 
 4469    In order to know if a cached entry is fresh, a cache needs to know if
 4470    its age exceeds its freshness lifetime. We discuss how to calculate
 4471    the latter in section 13.2.4; this section describes how to calculate
 4472    the age of a response or cache entry.
 4473 
 4474    In this discussion, we use the term "now" to mean "the current value
 4475    of the clock at the host performing the calculation." Hosts that use
 4476    HTTP, but especially hosts running origin servers and caches, SHOULD
 4477    use NTP [28] or some similar protocol to synchronize their clocks to
 4478    a globally accurate time standard.
 4479 
 4480 
 4481 
 4482 Fielding, et al.            Standards Track                    [Page 80]
 4483 
 4484 RFC 2616                        HTTP/1.1                       June 1999
 4485 
 4486 
 4487    HTTP/1.1 requires origin servers to send a Date header, if possible,
 4488    with every response, giving the time at which the response was
 4489    generated (see section 14.18). We use the term "date_value" to denote
 4490    the value of the Date header, in a form appropriate for arithmetic
 4491    operations.
 4492 
 4493    HTTP/1.1 uses the Age response-header to convey the estimated age of
 4494    the response message when obtained from a cache. The Age field value
 4495    is the cache's estimate of the amount of time since the response was
 4496    generated or revalidated by the origin server.
 4497 
 4498    In essence, the Age value is the sum of the time that the response
 4499    has been resident in each of the caches along the path from the
 4500    origin server, plus the amount of time it has been in transit along
 4501    network paths.
 4502 
 4503    We use the term "age_value" to denote the value of the Age header, in
 4504    a form appropriate for arithmetic operations.
 4505 
 4506    A response's age can be calculated in two entirely independent ways:
 4507 
 4508       1. now minus date_value, if the local clock is reasonably well
 4509          synchronized to the origin server's clock. If the result is
 4510          negative, the result is replaced by zero.
 4511 
 4512       2. age_value, if all of the caches along the response path
 4513          implement HTTP/1.1.
 4514 
 4515    Given that we have two independent ways to compute the age of a
 4516    response when it is received, we can combine these as
 4517 
 4518        corrected_received_age = max(now - date_value, age_value)
 4519 
 4520    and as long as we have either nearly synchronized clocks or all-
 4521    HTTP/1.1 paths, one gets a reliable (conservative) result.
 4522 
 4523    Because of network-imposed delays, some significant interval might
 4524    pass between the time that a server generates a response and the time
 4525    it is received at the next outbound cache or client. If uncorrected,
 4526    this delay could result in improperly low ages.
 4527 
 4528    Because the request that resulted in the returned Age value must have
 4529    been initiated prior to that Age value's generation, we can correct
 4530    for delays imposed by the network by recording the time at which the
 4531    request was initiated. Then, when an Age value is received, it MUST
 4532    be interpreted relative to the time the request was initiated, not
 4533 
 4534 
 4535 
 4536 
 4537 
 4538 Fielding, et al.            Standards Track                    [Page 81]
 4539 
 4540 RFC 2616                        HTTP/1.1                       June 1999
 4541 
 4542 
 4543    the time that the response was received. This algorithm results in
 4544    conservative behavior no matter how much delay is experienced. So, we
 4545    compute:
 4546 
 4547       corrected_initial_age = corrected_received_age
 4548                             + (now - request_time)
 4549 
 4550    where "request_time" is the time (according to the local clock) when
 4551    the request that elicited this response was sent.
 4552 
 4553    Summary of age calculation algorithm, when a cache receives a
 4554    response:
 4555 
 4556       /*
 4557        * age_value
 4558        *      is the value of Age: header received by the cache with
 4559        *              this response.
 4560        * date_value
 4561        *      is the value of the origin server's Date: header
 4562        * request_time
 4563        *      is the (local) time when the cache made the request
 4564        *              that resulted in this cached response
 4565        * response_time
 4566        *      is the (local) time when the cache received the
 4567        *              response
 4568        * now
 4569        *      is the current (local) time
 4570        */
 4571 
 4572       apparent_age = max(0, response_time - date_value);
 4573       corrected_received_age = max(apparent_age, age_value);
 4574       response_delay = response_time - request_time;
 4575       corrected_initial_age = corrected_received_age + response_delay;
 4576       resident_time = now - response_time;
 4577       current_age   = corrected_initial_age + resident_time;
 4578 
 4579    The current_age of a cache entry is calculated by adding the amount
 4580    of time (in seconds) since the cache entry was last validated by the
 4581    origin server to the corrected_initial_age. When a response is
 4582    generated from a cache entry, the cache MUST include a single Age
 4583    header field in the response with a value equal to the cache entry's
 4584    current_age.
 4585 
 4586    The presence of an Age header field in a response implies that a
 4587    response is not first-hand. However, the converse is not true, since
 4588    the lack of an Age header field in a response does not imply that the
 4589 
 4590 
 4591 
 4592 
 4593 
 4594 Fielding, et al.            Standards Track                    [Page 82]
 4595 
 4596 RFC 2616                        HTTP/1.1                       June 1999
 4597 
 4598 
 4599    response is first-hand unless all caches along the request path are
 4600    compliant with HTTP/1.1 (i.e., older HTTP caches did not implement
 4601    the Age header field).
 4602 
 4603 13.2.4 Expiration Calculations
 4604 
 4605    In order to decide whether a response is fresh or stale, we need to
 4606    compare its freshness lifetime to its age. The age is calculated as
 4607    described in section 13.2.3; this section describes how to calculate
 4608    the freshness lifetime, and to determine if a response has expired.
 4609    In the discussion below, the values can be represented in any form
 4610    appropriate for arithmetic operations.
 4611 
 4612    We use the term "expires_value" to denote the value of the Expires
 4613    header. We use the term "max_age_value" to denote an appropriate
 4614    value of the number of seconds carried by the "max-age" directive of
 4615    the Cache-Control header in a response (see section 14.9.3).
 4616 
 4617    The max-age directive takes priority over Expires, so if max-age is
 4618    present in a response, the calculation is simply:
 4619 
 4620       freshness_lifetime = max_age_value
 4621 
 4622    Otherwise, if Expires is present in the response, the calculation is:
 4623 
 4624       freshness_lifetime = expires_value - date_value
 4625 
 4626    Note that neither of these calculations is vulnerable to clock skew,
 4627    since all of the information comes from the origin server.
 4628 
 4629    If none of Expires, Cache-Control: max-age, or Cache-Control: s-
 4630    maxage (see section 14.9.3) appears in the response, and the response
 4631    does not include other restrictions on caching, the cache MAY compute
 4632    a freshness lifetime using a heuristic. The cache MUST attach Warning
 4633    113 to any response whose age is more than 24 hours if such warning
 4634    has not already been added.
 4635 
 4636    Also, if the response does have a Last-Modified time, the heuristic
 4637    expiration value SHOULD be no more than some fraction of the interval
 4638    since that time. A typical setting of this fraction might be 10%.
 4639 
 4640    The calculation to determine if a response has expired is quite
 4641    simple:
 4642 
 4643       response_is_fresh = (freshness_lifetime > current_age)
 4644 
 4645 
 4646 
 4647 
 4648 
 4649 
 4650 Fielding, et al.            Standards Track                    [Page 83]
 4651 
 4652 RFC 2616                        HTTP/1.1                       June 1999
 4653 
 4654 
 4655 13.2.5 Disambiguating Expiration Values
 4656 
 4657    Because expiration values are assigned optimistically, it is possible
 4658    for two caches to contain fresh values for the same resource that are
 4659    different.
 4660 
 4661    If a client performing a retrieval receives a non-first-hand response
 4662    for a request that was already fresh in its own cache, and the Date
 4663    header in its existing cache entry is newer than the Date on the new
 4664    response, then the client MAY ignore the response. If so, it MAY
 4665    retry the request with a "Cache-Control: max-age=0" directive (see
 4666    section 14.9), to force a check with the origin server.
 4667 
 4668    If a cache has two fresh responses for the same representation with
 4669    different validators, it MUST use the one with the more recent Date
 4670    header. This situation might arise because the cache is pooling
 4671    responses from other caches, or because a client has asked for a
 4672    reload or a revalidation of an apparently fresh cache entry.
 4673 
 4674 13.2.6 Disambiguating Multiple Responses
 4675 
 4676    Because a client might be receiving responses via multiple paths, so
 4677    that some responses flow through one set of caches and other
 4678    responses flow through a different set of caches, a client might
 4679    receive responses in an order different from that in which the origin
 4680    server sent them. We would like the client to use the most recently
 4681    generated response, even if older responses are still apparently
 4682    fresh.
 4683 
 4684    Neither the entity tag nor the expiration value can impose an
 4685    ordering on responses, since it is possible that a later response
 4686    intentionally carries an earlier expiration time. The Date values are
 4687    ordered to a granularity of one second.
 4688 
 4689    When a client tries to revalidate a cache entry, and the response it
 4690    receives contains a Date header that appears to be older than the one
 4691    for the existing entry, then the client SHOULD repeat the request
 4692    unconditionally, and include
 4693 
 4694        Cache-Control: max-age=0
 4695 
 4696    to force any intermediate caches to validate their copies directly
 4697    with the origin server, or
 4698 
 4699        Cache-Control: no-cache
 4700 
 4701    to force any intermediate caches to obtain a new copy from the origin
 4702    server.
 4703 
 4704 
 4705 
 4706 Fielding, et al.            Standards Track                    [Page 84]
 4707 
 4708 RFC 2616                        HTTP/1.1                       June 1999
 4709 
 4710 
 4711    If the Date values are equal, then the client MAY use either response
 4712    (or MAY, if it is being extremely prudent, request a new response).
 4713    Servers MUST NOT depend on clients being able to choose
 4714    deterministically between responses generated during the same second,
 4715    if their expiration times overlap.
 4716 
 4717 13.3 Validation Model
 4718 
 4719    When a cache has a stale entry that it would like to use as a
 4720    response to a client's request, it first has to check with the origin
 4721    server (or possibly an intermediate cache with a fresh response) to
 4722    see if its cached entry is still usable. We call this "validating"
 4723    the cache entry. Since we do not want to have to pay the overhead of
 4724    retransmitting the full response if the cached entry is good, and we
 4725    do not want to pay the overhead of an extra round trip if the cached
 4726    entry is invalid, the HTTP/1.1 protocol supports the use of
 4727    conditional methods.
 4728 
 4729    The key protocol features for supporting conditional methods are
 4730    those concerned with "cache validators." When an origin server
 4731    generates a full response, it attaches some sort of validator to it,
 4732    which is kept with the cache entry. When a client (user agent or
 4733    proxy cache) makes a conditional request for a resource for which it
 4734    has a cache entry, it includes the associated validator in the
 4735    request.
 4736 
 4737    The server then checks that validator against the current validator
 4738    for the entity, and, if they match (see section 13.3.3), it responds
 4739    with a special status code (usually, 304 (Not Modified)) and no
 4740    entity-body. Otherwise, it returns a full response (including
 4741    entity-body). Thus, we avoid transmitting the full response if the
 4742    validator matches, and we avoid an extra round trip if it does not
 4743    match.
 4744 
 4745    In HTTP/1.1, a conditional request looks exactly the same as a normal
 4746    request for the same resource, except that it carries a special
 4747    header (which includes the validator) that implicitly turns the
 4748    method (usually, GET) into a conditional.
 4749 
 4750    The protocol includes both positive and negative senses of cache-
 4751    validating conditions. That is, it is possible to request either that
 4752    a method be performed if and only if a validator matches or if and
 4753    only if no validators match.
 4754 
 4755 
 4756 
 4757 
 4758 
 4759 
 4760 
 4761 
 4762 Fielding, et al.            Standards Track                    [Page 85]
 4763 
 4764 RFC 2616                        HTTP/1.1                       June 1999
 4765 
 4766 
 4767       Note: a response that lacks a validator may still be cached, and
 4768       served from cache until it expires, unless this is explicitly
 4769       prohibited by a cache-control directive. However, a cache cannot
 4770       do a conditional retrieval if it does not have a validator for the
 4771       entity, which means it will not be refreshable after it expires.
 4772 
 4773 13.3.1 Last-Modified Dates
 4774 
 4775    The Last-Modified entity-header field value is often used as a cache
 4776    validator. In simple terms, a cache entry is considered to be valid
 4777    if the entity has not been modified since the Last-Modified value.
 4778 
 4779 13.3.2 Entity Tag Cache Validators
 4780 
 4781    The ETag response-header field value, an entity tag, provides for an
 4782    "opaque" cache validator. This might allow more reliable validation
 4783    in situations where it is inconvenient to store modification dates,
 4784    where the one-second resolution of HTTP date values is not
 4785    sufficient, or where the origin server wishes to avoid certain
 4786    paradoxes that might arise from the use of modification dates.
 4787 
 4788    Entity Tags are described in section 3.11. The headers used with
 4789    entity tags are described in sections 14.19, 14.24, 14.26 and 14.44.
 4790 
 4791 13.3.3 Weak and Strong Validators
 4792 
 4793    Since both origin servers and caches will compare two validators to
 4794    decide if they represent the same or different entities, one normally
 4795    would expect that if the entity (the entity-body or any entity-
 4796    headers) changes in any way, then the associated validator would
 4797    change as well. If this is true, then we call this validator a
 4798    "strong validator."
 4799 
 4800    However, there might be cases when a server prefers to change the
 4801    validator only on semantically significant changes, and not when
 4802    insignificant aspects of the entity change. A validator that does not
 4803    always change when the resource changes is a "weak validator."
 4804 
 4805    Entity tags are normally "strong validators," but the protocol
 4806    provides a mechanism to tag an entity tag as "weak." One can think of
 4807    a strong validator as one that changes whenever the bits of an entity
 4808    changes, while a weak value changes whenever the meaning of an entity
 4809    changes. Alternatively, one can think of a strong validator as part
 4810    of an identifier for a specific entity, while a weak validator is
 4811    part of an identifier for a set of semantically equivalent entities.
 4812 
 4813       Note: One example of a strong validator is an integer that is
 4814       incremented in stable storage every time an entity is changed.
 4815 
 4816 
 4817 
 4818 Fielding, et al.            Standards Track                    [Page 86]
 4819 
 4820 RFC 2616                        HTTP/1.1                       June 1999
 4821 
 4822 
 4823       An entity's modification time, if represented with one-second
 4824       resolution, could be a weak validator, since it is possible that
 4825       the resource might be modified twice during a single second.
 4826 
 4827       Support for weak validators is optional. However, weak validators
 4828       allow for more efficient caching of equivalent objects; for
 4829       example, a hit counter on a site is probably good enough if it is
 4830       updated every few days or weeks, and any value during that period
 4831       is likely "good enough" to be equivalent.
 4832 
 4833    A "use" of a validator is either when a client generates a request
 4834    and includes the validator in a validating header field, or when a
 4835    server compares two validators.
 4836 
 4837    Strong validators are usable in any context. Weak validators are only
 4838    usable in contexts that do not depend on exact equality of an entity.
 4839    For example, either kind is usable for a conditional GET of a full
 4840    entity. However, only a strong validator is usable for a sub-range
 4841    retrieval, since otherwise the client might end up with an internally
 4842    inconsistent entity.
 4843 
 4844    Clients MAY issue simple (non-subrange) GET requests with either weak
 4845    validators or strong validators. Clients MUST NOT use weak validators
 4846    in other forms of request.
 4847 
 4848    The only function that the HTTP/1.1 protocol defines on validators is
 4849    comparison. There are two validator comparison functions, depending
 4850    on whether the comparison context allows the use of weak validators
 4851    or not:
 4852 
 4853       - The strong comparison function: in order to be considered equal,
 4854         both validators MUST be identical in every way, and both MUST
 4855         NOT be weak.
 4856 
 4857       - The weak comparison function: in order to be considered equal,
 4858         both validators MUST be identical in every way, but either or
 4859         both of them MAY be tagged as "weak" without affecting the
 4860         result.
 4861 
 4862    An entity tag is strong unless it is explicitly tagged as weak.
 4863    Section 3.11 gives the syntax for entity tags.
 4864 
 4865    A Last-Modified time, when used as a validator in a request, is
 4866    implicitly weak unless it is possible to deduce that it is strong,
 4867    using the following rules:
 4868 
 4869       - The validator is being compared by an origin server to the
 4870         actual current validator for the entity and,
 4871 
 4872 
 4873 
 4874 Fielding, et al.            Standards Track                    [Page 87]
 4875 
 4876 RFC 2616                        HTTP/1.1                       June 1999
 4877 
 4878 
 4879       - That origin server reliably knows that the associated entity did
 4880         not change twice during the second covered by the presented
 4881         validator.
 4882 
 4883    or
 4884 
 4885       - The validator is about to be used by a client in an If-
 4886         Modified-Since or If-Unmodified-Since header, because the client
 4887         has a cache entry for the associated entity, and
 4888 
 4889       - That cache entry includes a Date value, which gives the time
 4890         when the origin server sent the original response, and
 4891 
 4892       - The presented Last-Modified time is at least 60 seconds before
 4893         the Date value.
 4894 
 4895    or
 4896 
 4897       - The validator is being compared by an intermediate cache to the
 4898         validator stored in its cache entry for the entity, and
 4899 
 4900       - That cache entry includes a Date value, which gives the time
 4901         when the origin server sent the original response, and
 4902 
 4903       - The presented Last-Modified time is at least 60 seconds before
 4904         the Date value.
 4905 
 4906    This method relies on the fact that if two different responses were
 4907    sent by the origin server during the same second, but both had the
 4908    same Last-Modified time, then at least one of those responses would
 4909    have a Date value equal to its Last-Modified time. The arbitrary 60-
 4910    second limit guards against the possibility that the Date and Last-
 4911    Modified values are generated from different clocks, or at somewhat
 4912    different times during the preparation of the response. An
 4913    implementation MAY use a value larger than 60 seconds, if it is
 4914    believed that 60 seconds is too short.
 4915 
 4916    If a client wishes to perform a sub-range retrieval on a value for
 4917    which it has only a Last-Modified time and no opaque validator, it
 4918    MAY do this only if the Last-Modified time is strong in the sense
 4919    described here.
 4920 
 4921    A cache or origin server receiving a conditional request, other than
 4922    a full-body GET request, MUST use the strong comparison function to
 4923    evaluate the condition.
 4924 
 4925    These rules allow HTTP/1.1 caches and clients to safely perform sub-
 4926    range retrievals on values that have been obtained from HTTP/1.0
 4927 
 4928 
 4929 
 4930 Fielding, et al.            Standards Track                    [Page 88]
 4931 
 4932 RFC 2616                        HTTP/1.1                       June 1999
 4933 
 4934 
 4935    servers.
 4936 
 4937 13.3.4 Rules for When to Use Entity Tags and Last-Modified Dates
 4938 
 4939    We adopt a set of rules and recommendations for origin servers,
 4940    clients, and caches regarding when various validator types ought to
 4941    be used, and for what purposes.
 4942 
 4943    HTTP/1.1 origin servers:
 4944 
 4945       - SHOULD send an entity tag validator unless it is not feasible to
 4946         generate one.
 4947 
 4948       - MAY send a weak entity tag instead of a strong entity tag, if
 4949         performance considerations support the use of weak entity tags,
 4950         or if it is unfeasible to send a strong entity tag.
 4951 
 4952       - SHOULD send a Last-Modified value if it is feasible to send one,
 4953         unless the risk of a breakdown in semantic transparency that
 4954         could result from using this date in an If-Modified-Since header
 4955         would lead to serious problems.
 4956 
 4957    In other words, the preferred behavior for an HTTP/1.1 origin server
 4958    is to send both a strong entity tag and a Last-Modified value.
 4959 
 4960    In order to be legal, a strong entity tag MUST change whenever the
 4961    associated entity value changes in any way. A weak entity tag SHOULD
 4962    change whenever the associated entity changes in a semantically
 4963    significant way.
 4964 
 4965       Note: in order to provide semantically transparent caching, an
 4966       origin server must avoid reusing a specific strong entity tag
 4967       value for two different entities, or reusing a specific weak
 4968       entity tag value for two semantically different entities. Cache
 4969       entries might persist for arbitrarily long periods, regardless of
 4970       expiration times, so it might be inappropriate to expect that a
 4971       cache will never again attempt to validate an entry using a
 4972       validator that it obtained at some point in the past.
 4973 
 4974    HTTP/1.1 clients:
 4975 
 4976       - If an entity tag has been provided by the origin server, MUST
 4977         use that entity tag in any cache-conditional request (using If-
 4978         Match or If-None-Match).
 4979 
 4980       - If only a Last-Modified value has been provided by the origin
 4981         server, SHOULD use that value in non-subrange cache-conditional
 4982         requests (using If-Modified-Since).
 4983 
 4984 
 4985 
 4986 Fielding, et al.            Standards Track                    [Page 89]
 4987 
 4988 RFC 2616                        HTTP/1.1                       June 1999
 4989 
 4990 
 4991       - If only a Last-Modified value has been provided by an HTTP/1.0
 4992         origin server, MAY use that value in subrange cache-conditional
 4993         requests (using If-Unmodified-Since:). The user agent SHOULD
 4994         provide a way to disable this, in case of difficulty.
 4995 
 4996       - If both an entity tag and a Last-Modified value have been
 4997         provided by the origin server, SHOULD use both validators in
 4998         cache-conditional requests. This allows both HTTP/1.0 and
 4999         HTTP/1.1 caches to respond appropriately.
 5000 
 5001    An HTTP/1.1 origin server, upon receiving a conditional request that
 5002    includes both a Last-Modified date (e.g., in an If-Modified-Since or
 5003    If-Unmodified-Since header field) and one or more entity tags (e.g.,
 5004    in an If-Match, If-None-Match, or If-Range header field) as cache
 5005    validators, MUST NOT return a response status of 304 (Not Modified)
 5006    unless doing so is consistent with all of the conditional header
 5007    fields in the request.
 5008 
 5009    An HTTP/1.1 caching proxy, upon receiving a conditional request that
 5010    includes both a Last-Modified date and one or more entity tags as
 5011    cache validators, MUST NOT return a locally cached response to the
 5012    client unless that cached response is consistent with all of the
 5013    conditional header fields in the request.
 5014 
 5015       Note: The general principle behind these rules is that HTTP/1.1
 5016       servers and clients should transmit as much non-redundant
 5017       information as is available in their responses and requests.
 5018       HTTP/1.1 systems receiving this information will make the most
 5019       conservative assumptions about the validators they receive.
 5020 
 5021       HTTP/1.0 clients and caches will ignore entity tags. Generally,
 5022       last-modified values received or used by these systems will
 5023       support transparent and efficient caching, and so HTTP/1.1 origin
 5024       servers should provide Last-Modified values. In those rare cases
 5025       where the use of a Last-Modified value as a validator by an
 5026       HTTP/1.0 system could result in a serious problem, then HTTP/1.1
 5027       origin servers should not provide one.
 5028 
 5029 13.3.5 Non-validating Conditionals
 5030 
 5031    The principle behind entity tags is that only the service author
 5032    knows the semantics of a resource well enough to select an
 5033    appropriate cache validation mechanism, and the specification of any
 5034    validator comparison function more complex than byte-equality would
 5035    open up a can of worms. Thus, comparisons of any other headers
 5036    (except Last-Modified, for compatibility with HTTP/1.0) are never
 5037    used for purposes of validating a cache entry.
 5038 
 5039 
 5040 
 5041 
 5042 Fielding, et al.            Standards Track                    [Page 90]
 5043 
 5044 RFC 2616                        HTTP/1.1                       June 1999
 5045 
 5046 
 5047 13.4 Response Cacheability
 5048 
 5049    Unless specifically constrained by a cache-control (section 14.9)
 5050    directive, a caching system MAY always store a successful response
 5051    (see section 13.8) as a cache entry, MAY return it without validation
 5052    if it is fresh, and MAY return it after successful validation. If
 5053    there is neither a cache validator nor an explicit expiration time
 5054    associated with a response, we do not expect it to be cached, but
 5055    certain caches MAY violate this expectation (for example, when little
 5056    or no network connectivity is available). A client can usually detect
 5057    that such a response was taken from a cache by comparing the Date
 5058    header to the current time.
 5059 
 5060       Note: some HTTP/1.0 caches are known to violate this expectation
 5061       without providing any Warning.
 5062 
 5063    However, in some cases it might be inappropriate for a cache to
 5064    retain an entity, or to return it in response to a subsequent
 5065    request. This might be because absolute semantic transparency is
 5066    deemed necessary by the service author, or because of security or
 5067    privacy considerations. Certain cache-control directives are
 5068    therefore provided so that the server can indicate that certain
 5069    resource entities, or portions thereof, are not to be cached
 5070    regardless of other considerations.
 5071 
 5072    Note that section 14.8 normally prevents a shared cache from saving
 5073    and returning a response to a previous request if that request
 5074    included an Authorization header.
 5075 
 5076    A response received with a status code of 200, 203, 206, 300, 301 or
 5077    410 MAY be stored by a cache and used in reply to a subsequent
 5078    request, subject to the expiration mechanism, unless a cache-control
 5079    directive prohibits caching. However, a cache that does not support
 5080    the Range and Content-Range headers MUST NOT cache 206 (Partial
 5081    Content) responses.
 5082 
 5083    A response received with any other status code (e.g. status codes 302
 5084    and 307) MUST NOT be returned in a reply to a subsequent request
 5085    unless there are cache-control directives or another header(s) that
 5086    explicitly allow it. For example, these include the following: an
 5087    Expires header (section 14.21); a "max-age", "s-maxage",  "must-
 5088    revalidate", "proxy-revalidate", "public" or "private" cache-control
 5089    directive (section 14.9).
 5090 
 5091 
 5092 
 5093 
 5094 
 5095 
 5096 
 5097 
 5098 Fielding, et al.            Standards Track                    [Page 91]
 5099 
 5100 RFC 2616                        HTTP/1.1                       June 1999
 5101 
 5102 
 5103 13.5 Constructing Responses From Caches
 5104 
 5105    The purpose of an HTTP cache is to store information received in
 5106    response to requests for use in responding to future requests. In
 5107    many cases, a cache simply returns the appropriate parts of a
 5108    response to the requester. However, if the cache holds a cache entry
 5109    based on a previous response, it might have to combine parts of a new
 5110    response with what is held in the cache entry.
 5111 
 5112 13.5.1 End-to-end and Hop-by-hop Headers
 5113 
 5114    For the purpose of defining the behavior of caches and non-caching
 5115    proxies, we divide HTTP headers into two categories:
 5116 
 5117       - End-to-end headers, which are  transmitted to the ultimate
 5118         recipient of a request or response. End-to-end headers in
 5119         responses MUST be stored as part of a cache entry and MUST be
 5120         transmitted in any response formed from a cache entry.
 5121 
 5122       - Hop-by-hop headers, which are meaningful only for a single
 5123         transport-level connection, and are not stored by caches or
 5124         forwarded by proxies.
 5125 
 5126    The following HTTP/1.1 headers are hop-by-hop headers:
 5127 
 5128       - Connection
 5129       - Keep-Alive
 5130       - Proxy-Authenticate
 5131       - Proxy-Authorization
 5132       - TE
 5133       - Trailers
 5134       - Transfer-Encoding
 5135       - Upgrade
 5136 
 5137    All other headers defined by HTTP/1.1 are end-to-end headers.
 5138 
 5139    Other hop-by-hop headers MUST be listed in a Connection header,
 5140    (section 14.10) to be introduced into HTTP/1.1 (or later).
 5141 
 5142 13.5.2 Non-modifiable Headers
 5143 
 5144    Some features of the HTTP/1.1 protocol, such as Digest
 5145    Authentication, depend on the value of certain end-to-end headers. A
 5146    transparent proxy SHOULD NOT modify an end-to-end header unless the
 5147    definition of that header requires or specifically allows that.
 5148 
 5149 
 5150 
 5151 
 5152 
 5153 
 5154 Fielding, et al.            Standards Track                    [Page 92]
 5155 
 5156 RFC 2616                        HTTP/1.1                       June 1999
 5157 
 5158 
 5159    A transparent proxy MUST NOT modify any of the following fields in a
 5160    request or response, and it MUST NOT add any of these fields if not
 5161    already present:
 5162 
 5163       - Content-Location
 5164 
 5165       - Content-MD5
 5166 
 5167       - ETag
 5168 
 5169       - Last-Modified
 5170 
 5171    A transparent proxy MUST NOT modify any of the following fields in a
 5172    response:
 5173 
 5174       - Expires
 5175 
 5176    but it MAY add any of these fields if not already present. If an
 5177    Expires header is added, it MUST be given a field-value identical to
 5178    that of the Date header in that response.
 5179 
 5180    A  proxy MUST NOT modify or add any of the following fields in a
 5181    message that contains the no-transform cache-control directive, or in
 5182    any request:
 5183 
 5184       - Content-Encoding
 5185 
 5186       - Content-Range
 5187 
 5188       - Content-Type
 5189 
 5190    A non-transparent proxy MAY modify or add these fields to a message
 5191    that does not include no-transform, but if it does so, it MUST add a
 5192    Warning 214 (Transformation applied) if one does not already appear
 5193    in the message (see section 14.46).
 5194 
 5195       Warning: unnecessary modification of end-to-end headers might
 5196       cause authentication failures if stronger authentication
 5197       mechanisms are introduced in later versions of HTTP. Such
 5198       authentication mechanisms MAY rely on the values of header fields
 5199       not listed here.
 5200 
 5201    The Content-Length field of a request or response is added or deleted
 5202    according to the rules in section 4.4. A transparent proxy MUST
 5203    preserve the entity-length (section 7.2.2) of the entity-body,
 5204    although it MAY change the transfer-length (section 4.4).
 5205 
 5206 
 5207 
 5208 
 5209 
 5210 Fielding, et al.            Standards Track                    [Page 93]
 5211 
 5212 RFC 2616                        HTTP/1.1                       June 1999
 5213 
 5214 
 5215 13.5.3 Combining Headers
 5216 
 5217    When a cache makes a validating request to a server, and the server
 5218    provides a 304 (Not Modified) response or a 206 (Partial Content)
 5219    response, the cache then constructs a response to send to the
 5220    requesting client.
 5221 
 5222    If the status code is 304 (Not Modified), the cache uses the entity-
 5223    body stored in the cache entry as the entity-body of this outgoing
 5224    response. If the status code is 206 (Partial Content) and the ETag or
 5225    Last-Modified headers match exactly, the cache MAY combine the
 5226    contents stored in the cache entry with the new contents received in
 5227    the response and use the result as the entity-body of this outgoing
 5228    response, (see 13.5.4).
 5229 
 5230    The end-to-end headers stored in the cache entry are used for the
 5231    constructed response, except that
 5232 
 5233       - any stored Warning headers with warn-code 1xx (see section
 5234         14.46) MUST be deleted from the cache entry and the forwarded
 5235         response.
 5236 
 5237       - any stored Warning headers with warn-code 2xx MUST be retained
 5238         in the cache entry and the forwarded response.
 5239 
 5240       - any end-to-end headers provided in the 304 or 206 response MUST
 5241         replace the corresponding headers from the cache entry.
 5242 
 5243    Unless the cache decides to remove the cache entry, it MUST also
 5244    replace the end-to-end headers stored with the cache entry with
 5245    corresponding headers received in the incoming response, except for
 5246    Warning headers as described immediately above. If a header field-
 5247    name in the incoming response matches more than one header in the
 5248    cache entry, all such old headers MUST be replaced.
 5249 
 5250    In other words, the set of end-to-end headers received in the
 5251    incoming response overrides all corresponding end-to-end headers
 5252    stored with the cache entry (except for stored Warning headers with
 5253    warn-code 1xx, which are deleted even if not overridden).
 5254 
 5255       Note: this rule allows an origin server to use a 304 (Not
 5256       Modified) or a 206 (Partial Content) response to update any header
 5257       associated with a previous response for the same entity or sub-
 5258       ranges thereof, although it might not always be meaningful or
 5259       correct to do so. This rule does not allow an origin server to use
 5260       a 304 (Not Modified) or a 206 (Partial Content) response to
 5261       entirely delete a header that it had provided with a previous
 5262       response.
 5263 
 5264 
 5265 
 5266 Fielding, et al.            Standards Track                    [Page 94]
 5267 
 5268 RFC 2616                        HTTP/1.1                       June 1999
 5269 
 5270 
 5271 13.5.4 Combining Byte Ranges
 5272 
 5273    A response might transfer only a subrange of the bytes of an entity-
 5274    body, either because the request included one or more Range
 5275    specifications, or because a connection was broken prematurely. After
 5276    several such transfers, a cache might have received several ranges of
 5277    the same entity-body.
 5278 
 5279    If a cache has a stored non-empty set of subranges for an entity, and
 5280    an incoming response transfers another subrange, the cache MAY
 5281    combine the new subrange with the existing set if both the following
 5282    conditions are met:
 5283 
 5284       - Both the incoming response and the cache entry have a cache
 5285         validator.
 5286 
 5287       - The two cache validators match using the strong comparison
 5288         function (see section 13.3.3).
 5289 
 5290    If either requirement is not met, the cache MUST use only the most
 5291    recent partial response (based on the Date values transmitted with
 5292    every response, and using the incoming response if these values are
 5293    equal or missing), and MUST discard the other partial information.
 5294 
 5295 13.6 Caching Negotiated Responses
 5296 
 5297    Use of server-driven content negotiation (section 12.1), as indicated
 5298    by the presence of a Vary header field in a response, alters the
 5299    conditions and procedure by which a cache can use the response for
 5300    subsequent requests. See section 14.44 for use of the Vary header
 5301    field by servers.
 5302 
 5303    A server SHOULD use the Vary header field to inform a cache of what
 5304    request-header fields were used to select among multiple
 5305    representations of a cacheable response subject to server-driven
 5306    negotiation. The set of header fields named by the Vary field value
 5307    is known as the "selecting" request-headers.
 5308 
 5309    When the cache receives a subsequent request whose Request-URI
 5310    specifies one or more cache entries including a Vary header field,
 5311    the cache MUST NOT use such a cache entry to construct a response to
 5312    the new request unless all of the selecting request-headers present
 5313    in the new request match the corresponding stored request-headers in
 5314    the original request.
 5315 
 5316    The selecting request-headers from two requests are defined to match
 5317    if and only if the selecting request-headers in the first request can
 5318    be transformed to the selecting request-headers in the second request
 5319 
 5320 
 5321 
 5322 Fielding, et al.            Standards Track                    [Page 95]
 5323 
 5324 RFC 2616                        HTTP/1.1                       June 1999
 5325 
 5326 
 5327    by adding or removing linear white space (LWS) at places where this
 5328    is allowed by the corresponding BNF, and/or combining multiple
 5329    message-header fields with the same field name following the rules
 5330    about message headers in section 4.2.
 5331 
 5332    A Vary header field-value of "*" always fails to match and subsequent
 5333    requests on that resource can only be properly interpreted by the
 5334    origin server.
 5335 
 5336    If the selecting request header fields for the cached entry do not
 5337    match the selecting request header fields of the new request, then
 5338    the cache MUST NOT use a cached entry to satisfy the request unless
 5339    it first relays the new request to the origin server in a conditional
 5340    request and the server responds with 304 (Not Modified), including an
 5341    entity tag or Content-Location that indicates the entity to be used.
 5342 
 5343    If an entity tag was assigned to a cached representation, the
 5344    forwarded request SHOULD be conditional and include the entity tags
 5345    in an If-None-Match header field from all its cache entries for the
 5346    resource. This conveys to the server the set of entities currently
 5347    held by the cache, so that if any one of these entities matches the
 5348    requested entity, the server can use the ETag header field in its 304
 5349    (Not Modified) response to tell the cache which entry is appropriate.
 5350    If the entity-tag of the new response matches that of an existing
 5351    entry, the new response SHOULD be used to update the header fields of
 5352    the existing entry, and the result MUST be returned to the client.
 5353 
 5354    If any of the existing cache entries contains only partial content
 5355    for the associated entity, its entity-tag SHOULD NOT be included in
 5356    the If-None-Match header field unless the request is for a range that
 5357    would be fully satisfied by that entry.
 5358 
 5359    If a cache receives a successful response whose Content-Location
 5360    field matches that of an existing cache entry for the same Request-
 5361    ]URI, whose entity-tag differs from that of the existing entry, and
 5362    whose Date is more recent than that of the existing entry, the
 5363    existing entry SHOULD NOT be returned in response to future requests
 5364    and SHOULD be deleted from the cache.
 5365 
 5366 13.7 Shared and Non-Shared Caches
 5367 
 5368    For reasons of security and privacy, it is necessary to make a
 5369    distinction between "shared" and "non-shared" caches. A non-shared
 5370    cache is one that is accessible only to a single user. Accessibility
 5371    in this case SHOULD be enforced by appropriate security mechanisms.
 5372    All other caches are considered to be "shared." Other sections of
 5373 
 5374 
 5375 
 5376 
 5377 
 5378 Fielding, et al.            Standards Track                    [Page 96]
 5379 
 5380 RFC 2616                        HTTP/1.1                       June 1999
 5381 
 5382 
 5383    this specification place certain constraints on the operation of
 5384    shared caches in order to prevent loss of privacy or failure of
 5385    access controls.
 5386 
 5387 13.8 Errors or Incomplete Response Cache Behavior
 5388 
 5389    A cache that receives an incomplete response (for example, with fewer
 5390    bytes of data than specified in a Content-Length header) MAY store
 5391    the response. However, the cache MUST treat this as a partial
 5392    response. Partial responses MAY be combined as described in section
 5393    13.5.4; the result might be a full response or might still be
 5394    partial. A cache MUST NOT return a partial response to a client
 5395    without explicitly marking it as such, using the 206 (Partial
 5396    Content) status code. A cache MUST NOT return a partial response
 5397    using a status code of 200 (OK).
 5398 
 5399    If a cache receives a 5xx response while attempting to revalidate an
 5400    entry, it MAY either forward this response to the requesting client,
 5401    or act as if the server failed to respond. In the latter case, it MAY
 5402    return a previously received response unless the cached entry
 5403    includes the "must-revalidate" cache-control directive (see section
 5404    14.9).
 5405 
 5406 13.9 Side Effects of GET and HEAD
 5407 
 5408    Unless the origin server explicitly prohibits the caching of their
 5409    responses, the application of GET and HEAD methods to any resources
 5410    SHOULD NOT have side effects that would lead to erroneous behavior if
 5411    these responses are taken from a cache. They MAY still have side
 5412    effects, but a cache is not required to consider such side effects in
 5413    its caching decisions. Caches are always expected to observe an
 5414    origin server's explicit restrictions on caching.
 5415 
 5416    We note one exception to this rule: since some applications have
 5417    traditionally used GETs and HEADs with query URLs (those containing a
 5418    "?" in the rel_path part) to perform operations with significant side
 5419    effects, caches MUST NOT treat responses to such URIs as fresh unless
 5420    the server provides an explicit expiration time. This specifically
 5421    means that responses from HTTP/1.0 servers for such URIs SHOULD NOT
 5422    be taken from a cache. See section 9.1.1 for related information.
 5423 
 5424 13.10 Invalidation After Updates or Deletions
 5425 
 5426    The effect of certain methods performed on a resource at the origin
 5427    server might cause one or more existing cache entries to become non-
 5428    transparently invalid. That is, although they might continue to be
 5429    "fresh," they do not accurately reflect what the origin server would
 5430    return for a new request on that resource.
 5431 
 5432 
 5433 
 5434 Fielding, et al.            Standards Track                    [Page 97]
 5435 
 5436 RFC 2616                        HTTP/1.1                       June 1999
 5437 
 5438 
 5439    There is no way for the HTTP protocol to guarantee that all such
 5440    cache entries are marked invalid. For example, the request that
 5441    caused the change at the origin server might not have gone through
 5442    the proxy where a cache entry is stored. However, several rules help
 5443    reduce the likelihood of erroneous behavior.
 5444 
 5445    In this section, the phrase "invalidate an entity" means that the
 5446    cache will either remove all instances of that entity from its
 5447    storage, or will mark these as "invalid" and in need of a mandatory
 5448    revalidation before they can be returned in response to a subsequent
 5449    request.
 5450 
 5451    Some HTTP methods MUST cause a cache to invalidate an entity. This is
 5452    either the entity referred to by the Request-URI, or by the Location
 5453    or Content-Location headers (if present). These methods are:
 5454 
 5455       - PUT
 5456 
 5457       - DELETE
 5458 
 5459       - POST
 5460 
 5461    In order to prevent denial of service attacks, an invalidation based
 5462    on the URI in a Location or Content-Location header MUST only be
 5463    performed if the host part is the same as in the Request-URI.
 5464 
 5465    A cache that passes through requests for methods it does not
 5466    understand SHOULD invalidate any entities referred to by the
 5467    Request-URI.
 5468 
 5469 13.11 Write-Through Mandatory
 5470 
 5471    All methods that might be expected to cause modifications to the
 5472    origin server's resources MUST be written through to the origin
 5473    server. This currently includes all methods except for GET and HEAD.
 5474    A cache MUST NOT reply to such a request from a client before having
 5475    transmitted the request to the inbound server, and having received a
 5476    corresponding response from the inbound server. This does not prevent
 5477    a proxy cache from sending a 100 (Continue) response before the
 5478    inbound server has sent its final reply.
 5479 
 5480    The alternative (known as "write-back" or "copy-back" caching) is not
 5481    allowed in HTTP/1.1, due to the difficulty of providing consistent
 5482    updates and the problems arising from server, cache, or network
 5483    failure prior to write-back.
 5484 
 5485 
 5486 
 5487 
 5488 
 5489 
 5490 Fielding, et al.            Standards Track                    [Page 98]
 5491 
 5492 RFC 2616                        HTTP/1.1                       June 1999
 5493 
 5494 
 5495 13.12 Cache Replacement
 5496 
 5497    If a new cacheable (see sections 14.9.2, 13.2.5, 13.2.6 and 13.8)
 5498    response is received from a resource while any existing responses for
 5499    the same resource are cached, the cache SHOULD use the new response
 5500    to reply to the current request. It MAY insert it into cache storage
 5501    and MAY, if it meets all other requirements, use it to respond to any
 5502    future requests that would previously have caused the old response to
 5503    be returned. If it inserts the new response into cache storage  the
 5504    rules in section 13.5.3 apply.
 5505 
 5506       Note: a new response that has an older Date header value than
 5507       existing cached responses is not cacheable.
 5508 
 5509 13.13 History Lists
 5510 
 5511    User agents often have history mechanisms, such as "Back" buttons and
 5512    history lists, which can be used to redisplay an entity retrieved
 5513    earlier in a session.
 5514 
 5515    History mechanisms and caches are different. In particular history
 5516    mechanisms SHOULD NOT try to show a semantically transparent view of
 5517    the current state of a resource. Rather, a history mechanism is meant
 5518    to show exactly what the user saw at the time when the resource was
 5519    retrieved.
 5520 
 5521    By default, an expiration time does not apply to history mechanisms.
 5522    If the entity is still in storage, a history mechanism SHOULD display
 5523    it even if the entity has expired, unless the user has specifically
 5524    configured the agent to refresh expired history documents.
 5525 
 5526    This is not to be construed to prohibit the history mechanism from
 5527    telling the user that a view might be stale.
 5528 
 5529       Note: if history list mechanisms unnecessarily prevent users from
 5530       viewing stale resources, this will tend to force service authors
 5531       to avoid using HTTP expiration controls and cache controls when
 5532       they would otherwise like to. Service authors may consider it
 5533       important that users not be presented with error messages or
 5534       warning messages when they use navigation controls (such as BACK)
 5535       to view previously fetched resources. Even though sometimes such
 5536       resources ought not to cached, or ought to expire quickly, user
 5537       interface considerations may force service authors to resort to
 5538       other means of preventing caching (e.g. "once-only" URLs) in order
 5539       not to suffer the effects of improperly functioning history
 5540       mechanisms.
 5541 
 5542 
 5543 
 5544 
 5545 
 5546 Fielding, et al.            Standards Track                    [Page 99]
 5547 
 5548 RFC 2616                        HTTP/1.1                       June 1999
 5549 
 5550 
 5551 14 Header Field Definitions
 5552 
 5553    This section defines the syntax and semantics of all standard
 5554    HTTP/1.1 header fields. For entity-header fields, both sender and
 5555    recipient refer to either the client or the server, depending on who
 5556    sends and who receives the entity.
 5557 
 5558 14.1 Accept
 5559 
 5560    The Accept request-header field can be used to specify certain media
 5561    types which are acceptable for the response. Accept headers can be
 5562    used to indicate that the request is specifically limited to a small
 5563    set of desired types, as in the case of a request for an in-line
 5564    image.
 5565 
 5566        Accept         = "Accept" ":"
 5567                         #( media-range [ accept-params ] )
 5568 
 5569        media-range    = ( "*/*"
 5570                         | ( type "/" "*" )
 5571                         | ( type "/" subtype )
 5572                         ) *( ";" parameter )
 5573        accept-params  = ";" "q" "=" qvalue *( accept-extension )
 5574        accept-extension = ";" token [ "=" ( token | quoted-string ) ]
 5575 
 5576    The asterisk "*" character is used to group media types into ranges,
 5577    with "*/*" indicating all media types and "type/*" indicating all
 5578    subtypes of that type. The media-range MAY include media type
 5579    parameters that are applicable to that range.
 5580 
 5581    Each media-range MAY be followed by one or more accept-params,
 5582    beginning with the "q" parameter for indicating a relative quality
 5583    factor. The first "q" parameter (if any) separates the media-range
 5584    parameter(s) from the accept-params. Quality factors allow the user
 5585    or user agent to indicate the relative degree of preference for that
 5586    media-range, using the qvalue scale from 0 to 1 (section 3.9). The
 5587    default value is q=1.
 5588 
 5589       Note: Use of the "q" parameter name to separate media type
 5590       parameters from Accept extension parameters is due to historical
 5591       practice. Although this prevents any media type parameter named
 5592       "q" from being used with a media range, such an event is believed
 5593       to be unlikely given the lack of any "q" parameters in the IANA
 5594       media type registry and the rare usage of any media type
 5595       parameters in Accept. Future media types are discouraged from
 5596       registering any parameter named "q".
 5597 
 5598 
 5599 
 5600 
 5601 
 5602 Fielding, et al.            Standards Track                   [Page 100]
 5603 
 5604 RFC 2616                        HTTP/1.1                       June 1999
 5605 
 5606 
 5607    The example
 5608 
 5609        Accept: audio/*; q=0.2, audio/basic
 5610 
 5611    SHOULD be interpreted as "I prefer audio/basic, but send me any audio
 5612    type if it is the best available after an 80% mark-down in quality."
 5613 
 5614    If no Accept header field is present, then it is assumed that the
 5615    client accepts all media types. If an Accept header field is present,
 5616    and if the server cannot send a response which is acceptable
 5617    according to the combined Accept field value, then the server SHOULD
 5618    send a 406 (not acceptable) response.
 5619 
 5620    A more elaborate example is
 5621 
 5622        Accept: text/plain; q=0.5, text/html,
 5623                text/x-dvi; q=0.8, text/x-c
 5624 
 5625    Verbally, this would be interpreted as "text/html and text/x-c are
 5626    the preferred media types, but if they do not exist, then send the
 5627    text/x-dvi entity, and if that does not exist, send the text/plain
 5628    entity."
 5629 
 5630    Media ranges can be overridden by more specific media ranges or
 5631    specific media types. If more than one media range applies to a given
 5632    type, the most specific reference has precedence. For example,
 5633 
 5634        Accept: text/*, text/html, text/html;level=1, */*
 5635 
 5636    have the following precedence:
 5637 
 5638        1) text/html;level=1
 5639        2) text/html
 5640        3) text/*
 5641        4) */*
 5642 
 5643    The media type quality factor associated with a given type is
 5644    determined by finding the media range with the highest precedence
 5645    which matches that type. For example,
 5646 
 5647        Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,
 5648                text/html;level=2;q=0.4, */*;q=0.5
 5649 
 5650    would cause the following values to be associated:
 5651 
 5652        text/html;level=1         = 1
 5653        text/html                 = 0.7
 5654        text/plain                = 0.3
 5655 
 5656 
 5657 
 5658 Fielding, et al.            Standards Track                   [Page 101]
 5659 
 5660 RFC 2616                        HTTP/1.1                       June 1999
 5661 
 5662 
 5663        image/jpeg                = 0.5
 5664        text/html;level=2         = 0.4
 5665        text/html;level=3         = 0.7
 5666 
 5667       Note: A user agent might be provided with a default set of quality
 5668       values for certain media ranges. However, unless the user agent is
 5669       a closed system which cannot interact with other rendering agents,
 5670       this default set ought to be configurable by the user.
 5671 
 5672 14.2 Accept-Charset
 5673 
 5674    The Accept-Charset request-header field can be used to indicate what
 5675    character sets are acceptable for the response. This field allows
 5676    clients capable of understanding more comprehensive or special-
 5677    purpose character sets to signal that capability to a server which is
 5678    capable of representing documents in those character sets.
 5679 
 5680       Accept-Charset = "Accept-Charset" ":"
 5681               1#( ( charset | "*" )[ ";" "q" "=" qvalue ] )
 5682 
 5683 
 5684    Character set values are described in section 3.4. Each charset MAY
 5685    be given an associated quality value which represents the user's
 5686    preference for that charset. The default value is q=1. An example is
 5687 
 5688       Accept-Charset: iso-8859-5, unicode-1-1;q=0.8
 5689 
 5690    The special value "*", if present in the Accept-Charset field,
 5691    matches every character set (including ISO-8859-1) which is not
 5692    mentioned elsewhere in the Accept-Charset field. If no "*" is present
 5693    in an Accept-Charset field, then all character sets not explicitly
 5694    mentioned get a quality value of 0, except for ISO-8859-1, which gets
 5695    a quality value of 1 if not explicitly mentioned.
 5696 
 5697    If no Accept-Charset header is present, the default is that any
 5698    character set is acceptable. If an Accept-Charset header is present,
 5699    and if the server cannot send a response which is acceptable
 5700    according to the Accept-Charset header, then the server SHOULD send
 5701    an error response with the 406 (not acceptable) status code, though
 5702    the sending of an unacceptable response is also allowed.
 5703 
 5704 14.3 Accept-Encoding
 5705 
 5706    The Accept-Encoding request-header field is similar to Accept, but
 5707    restricts the content-codings (section 3.5) that are acceptable in
 5708    the response.
 5709 
 5710        Accept-Encoding  = "Accept-Encoding" ":"
 5711 
 5712 
 5713 
 5714 Fielding, et al.            Standards Track                   [Page 102]
 5715 
 5716 RFC 2616                        HTTP/1.1                       June 1999
 5717 
 5718 
 5719                           1#( codings [ ";" "q" "=" qvalue ] )
 5720        codings          = ( content-coding | "*" )
 5721 
 5722    Examples of its use are:
 5723 
 5724        Accept-Encoding: compress, gzip
 5725        Accept-Encoding:
 5726        Accept-Encoding: *
 5727        Accept-Encoding: compress;q=0.5, gzip;q=1.0
 5728        Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0
 5729 
 5730    A server tests whether a content-coding is acceptable, according to
 5731    an Accept-Encoding field, using these rules:
 5732 
 5733       1. If the content-coding is one of the content-codings listed in
 5734          the Accept-Encoding field, then it is acceptable, unless it is
 5735          accompanied by a qvalue of 0. (As defined in section 3.9, a
 5736          qvalue of 0 means "not acceptable.")
 5737 
 5738       2. The special "*" symbol in an Accept-Encoding field matches any
 5739          available content-coding not explicitly listed in the header
 5740          field.
 5741 
 5742       3. If multiple content-codings are acceptable, then the acceptable
 5743          content-coding with the highest non-zero qvalue is preferred.
 5744 
 5745       4. The "identity" content-coding is always acceptable, unless
 5746          specifically refused because the Accept-Encoding field includes
 5747          "identity;q=0", or because the field includes "*;q=0" and does
 5748          not explicitly include the "identity" content-coding. If the
 5749          Accept-Encoding field-value is empty, then only the "identity"
 5750          encoding is acceptable.
 5751 
 5752    If an Accept-Encoding field is present in a request, and if the
 5753    server cannot send a response which is acceptable according to the
 5754    Accept-Encoding header, then the server SHOULD send an error response
 5755    with the 406 (Not Acceptable) status code.
 5756 
 5757    If no Accept-Encoding field is present in a request, the server MAY
 5758    assume that the client will accept any content coding. In this case,
 5759    if "identity" is one of the available content-codings, then the
 5760    server SHOULD use the "identity" content-coding, unless it has
 5761    additional information that a different content-coding is meaningful
 5762    to the client.
 5763 
 5764       Note: If the request does not include an Accept-Encoding field,
 5765       and if the "identity" content-coding is unavailable, then
 5766       content-codings commonly understood by HTTP/1.0 clients (i.e.,
 5767 
 5768 
 5769 
 5770 Fielding, et al.            Standards Track                   [Page 103]
 5771 
 5772 RFC 2616                        HTTP/1.1                       June 1999
 5773 
 5774 
 5775       "gzip" and "compress") are preferred; some older clients
 5776       improperly display messages sent with other content-codings.  The
 5777       server might also make this decision based on information about
 5778       the particular user-agent or client.
 5779 
 5780       Note: Most HTTP/1.0 applications do not recognize or obey qvalues
 5781       associated with content-codings. This means that qvalues will not
 5782       work and are not permitted with x-gzip or x-compress.
 5783 
 5784 14.4 Accept-Language
 5785 
 5786    The Accept-Language request-header field is similar to Accept, but
 5787    restricts the set of natural languages that are preferred as a
 5788    response to the request. Language tags are defined in section 3.10.
 5789 
 5790        Accept-Language = "Accept-Language" ":"
 5791                          1#( language-range [ ";" "q" "=" qvalue ] )
 5792        language-range  = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) | "*" )
 5793 
 5794    Each language-range MAY be given an associated quality value which
 5795    represents an estimate of the user's preference for the languages
 5796    specified by that range. The quality value defaults to "q=1". For
 5797    example,
 5798 
 5799        Accept-Language: da, en-gb;q=0.8, en;q=0.7
 5800 
 5801    would mean: "I prefer Danish, but will accept British English and
 5802    other types of English." A language-range matches a language-tag if
 5803    it exactly equals the tag, or if it exactly equals a prefix of the
 5804    tag such that the first tag character following the prefix is "-".
 5805    The special range "*", if present in the Accept-Language field,
 5806    matches every tag not matched by any other range present in the
 5807    Accept-Language field.
 5808 
 5809       Note: This use of a prefix matching rule does not imply that
 5810       language tags are assigned to languages in such a way that it is
 5811       always true that if a user understands a language with a certain
 5812       tag, then this user will also understand all languages with tags
 5813       for which this tag is a prefix. The prefix rule simply allows the
 5814       use of prefix tags if this is the case.
 5815 
 5816    The language quality factor assigned to a language-tag by the
 5817    Accept-Language field is the quality value of the longest language-
 5818    range in the field that matches the language-tag. If no language-
 5819    range in the field matches the tag, the language quality factor
 5820    assigned is 0. If no Accept-Language header is present in the
 5821    request, the server
 5822 
 5823 
 5824 
 5825 
 5826 Fielding, et al.            Standards Track                   [Page 104]
 5827 
 5828 RFC 2616                        HTTP/1.1                       June 1999
 5829 
 5830 
 5831    SHOULD assume that all languages are equally acceptable. If an
 5832    Accept-Language header is present, then all languages which are
 5833    assigned a quality factor greater than 0 are acceptable.
 5834 
 5835    It might be contrary to the privacy expectations of the user to send
 5836    an Accept-Language header with the complete linguistic preferences of
 5837    the user in every request. For a discussion of this issue, see
 5838    section 15.1.4.
 5839 
 5840    As intelligibility is highly dependent on the individual user, it is
 5841    recommended that client applications make the choice of linguistic
 5842    preference available to the user. If the choice is not made
 5843    available, then the Accept-Language header field MUST NOT be given in
 5844    the request.
 5845 
 5846       Note: When making the choice of linguistic preference available to
 5847       the user, we remind implementors of  the fact that users are not
 5848       familiar with the details of language matching as described above,
 5849       and should provide appropriate guidance. As an example, users
 5850       might assume that on selecting "en-gb", they will be served any
 5851       kind of English document if British English is not available. A
 5852       user agent might suggest in such a case to add "en" to get the
 5853       best matching behavior.
 5854 
 5855 14.5 Accept-Ranges
 5856 
 5857       The Accept-Ranges response-header field allows the server to
 5858       indicate its acceptance of range requests for a resource:
 5859 
 5860           Accept-Ranges     = "Accept-Ranges" ":" acceptable-ranges
 5861           acceptable-ranges = 1#range-unit | "none"
 5862 
 5863       Origin servers that accept byte-range requests MAY send
 5864 
 5865           Accept-Ranges: bytes
 5866 
 5867       but are not required to do so. Clients MAY generate byte-range
 5868       requests without having received this header for the resource
 5869       involved. Range units are defined in section 3.12.
 5870 
 5871       Servers that do not accept any kind of range request for a
 5872       resource MAY send
 5873 
 5874           Accept-Ranges: none
 5875 
 5876       to advise the client not to attempt a range request.
 5877 
 5878 
 5879 
 5880 
 5881 
 5882 Fielding, et al.            Standards Track                   [Page 105]
 5883 
 5884 RFC 2616                        HTTP/1.1                       June 1999
 5885 
 5886 
 5887 14.6 Age
 5888 
 5889       The Age response-header field conveys the sender's estimate of the
 5890       amount of time since the response (or its revalidation) was
 5891       generated at the origin server. A cached response is "fresh" if
 5892       its age does not exceed its freshness lifetime. Age values are
 5893       calculated as specified in section 13.2.3.
 5894 
 5895            Age = "Age" ":" age-value
 5896            age-value = delta-seconds
 5897 
 5898       Age values are non-negative decimal integers, representing time in
 5899       seconds.
 5900 
 5901       If a cache receives a value larger than the largest positive
 5902       integer it can represent, or if any of its age calculations
 5903       overflows, it MUST transmit an Age header with a value of
 5904       2147483648 (2^31). An HTTP/1.1 server that includes a cache MUST
 5905       include an Age header field in every response generated from its
 5906       own cache. Caches SHOULD use an arithmetic type of at least 31
 5907       bits of range.
 5908 
 5909 14.7 Allow
 5910 
 5911       The Allow entity-header field lists the set of methods supported
 5912       by the resource identified by the Request-URI. The purpose of this
 5913       field is strictly to inform the recipient of valid methods
 5914       associated with the resource. An Allow header field MUST be
 5915       present in a 405 (Method Not Allowed) response.
 5916 
 5917           Allow   = "Allow" ":" #Method
 5918 
 5919       Example of use:
 5920 
 5921           Allow: GET, HEAD, PUT
 5922 
 5923       This field cannot prevent a client from trying other methods.
 5924       However, the indications given by the Allow header field value
 5925       SHOULD be followed. The actual set of allowed methods is defined
 5926       by the origin server at the time of each request.
 5927 
 5928       The Allow header field MAY be provided with a PUT request to
 5929       recommend the methods to be supported by the new or modified
 5930       resource. The server is not required to support these methods and
 5931       SHOULD include an Allow header in the response giving the actual
 5932       supported methods.
 5933 
 5934 
 5935 
 5936 
 5937 
 5938 Fielding, et al.            Standards Track                   [Page 106]
 5939 
 5940 RFC 2616                        HTTP/1.1                       June 1999
 5941 
 5942 
 5943       A proxy MUST NOT modify the Allow header field even if it does not
 5944       understand all the methods specified, since the user agent might
 5945       have other means of communicating with the origin server.
 5946 
 5947 14.8 Authorization
 5948 
 5949       A user agent that wishes to authenticate itself with a server--
 5950       usually, but not necessarily, after receiving a 401 response--does
 5951       so by including an Authorization request-header field with the
 5952       request.  The Authorization field value consists of credentials
 5953       containing the authentication information of the user agent for
 5954       the realm of the resource being requested.
 5955 
 5956           Authorization  = "Authorization" ":" credentials
 5957 
 5958       HTTP access authentication is described in "HTTP Authentication:
 5959       Basic and Digest Access Authentication" [43]. If a request is
 5960       authenticated and a realm specified, the same credentials SHOULD
 5961       be valid for all other requests within this realm (assuming that
 5962       the authentication scheme itself does not require otherwise, such
 5963       as credentials that vary according to a challenge value or using
 5964       synchronized clocks).
 5965 
 5966       When a shared cache (see section 13.7) receives a request
 5967       containing an Authorization field, it MUST NOT return the
 5968       corresponding response as a reply to any other request, unless one
 5969       of the following specific exceptions holds:
 5970 
 5971       1. If the response includes the "s-maxage" cache-control
 5972          directive, the cache MAY use that response in replying to a
 5973          subsequent request. But (if the specified maximum age has
 5974          passed) a proxy cache MUST first revalidate it with the origin
 5975          server, using the request-headers from the new request to allow
 5976          the origin server to authenticate the new request. (This is the
 5977          defined behavior for s-maxage.) If the response includes "s-
 5978          maxage=0", the proxy MUST always revalidate it before re-using
 5979          it.
 5980 
 5981       2. If the response includes the "must-revalidate" cache-control
 5982          directive, the cache MAY use that response in replying to a
 5983          subsequent request. But if the response is stale, all caches
 5984          MUST first revalidate it with the origin server, using the
 5985          request-headers from the new request to allow the origin server
 5986          to authenticate the new request.
 5987 
 5988       3. If the response includes the "public" cache-control directive,
 5989          it MAY be returned in reply to any subsequent request.
 5990 
 5991 
 5992 
 5993 
 5994 Fielding, et al.            Standards Track                   [Page 107]
 5995 
 5996 RFC 2616                        HTTP/1.1                       June 1999
 5997 
 5998 
 5999 14.9 Cache-Control
 6000 
 6001    The Cache-Control general-header field is used to specify directives
 6002    that MUST be obeyed by all caching mechanisms along the
 6003    request/response chain. The directives specify behavior intended to
 6004    prevent caches from adversely interfering with the request or
 6005    response. These directives typically override the default caching
 6006    algorithms. Cache directives are unidirectional in that the presence
 6007    of a directive in a request does not imply that the same directive is
 6008    to be given in the response.
 6009 
 6010       Note that HTTP/1.0 caches might not implement Cache-Control and
 6011       might only implement Pragma: no-cache (see section 14.32).
 6012 
 6013    Cache directives MUST be passed through by a proxy or gateway
 6014    application, regardless of their significance to that application,
 6015    since the directives might be applicable to all recipients along the
 6016    request/response chain. It is not possible to specify a cache-
 6017    directive for a specific cache.
 6018 
 6019     Cache-Control   = "Cache-Control" ":" 1#cache-directive
 6020 
 6021     cache-directive = cache-request-directive
 6022          | cache-response-directive
 6023 
 6024     cache-request-directive =
 6025            "no-cache"                          ; Section 14.9.1
 6026          | "no-store"                          ; Section 14.9.2
 6027          | "max-age" "=" delta-seconds         ; Section 14.9.3, 14.9.4
 6028          | "max-stale" [ "=" delta-seconds ]   ; Section 14.9.3
 6029          | "min-fresh" "=" delta-seconds       ; Section 14.9.3
 6030          | "no-transform"                      ; Section 14.9.5
 6031          | "only-if-cached"                    ; Section 14.9.4
 6032          | cache-extension                     ; Section 14.9.6
 6033 
 6034      cache-response-directive =
 6035            "public"                               ; Section 14.9.1
 6036          | "private" [ "=" <"> 1#field-name <"> ] ; Section 14.9.1
 6037          | "no-cache" [ "=" <"> 1#field-name <"> ]; Section 14.9.1
 6038          | "no-store"                             ; Section 14.9.2
 6039          | "no-transform"                         ; Section 14.9.5
 6040          | "must-revalidate"                      ; Section 14.9.4
 6041          | "proxy-revalidate"                     ; Section 14.9.4
 6042          | "max-age" "=" delta-seconds            ; Section 14.9.3
 6043          | "s-maxage" "=" delta-seconds           ; Section 14.9.3
 6044          | cache-extension                        ; Section 14.9.6
 6045 
 6046     cache-extension = token [ "=" ( token | quoted-string ) ]
 6047 
 6048 
 6049 
 6050 Fielding, et al.            Standards Track                   [Page 108]
 6051 
 6052 RFC 2616                        HTTP/1.1                       June 1999
 6053 
 6054 
 6055    When a directive appears without any 1#field-name parameter, the
 6056    directive applies to the entire request or response. When such a
 6057    directive appears with a 1#field-name parameter, it applies only to
 6058    the named field or fields, and not to the rest of the request or
 6059    response. This mechanism supports extensibility; implementations of
 6060    future versions of the HTTP protocol might apply these directives to
 6061    header fields not defined in HTTP/1.1.
 6062 
 6063    The cache-control directives can be broken down into these general
 6064    categories:
 6065 
 6066       - Restrictions on what are cacheable; these may only be imposed by
 6067         the origin server.
 6068 
 6069       - Restrictions on what may be stored by a cache; these may be
 6070         imposed by either the origin server or the user agent.
 6071 
 6072       - Modifications of the basic expiration mechanism; these may be
 6073         imposed by either the origin server or the user agent.
 6074 
 6075       - Controls over cache revalidation and reload; these may only be
 6076         imposed by a user agent.
 6077 
 6078       - Control over transformation of entities.
 6079 
 6080       - Extensions to the caching system.
 6081 
 6082 14.9.1 What is Cacheable
 6083 
 6084    By default, a response is cacheable if the requirements of the
 6085    request method, request header fields, and the response status
 6086    indicate that it is cacheable. Section 13.4 summarizes these defaults
 6087    for cacheability. The following Cache-Control response directives
 6088    allow an origin server to override the default cacheability of a
 6089    response:
 6090 
 6091    public
 6092       Indicates that the response MAY be cached by any cache, even if it
 6093       would normally be non-cacheable or cacheable only within a non-
 6094       shared cache. (See also Authorization, section 14.8, for
 6095       additional details.)
 6096 
 6097    private
 6098       Indicates that all or part of the response message is intended for
 6099       a single user and MUST NOT be cached by a shared cache. This
 6100       allows an origin server to state that the specified parts of the
 6101 
 6102 
 6103 
 6104 
 6105 
 6106 Fielding, et al.            Standards Track                   [Page 109]
 6107 
 6108 RFC 2616                        HTTP/1.1                       June 1999
 6109 
 6110 
 6111       response are intended for only one user and are not a valid
 6112       response for requests by other users. A private (non-shared) cache
 6113       MAY cache the response.
 6114 
 6115        Note: This usage of the word private only controls where the
 6116        response may be cached, and cannot ensure the privacy of the
 6117        message content.
 6118 
 6119    no-cache
 6120        If the no-cache directive does not specify a field-name, then a
 6121       cache MUST NOT use the response to satisfy a subsequent request
 6122       without successful revalidation with the origin server. This
 6123       allows an origin server to prevent caching even by caches that
 6124       have been configured to return stale responses to client requests.
 6125 
 6126       If the no-cache directive does specify one or more field-names,
 6127       then a cache MAY use the response to satisfy a subsequent request,
 6128       subject to any other restrictions on caching. However, the
 6129       specified field-name(s) MUST NOT be sent in the response to a
 6130       subsequent request without successful revalidation with the origin
 6131       server. This allows an origin server to prevent the re-use of
 6132       certain header fields in a response, while still allowing caching
 6133       of the rest of the response.
 6134 
 6135        Note: Most HTTP/1.0 caches will not recognize or obey this
 6136        directive.
 6137 
 6138 14.9.2 What May be Stored by Caches
 6139 
 6140    no-store
 6141       The purpose of the no-store directive is to prevent the
 6142       inadvertent release or retention of sensitive information (for
 6143       example, on backup tapes). The no-store directive applies to the
 6144       entire message, and MAY be sent either in a response or in a
 6145       request. If sent in a request, a cache MUST NOT store any part of
 6146       either this request or any response to it. If sent in a response,
 6147       a cache MUST NOT store any part of either this response or the
 6148       request that elicited it. This directive applies to both non-
 6149       shared and shared caches. "MUST NOT store" in this context means
 6150       that the cache MUST NOT intentionally store the information in
 6151       non-volatile storage, and MUST make a best-effort attempt to
 6152       remove the information from volatile storage as promptly as
 6153       possible after forwarding it.
 6154 
 6155       Even when this directive is associated with a response, users
 6156       might explicitly store such a response outside of the caching
 6157       system (e.g., with a "Save As" dialog). History buffers MAY store
 6158       such responses as part of their normal operation.
 6159 
 6160 
 6161 
 6162 Fielding, et al.            Standards Track                   [Page 110]
 6163 
 6164 RFC 2616                        HTTP/1.1                       June 1999
 6165 
 6166 
 6167       The purpose of this directive is to meet the stated requirements
 6168       of certain users and service authors who are concerned about
 6169       accidental releases of information via unanticipated accesses to
 6170       cache data structures. While the use of this directive might
 6171       improve privacy in some cases, we caution that it is NOT in any
 6172       way a reliable or sufficient mechanism for ensuring privacy. In
 6173       particular, malicious or compromised caches might not recognize or
 6174       obey this directive, and communications networks might be
 6175       vulnerable to eavesdropping.
 6176 
 6177 14.9.3 Modifications of the Basic Expiration Mechanism
 6178 
 6179    The expiration time of an entity MAY be specified by the origin
 6180    server using the Expires header (see section 14.21). Alternatively,
 6181    it MAY be specified using the max-age directive in a response. When
 6182    the max-age cache-control directive is present in a cached response,
 6183    the response is stale if its current age is greater than the age
 6184    value given (in seconds) at the time of a new request for that
 6185    resource. The max-age directive on a response implies that the
 6186    response is cacheable (i.e., "public") unless some other, more
 6187    restrictive cache directive is also present.
 6188 
 6189    If a response includes both an Expires header and a max-age
 6190    directive, the max-age directive overrides the Expires header, even
 6191    if the Expires header is more restrictive. This rule allows an origin
 6192    server to provide, for a given response, a longer expiration time to
 6193    an HTTP/1.1 (or later) cache than to an HTTP/1.0 cache. This might be
 6194    useful if certain HTTP/1.0 caches improperly calculate ages or
 6195    expiration times, perhaps due to desynchronized clocks.
 6196 
 6197    Many HTTP/1.0 cache implementations will treat an Expires value that
 6198    is less than or equal to the response Date value as being equivalent
 6199    to the Cache-Control response directive "no-cache". If an HTTP/1.1
 6200    cache receives such a response, and the response does not include a
 6201    Cache-Control header field, it SHOULD consider the response to be
 6202    non-cacheable in order to retain compatibility with HTTP/1.0 servers.
 6203 
 6204        Note: An origin server might wish to use a relatively new HTTP
 6205        cache control feature, such as the "private" directive, on a
 6206        network including older caches that do not understand that
 6207        feature. The origin server will need to combine the new feature
 6208        with an Expires field whose value is less than or equal to the
 6209        Date value. This will prevent older caches from improperly
 6210        caching the response.
 6211 
 6212 
 6213 
 6214 
 6215 
 6216 
 6217 
 6218 Fielding, et al.            Standards Track                   [Page 111]
 6219 
 6220 RFC 2616                        HTTP/1.1                       June 1999
 6221 
 6222 
 6223    s-maxage
 6224        If a response includes an s-maxage directive, then for a shared
 6225        cache (but not for a private cache), the maximum age specified by
 6226        this directive overrides the maximum age specified by either the
 6227        max-age directive or the Expires header. The s-maxage directive
 6228        also implies the semantics of the proxy-revalidate directive (see
 6229        section 14.9.4), i.e., that the shared cache must not use the
 6230        entry after it becomes stale to respond to a subsequent request
 6231        without first revalidating it with the origin server. The s-
 6232        maxage directive is always ignored by a private cache.
 6233 
 6234    Note that most older caches, not compliant with this specification,
 6235    do not implement any cache-control directives. An origin server
 6236    wishing to use a cache-control directive that restricts, but does not
 6237    prevent, caching by an HTTP/1.1-compliant cache MAY exploit the
 6238    requirement that the max-age directive overrides the Expires header,
 6239    and the fact that pre-HTTP/1.1-compliant caches do not observe the
 6240    max-age directive.
 6241 
 6242    Other directives allow a user agent to modify the basic expiration
 6243    mechanism. These directives MAY be specified on a request:
 6244 
 6245    max-age
 6246       Indicates that the client is willing to accept a response whose
 6247       age is no greater than the specified time in seconds. Unless max-
 6248       stale directive is also included, the client is not willing to
 6249       accept a stale response.
 6250 
 6251    min-fresh
 6252       Indicates that the client is willing to accept a response whose
 6253       freshness lifetime is no less than its current age plus the
 6254       specified time in seconds. That is, the client wants a response
 6255       that will still be fresh for at least the specified number of
 6256       seconds.
 6257 
 6258    max-stale
 6259       Indicates that the client is willing to accept a response that has
 6260       exceeded its expiration time. If max-stale is assigned a value,
 6261       then the client is willing to accept a response that has exceeded
 6262       its expiration time by no more than the specified number of
 6263       seconds. If no value is assigned to max-stale, then the client is
 6264       willing to accept a stale response of any age.
 6265 
 6266    If a cache returns a stale response, either because of a max-stale
 6267    directive on a request, or because the cache is configured to
 6268    override the expiration time of a response, the cache MUST attach a
 6269    Warning header to the stale response, using Warning 110 (Response is
 6270    stale).
 6271 
 6272 
 6273 
 6274 Fielding, et al.            Standards Track                   [Page 112]
 6275 
 6276 RFC 2616                        HTTP/1.1                       June 1999
 6277 
 6278 
 6279    A cache MAY be configured to return stale responses without
 6280    validation, but only if this does not conflict with any "MUST"-level
 6281    requirements concerning cache validation (e.g., a "must-revalidate"
 6282    cache-control directive).
 6283 
 6284    If both the new request and the cached entry include "max-age"
 6285    directives, then the lesser of the two values is used for determining
 6286    the freshness of the cached entry for that request.
 6287 
 6288 14.9.4 Cache Revalidation and Reload Controls
 6289 
 6290    Sometimes a user agent might want or need to insist that a cache
 6291    revalidate its cache entry with the origin server (and not just with
 6292    the next cache along the path to the origin server), or to reload its
 6293    cache entry from the origin server. End-to-end revalidation might be
 6294    necessary if either the cache or the origin server has overestimated
 6295    the expiration time of the cached response. End-to-end reload may be
 6296    necessary if the cache entry has become corrupted for some reason.
 6297 
 6298    End-to-end revalidation may be requested either when the client does
 6299    not have its own local cached copy, in which case we call it
 6300    "unspecified end-to-end revalidation", or when the client does have a
 6301    local cached copy, in which case we call it "specific end-to-end
 6302    revalidation."
 6303 
 6304    The client can specify these three kinds of action using Cache-
 6305    Control request directives:
 6306 
 6307    End-to-end reload
 6308       The request includes a "no-cache" cache-control directive or, for
 6309       compatibility with HTTP/1.0 clients, "Pragma: no-cache". Field
 6310       names MUST NOT be included with the no-cache directive in a
 6311       request. The server MUST NOT use a cached copy when responding to
 6312       such a request.
 6313 
 6314    Specific end-to-end revalidation
 6315       The request includes a "max-age=0" cache-control directive, which
 6316       forces each cache along the path to the origin server to
 6317       revalidate its own entry, if any, with the next cache or server.
 6318       The initial request includes a cache-validating conditional with
 6319       the client's current validator.
 6320 
 6321    Unspecified end-to-end revalidation
 6322       The request includes "max-age=0" cache-control directive, which
 6323       forces each cache along the path to the origin server to
 6324       revalidate its own entry, if any, with the next cache or server.
 6325       The initial request does not include a cache-validating
 6326 
 6327 
 6328 
 6329 
 6330 Fielding, et al.            Standards Track                   [Page 113]
 6331 
 6332 RFC 2616                        HTTP/1.1                       June 1999
 6333 
 6334 
 6335       conditional; the first cache along the path (if any) that holds a
 6336       cache entry for this resource includes a cache-validating
 6337       conditional with its current validator.
 6338 
 6339    max-age
 6340       When an intermediate cache is forced, by means of a max-age=0
 6341       directive, to revalidate its own cache entry, and the client has
 6342       supplied its own validator in the request, the supplied validator
 6343       might differ from the validator currently stored with the cache
 6344       entry. In this case, the cache MAY use either validator in making
 6345       its own request without affecting semantic transparency.
 6346 
 6347       However, the choice of validator might affect performance. The
 6348       best approach is for the intermediate cache to use its own
 6349       validator when making its request. If the server replies with 304
 6350       (Not Modified), then the cache can return its now validated copy
 6351       to the client with a 200 (OK) response. If the server replies with
 6352       a new entity and cache validator, however, the intermediate cache
 6353       can compare the returned validator with the one provided in the
 6354       client's request, using the strong comparison function. If the
 6355       client's validator is equal to the origin server's, then the
 6356       intermediate cache simply returns 304 (Not Modified). Otherwise,
 6357       it returns the new entity with a 200 (OK) response.
 6358 
 6359       If a request includes the no-cache directive, it SHOULD NOT
 6360       include min-fresh, max-stale, or max-age.
 6361 
 6362    only-if-cached
 6363       In some cases, such as times of extremely poor network
 6364       connectivity, a client may want a cache to return only those
 6365       responses that it currently has stored, and not to reload or
 6366       revalidate with the origin server. To do this, the client may
 6367       include the only-if-cached directive in a request. If it receives
 6368       this directive, a cache SHOULD either respond using a cached entry
 6369       that is consistent with the other constraints of the request, or
 6370       respond with a 504 (Gateway Timeout) status. However, if a group
 6371       of caches is being operated as a unified system with good internal
 6372       connectivity, such a request MAY be forwarded within that group of
 6373       caches.
 6374 
 6375    must-revalidate
 6376       Because a cache MAY be configured to ignore a server's specified
 6377       expiration time, and because a client request MAY include a max-
 6378       stale directive (which has a similar effect), the protocol also
 6379       includes a mechanism for the origin server to require revalidation
 6380       of a cache entry on any subsequent use. When the must-revalidate
 6381       directive is present in a response received by a cache, that cache
 6382       MUST NOT use the entry after it becomes stale to respond to a
 6383 
 6384 
 6385 
 6386 Fielding, et al.            Standards Track                   [Page 114]
 6387 
 6388 RFC 2616                        HTTP/1.1                       June 1999
 6389 
 6390 
 6391       subsequent request without first revalidating it with the origin
 6392       server. (I.e., the cache MUST do an end-to-end revalidation every
 6393       time, if, based solely on the origin server's Expires or max-age
 6394       value, the cached response is stale.)
 6395 
 6396       The must-revalidate directive is necessary to support reliable
 6397       operation for certain protocol features. In all circumstances an
 6398       HTTP/1.1 cache MUST obey the must-revalidate directive; in
 6399       particular, if the cache cannot reach the origin server for any
 6400       reason, it MUST generate a 504 (Gateway Timeout) response.
 6401 
 6402       Servers SHOULD send the must-revalidate directive if and only if
 6403       failure to revalidate a request on the entity could result in
 6404       incorrect operation, such as a silently unexecuted financial
 6405       transaction. Recipients MUST NOT take any automated action that
 6406       violates this directive, and MUST NOT automatically provide an
 6407       unvalidated copy of the entity if revalidation fails.
 6408 
 6409       Although this is not recommended, user agents operating under
 6410       severe connectivity constraints MAY violate this directive but, if
 6411       so, MUST explicitly warn the user that an unvalidated response has
 6412       been provided. The warning MUST be provided on each unvalidated
 6413       access, and SHOULD require explicit user confirmation.
 6414 
 6415    proxy-revalidate
 6416       The proxy-revalidate directive has the same meaning as the must-
 6417       revalidate directive, except that it does not apply to non-shared
 6418       user agent caches. It can be used on a response to an
 6419       authenticated request to permit the user's cache to store and
 6420       later return the response without needing to revalidate it (since
 6421       it has already been authenticated once by that user), while still
 6422       requiring proxies that service many users to revalidate each time
 6423       (in order to make sure that each user has been authenticated).
 6424       Note that such authenticated responses also need the public cache
 6425       control directive in order to allow them to be cached at all.
 6426 
 6427 14.9.5 No-Transform Directive
 6428 
 6429    no-transform
 6430       Implementors of intermediate caches (proxies) have found it useful
 6431       to convert the media type of certain entity bodies. A non-
 6432       transparent proxy might, for example, convert between image
 6433       formats in order to save cache space or to reduce the amount of
 6434       traffic on a slow link.
 6435 
 6436       Serious operational problems occur, however, when these
 6437       transformations are applied to entity bodies intended for certain
 6438       kinds of applications. For example, applications for medical
 6439 
 6440 
 6441 
 6442 Fielding, et al.            Standards Track                   [Page 115]
 6443 
 6444 RFC 2616                        HTTP/1.1                       June 1999
 6445 
 6446 
 6447       imaging, scientific data analysis and those using end-to-end
 6448       authentication, all depend on receiving an entity body that is bit
 6449       for bit identical to the original entity-body.
 6450 
 6451       Therefore, if a message includes the no-transform directive, an
 6452       intermediate cache or proxy MUST NOT change those headers that are
 6453       listed in section 13.5.2 as being subject to the no-transform
 6454       directive. This implies that the cache or proxy MUST NOT change
 6455       any aspect of the entity-body that is specified by these headers,
 6456       including the value of the entity-body itself.
 6457 
 6458 14.9.6 Cache Control Extensions
 6459 
 6460    The Cache-Control header field can be extended through the use of one
 6461    or more cache-extension tokens, each with an optional assigned value.
 6462    Informational extensions (those which do not require a change in
 6463    cache behavior) MAY be added without changing the semantics of other
 6464    directives. Behavioral extensions are designed to work by acting as
 6465    modifiers to the existing base of cache directives. Both the new
 6466    directive and the standard directive are supplied, such that
 6467    applications which do not understand the new directive will default
 6468    to the behavior specified by the standard directive, and those that
 6469    understand the new directive will recognize it as modifying the
 6470    requirements associated with the standard directive. In this way,
 6471    extensions to the cache-control directives can be made without
 6472    requiring changes to the base protocol.
 6473 
 6474    This extension mechanism depends on an HTTP cache obeying all of the
 6475    cache-control directives defined for its native HTTP-version, obeying
 6476    certain extensions, and ignoring all directives that it does not
 6477    understand.
 6478 
 6479    For example, consider a hypothetical new response directive called
 6480    community which acts as a modifier to the private directive. We
 6481    define this new directive to mean that, in addition to any non-shared
 6482    cache, any cache which is shared only by members of the community
 6483    named within its value may cache the response. An origin server
 6484    wishing to allow the UCI community to use an otherwise private
 6485    response in their shared cache(s) could do so by including
 6486 
 6487        Cache-Control: private, community="UCI"
 6488 
 6489    A cache seeing this header field will act correctly even if the cache
 6490    does not understand the community cache-extension, since it will also
 6491    see and understand the private directive and thus default to the safe
 6492    behavior.
 6493 
 6494 
 6495 
 6496 
 6497 
 6498 Fielding, et al.            Standards Track                   [Page 116]
 6499 
 6500 RFC 2616                        HTTP/1.1                       June 1999
 6501 
 6502 
 6503    Unrecognized cache-directives MUST be ignored; it is assumed that any
 6504    cache-directive likely to be unrecognized by an HTTP/1.1 cache will
 6505    be combined with standard directives (or the response's default
 6506    cacheability) such that the cache behavior will remain minimally
 6507    correct even if the cache does not understand the extension(s).
 6508 
 6509 14.10 Connection
 6510 
 6511    The Connection general-header field allows the sender to specify
 6512    options that are desired for that particular connection and MUST NOT
 6513    be communicated by proxies over further connections.
 6514 
 6515    The Connection header has the following grammar:
 6516 
 6517        Connection = "Connection" ":" 1#(connection-token)
 6518        connection-token  = token
 6519 
 6520    HTTP/1.1 proxies MUST parse the Connection header field before a
 6521    message is forwarded and, for each connection-token in this field,
 6522    remove any header field(s) from the message with the same name as the
 6523    connection-token. Connection options are signaled by the presence of
 6524    a connection-token in the Connection header field, not by any
 6525    corresponding additional header field(s), since the additional header
 6526    field may not be sent if there are no parameters associated with that
 6527    connection option.
 6528 
 6529    Message headers listed in the Connection header MUST NOT include
 6530    end-to-end headers, such as Cache-Control.
 6531 
 6532    HTTP/1.1 defines the "close" connection option for the sender to
 6533    signal that the connection will be closed after completion of the
 6534    response. For example,
 6535 
 6536        Connection: close
 6537 
 6538    in either the request or the response header fields indicates that
 6539    the connection SHOULD NOT be considered `persistent' (section 8.1)
 6540    after the current request/response is complete.
 6541 
 6542    HTTP/1.1 applications that do not support persistent connections MUST
 6543    include the "close" connection option in every message.
 6544 
 6545    A system receiving an HTTP/1.0 (or lower-version) message that
 6546    includes a Connection header MUST, for each connection-token in this
 6547    field, remove and ignore any header field(s) from the message with
 6548    the same name as the connection-token. This protects against mistaken
 6549    forwarding of such header fields by pre-HTTP/1.1 proxies. See section
 6550    19.6.2.
 6551 
 6552 
 6553 
 6554 Fielding, et al.            Standards Track                   [Page 117]
 6555 
 6556 RFC 2616                        HTTP/1.1                       June 1999
 6557 
 6558 
 6559 14.11 Content-Encoding
 6560 
 6561    The Content-Encoding entity-header field is used as a modifier to the
 6562    media-type. When present, its value indicates what additional content
 6563    codings have been applied to the entity-body, and thus what decoding
 6564    mechanisms must be applied in order to obtain the media-type
 6565    referenced by the Content-Type header field. Content-Encoding is
 6566    primarily used to allow a document to be compressed without losing
 6567    the identity of its underlying media type.
 6568 
 6569        Content-Encoding  = "Content-Encoding" ":" 1#content-coding
 6570 
 6571    Content codings are defined in section 3.5. An example of its use is
 6572 
 6573        Content-Encoding: gzip
 6574 
 6575    The content-coding is a characteristic of the entity identified by
 6576    the Request-URI. Typically, the entity-body is stored with this
 6577    encoding and is only decoded before rendering or analogous usage.
 6578    However, a non-transparent proxy MAY modify the content-coding if the
 6579    new coding is known to be acceptable to the recipient, unless the
 6580    "no-transform" cache-control directive is present in the message.
 6581 
 6582    If the content-coding of an entity is not "identity", then the
 6583    response MUST include a Content-Encoding entity-header (section
 6584    14.11) that lists the non-identity content-coding(s) used.
 6585 
 6586    If the content-coding of an entity in a request message is not
 6587    acceptable to the origin server, the server SHOULD respond with a
 6588    status code of 415 (Unsupported Media Type).
 6589 
 6590    If multiple encodings have been applied to an entity, the content
 6591    codings MUST be listed in the order in which they were applied.
 6592    Additional information about the encoding parameters MAY be provided
 6593    by other entity-header fields not defined by this specification.
 6594 
 6595 14.12 Content-Language
 6596 
 6597    The Content-Language entity-header field describes the natural
 6598    language(s) of the intended audience for the enclosed entity. Note
 6599    that this might not be equivalent to all the languages used within
 6600    the entity-body.
 6601 
 6602        Content-Language  = "Content-Language" ":" 1#language-tag
 6603 
 6604 
 6605 
 6606 
 6607 
 6608 
 6609 
 6610 Fielding, et al.            Standards Track                   [Page 118]
 6611 
 6612 RFC 2616                        HTTP/1.1                       June 1999
 6613 
 6614 
 6615    Language tags are defined in section 3.10. The primary purpose of
 6616    Content-Language is to allow a user to identify and differentiate
 6617    entities according to the user's own preferred language. Thus, if the
 6618    body content is intended only for a Danish-literate audience, the
 6619    appropriate field is
 6620 
 6621        Content-Language: da
 6622 
 6623    If no Content-Language is specified, the default is that the content
 6624    is intended for all language audiences. This might mean that the
 6625    sender does not consider it to be specific to any natural language,
 6626    or that the sender does not know for which language it is intended.
 6627 
 6628    Multiple languages MAY be listed for content that is intended for
 6629    multiple audiences. For example, a rendition of the "Treaty of
 6630    Waitangi," presented simultaneously in the original Maori and English
 6631    versions, would call for
 6632 
 6633        Content-Language: mi, en
 6634 
 6635    However, just because multiple languages are present within an entity
 6636    does not mean that it is intended for multiple linguistic audiences.
 6637    An example would be a beginner's language primer, such as "A First
 6638    Lesson in Latin," which is clearly intended to be used by an
 6639    English-literate audience. In this case, the Content-Language would
 6640    properly only include "en".
 6641 
 6642    Content-Language MAY be applied to any media type -- it is not
 6643    limited to textual documents.
 6644 
 6645 14.13 Content-Length
 6646 
 6647    The Content-Length entity-header field indicates the size of the
 6648    entity-body, in decimal number of OCTETs, sent to the recipient or,
 6649    in the case of the HEAD method, the size of the entity-body that
 6650    would have been sent had the request been a GET.
 6651 
 6652        Content-Length    = "Content-Length" ":" 1*DIGIT
 6653 
 6654    An example is
 6655 
 6656        Content-Length: 3495
 6657 
 6658    Applications SHOULD use this field to indicate the transfer-length of
 6659    the message-body, unless this is prohibited by the rules in section
 6660    4.4.
 6661 
 6662 
 6663 
 6664 
 6665 
 6666 Fielding, et al.            Standards Track                   [Page 119]
 6667 
 6668 RFC 2616                        HTTP/1.1                       June 1999
 6669 
 6670 
 6671    Any Content-Length greater than or equal to zero is a valid value.
 6672    Section 4.4 describes how to determine the length of a message-body
 6673    if a Content-Length is not given.
 6674 
 6675    Note that the meaning of this field is significantly different from
 6676    the corresponding definition in MIME, where it is an optional field
 6677    used within the "message/external-body" content-type. In HTTP, it
 6678    SHOULD be sent whenever the message's length can be determined prior
 6679    to being transferred, unless this is prohibited by the rules in
 6680    section 4.4.
 6681 
 6682 14.14 Content-Location
 6683 
 6684    The Content-Location entity-header field MAY be used to supply the
 6685    resource location for the entity enclosed in the message when that
 6686    entity is accessible from a location separate from the requested
 6687    resource's URI. A server SHOULD provide a Content-Location for the
 6688    variant corresponding to the response entity; especially in the case
 6689    where a resource has multiple entities associated with it, and those
 6690    entities actually have separate locations by which they might be
 6691    individually accessed, the server SHOULD provide a Content-Location
 6692    for the particular variant which is returned.
 6693 
 6694        Content-Location = "Content-Location" ":"
 6695                          ( absoluteURI | relativeURI )
 6696 
 6697    The value of Content-Location also defines the base URI for the
 6698    entity.
 6699 
 6700    The Content-Location value is not a replacement for the original
 6701    requested URI; it is only a statement of the location of the resource
 6702    corresponding to this particular entity at the time of the request.
 6703    Future requests MAY specify the Content-Location URI as the request-
 6704    URI if the desire is to identify the source of that particular
 6705    entity.
 6706 
 6707    A cache cannot assume that an entity with a Content-Location
 6708    different from the URI used to retrieve it can be used to respond to
 6709    later requests on that Content-Location URI. However, the Content-
 6710    Location can be used to differentiate between multiple entities
 6711    retrieved from a single requested resource, as described in section
 6712    13.6.
 6713 
 6714    If the Content-Location is a relative URI, the relative URI is
 6715    interpreted relative to the Request-URI.
 6716 
 6717    The meaning of the Content-Location header in PUT or POST requests is
 6718    undefined; servers are free to ignore it in those cases.
 6719 
 6720 
 6721 
 6722 Fielding, et al.            Standards Track                   [Page 120]
 6723 
 6724 RFC 2616                        HTTP/1.1                       June 1999
 6725 
 6726 
 6727 14.15 Content-MD5
 6728 
 6729    The Content-MD5 entity-header field, as defined in RFC 1864 [23], is
 6730    an MD5 digest of the entity-body for the purpose of providing an
 6731    end-to-end message integrity check (MIC) of the entity-body. (Note: a
 6732    MIC is good for detecting accidental modification of the entity-body
 6733    in transit, but is not proof against malicious attacks.)
 6734 
 6735         Content-MD5   = "Content-MD5" ":" md5-digest
 6736         md5-digest   = <base64 of 128 bit MD5 digest as per RFC 1864>
 6737 
 6738    The Content-MD5 header field MAY be generated by an origin server or
 6739    client to function as an integrity check of the entity-body. Only
 6740    origin servers or clients MAY generate the Content-MD5 header field;
 6741    proxies and gateways MUST NOT generate it, as this would defeat its
 6742    value as an end-to-end integrity check. Any recipient of the entity-
 6743    body, including gateways and proxies, MAY check that the digest value
 6744    in this header field matches that of the entity-body as received.
 6745 
 6746    The MD5 digest is computed based on the content of the entity-body,
 6747    including any content-coding that has been applied, but not including
 6748    any transfer-encoding applied to the message-body. If the message is
 6749    received with a transfer-encoding, that encoding MUST be removed
 6750    prior to checking the Content-MD5 value against the received entity.
 6751 
 6752    This has the result that the digest is computed on the octets of the
 6753    entity-body exactly as, and in the order that, they would be sent if
 6754    no transfer-encoding were being applied.
 6755 
 6756    HTTP extends RFC 1864 to permit the digest to be computed for MIME
 6757    composite media-types (e.g., multipart/* and message/rfc822), but
 6758    this does not change how the digest is computed as defined in the
 6759    preceding paragraph.
 6760 
 6761    There are several consequences of this. The entity-body for composite
 6762    types MAY contain many body-parts, each with its own MIME and HTTP
 6763    headers (including Content-MD5, Content-Transfer-Encoding, and
 6764    Content-Encoding headers). If a body-part has a Content-Transfer-
 6765    Encoding or Content-Encoding header, it is assumed that the content
 6766    of the body-part has had the encoding applied, and the body-part is
 6767    included in the Content-MD5 digest as is -- i.e., after the
 6768    application. The Transfer-Encoding header field is not allowed within
 6769    body-parts.
 6770 
 6771    Conversion of all line breaks to CRLF MUST NOT be done before
 6772    computing or checking the digest: the line break convention used in
 6773    the text actually transmitted MUST be left unaltered when computing
 6774    the digest.
 6775 
 6776 
 6777 
 6778 Fielding, et al.            Standards Track                   [Page 121]
 6779 
 6780 RFC 2616                        HTTP/1.1                       June 1999
 6781 
 6782 
 6783       Note: while the definition of Content-MD5 is exactly the same for
 6784       HTTP as in RFC 1864 for MIME entity-bodies, there are several ways
 6785       in which the application of Content-MD5 to HTTP entity-bodies
 6786       differs from its application to MIME entity-bodies. One is that
 6787       HTTP, unlike MIME, does not use Content-Transfer-Encoding, and
 6788       does use Transfer-Encoding and Content-Encoding. Another is that
 6789       HTTP more frequently uses binary content types than MIME, so it is
 6790       worth noting that, in such cases, the byte order used to compute
 6791       the digest is the transmission byte order defined for the type.
 6792       Lastly, HTTP allows transmission of text types with any of several
 6793       line break conventions and not just the canonical form using CRLF.
 6794 
 6795 14.16 Content-Range
 6796 
 6797    The Content-Range entity-header is sent with a partial entity-body to
 6798    specify where in the full entity-body the partial body should be
 6799    applied. Range units are defined in section 3.12.
 6800 
 6801        Content-Range = "Content-Range" ":" content-range-spec
 6802 
 6803        content-range-spec      = byte-content-range-spec
 6804        byte-content-range-spec = bytes-unit SP
 6805                                  byte-range-resp-spec "/"
 6806                                  ( instance-length | "*" )
 6807 
 6808        byte-range-resp-spec = (first-byte-pos "-" last-byte-pos)
 6809                                       | "*"
 6810        instance-length           = 1*DIGIT
 6811 
 6812    The header SHOULD indicate the total length of the full entity-body,
 6813    unless this length is unknown or difficult to determine. The asterisk
 6814    "*" character means that the instance-length is unknown at the time
 6815    when the response was generated.
 6816 
 6817    Unlike byte-ranges-specifier values (see section 14.35.1), a byte-
 6818    range-resp-spec MUST only specify one range, and MUST contain
 6819    absolute byte positions for both the first and last byte of the
 6820    range.
 6821 
 6822    A byte-content-range-spec with a byte-range-resp-spec whose last-
 6823    byte-pos value is less than its first-byte-pos value, or whose
 6824    instance-length value is less than or equal to its last-byte-pos
 6825    value, is invalid. The recipient of an invalid byte-content-range-
 6826    spec MUST ignore it and any content transferred along with it.
 6827 
 6828    A server sending a response with status code 416 (Requested range not
 6829    satisfiable) SHOULD include a Content-Range field with a byte-range-
 6830    resp-spec of "*". The instance-length specifies the current length of
 6831 
 6832 
 6833 
 6834 Fielding, et al.            Standards Track                   [Page 122]
 6835 
 6836 RFC 2616                        HTTP/1.1                       June 1999
 6837 
 6838 
 6839    the selected resource. A response with status code 206 (Partial
 6840    Content) MUST NOT include a Content-Range field with a byte-range-
 6841    resp-spec of "*".
 6842 
 6843    Examples of byte-content-range-spec values, assuming that the entity
 6844    contains a total of 1234 bytes:
 6845 
 6846       . The first 500 bytes:
 6847        bytes 0-499/1234
 6848 
 6849       . The second 500 bytes:
 6850        bytes 500-999/1234
 6851 
 6852       . All except for the first 500 bytes:
 6853        bytes 500-1233/1234
 6854 
 6855       . The last 500 bytes:
 6856        bytes 734-1233/1234
 6857 
 6858    When an HTTP message includes the content of a single range (for
 6859    example, a response to a request for a single range, or to a request
 6860    for a set of ranges that overlap without any holes), this content is
 6861    transmitted with a Content-Range header, and a Content-Length header
 6862    showing the number of bytes actually transferred. For example,
 6863 
 6864        HTTP/1.1 206 Partial content
 6865        Date: Wed, 15 Nov 1995 06:25:24 GMT
 6866        Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
 6867        Content-Range: bytes 21010-47021/47022
 6868        Content-Length: 26012
 6869        Content-Type: image/gif
 6870 
 6871    When an HTTP message includes the content of multiple ranges (for
 6872    example, a response to a request for multiple non-overlapping
 6873    ranges), these are transmitted as a multipart message. The multipart
 6874    media type used for this purpose is "multipart/byteranges" as defined
 6875    in appendix 19.2. See appendix 19.6.3 for a compatibility issue.
 6876 
 6877    A response to a request for a single range MUST NOT be sent using the
 6878    multipart/byteranges media type.  A response to a request for
 6879    multiple ranges, whose result is a single range, MAY be sent as a
 6880    multipart/byteranges media type with one part. A client that cannot
 6881    decode a multipart/byteranges message MUST NOT ask for multiple
 6882    byte-ranges in a single request.
 6883 
 6884    When a client requests multiple byte-ranges in one request, the
 6885    server SHOULD return them in the order that they appeared in the
 6886    request.
 6887 
 6888 
 6889 
 6890 Fielding, et al.            Standards Track                   [Page 123]
 6891 
 6892 RFC 2616                        HTTP/1.1                       June 1999
 6893 
 6894 
 6895    If the server ignores a byte-range-spec because it is syntactically
 6896    invalid, the server SHOULD treat the request as if the invalid Range
 6897    header field did not exist. (Normally, this means return a 200
 6898    response containing the full entity).
 6899 
 6900    If the server receives a request (other than one including an If-
 6901    Range request-header field) with an unsatisfiable Range request-
 6902    header field (that is, all of whose byte-range-spec values have a
 6903    first-byte-pos value greater than the current length of the selected
 6904    resource), it SHOULD return a response code of 416 (Requested range
 6905    not satisfiable) (section 10.4.17).
 6906 
 6907       Note: clients cannot depend on servers to send a 416 (Requested
 6908       range not satisfiable) response instead of a 200 (OK) response for
 6909       an unsatisfiable Range request-header, since not all servers
 6910       implement this request-header.
 6911 
 6912 14.17 Content-Type
 6913 
 6914    The Content-Type entity-header field indicates the media type of the
 6915    entity-body sent to the recipient or, in the case of the HEAD method,
 6916    the media type that would have been sent had the request been a GET.
 6917 
 6918        Content-Type   = "Content-Type" ":" media-type
 6919 
 6920    Media types are defined in section 3.7. An example of the field is
 6921 
 6922        Content-Type: text/html; charset=ISO-8859-4
 6923 
 6924    Further discussion of methods for identifying the media type of an
 6925    entity is provided in section 7.2.1.
 6926 
 6927 14.18 Date
 6928 
 6929    The Date general-header field represents the date and time at which
 6930    the message was originated, having the same semantics as orig-date in
 6931    RFC 822. The field value is an HTTP-date, as described in section
 6932    3.3.1; it MUST be sent in RFC 1123 [8]-date format.
 6933 
 6934        Date  = "Date" ":" HTTP-date
 6935 
 6936    An example is
 6937 
 6938        Date: Tue, 15 Nov 1994 08:12:31 GMT
 6939 
 6940    Origin servers MUST include a Date header field in all responses,
 6941    except in these cases:
 6942 
 6943 
 6944 
 6945 
 6946 Fielding, et al.            Standards Track                   [Page 124]
 6947 
 6948 RFC 2616                        HTTP/1.1                       June 1999
 6949 
 6950 
 6951       1. If the response status code is 100 (Continue) or 101 (Switching
 6952          Protocols), the response MAY include a Date header field, at
 6953          the server's option.
 6954 
 6955       2. If the response status code conveys a server error, e.g. 500
 6956          (Internal Server Error) or 503 (Service Unavailable), and it is
 6957          inconvenient or impossible to generate a valid Date.
 6958 
 6959       3. If the server does not have a clock that can provide a
 6960          reasonable approximation of the current time, its responses
 6961          MUST NOT include a Date header field. In this case, the rules
 6962          in section 14.18.1 MUST be followed.
 6963 
 6964    A received message that does not have a Date header field MUST be
 6965    assigned one by the recipient if the message will be cached by that
 6966    recipient or gatewayed via a protocol which requires a Date. An HTTP
 6967    implementation without a clock MUST NOT cache responses without
 6968    revalidating them on every use. An HTTP cache, especially a shared
 6969    cache, SHOULD use a mechanism, such as NTP [28], to synchronize its
 6970    clock with a reliable external standard.
 6971 
 6972    Clients SHOULD only send a Date header field in messages that include
 6973    an entity-body, as in the case of the PUT and POST requests, and even
 6974    then it is optional. A client without a clock MUST NOT send a Date
 6975    header field in a request.
 6976 
 6977    The HTTP-date sent in a Date header SHOULD NOT represent a date and
 6978    time subsequent to the generation of the message. It SHOULD represent
 6979    the best available approximation of the date and time of message
 6980    generation, unless the implementation has no means of generating a
 6981    reasonably accurate date and time. In theory, the date ought to
 6982    represent the moment just before the entity is generated. In
 6983    practice, the date can be generated at any time during the message
 6984    origination without affecting its semantic value.
 6985 
 6986 14.18.1 Clockless Origin Server Operation
 6987 
 6988    Some origin server implementations might not have a clock available.
 6989    An origin server without a clock MUST NOT assign Expires or Last-
 6990    Modified values to a response, unless these values were associated
 6991    with the resource by a system or user with a reliable clock. It MAY
 6992    assign an Expires value that is known, at or before server
 6993    configuration time, to be in the past (this allows "pre-expiration"
 6994    of responses without storing separate Expires values for each
 6995    resource).
 6996 
 6997 
 6998 
 6999 
 7000 
 7001 
 7002 Fielding, et al.            Standards Track                   [Page 125]
 7003 
 7004 RFC 2616                        HTTP/1.1                       June 1999
 7005 
 7006 
 7007 14.19 ETag
 7008 
 7009    The ETag response-header field provides the current value of the
 7010    entity tag for the requested variant. The headers used with entity
 7011    tags are described in sections 14.24, 14.26 and 14.44. The entity tag
 7012    MAY be used for comparison with other entities from the same resource
 7013    (see section 13.3.3).
 7014 
 7015       ETag = "ETag" ":" entity-tag
 7016 
 7017    Examples:
 7018 
 7019       ETag: "xyzzy"
 7020       ETag: W/"xyzzy"
 7021       ETag: ""
 7022 
 7023 14.20 Expect
 7024 
 7025    The Expect request-header field is used to indicate that particular
 7026    server behaviors are required by the client.
 7027 
 7028       Expect       =  "Expect" ":" 1#expectation
 7029 
 7030       expectation  =  "100-continue" | expectation-extension
 7031       expectation-extension =  token [ "=" ( token | quoted-string )
 7032                                *expect-params ]
 7033       expect-params =  ";" token [ "=" ( token | quoted-string ) ]
 7034 
 7035 
 7036    A server that does not understand or is unable to comply with any of
 7037    the expectation values in the Expect field of a request MUST respond
 7038    with appropriate error status. The server MUST respond with a 417
 7039    (Expectation Failed) status if any of the expectations cannot be met
 7040    or, if there are other problems with the request, some other 4xx
 7041    status.
 7042 
 7043    This header field is defined with extensible syntax to allow for
 7044    future extensions. If a server receives a request containing an
 7045    Expect field that includes an expectation-extension that it does not
 7046    support, it MUST respond with a 417 (Expectation Failed) status.
 7047 
 7048    Comparison of expectation values is case-insensitive for unquoted
 7049    tokens (including the 100-continue token), and is case-sensitive for
 7050    quoted-string expectation-extensions.
 7051 
 7052 
 7053 
 7054 
 7055 
 7056 
 7057 
 7058 Fielding, et al.            Standards Track                   [Page 126]
 7059 
 7060 RFC 2616                        HTTP/1.1                       June 1999
 7061 
 7062 
 7063    The Expect mechanism is hop-by-hop: that is, an HTTP/1.1 proxy MUST
 7064    return a 417 (Expectation Failed) status if it receives a request
 7065    with an expectation that it cannot meet. However, the Expect
 7066    request-header itself is end-to-end; it MUST be forwarded if the
 7067    request is forwarded.
 7068 
 7069    Many older HTTP/1.0 and HTTP/1.1 applications do not understand the
 7070    Expect header.
 7071 
 7072    See section 8.2.3 for the use of the 100 (continue) status.
 7073 
 7074 14.21 Expires
 7075 
 7076    The Expires entity-header field gives the date/time after which the
 7077    response is considered stale. A stale cache entry may not normally be
 7078    returned by a cache (either a proxy cache or a user agent cache)
 7079    unless it is first validated with the origin server (or with an
 7080    intermediate cache that has a fresh copy of the entity). See section
 7081    13.2 for further discussion of the expiration model.
 7082 
 7083    The presence of an Expires field does not imply that the original
 7084    resource will change or cease to exist at, before, or after that
 7085    time.
 7086 
 7087    The format is an absolute date and time as defined by HTTP-date in
 7088    section 3.3.1; it MUST be in RFC 1123 date format:
 7089 
 7090       Expires = "Expires" ":" HTTP-date
 7091 
 7092    An example of its use is
 7093 
 7094       Expires: Thu, 01 Dec 1994 16:00:00 GMT
 7095 
 7096       Note: if a response includes a Cache-Control field with the max-
 7097       age directive (see section 14.9.3), that directive overrides the
 7098       Expires field.
 7099 
 7100    HTTP/1.1 clients and caches MUST treat other invalid date formats,
 7101    especially including the value "0", as in the past (i.e., "already
 7102    expired").
 7103 
 7104    To mark a response as "already expired," an origin server sends an
 7105    Expires date that is equal to the Date header value. (See the rules
 7106    for expiration calculations in section 13.2.4.)
 7107 
 7108 
 7109 
 7110 
 7111 
 7112 
 7113 
 7114 Fielding, et al.            Standards Track                   [Page 127]
 7115 
 7116 RFC 2616                        HTTP/1.1                       June 1999
 7117 
 7118 
 7119    To mark a response as "never expires," an origin server sends an
 7120    Expires date approximately one year from the time the response is
 7121    sent. HTTP/1.1 servers SHOULD NOT send Expires dates more than one
 7122    year in the future.
 7123 
 7124    The presence of an Expires header field with a date value of some
 7125    time in the future on a response that otherwise would by default be
 7126    non-cacheable indicates that the response is cacheable, unless
 7127    indicated otherwise by a Cache-Control header field (section 14.9).
 7128 
 7129 14.22 From
 7130 
 7131    The From request-header field, if given, SHOULD contain an Internet
 7132    e-mail address for the human user who controls the requesting user
 7133    agent. The address SHOULD be machine-usable, as defined by "mailbox"
 7134    in RFC 822 [9] as updated by RFC 1123 [8]:
 7135 
 7136        From   = "From" ":" mailbox
 7137 
 7138    An example is:
 7139 
 7140        From: webmaster@w3.org
 7141 
 7142    This header field MAY be used for logging purposes and as a means for
 7143    identifying the source of invalid or unwanted requests. It SHOULD NOT
 7144    be used as an insecure form of access protection. The interpretation
 7145    of this field is that the request is being performed on behalf of the
 7146    person given, who accepts responsibility for the method performed. In
 7147    particular, robot agents SHOULD include this header so that the
 7148    person responsible for running the robot can be contacted if problems
 7149    occur on the receiving end.
 7150 
 7151    The Internet e-mail address in this field MAY be separate from the
 7152    Internet host which issued the request. For example, when a request
 7153    is passed through a proxy the original issuer's address SHOULD be
 7154    used.
 7155 
 7156    The client SHOULD NOT send the From header field without the user's
 7157    approval, as it might conflict with the user's privacy interests or
 7158    their site's security policy. It is strongly recommended that the
 7159    user be able to disable, enable, and modify the value of this field
 7160    at any time prior to a request.
 7161 
 7162 14.23 Host
 7163 
 7164    The Host request-header field specifies the Internet host and port
 7165    number of the resource being requested, as obtained from the original
 7166    URI given by the user or referring resource (generally an HTTP URL,
 7167 
 7168 
 7169 
 7170 Fielding, et al.            Standards Track                   [Page 128]
 7171 
 7172 RFC 2616                        HTTP/1.1                       June 1999
 7173 
 7174 
 7175    as described in section 3.2.2). The Host field value MUST represent
 7176    the naming authority of the origin server or gateway given by the
 7177    original URL. This allows the origin server or gateway to
 7178    differentiate between internally-ambiguous URLs, such as the root "/"
 7179    URL of a server for multiple host names on a single IP address.
 7180 
 7181        Host = "Host" ":" host [ ":" port ] ; Section 3.2.2
 7182 
 7183    A "host" without any trailing port information implies the default
 7184    port for the service requested (e.g., "80" for an HTTP URL). For
 7185    example, a request on the origin server for
 7186    <http://www.w3.org/pub/WWW/> would properly include:
 7187 
 7188        GET /pub/WWW/ HTTP/1.1
 7189        Host: www.w3.org
 7190 
 7191    A client MUST include a Host header field in all HTTP/1.1 request
 7192    messages . If the requested URI does not include an Internet host
 7193    name for the service being requested, then the Host header field MUST
 7194    be given with an empty value. An HTTP/1.1 proxy MUST ensure that any
 7195    request message it forwards does contain an appropriate Host header
 7196    field that identifies the service being requested by the proxy. All
 7197    Internet-based HTTP/1.1 servers MUST respond with a 400 (Bad Request)
 7198    status code to any HTTP/1.1 request message which lacks a Host header
 7199    field.
 7200 
 7201    See sections 5.2 and 19.6.1.1 for other requirements relating to
 7202    Host.
 7203 
 7204 14.24 If-Match
 7205 
 7206    The If-Match request-header field is used with a method to make it
 7207    conditional. A client that has one or more entities previously
 7208    obtained from the resource can verify that one of those entities is
 7209    current by including a list of their associated entity tags in the
 7210    If-Match header field. Entity tags are defined in section 3.11. The
 7211    purpose of this feature is to allow efficient updates of cached
 7212    information with a minimum amount of transaction overhead. It is also
 7213    used, on updating requests, to prevent inadvertent modification of
 7214    the wrong version of a resource. As a special case, the value "*"
 7215    matches any current entity of the resource.
 7216 
 7217        If-Match = "If-Match" ":" ( "*" | 1#entity-tag )
 7218 
 7219    If any of the entity tags match the entity tag of the entity that
 7220    would have been returned in the response to a similar GET request
 7221    (without the If-Match header) on that resource, or if "*" is given
 7222 
 7223 
 7224 
 7225 
 7226 Fielding, et al.            Standards Track                   [Page 129]
 7227 
 7228 RFC 2616                        HTTP/1.1                       June 1999
 7229 
 7230 
 7231    and any current entity exists for that resource, then the server MAY
 7232    perform the requested method as if the If-Match header field did not
 7233    exist.
 7234 
 7235    A server MUST use the strong comparison function (see section 13.3.3)
 7236    to compare the entity tags in If-Match.
 7237 
 7238    If none of the entity tags match, or if "*" is given and no current
 7239    entity exists, the server MUST NOT perform the requested method, and
 7240    MUST return a 412 (Precondition Failed) response. This behavior is
 7241    most useful when the client wants to prevent an updating method, such
 7242    as PUT, from modifying a resource that has changed since the client
 7243    last retrieved it.
 7244 
 7245    If the request would, without the If-Match header field, result in
 7246    anything other than a 2xx or 412 status, then the If-Match header
 7247    MUST be ignored.
 7248 
 7249    The meaning of "If-Match: *" is that the method SHOULD be performed
 7250    if the representation selected by the origin server (or by a cache,
 7251    possibly using the Vary mechanism, see section 14.44) exists, and
 7252    MUST NOT be performed if the representation does not exist.
 7253 
 7254    A request intended to update a resource (e.g., a PUT) MAY include an
 7255    If-Match header field to signal that the request method MUST NOT be
 7256    applied if the entity corresponding to the If-Match value (a single
 7257    entity tag) is no longer a representation of that resource. This
 7258    allows the user to indicate that they do not wish the request to be
 7259    successful if the resource has been changed without their knowledge.
 7260    Examples:
 7261 
 7262        If-Match: "xyzzy"
 7263        If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
 7264        If-Match: *
 7265 
 7266    The result of a request having both an If-Match header field and
 7267    either an If-None-Match or an If-Modified-Since header fields is
 7268    undefined by this specification.
 7269 
 7270 14.25 If-Modified-Since
 7271 
 7272    The If-Modified-Since request-header field is used with a method to
 7273    make it conditional: if the requested variant has not been modified
 7274    since the time specified in this field, an entity will not be
 7275    returned from the server; instead, a 304 (not modified) response will
 7276    be returned without any message-body.
 7277 
 7278        If-Modified-Since = "If-Modified-Since" ":" HTTP-date
 7279 
 7280 
 7281 
 7282 Fielding, et al.            Standards Track                   [Page 130]
 7283 
 7284 RFC 2616                        HTTP/1.1                       June 1999
 7285 
 7286 
 7287    An example of the field is:
 7288 
 7289        If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
 7290 
 7291    A GET method with an If-Modified-Since header and no Range header
 7292    requests that the identified entity be transferred only if it has
 7293    been modified since the date given by the If-Modified-Since header.
 7294    The algorithm for determining this includes the following cases:
 7295 
 7296       a) If the request would normally result in anything other than a
 7297          200 (OK) status, or if the passed If-Modified-Since date is
 7298          invalid, the response is exactly the same as for a normal GET.
 7299          A date which is later than the server's current time is
 7300          invalid.
 7301 
 7302       b) If the variant has been modified since the If-Modified-Since
 7303          date, the response is exactly the same as for a normal GET.
 7304 
 7305       c) If the variant has not been modified since a valid If-
 7306          Modified-Since date, the server SHOULD return a 304 (Not
 7307          Modified) response.
 7308 
 7309    The purpose of this feature is to allow efficient updates of cached
 7310    information with a minimum amount of transaction overhead.
 7311 
 7312       Note: The Range request-header field modifies the meaning of If-
 7313       Modified-Since; see section 14.35 for full details.
 7314 
 7315       Note: If-Modified-Since times are interpreted by the server, whose
 7316       clock might not be synchronized with the client.
 7317 
 7318       Note: When handling an If-Modified-Since header field, some
 7319       servers will use an exact date comparison function, rather than a
 7320       less-than function, for deciding whether to send a 304 (Not
 7321       Modified) response. To get best results when sending an If-
 7322       Modified-Since header field for cache validation, clients are
 7323       advised to use the exact date string received in a previous Last-
 7324       Modified header field whenever possible.
 7325 
 7326       Note: If a client uses an arbitrary date in the If-Modified-Since
 7327       header instead of a date taken from the Last-Modified header for
 7328       the same request, the client should be aware of the fact that this
 7329       date is interpreted in the server's understanding of time. The
 7330       client should consider unsynchronized clocks and rounding problems
 7331       due to the different encodings of time between the client and
 7332       server. This includes the possibility of race conditions if the
 7333       document has changed between the time it was first requested and
 7334       the If-Modified-Since date of a subsequent request, and the
 7335 
 7336 
 7337 
 7338 Fielding, et al.            Standards Track                   [Page 131]
 7339 
 7340 RFC 2616                        HTTP/1.1                       June 1999
 7341 
 7342 
 7343       possibility of clock-skew-related problems if the If-Modified-
 7344       Since date is derived from the client's clock without correction
 7345       to the server's clock. Corrections for different time bases
 7346       between client and server are at best approximate due to network
 7347       latency.
 7348 
 7349    The result of a request having both an If-Modified-Since header field
 7350    and either an If-Match or an If-Unmodified-Since header fields is
 7351    undefined by this specification.
 7352 
 7353 14.26 If-None-Match
 7354 
 7355    The If-None-Match request-header field is used with a method to make
 7356    it conditional. A client that has one or more entities previously
 7357    obtained from the resource can verify that none of those entities is
 7358    current by including a list of their associated entity tags in the
 7359    If-None-Match header field. The purpose of this feature is to allow
 7360    efficient updates of cached information with a minimum amount of
 7361    transaction overhead. It is also used to prevent a method (e.g. PUT)
 7362    from inadvertently modifying an existing resource when the client
 7363    believes that the resource does not exist.
 7364 
 7365    As a special case, the value "*" matches any current entity of the
 7366    resource.
 7367 
 7368        If-None-Match = "If-None-Match" ":" ( "*" | 1#entity-tag )
 7369 
 7370    If any of the entity tags match the entity tag of the entity that
 7371    would have been returned in the response to a similar GET request
 7372    (without the If-None-Match header) on that resource, or if "*" is
 7373    given and any current entity exists for that resource, then the
 7374    server MUST NOT perform the requested method, unless required to do
 7375    so because the resource's modification date fails to match that
 7376    supplied in an If-Modified-Since header field in the request.
 7377    Instead, if the request method was GET or HEAD, the server SHOULD
 7378    respond with a 304 (Not Modified) response, including the cache-
 7379    related header fields (particularly ETag) of one of the entities that
 7380    matched. For all other request methods, the server MUST respond with
 7381    a status of 412 (Precondition Failed).
 7382 
 7383    See section 13.3.3 for rules on how to determine if two entities tags
 7384    match. The weak comparison function can only be used with GET or HEAD
 7385    requests.
 7386 
 7387 
 7388 
 7389 
 7390 
 7391 
 7392 
 7393 
 7394 Fielding, et al.            Standards Track                   [Page 132]
 7395 
 7396 RFC 2616                        HTTP/1.1                       June 1999
 7397 
 7398 
 7399    If none of the entity tags match, then the server MAY perform the
 7400    requested method as if the If-None-Match header field did not exist,
 7401    but MUST also ignore any If-Modified-Since header field(s) in the
 7402    request. That is, if no entity tags match, then the server MUST NOT
 7403    return a 304 (Not Modified) response.
 7404 
 7405    If the request would, without the If-None-Match header field, result
 7406    in anything other than a 2xx or 304 status, then the If-None-Match
 7407    header MUST be ignored. (See section 13.3.4 for a discussion of
 7408    server behavior when both If-Modified-Since and If-None-Match appear
 7409    in the same request.)
 7410 
 7411    The meaning of "If-None-Match: *" is that the method MUST NOT be
 7412    performed if the representation selected by the origin server (or by
 7413    a cache, possibly using the Vary mechanism, see section 14.44)
 7414    exists, and SHOULD be performed if the representation does not exist.
 7415    This feature is intended to be useful in preventing races between PUT
 7416    operations.
 7417 
 7418    Examples:
 7419 
 7420        If-None-Match: "xyzzy"
 7421        If-None-Match: W/"xyzzy"
 7422        If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
 7423        If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz"
 7424        If-None-Match: *
 7425 
 7426    The result of a request having both an If-None-Match header field and
 7427    either an If-Match or an If-Unmodified-Since header fields is
 7428    undefined by this specification.
 7429 
 7430 14.27 If-Range
 7431 
 7432    If a client has a partial copy of an entity in its cache, and wishes
 7433    to have an up-to-date copy of the entire entity in its cache, it
 7434    could use the Range request-header with a conditional GET (using
 7435    either or both of If-Unmodified-Since and If-Match.) However, if the
 7436    condition fails because the entity has been modified, the client
 7437    would then have to make a second request to obtain the entire current
 7438    entity-body.
 7439 
 7440    The If-Range header allows a client to "short-circuit" the second
 7441    request. Informally, its meaning is `if the entity is unchanged, send
 7442    me the part(s) that I am missing; otherwise, send me the entire new
 7443    entity'.
 7444 
 7445         If-Range = "If-Range" ":" ( entity-tag | HTTP-date )
 7446 
 7447 
 7448 
 7449 
 7450 Fielding, et al.            Standards Track                   [Page 133]
 7451 
 7452 RFC 2616                        HTTP/1.1                       June 1999
 7453 
 7454 
 7455    If the client has no entity tag for an entity, but does have a Last-
 7456    Modified date, it MAY use that date in an If-Range header. (The
 7457    server can distinguish between a valid HTTP-date and any form of
 7458    entity-tag by examining no more than two characters.) The If-Range
 7459    header SHOULD only be used together with a Range header, and MUST be
 7460    ignored if the request does not include a Range header, or if the
 7461    server does not support the sub-range operation.
 7462 
 7463    If the entity tag given in the If-Range header matches the current
 7464    entity tag for the entity, then the server SHOULD provide the
 7465    specified sub-range of the entity using a 206 (Partial content)
 7466    response. If the entity tag does not match, then the server SHOULD
 7467    return the entire entity using a 200 (OK) response.
 7468 
 7469 14.28 If-Unmodified-Since
 7470 
 7471    The If-Unmodified-Since request-header field is used with a method to
 7472    make it conditional. If the requested resource has not been modified
 7473    since the time specified in this field, the server SHOULD perform the
 7474    requested operation as if the If-Unmodified-Since header were not
 7475    present.
 7476 
 7477    If the requested variant has been modified since the specified time,
 7478    the server MUST NOT perform the requested operation, and MUST return
 7479    a 412 (Precondition Failed).
 7480 
 7481       If-Unmodified-Since = "If-Unmodified-Since" ":" HTTP-date
 7482 
 7483    An example of the field is:
 7484 
 7485        If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT
 7486 
 7487    If the request normally (i.e., without the If-Unmodified-Since
 7488    header) would result in anything other than a 2xx or 412 status, the
 7489    If-Unmodified-Since header SHOULD be ignored.
 7490 
 7491    If the specified date is invalid, the header is ignored.
 7492 
 7493    The result of a request having both an If-Unmodified-Since header
 7494    field and either an If-None-Match or an If-Modified-Since header
 7495    fields is undefined by this specification.
 7496 
 7497 14.29 Last-Modified
 7498 
 7499    The Last-Modified entity-header field indicates the date and time at
 7500    which the origin server believes the variant was last modified.
 7501 
 7502        Last-Modified  = "Last-Modified" ":" HTTP-date
 7503 
 7504 
 7505 
 7506 Fielding, et al.            Standards Track                   [Page 134]
 7507 
 7508 RFC 2616                        HTTP/1.1                       June 1999
 7509 
 7510 
 7511    An example of its use is
 7512 
 7513        Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
 7514 
 7515    The exact meaning of this header field depends on the implementation
 7516    of the origin server and the nature of the original resource. For
 7517    files, it may be just the file system last-modified time. For
 7518    entities with dynamically included parts, it may be the most recent
 7519    of the set of last-modify times for its component parts. For database
 7520    gateways, it may be the last-update time stamp of the record. For
 7521    virtual objects, it may be the last time the internal state changed.
 7522 
 7523    An origin server MUST NOT send a Last-Modified date which is later
 7524    than the server's time of message origination. In such cases, where
 7525    the resource's last modification would indicate some time in the
 7526    future, the server MUST replace that date with the message
 7527    origination date.
 7528 
 7529    An origin server SHOULD obtain the Last-Modified value of the entity
 7530    as close as possible to the time that it generates the Date value of
 7531    its response. This allows a recipient to make an accurate assessment
 7532    of the entity's modification time, especially if the entity changes
 7533    near the time that the response is generated.
 7534 
 7535    HTTP/1.1 servers SHOULD send Last-Modified whenever feasible.
 7536 
 7537 14.30 Location
 7538 
 7539    The Location response-header field is used to redirect the recipient
 7540    to a location other than the Request-URI for completion of the
 7541    request or identification of a new resource. For 201 (Created)
 7542    responses, the Location is that of the new resource which was created
 7543    by the request. For 3xx responses, the location SHOULD indicate the
 7544    server's preferred URI for automatic redirection to the resource. The
 7545    field value consists of a single absolute URI.
 7546 
 7547        Location       = "Location" ":" absoluteURI
 7548 
 7549    An example is:
 7550 
 7551        Location: http://www.w3.org/pub/WWW/People.html
 7552 
 7553       Note: The Content-Location header field (section 14.14) differs
 7554       from Location in that the Content-Location identifies the original
 7555       location of the entity enclosed in the request. It is therefore
 7556       possible for a response to contain header fields for both Location
 7557       and Content-Location. Also see section 13.10 for cache
 7558       requirements of some methods.
 7559 
 7560 
 7561 
 7562 Fielding, et al.            Standards Track                   [Page 135]
 7563 
 7564 RFC 2616                        HTTP/1.1                       June 1999
 7565 
 7566 
 7567 14.31 Max-Forwards
 7568 
 7569    The Max-Forwards request-header field provides a mechanism with the
 7570    TRACE (section 9.8) and OPTIONS (section 9.2) methods to limit the
 7571    number of proxies or gateways that can forward the request to the
 7572    next inbound server. This can be useful when the client is attempting
 7573    to trace a request chain which appears to be failing or looping in
 7574    mid-chain.
 7575 
 7576        Max-Forwards   = "Max-Forwards" ":" 1*DIGIT
 7577 
 7578    The Max-Forwards value is a decimal integer indicating the remaining
 7579    number of times this request message may be forwarded.
 7580 
 7581    Each proxy or gateway recipient of a TRACE or OPTIONS request
 7582    containing a Max-Forwards header field MUST check and update its
 7583    value prior to forwarding the request. If the received value is zero
 7584    (0), the recipient MUST NOT forward the request; instead, it MUST
 7585    respond as the final recipient. If the received Max-Forwards value is
 7586    greater than zero, then the forwarded message MUST contain an updated
 7587    Max-Forwards field with a value decremented by one (1).
 7588 
 7589    The Max-Forwards header field MAY be ignored for all other methods
 7590    defined by this specification and for any extension methods for which
 7591    it is not explicitly referred to as part of that method definition.
 7592 
 7593 14.32 Pragma
 7594 
 7595    The Pragma general-header field is used to include implementation-
 7596    specific directives that might apply to any recipient along the
 7597    request/response chain. All pragma directives specify optional
 7598    behavior from the viewpoint of the protocol; however, some systems
 7599    MAY require that behavior be consistent with the directives.
 7600 
 7601        Pragma            = "Pragma" ":" 1#pragma-directive
 7602        pragma-directive  = "no-cache" | extension-pragma
 7603        extension-pragma  = token [ "=" ( token | quoted-string ) ]
 7604 
 7605    When the no-cache directive is present in a request message, an
 7606    application SHOULD forward the request toward the origin server even
 7607    if it has a cached copy of what is being requested. This pragma
 7608    directive has the same semantics as the no-cache cache-directive (see
 7609    section 14.9) and is defined here for backward compatibility with
 7610    HTTP/1.0. Clients SHOULD include both header fields when a no-cache
 7611    request is sent to a server not known to be HTTP/1.1 compliant.
 7612 
 7613 
 7614 
 7615 
 7616 
 7617 
 7618 Fielding, et al.            Standards Track                   [Page 136]
 7619 
 7620 RFC 2616                        HTTP/1.1                       June 1999
 7621 
 7622 
 7623    Pragma directives MUST be passed through by a proxy or gateway
 7624    application, regardless of their significance to that application,
 7625    since the directives might be applicable to all recipients along the
 7626    request/response chain. It is not possible to specify a pragma for a
 7627    specific recipient; however, any pragma directive not relevant to a
 7628    recipient SHOULD be ignored by that recipient.
 7629 
 7630    HTTP/1.1 caches SHOULD treat "Pragma: no-cache" as if the client had
 7631    sent "Cache-Control: no-cache". No new Pragma directives will be
 7632    defined in HTTP.
 7633 
 7634       Note: because the meaning of "Pragma: no-cache as a response
 7635       header field is not actually specified, it does not provide a
 7636       reliable replacement for "Cache-Control: no-cache" in a response
 7637 
 7638 14.33 Proxy-Authenticate
 7639 
 7640    The Proxy-Authenticate response-header field MUST be included as part
 7641    of a 407 (Proxy Authentication Required) response. The field value
 7642    consists of a challenge that indicates the authentication scheme and
 7643    parameters applicable to the proxy for this Request-URI.
 7644 
 7645        Proxy-Authenticate  = "Proxy-Authenticate" ":" 1#challenge
 7646 
 7647    The HTTP access authentication process is described in "HTTP
 7648    Authentication: Basic and Digest Access Authentication" [43]. Unlike
 7649    WWW-Authenticate, the Proxy-Authenticate header field applies only to
 7650    the current connection and SHOULD NOT be passed on to downstream
 7651    clients. However, an intermediate proxy might need to obtain its own
 7652    credentials by requesting them from the downstream client, which in
 7653    some circumstances will appear as if the proxy is forwarding the
 7654    Proxy-Authenticate header field.
 7655 
 7656 14.34 Proxy-Authorization
 7657 
 7658    The Proxy-Authorization request-header field allows the client to
 7659    identify itself (or its user) to a proxy which requires
 7660    authentication. The Proxy-Authorization field value consists of
 7661    credentials containing the authentication information of the user
 7662    agent for the proxy and/or realm of the resource being requested.
 7663 
 7664        Proxy-Authorization     = "Proxy-Authorization" ":" credentials
 7665 
 7666    The HTTP access authentication process is described in "HTTP
 7667    Authentication: Basic and Digest Access Authentication" [43] . Unlike
 7668    Authorization, the Proxy-Authorization header field applies only to
 7669    the next outbound proxy that demanded authentication using the Proxy-
 7670    Authenticate field. When multiple proxies are used in a chain, the
 7671 
 7672 
 7673 
 7674 Fielding, et al.            Standards Track                   [Page 137]
 7675 
 7676 RFC 2616                        HTTP/1.1                       June 1999
 7677 
 7678 
 7679    Proxy-Authorization header field is consumed by the first outbound
 7680    proxy that was expecting to receive credentials. A proxy MAY relay
 7681    the credentials from the client request to the next proxy if that is
 7682    the mechanism by which the proxies cooperatively authenticate a given
 7683    request.
 7684 
 7685 14.35 Range
 7686 
 7687 14.35.1 Byte Ranges
 7688 
 7689    Since all HTTP entities are represented in HTTP messages as sequences
 7690    of bytes, the concept of a byte range is meaningful for any HTTP
 7691    entity. (However, not all clients and servers need to support byte-
 7692    range operations.)
 7693 
 7694    Byte range specifications in HTTP apply to the sequence of bytes in
 7695    the entity-body (not necessarily the same as the message-body).
 7696 
 7697    A byte range operation MAY specify a single range of bytes, or a set
 7698    of ranges within a single entity.
 7699 
 7700        ranges-specifier = byte-ranges-specifier
 7701        byte-ranges-specifier = bytes-unit "=" byte-range-set
 7702        byte-range-set  = 1#( byte-range-spec | suffix-byte-range-spec )
 7703        byte-range-spec = first-byte-pos "-" [last-byte-pos]
 7704        first-byte-pos  = 1*DIGIT
 7705        last-byte-pos   = 1*DIGIT
 7706 
 7707    The first-byte-pos value in a byte-range-spec gives the byte-offset
 7708    of the first byte in a range. The last-byte-pos value gives the
 7709    byte-offset of the last byte in the range; that is, the byte
 7710    positions specified are inclusive. Byte offsets start at zero.
 7711 
 7712    If the last-byte-pos value is present, it MUST be greater than or
 7713    equal to the first-byte-pos in that byte-range-spec, or the byte-
 7714    range-spec is syntactically invalid. The recipient of a byte-range-
 7715    set that includes one or more syntactically invalid byte-range-spec
 7716    values MUST ignore the header field that includes that byte-range-
 7717    set.
 7718 
 7719    If the last-byte-pos value is absent, or if the value is greater than
 7720    or equal to the current length of the entity-body, last-byte-pos is
 7721    taken to be equal to one less than the current length of the entity-
 7722    body in bytes.
 7723 
 7724    By its choice of last-byte-pos, a client can limit the number of
 7725    bytes retrieved without knowing the size of the entity.
 7726 
 7727 
 7728 
 7729 
 7730 Fielding, et al.            Standards Track                   [Page 138]
 7731 
 7732 RFC 2616                        HTTP/1.1                       June 1999
 7733 
 7734 
 7735        suffix-byte-range-spec = "-" suffix-length
 7736        suffix-length = 1*DIGIT
 7737 
 7738    A suffix-byte-range-spec is used to specify the suffix of the
 7739    entity-body, of a length given by the suffix-length value. (That is,
 7740    this form specifies the last N bytes of an entity-body.) If the
 7741    entity is shorter than the specified suffix-length, the entire
 7742    entity-body is used.
 7743 
 7744    If a syntactically valid byte-range-set includes at least one byte-
 7745    range-spec whose first-byte-pos is less than the current length of
 7746    the entity-body, or at least one suffix-byte-range-spec with a non-
 7747    zero suffix-length, then the byte-range-set is satisfiable.
 7748    Otherwise, the byte-range-set is unsatisfiable. If the byte-range-set
 7749    is unsatisfiable, the server SHOULD return a response with a status
 7750    of 416 (Requested range not satisfiable). Otherwise, the server
 7751    SHOULD return a response with a status of 206 (Partial Content)
 7752    containing the satisfiable ranges of the entity-body.
 7753 
 7754    Examples of byte-ranges-specifier values (assuming an entity-body of
 7755    length 10000):
 7756 
 7757       - The first 500 bytes (byte offsets 0-499, inclusive):  bytes=0-
 7758         499
 7759 
 7760       - The second 500 bytes (byte offsets 500-999, inclusive):
 7761         bytes=500-999
 7762 
 7763       - The final 500 bytes (byte offsets 9500-9999, inclusive):
 7764         bytes=-500
 7765 
 7766       - Or bytes=9500-
 7767 
 7768       - The first and last bytes only (bytes 0 and 9999):  bytes=0-0,-1
 7769 
 7770       - Several legal but not canonical specifications of the second 500
 7771         bytes (byte offsets 500-999, inclusive):
 7772          bytes=500-600,601-999
 7773          bytes=500-700,601-999
 7774 
 7775 14.35.2 Range Retrieval Requests
 7776 
 7777    HTTP retrieval requests using conditional or unconditional GET
 7778    methods MAY request one or more sub-ranges of the entity, instead of
 7779    the entire entity, using the Range request header, which applies to
 7780    the entity returned as the result of the request:
 7781 
 7782       Range = "Range" ":" ranges-specifier
 7783 
 7784 
 7785 
 7786 Fielding, et al.            Standards Track                   [Page 139]
 7787 
 7788 RFC 2616                        HTTP/1.1                       June 1999
 7789 
 7790 
 7791    A server MAY ignore the Range header. However, HTTP/1.1 origin
 7792    servers and intermediate caches ought to support byte ranges when
 7793    possible, since Range supports efficient recovery from partially
 7794    failed transfers, and supports efficient partial retrieval of large
 7795    entities.
 7796 
 7797    If the server supports the Range header and the specified range or
 7798    ranges are appropriate for the entity:
 7799 
 7800       - The presence of a Range header in an unconditional GET modifies
 7801         what is returned if the GET is otherwise successful. In other
 7802         words, the response carries a status code of 206 (Partial
 7803         Content) instead of 200 (OK).
 7804 
 7805       - The presence of a Range header in a conditional GET (a request
 7806         using one or both of If-Modified-Since and If-None-Match, or
 7807         one or both of If-Unmodified-Since and If-Match) modifies what
 7808         is returned if the GET is otherwise successful and the
 7809         condition is true. It does not affect the 304 (Not Modified)
 7810         response returned if the conditional is false.
 7811 
 7812    In some cases, it might be more appropriate to use the If-Range
 7813    header (see section 14.27) in addition to the Range header.
 7814 
 7815    If a proxy that supports ranges receives a Range request, forwards
 7816    the request to an inbound server, and receives an entire entity in
 7817    reply, it SHOULD only return the requested range to its client. It
 7818    SHOULD store the entire received response in its cache if that is
 7819    consistent with its cache allocation policies.
 7820 
 7821 14.36 Referer
 7822 
 7823    The Referer[sic] request-header field allows the client to specify,
 7824    for the server's benefit, the address (URI) of the resource from
 7825    which the Request-URI was obtained (the "referrer", although the
 7826    header field is misspelled.) The Referer request-header allows a
 7827    server to generate lists of back-links to resources for interest,
 7828    logging, optimized caching, etc. It also allows obsolete or mistyped
 7829    links to be traced for maintenance. The Referer field MUST NOT be
 7830    sent if the Request-URI was obtained from a source that does not have
 7831    its own URI, such as input from the user keyboard.
 7832 
 7833        Referer        = "Referer" ":" ( absoluteURI | relativeURI )
 7834 
 7835    Example:
 7836 
 7837        Referer: http://www.w3.org/hypertext/DataSources/Overview.html
 7838 
 7839 
 7840 
 7841 
 7842 Fielding, et al.            Standards Track                   [Page 140]
 7843 
 7844 RFC 2616                        HTTP/1.1                       June 1999
 7845 
 7846 
 7847    If the field value is a relative URI, it SHOULD be interpreted
 7848    relative to the Request-URI. The URI MUST NOT include a fragment. See
 7849    section 15.1.3 for security considerations.
 7850 
 7851 14.37 Retry-After
 7852 
 7853    The Retry-After response-header field can be used with a 503 (Service
 7854    Unavailable) response to indicate how long the service is expected to
 7855    be unavailable to the requesting client. This field MAY also be used
 7856    with any 3xx (Redirection) response to indicate the minimum time the
 7857    user-agent is asked wait before issuing the redirected request. The
 7858    value of this field can be either an HTTP-date or an integer number
 7859    of seconds (in decimal) after the time of the response.
 7860 
 7861        Retry-After  = "Retry-After" ":" ( HTTP-date | delta-seconds )
 7862 
 7863    Two examples of its use are
 7864 
 7865        Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
 7866        Retry-After: 120
 7867 
 7868    In the latter example, the delay is 2 minutes.
 7869 
 7870 14.38 Server
 7871 
 7872    The Server response-header field contains information about the
 7873    software used by the origin server to handle the request. The field
 7874    can contain multiple product tokens (section 3.8) and comments
 7875    identifying the server and any significant subproducts. The product
 7876    tokens are listed in order of their significance for identifying the
 7877    application.
 7878 
 7879        Server         = "Server" ":" 1*( product | comment )
 7880 
 7881    Example:
 7882 
 7883        Server: CERN/3.0 libwww/2.17
 7884 
 7885    If the response is being forwarded through a proxy, the proxy
 7886    application MUST NOT modify the Server response-header. Instead, it
 7887    SHOULD include a Via field (as described in section 14.45).
 7888 
 7889       Note: Revealing the specific software version of the server might
 7890       allow the server machine to become more vulnerable to attacks
 7891       against software that is known to contain security holes. Server
 7892       implementors are encouraged to make this field a configurable
 7893       option.
 7894 
 7895 
 7896 
 7897 
 7898 Fielding, et al.            Standards Track                   [Page 141]
 7899 
 7900 RFC 2616                        HTTP/1.1                       June 1999
 7901 
 7902 
 7903 14.39 TE
 7904 
 7905    The TE request-header field indicates what extension transfer-codings
 7906    it is willing to accept in the response and whether or not it is
 7907    willing to accept trailer fields in a chunked transfer-coding. Its
 7908    value may consist of the keyword "trailers" and/or a comma-separated
 7909    list of extension transfer-coding names with optional accept
 7910    parameters (as described in section 3.6).
 7911 
 7912        TE        = "TE" ":" #( t-codings )
 7913        t-codings = "trailers" | ( transfer-extension [ accept-params ] )
 7914 
 7915    The presence of the keyword "trailers" indicates that the client is
 7916    willing to accept trailer fields in a chunked transfer-coding, as
 7917    defined in section 3.6.1. This keyword is reserved for use with
 7918    transfer-coding values even though it does not itself represent a
 7919    transfer-coding.
 7920 
 7921    Examples of its use are:
 7922 
 7923        TE: deflate
 7924        TE:
 7925        TE: trailers, deflate;q=0.5
 7926 
 7927    The TE header field only applies to the immediate connection.
 7928    Therefore, the keyword MUST be supplied within a Connection header
 7929    field (section 14.10) whenever TE is present in an HTTP/1.1 message.
 7930 
 7931    A server tests whether a transfer-coding is acceptable, according to
 7932    a TE field, using these rules:
 7933 
 7934       1. The "chunked" transfer-coding is always acceptable. If the
 7935          keyword "trailers" is listed, the client indicates that it is
 7936          willing to accept trailer fields in the chunked response on
 7937          behalf of itself and any downstream clients. The implication is
 7938          that, if given, the client is stating that either all
 7939          downstream clients are willing to accept trailer fields in the
 7940          forwarded response, or that it will attempt to buffer the
 7941          response on behalf of downstream recipients.
 7942 
 7943          Note: HTTP/1.1 does not define any means to limit the size of a
 7944          chunked response such that a client can be assured of buffering
 7945          the entire response.
 7946 
 7947       2. If the transfer-coding being tested is one of the transfer-
 7948          codings listed in the TE field, then it is acceptable unless it
 7949          is accompanied by a qvalue of 0. (As defined in section 3.9, a
 7950          qvalue of 0 means "not acceptable.")
 7951 
 7952 
 7953 
 7954 Fielding, et al.            Standards Track                   [Page 142]
 7955 
 7956 RFC 2616                        HTTP/1.1                       June 1999
 7957 
 7958 
 7959       3. If multiple transfer-codings are acceptable, then the
 7960          acceptable transfer-coding with the highest non-zero qvalue is
 7961          preferred.  The "chunked" transfer-coding always has a qvalue
 7962          of 1.
 7963 
 7964    If the TE field-value is empty or if no TE field is present, the only
 7965    transfer-coding  is "chunked". A message with no transfer-coding is
 7966    always acceptable.
 7967 
 7968 14.40 Trailer
 7969 
 7970    The Trailer general field value indicates that the given set of
 7971    header fields is present in the trailer of a message encoded with
 7972    chunked transfer-coding.
 7973 
 7974        Trailer  = "Trailer" ":" 1#field-name
 7975 
 7976    An HTTP/1.1 message SHOULD include a Trailer header field in a
 7977    message using chunked transfer-coding with a non-empty trailer. Doing
 7978    so allows the recipient to know which header fields to expect in the
 7979    trailer.
 7980 
 7981    If no Trailer header field is present, the trailer SHOULD NOT include
 7982    any header fields. See section 3.6.1 for restrictions on the use of
 7983    trailer fields in a "chunked" transfer-coding.
 7984 
 7985    Message header fields listed in the Trailer header field MUST NOT
 7986    include the following header fields:
 7987 
 7988       . Transfer-Encoding
 7989 
 7990       . Content-Length
 7991 
 7992       . Trailer
 7993 
 7994 14.41 Transfer-Encoding
 7995 
 7996    The Transfer-Encoding general-header field indicates what (if any)
 7997    type of transformation has been applied to the message body in order
 7998    to safely transfer it between the sender and the recipient. This
 7999    differs from the content-coding in that the transfer-coding is a
 8000    property of the message, not of the entity.
 8001 
 8002      Transfer-Encoding       = "Transfer-Encoding" ":" 1#transfer-coding
 8003 
 8004    Transfer-codings are defined in section 3.6. An example is:
 8005 
 8006      Transfer-Encoding: chunked
 8007 
 8008 
 8009 
 8010 Fielding, et al.            Standards Track                   [Page 143]
 8011 
 8012 RFC 2616                        HTTP/1.1                       June 1999
 8013 
 8014 
 8015    If multiple encodings have been applied to an entity, the transfer-
 8016    codings MUST be listed in the order in which they were applied.
 8017    Additional information about the encoding parameters MAY be provided
 8018    by other entity-header fields not defined by this specification.
 8019 
 8020    Many older HTTP/1.0 applications do not understand the Transfer-
 8021    Encoding header.
 8022 
 8023 14.42 Upgrade
 8024 
 8025    The Upgrade general-header allows the client to specify what
 8026    additional communication protocols it supports and would like to use
 8027    if the server finds it appropriate to switch protocols. The server
 8028    MUST use the Upgrade header field within a 101 (Switching Protocols)
 8029    response to indicate which protocol(s) are being switched.
 8030 
 8031        Upgrade        = "Upgrade" ":" 1#product
 8032 
 8033    For example,
 8034 
 8035        Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
 8036 
 8037    The Upgrade header field is intended to provide a simple mechanism
 8038    for transition from HTTP/1.1 to some other, incompatible protocol. It
 8039    does so by allowing the client to advertise its desire to use another
 8040    protocol, such as a later version of HTTP with a higher major version
 8041    number, even though the current request has been made using HTTP/1.1.
 8042    This eases the difficult transition between incompatible protocols by
 8043    allowing the client to initiate a request in the more commonly
 8044    supported protocol while indicating to the server that it would like
 8045    to use a "better" protocol if available (where "better" is determined
 8046    by the server, possibly according to the nature of the method and/or
 8047    resource being requested).
 8048 
 8049    The Upgrade header field only applies to switching application-layer
 8050    protocols upon the existing transport-layer connection. Upgrade
 8051    cannot be used to insist on a protocol change; its acceptance and use
 8052    by the server is optional. The capabilities and nature of the
 8053    application-layer communication after the protocol change is entirely
 8054    dependent upon the new protocol chosen, although the first action
 8055    after changing the protocol MUST be a response to the initial HTTP
 8056    request containing the Upgrade header field.
 8057 
 8058    The Upgrade header field only applies to the immediate connection.
 8059    Therefore, the upgrade keyword MUST be supplied within a Connection
 8060    header field (section 14.10) whenever Upgrade is present in an
 8061    HTTP/1.1 message.
 8062 
 8063 
 8064 
 8065 
 8066 Fielding, et al.            Standards Track                   [Page 144]
 8067 
 8068 RFC 2616                        HTTP/1.1                       June 1999
 8069 
 8070 
 8071    The Upgrade header field cannot be used to indicate a switch to a
 8072    protocol on a different connection. For that purpose, it is more
 8073    appropriate to use a 301, 302, 303, or 305 redirection response.
 8074 
 8075    This specification only defines the protocol name "HTTP" for use by
 8076    the family of Hypertext Transfer Protocols, as defined by the HTTP
 8077    version rules of section 3.1 and future updates to this
 8078    specification. Any token can be used as a protocol name; however, it
 8079    will only be useful if both the client and server associate the name
 8080    with the same protocol.
 8081 
 8082 14.43 User-Agent
 8083 
 8084    The User-Agent request-header field contains information about the
 8085    user agent originating the request. This is for statistical purposes,
 8086    the tracing of protocol violations, and automated recognition of user
 8087    agents for the sake of tailoring responses to avoid particular user
 8088    agent limitations. User agents SHOULD include this field with
 8089    requests. The field can contain multiple product tokens (section 3.8)
 8090    and comments identifying the agent and any subproducts which form a
 8091    significant part of the user agent. By convention, the product tokens
 8092    are listed in order of their significance for identifying the
 8093    application.
 8094 
 8095        User-Agent     = "User-Agent" ":" 1*( product | comment )
 8096 
 8097    Example:
 8098 
 8099        User-Agent: CERN-LineMode/2.15 libwww/2.17b3
 8100 
 8101 14.44 Vary
 8102 
 8103    The Vary field value indicates the set of request-header fields that
 8104    fully determines, while the response is fresh, whether a cache is
 8105    permitted to use the response to reply to a subsequent request
 8106    without revalidation. For uncacheable or stale responses, the Vary
 8107    field value advises the user agent about the criteria that were used
 8108    to select the representation. A Vary field value of "*" implies that
 8109    a cache cannot determine from the request headers of a subsequent
 8110    request whether this response is the appropriate representation. See
 8111    section 13.6 for use of the Vary header field by caches.
 8112 
 8113        Vary  = "Vary" ":" ( "*" | 1#field-name )
 8114 
 8115    An HTTP/1.1 server SHOULD include a Vary header field with any
 8116    cacheable response that is subject to server-driven negotiation.
 8117    Doing so allows a cache to properly interpret future requests on that
 8118    resource and informs the user agent about the presence of negotiation
 8119 
 8120 
 8121 
 8122 Fielding, et al.            Standards Track                   [Page 145]
 8123 
 8124 RFC 2616                        HTTP/1.1                       June 1999
 8125 
 8126 
 8127    on that resource. A server MAY include a Vary header field with a
 8128    non-cacheable response that is subject to server-driven negotiation,
 8129    since this might provide the user agent with useful information about
 8130    the dimensions over which the response varies at the time of the
 8131    response.
 8132 
 8133    A Vary field value consisting of a list of field-names signals that
 8134    the representation selected for the response is based on a selection
 8135    algorithm which considers ONLY the listed request-header field values
 8136    in selecting the most appropriate representation. A cache MAY assume
 8137    that the same selection will be made for future requests with the
 8138    same values for the listed field names, for the duration of time for
 8139    which the response is fresh.
 8140 
 8141    The field-names given are not limited to the set of standard
 8142    request-header fields defined by this specification. Field names are
 8143    case-insensitive.
 8144 
 8145    A Vary field value of "*" signals that unspecified parameters not
 8146    limited to the request-headers (e.g., the network address of the
 8147    client), play a role in the selection of the response representation.
 8148    The "*" value MUST NOT be generated by a proxy server; it may only be
 8149    generated by an origin server.
 8150 
 8151 14.45  Via
 8152 
 8153    The Via general-header field MUST be used by gateways and proxies to
 8154    indicate the intermediate protocols and recipients between the user
 8155    agent and the server on requests, and between the origin server and
 8156    the client on responses. It is analogous to the "Received" field of
 8157    RFC 822 [9] and is intended to be used for tracking message forwards,
 8158    avoiding request loops, and identifying the protocol capabilities of
 8159    all senders along the request/response chain.
 8160 
 8161       Via =  "Via" ":" 1#( received-protocol received-by [ comment ] )
 8162       received-protocol = [ protocol-name "/" ] protocol-version
 8163       protocol-name     = token
 8164       protocol-version  = token
 8165       received-by       = ( host [ ":" port ] ) | pseudonym
 8166       pseudonym         = token
 8167 
 8168    The received-protocol indicates the protocol version of the message
 8169    received by the server or client along each segment of the
 8170    request/response chain. The received-protocol version is appended to
 8171    the Via field value when the message is forwarded so that information
 8172    about the protocol capabilities of upstream applications remains
 8173    visible to all recipients.
 8174 
 8175 
 8176 
 8177 
 8178 Fielding, et al.            Standards Track                   [Page 146]
 8179 
 8180 RFC 2616                        HTTP/1.1                       June 1999
 8181 
 8182 
 8183    The protocol-name is optional if and only if it would be "HTTP". The
 8184    received-by field is normally the host and optional port number of a
 8185    recipient server or client that subsequently forwarded the message.
 8186    However, if the real host is considered to be sensitive information,
 8187    it MAY be replaced by a pseudonym. If the port is not given, it MAY
 8188    be assumed to be the default port of the received-protocol.
 8189 
 8190    Multiple Via field values represents each proxy or gateway that has
 8191    forwarded the message. Each recipient MUST append its information
 8192    such that the end result is ordered according to the sequence of
 8193    forwarding applications.
 8194 
 8195    Comments MAY be used in the Via header field to identify the software
 8196    of the recipient proxy or gateway, analogous to the User-Agent and
 8197    Server header fields. However, all comments in the Via field are
 8198    optional and MAY be removed by any recipient prior to forwarding the
 8199    message.
 8200 
 8201    For example, a request message could be sent from an HTTP/1.0 user
 8202    agent to an internal proxy code-named "fred", which uses HTTP/1.1 to
 8203    forward the request to a public proxy at nowhere.com, which completes
 8204    the request by forwarding it to the origin server at www.ics.uci.edu.
 8205    The request received by www.ics.uci.edu would then have the following
 8206    Via header field:
 8207 
 8208        Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)
 8209 
 8210    Proxies and gateways used as a portal through a network firewall
 8211    SHOULD NOT, by default, forward the names and ports of hosts within
 8212    the firewall region. This information SHOULD only be propagated if
 8213    explicitly enabled. If not enabled, the received-by host of any host
 8214    behind the firewall SHOULD be replaced by an appropriate pseudonym
 8215    for that host.
 8216 
 8217    For organizations that have strong privacy requirements for hiding
 8218    internal structures, a proxy MAY combine an ordered subsequence of
 8219    Via header field entries with identical received-protocol values into
 8220    a single such entry. For example,
 8221 
 8222        Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
 8223 
 8224         could be collapsed to
 8225 
 8226        Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
 8227 
 8228 
 8229 
 8230 
 8231 
 8232 
 8233 
 8234 Fielding, et al.            Standards Track                   [Page 147]
 8235 
 8236 RFC 2616                        HTTP/1.1                       June 1999
 8237 
 8238 
 8239    Applications SHOULD NOT combine multiple entries unless they are all
 8240    under the same organizational control and the hosts have already been
 8241    replaced by pseudonyms. Applications MUST NOT combine entries which
 8242    have different received-protocol values.
 8243 
 8244 14.46 Warning
 8245 
 8246    The Warning general-header field is used to carry additional
 8247    information about the status or transformation of a message which
 8248    might not be reflected in the message. This information is typically
 8249    used to warn about a possible lack of semantic transparency from
 8250    caching operations or transformations applied to the entity body of
 8251    the message.
 8252 
 8253    Warning headers are sent with responses using:
 8254 
 8255        Warning    = "Warning" ":" 1#warning-value
 8256 
 8257        warning-value = warn-code SP warn-agent SP warn-text
 8258                                              [SP warn-date]
 8259 
 8260        warn-code  = 3DIGIT
 8261        warn-agent = ( host [ ":" port ] ) | pseudonym
 8262                        ; the name or pseudonym of the server adding
 8263                        ; the Warning header, for use in debugging
 8264        warn-text  = quoted-string
 8265        warn-date  = <"> HTTP-date <">
 8266 
 8267    A response MAY carry more than one Warning header.
 8268 
 8269    The warn-text SHOULD be in a natural language and character set that
 8270    is most likely to be intelligible to the human user receiving the
 8271    response. This decision MAY be based on any available knowledge, such
 8272    as the location of the cache or user, the Accept-Language field in a
 8273    request, the Content-Language field in a response, etc. The default
 8274    language is English and the default character set is ISO-8859-1.
 8275 
 8276    If a character set other than ISO-8859-1 is used, it MUST be encoded
 8277    in the warn-text using the method described in RFC 2047 [14].
 8278 
 8279    Warning headers can in general be applied to any message, however
 8280    some specific warn-codes are specific to caches and can only be
 8281    applied to response messages. New Warning headers SHOULD be added
 8282    after any existing Warning headers. A cache MUST NOT delete any
 8283    Warning header that it received with a message. However, if a cache
 8284    successfully validates a cache entry, it SHOULD remove any Warning
 8285    headers previously attached to that entry except as specified for
 8286 
 8287 
 8288 
 8289 
 8290 Fielding, et al.            Standards Track                   [Page 148]
 8291 
 8292 RFC 2616                        HTTP/1.1                       June 1999
 8293 
 8294 
 8295    specific Warning codes. It MUST then add any Warning headers received
 8296    in the validating response. In other words, Warning headers are those
 8297    that would be attached to the most recent relevant response.
 8298 
 8299    When multiple Warning headers are attached to a response, the user
 8300    agent ought to inform the user of as many of them as possible, in the
 8301    order that they appear in the response. If it is not possible to
 8302    inform the user of all of the warnings, the user agent SHOULD follow
 8303    these heuristics:
 8304 
 8305       - Warnings that appear early in the response take priority over
 8306         those appearing later in the response.
 8307 
 8308       - Warnings in the user's preferred character set take priority
 8309         over warnings in other character sets but with identical warn-
 8310         codes and warn-agents.
 8311 
 8312    Systems that generate multiple Warning headers SHOULD order them with
 8313    this user agent behavior in mind.
 8314 
 8315    Requirements for the behavior of caches with respect to Warnings are
 8316    stated in section 13.1.2.
 8317 
 8318    This is a list of the currently-defined warn-codes, each with a
 8319    recommended warn-text in English, and a description of its meaning.
 8320 
 8321    110 Response is stale
 8322      MUST be included whenever the returned response is stale.
 8323 
 8324    111 Revalidation failed
 8325      MUST be included if a cache returns a stale response because an
 8326      attempt to revalidate the response failed, due to an inability to
 8327      reach the server.
 8328 
 8329    112 Disconnected operation
 8330      SHOULD be included if the cache is intentionally disconnected from
 8331      the rest of the network for a period of time.
 8332 
 8333    113 Heuristic expiration
 8334      MUST be included if the cache heuristically chose a freshness
 8335      lifetime greater than 24 hours and the response's age is greater
 8336      than 24 hours.
 8337 
 8338    199 Miscellaneous warning
 8339      The warning text MAY include arbitrary information to be presented
 8340      to a human user, or logged. A system receiving this warning MUST
 8341      NOT take any automated action, besides presenting the warning to
 8342      the user.
 8343 
 8344 
 8345 
 8346 Fielding, et al.            Standards Track                   [Page 149]
 8347 
 8348 RFC 2616                        HTTP/1.1                       June 1999
 8349 
 8350 
 8351    214 Transformation applied
 8352      MUST be added by an intermediate cache or proxy if it applies any
 8353      transformation changing the content-coding (as specified in the
 8354      Content-Encoding header) or media-type (as specified in the
 8355      Content-Type header) of the response, or the entity-body of the
 8356      response, unless this Warning code already appears in the response.
 8357 
 8358    299 Miscellaneous persistent warning
 8359      The warning text MAY include arbitrary information to be presented
 8360      to a human user, or logged. A system receiving this warning MUST
 8361      NOT take any automated action.
 8362 
 8363    If an implementation sends a message with one or more Warning headers
 8364    whose version is HTTP/1.0 or lower, then the sender MUST include in
 8365    each warning-value a warn-date that matches the date in the response.
 8366 
 8367    If an implementation receives a message with a warning-value that
 8368    includes a warn-date, and that warn-date is different from the Date
 8369    value in the response, then that warning-value MUST be deleted from
 8370    the message before storing, forwarding, or using it. (This prevents
 8371    bad consequences of naive caching of Warning header fields.) If all
 8372    of the warning-values are deleted for this reason, the Warning header
 8373    MUST be deleted as well.
 8374 
 8375 14.47 WWW-Authenticate
 8376 
 8377    The WWW-Authenticate response-header field MUST be included in 401
 8378    (Unauthorized) response messages. The field value consists of at
 8379    least one challenge that indicates the authentication scheme(s) and
 8380    parameters applicable to the Request-URI.
 8381 
 8382        WWW-Authenticate  = "WWW-Authenticate" ":" 1#challenge
 8383 
 8384    The HTTP access authentication process is described in "HTTP
 8385    Authentication: Basic and Digest Access Authentication" [43]. User
 8386    agents are advised to take special care in parsing the WWW-
 8387    Authenticate field value as it might contain more than one challenge,
 8388    or if more than one WWW-Authenticate header field is provided, the
 8389    contents of a challenge itself can contain a comma-separated list of
 8390    authentication parameters.
 8391 
 8392 15 Security Considerations
 8393 
 8394    This section is meant to inform application developers, information
 8395    providers, and users of the security limitations in HTTP/1.1 as
 8396    described by this document. The discussion does not include
 8397    definitive solutions to the problems revealed, though it does make
 8398    some suggestions for reducing security risks.
 8399 
 8400 
 8401 
 8402 Fielding, et al.            Standards Track                   [Page 150]
 8403 
 8404 RFC 2616                        HTTP/1.1                       June 1999
 8405 
 8406 
 8407 15.1 Personal Information
 8408 
 8409    HTTP clients are often privy to large amounts of personal information
 8410    (e.g. the user's name, location, mail address, passwords, encryption
 8411    keys, etc.), and SHOULD be very careful to prevent unintentional
 8412    leakage of this information via the HTTP protocol to other sources.
 8413    We very strongly recommend that a convenient interface be provided
 8414    for the user to control dissemination of such information, and that
 8415    designers and implementors be particularly careful in this area.
 8416    History shows that errors in this area often create serious security
 8417    and/or privacy problems and generate highly adverse publicity for the
 8418    implementor's company.
 8419 
 8420 15.1.1 Abuse of Server Log Information
 8421 
 8422    A server is in the position to save personal data about a user's
 8423    requests which might identify their reading patterns or subjects of
 8424    interest. This information is clearly confidential in nature and its
 8425    handling can be constrained by law in certain countries. People using
 8426    the HTTP protocol to provide data are responsible for ensuring that
 8427    such material is not distributed without the permission of any
 8428    individuals that are identifiable by the published results.
 8429 
 8430 15.1.2 Transfer of Sensitive Information
 8431 
 8432    Like any generic data transfer protocol, HTTP cannot regulate the
 8433    content of the data that is transferred, nor is there any a priori
 8434    method of determining the sensitivity of any particular piece of
 8435    information within the context of any given request. Therefore,
 8436    applications SHOULD supply as much control over this information as
 8437    possible to the provider of that information. Four header fields are
 8438    worth special mention in this context: Server, Via, Referer and From.
 8439 
 8440    Revealing the specific software version of the server might allow the
 8441    server machine to become more vulnerable to attacks against software
 8442    that is known to contain security holes. Implementors SHOULD make the
 8443    Server header field a configurable option.
 8444 
 8445    Proxies which serve as a portal through a network firewall SHOULD
 8446    take special precautions regarding the transfer of header information
 8447    that identifies the hosts behind the firewall. In particular, they
 8448    SHOULD remove, or replace with sanitized versions, any Via fields
 8449    generated behind the firewall.
 8450 
 8451    The Referer header allows reading patterns to be studied and reverse
 8452    links drawn. Although it can be very useful, its power can be abused
 8453    if user details are not separated from the information contained in
 8454 
 8455 
 8456 
 8457 
 8458 Fielding, et al.            Standards Track                   [Page 151]
 8459 
 8460 RFC 2616                        HTTP/1.1                       June 1999
 8461 
 8462 
 8463    the Referer. Even when the personal information has been removed, the
 8464    Referer header might indicate a private document's URI whose
 8465    publication would be inappropriate.
 8466 
 8467    The information sent in the From field might conflict with the user's
 8468    privacy interests or their site's security policy, and hence it
 8469    SHOULD NOT be transmitted without the user being able to disable,
 8470    enable, and modify the contents of the field. The user MUST be able
 8471    to set the contents of this field within a user preference or
 8472    application defaults configuration.
 8473 
 8474    We suggest, though do not require, that a convenient toggle interface
 8475    be provided for the user to enable or disable the sending of From and
 8476    Referer information.
 8477 
 8478    The User-Agent (section 14.43) or Server (section 14.38) header
 8479    fields can sometimes be used to determine that a specific client or
 8480    server have a particular security hole which might be exploited.
 8481    Unfortunately, this same information is often used for other valuable
 8482    purposes for which HTTP currently has no better mechanism.
 8483 
 8484 15.1.3 Encoding Sensitive Information in URI's
 8485 
 8486    Because the source of a link might be private information or might
 8487    reveal an otherwise private information source, it is strongly
 8488    recommended that the user be able to select whether or not the
 8489    Referer field is sent. For example, a browser client could have a
 8490    toggle switch for browsing openly/anonymously, which would
 8491    respectively enable/disable the sending of Referer and From
 8492    information.
 8493 
 8494    Clients SHOULD NOT include a Referer header field in a (non-secure)
 8495    HTTP request if the referring page was transferred with a secure
 8496    protocol.
 8497 
 8498    Authors of services which use the HTTP protocol SHOULD NOT use GET
 8499    based forms for the submission of sensitive data, because this will
 8500    cause this data to be encoded in the Request-URI. Many existing
 8501    servers, proxies, and user agents will log the request URI in some
 8502    place where it might be visible to third parties. Servers can use
 8503    POST-based form submission instead
 8504 
 8505 15.1.4 Privacy Issues Connected to Accept Headers
 8506 
 8507    Accept request-headers can reveal information about the user to all
 8508    servers which are accessed. The Accept-Language header in particular
 8509    can reveal information the user would consider to be of a private
 8510    nature, because the understanding of particular languages is often
 8511 
 8512 
 8513 
 8514 Fielding, et al.            Standards Track                   [Page 152]
 8515 
 8516 RFC 2616                        HTTP/1.1                       June 1999
 8517 
 8518 
 8519    strongly correlated to the membership of a particular ethnic group.
 8520    User agents which offer the option to configure the contents of an
 8521    Accept-Language header to be sent in every request are strongly
 8522    encouraged to let the configuration process include a message which
 8523    makes the user aware of the loss of privacy involved.
 8524 
 8525    An approach that limits the loss of privacy would be for a user agent
 8526    to omit the sending of Accept-Language headers by default, and to ask
 8527    the user whether or not to start sending Accept-Language headers to a
 8528    server if it detects, by looking for any Vary response-header fields
 8529    generated by the server, that such sending could improve the quality
 8530    of service.
 8531 
 8532    Elaborate user-customized accept header fields sent in every request,
 8533    in particular if these include quality values, can be used by servers
 8534    as relatively reliable and long-lived user identifiers. Such user
 8535    identifiers would allow content providers to do click-trail tracking,
 8536    and would allow collaborating content providers to match cross-server
 8537    click-trails or form submissions of individual users. Note that for
 8538    many users not behind a proxy, the network address of the host
 8539    running the user agent will also serve as a long-lived user
 8540    identifier. In environments where proxies are used to enhance
 8541    privacy, user agents ought to be conservative in offering accept
 8542    header configuration options to end users. As an extreme privacy
 8543    measure, proxies could filter the accept headers in relayed requests.
 8544    General purpose user agents which provide a high degree of header
 8545    configurability SHOULD warn users about the loss of privacy which can
 8546    be involved.
 8547 
 8548 15.2 Attacks Based On File and Path Names
 8549 
 8550    Implementations of HTTP origin servers SHOULD be careful to restrict
 8551    the documents returned by HTTP requests to be only those that were
 8552    intended by the server administrators. If an HTTP server translates
 8553    HTTP URIs directly into file system calls, the server MUST take
 8554    special care not to serve files that were not intended to be
 8555    delivered to HTTP clients. For example, UNIX, Microsoft Windows, and
 8556    other operating systems use ".." as a path component to indicate a
 8557    directory level above the current one. On such a system, an HTTP
 8558    server MUST disallow any such construct in the Request-URI if it
 8559    would otherwise allow access to a resource outside those intended to
 8560    be accessible via the HTTP server. Similarly, files intended for
 8561    reference only internally to the server (such as access control
 8562    files, configuration files, and script code) MUST be protected from
 8563    inappropriate retrieval, since they might contain sensitive
 8564    information. Experience has shown that minor bugs in such HTTP server
 8565    implementations have turned into security risks.
 8566 
 8567 
 8568 
 8569 
 8570 Fielding, et al.            Standards Track                   [Page 153]
 8571 
 8572 RFC 2616                        HTTP/1.1                       June 1999
 8573 
 8574 
 8575 15.3 DNS Spoofing
 8576 
 8577    Clients using HTTP rely heavily on the Domain Name Service, and are
 8578    thus generally prone to security attacks based on the deliberate
 8579    mis-association of IP addresses and DNS names. Clients need to be
 8580    cautious in assuming the continuing validity of an IP number/DNS name
 8581    association.
 8582 
 8583    In particular, HTTP clients SHOULD rely on their name resolver for
 8584    confirmation of an IP number/DNS name association, rather than
 8585    caching the result of previous host name lookups. Many platforms
 8586    already can cache host name lookups locally when appropriate, and
 8587    they SHOULD be configured to do so. It is proper for these lookups to
 8588    be cached, however, only when the TTL (Time To Live) information
 8589    reported by the name server makes it likely that the cached
 8590    information will remain useful.
 8591 
 8592    If HTTP clients cache the results of host name lookups in order to
 8593    achieve a performance improvement, they MUST observe the TTL
 8594    information reported by DNS.
 8595 
 8596    If HTTP clients do not observe this rule, they could be spoofed when
 8597    a previously-accessed server's IP address changes. As network
 8598    renumbering is expected to become increasingly common [24], the
 8599    possibility of this form of attack will grow. Observing this
 8600    requirement thus reduces this potential security vulnerability.
 8601 
 8602    This requirement also improves the load-balancing behavior of clients
 8603    for replicated servers using the same DNS name and reduces the
 8604    likelihood of a user's experiencing failure in accessing sites which
 8605    use that strategy.
 8606 
 8607 15.4 Location Headers and Spoofing
 8608 
 8609    If a single server supports multiple organizations that do not trust
 8610    one another, then it MUST check the values of Location and Content-
 8611    Location headers in responses that are generated under control of
 8612    said organizations to make sure that they do not attempt to
 8613    invalidate resources over which they have no authority.
 8614 
 8615 15.5 Content-Disposition Issues
 8616 
 8617    RFC 1806 [35], from which the often implemented Content-Disposition
 8618    (see section 19.5.1) header in HTTP is derived, has a number of very
 8619    serious security considerations. Content-Disposition is not part of
 8620    the HTTP standard, but since it is widely implemented, we are
 8621    documenting its use and risks for implementors. See RFC 2183 [49]
 8622    (which updates RFC 1806) for details.
 8623 
 8624 
 8625 
 8626 Fielding, et al.            Standards Track                   [Page 154]
 8627 
 8628 RFC 2616                        HTTP/1.1                       June 1999
 8629 
 8630 
 8631 15.6 Authentication Credentials and Idle Clients
 8632 
 8633    Existing HTTP clients and user agents typically retain authentication
 8634    information indefinitely. HTTP/1.1. does not provide a method for a
 8635    server to direct clients to discard these cached credentials. This is
 8636    a significant defect that requires further extensions to HTTP.
 8637    Circumstances under which credential caching can interfere with the
 8638    application's security model include but are not limited to:
 8639 
 8640       - Clients which have been idle for an extended period following
 8641         which the server might wish to cause the client to reprompt the
 8642         user for credentials.
 8643 
 8644       - Applications which include a session termination indication
 8645         (such as a `logout' or `commit' button on a page) after which
 8646         the server side of the application `knows' that there is no
 8647         further reason for the client to retain the credentials.
 8648 
 8649    This is currently under separate study. There are a number of work-
 8650    arounds to parts of this problem, and we encourage the use of
 8651    password protection in screen savers, idle time-outs, and other
 8652    methods which mitigate the security problems inherent in this
 8653    problem. In particular, user agents which cache credentials are
 8654    encouraged to provide a readily accessible mechanism for discarding
 8655    cached credentials under user control.
 8656 
 8657 15.7 Proxies and Caching
 8658 
 8659    By their very nature, HTTP proxies are men-in-the-middle, and
 8660    represent an opportunity for man-in-the-middle attacks. Compromise of
 8661    the systems on which the proxies run can result in serious security
 8662    and privacy problems. Proxies have access to security-related
 8663    information, personal information about individual users and
 8664    organizations, and proprietary information belonging to users and
 8665    content providers. A compromised proxy, or a proxy implemented or
 8666    configured without regard to security and privacy considerations,
 8667    might be used in the commission of a wide range of potential attacks.
 8668 
 8669    Proxy operators should protect the systems on which proxies run as
 8670    they would protect any system that contains or transports sensitive
 8671    information. In particular, log information gathered at proxies often
 8672    contains highly sensitive personal information, and/or information
 8673    about organizations. Log information should be carefully guarded, and
 8674    appropriate guidelines for use developed and followed. (Section
 8675    15.1.1).
 8676 
 8677 
 8678 
 8679 
 8680 
 8681 
 8682 Fielding, et al.            Standards Track                   [Page 155]
 8683 
 8684 RFC 2616                        HTTP/1.1                       June 1999
 8685 
 8686 
 8687    Caching proxies provide additional potential vulnerabilities, since
 8688    the contents of the cache represent an attractive target for
 8689    malicious exploitation. Because cache contents persist after an HTTP
 8690    request is complete, an attack on the cache can reveal information
 8691    long after a user believes that the information has been removed from
 8692    the network. Therefore, cache contents should be protected as
 8693    sensitive information.
 8694 
 8695    Proxy implementors should consider the privacy and security
 8696    implications of their design and coding decisions, and of the
 8697    configuration options they provide to proxy operators (especially the
 8698    default configuration).
 8699 
 8700    Users of a proxy need to be aware that they are no trustworthier than
 8701    the people who run the proxy; HTTP itself cannot solve this problem.
 8702 
 8703    The judicious use of cryptography, when appropriate, may suffice to
 8704    protect against a broad range of security and privacy attacks. Such
 8705    cryptography is beyond the scope of the HTTP/1.1 specification.
 8706 
 8707 15.7.1 Denial of Service Attacks on Proxies
 8708 
 8709    They exist. They are hard to defend against. Research continues.
 8710    Beware.
 8711 
 8712 16 Acknowledgments
 8713 
 8714    This specification makes heavy use of the augmented BNF and generic
 8715    constructs defined by David H. Crocker for RFC 822 [9]. Similarly, it
 8716    reuses many of the definitions provided by Nathaniel Borenstein and
 8717    Ned Freed for MIME [7]. We hope that their inclusion in this
 8718    specification will help reduce past confusion over the relationship
 8719    between HTTP and Internet mail message formats.
 8720 
 8721    The HTTP protocol has evolved considerably over the years. It has
 8722    benefited from a large and active developer community--the many
 8723    people who have participated on the www-talk mailing list--and it is
 8724    that community which has been most responsible for the success of
 8725    HTTP and of the World-Wide Web in general. Marc Andreessen, Robert
 8726    Cailliau, Daniel W. Connolly, Bob Denny, John Franks, Jean-Francois
 8727    Groff, Phillip M. Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob
 8728    McCool, Lou Montulli, Dave Raggett, Tony Sanders, and Marc
 8729    VanHeyningen deserve special recognition for their efforts in
 8730    defining early aspects of the protocol.
 8731 
 8732    This document has benefited greatly from the comments of all those
 8733    participating in the HTTP-WG. In addition to those already mentioned,
 8734    the following individuals have contributed to this specification:
 8735 
 8736 
 8737 
 8738 Fielding, et al.            Standards Track                   [Page 156]
 8739 
 8740 RFC 2616                        HTTP/1.1                       June 1999
 8741 
 8742 
 8743        Gary Adams                  Ross Patterson
 8744        Harald Tveit Alvestrand     Albert Lunde
 8745        Keith Ball                  John C. Mallery
 8746        Brian Behlendorf            Jean-Philippe Martin-Flatin
 8747        Paul Burchard               Mitra
 8748        Maurizio Codogno            David Morris
 8749        Mike Cowlishaw              Gavin Nicol
 8750        Roman Czyborra              Bill Perry
 8751        Michael A. Dolan            Jeffrey Perry
 8752        David J. Fiander            Scott Powers
 8753        Alan Freier                 Owen Rees
 8754        Marc Hedlund                Luigi Rizzo
 8755        Greg Herlihy                David Robinson
 8756        Koen Holtman                Marc Salomon
 8757        Alex Hopmann                Rich Salz
 8758        Bob Jernigan                Allan M. Schiffman
 8759        Shel Kaphan                 Jim Seidman
 8760        Rohit Khare                 Chuck Shotton
 8761        John Klensin                Eric W. Sink
 8762        Martijn Koster              Simon E. Spero
 8763        Alexei Kosut                Richard N. Taylor
 8764        David M. Kristol            Robert S. Thau
 8765        Daniel LaLiberte            Bill (BearHeart) Weinman
 8766        Ben Laurie                  Francois Yergeau
 8767        Paul J. Leach               Mary Ellen Zurko
 8768        Daniel DuBois               Josh Cohen
 8769 
 8770 
 8771    Much of the content and presentation of the caching design is due to
 8772    suggestions and comments from individuals including: Shel Kaphan,
 8773    Paul Leach, Koen Holtman, David Morris, and Larry Masinter.
 8774 
 8775    Most of the specification of ranges is based on work originally done
 8776    by Ari Luotonen and John Franks, with additional input from Steve
 8777    Zilles.
 8778 
 8779    Thanks to the "cave men" of Palo Alto. You know who you are.
 8780 
 8781    Jim Gettys (the current editor of this document) wishes particularly
 8782    to thank Roy Fielding, the previous editor of this document, along
 8783    with John Klensin, Jeff Mogul, Paul Leach, Dave Kristol, Koen
 8784    Holtman, John Franks, Josh Cohen, Alex Hopmann, Scott Lawrence, and
 8785    Larry Masinter for their help. And thanks go particularly to Jeff
 8786    Mogul and Scott Lawrence for performing the "MUST/MAY/SHOULD" audit.
 8787 
 8788 
 8789 
 8790 
 8791 
 8792 
 8793 
 8794 Fielding, et al.            Standards Track                   [Page 157]
 8795 
 8796 RFC 2616                        HTTP/1.1                       June 1999
 8797 
 8798 
 8799    The Apache Group, Anselm Baird-Smith, author of Jigsaw, and Henrik
 8800    Frystyk implemented RFC 2068 early, and we wish to thank them for the
 8801    discovery of many of the problems that this document attempts to
 8802    rectify.
 8803 
 8804 17 References
 8805 
 8806    [1] Alvestrand, H., "Tags for the Identification of Languages", RFC
 8807        1766, March 1995.
 8808 
 8809    [2] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D., Torrey,
 8810        D. and B. Alberti, "The Internet Gopher Protocol (a distributed
 8811        document search and retrieval protocol)", RFC 1436, March 1993.
 8812 
 8813    [3] Berners-Lee, T., "Universal Resource Identifiers in WWW", RFC
 8814        1630, June 1994.
 8815 
 8816    [4] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource
 8817        Locators (URL)", RFC 1738, December 1994.
 8818 
 8819    [5] Berners-Lee, T. and D. Connolly, "Hypertext Markup Language -
 8820        2.0", RFC 1866, November 1995.
 8821 
 8822    [6] Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext Transfer
 8823        Protocol -- HTTP/1.0", RFC 1945, May 1996.
 8824 
 8825    [7] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
 8826        Extensions (MIME) Part One: Format of Internet Message Bodies",
 8827        RFC 2045, November 1996.
 8828 
 8829    [8] Braden, R., "Requirements for Internet Hosts -- Communication
 8830        Layers", STD 3, RFC 1123, October 1989.
 8831 
 8832    [9] Crocker, D., "Standard for The Format of ARPA Internet Text
 8833        Messages", STD 11, RFC 822, August 1982.
 8834 
 8835    [10] Davis, F., Kahle, B., Morris, H., Salem, J., Shen, T., Wang, R.,
 8836         Sui, J., and M. Grinbaum, "WAIS Interface Protocol Prototype
 8837         Functional Specification," (v1.5), Thinking Machines
 8838         Corporation, April 1990.
 8839 
 8840    [11] Fielding, R., "Relative Uniform Resource Locators", RFC 1808,
 8841         June 1995.
 8842 
 8843    [12] Horton, M. and R. Adams, "Standard for Interchange of USENET
 8844         Messages", RFC 1036, December 1987.
 8845 
 8846 
 8847 
 8848 
 8849 
 8850 Fielding, et al.            Standards Track                   [Page 158]
 8851 
 8852 RFC 2616                        HTTP/1.1                       June 1999
 8853 
 8854 
 8855    [13] Kantor, B. and P. Lapsley, "Network News Transfer Protocol", RFC
 8856         977, February 1986.
 8857 
 8858    [14] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part
 8859         Three: Message Header Extensions for Non-ASCII Text", RFC 2047,
 8860         November 1996.
 8861 
 8862    [15] Nebel, E. and L. Masinter, "Form-based File Upload in HTML", RFC
 8863         1867, November 1995.
 8864 
 8865    [16] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
 8866         August 1982.
 8867 
 8868    [17] Postel, J., "Media Type Registration Procedure", RFC 1590,
 8869         November 1996.
 8870 
 8871    [18] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC
 8872         959, October 1985.
 8873 
 8874    [19] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
 8875         October 1994.
 8876 
 8877    [20] Sollins, K. and L. Masinter, "Functional Requirements for
 8878         Uniform Resource Names", RFC 1737, December 1994.
 8879 
 8880    [21] US-ASCII. Coded Character Set - 7-Bit American Standard Code for
 8881         Information Interchange. Standard ANSI X3.4-1986, ANSI, 1986.
 8882 
 8883    [22] ISO-8859. International Standard -- Information Processing --
 8884         8-bit Single-Byte Coded Graphic Character Sets --
 8885         Part 1: Latin alphabet No. 1, ISO-8859-1:1987.
 8886         Part 2: Latin alphabet No. 2, ISO-8859-2, 1987.
 8887         Part 3: Latin alphabet No. 3, ISO-8859-3, 1988.
 8888         Part 4: Latin alphabet No. 4, ISO-8859-4, 1988.
 8889         Part 5: Latin/Cyrillic alphabet, ISO-8859-5, 1988.
 8890         Part 6: Latin/Arabic alphabet, ISO-8859-6, 1987.
 8891         Part 7: Latin/Greek alphabet, ISO-8859-7, 1987.
 8892         Part 8: Latin/Hebrew alphabet, ISO-8859-8, 1988.
 8893         Part 9: Latin alphabet No. 5, ISO-8859-9, 1990.
 8894 
 8895    [23] Meyers, J. and M. Rose, "The Content-MD5 Header Field", RFC
 8896         1864, October 1995.
 8897 
 8898    [24] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", RFC
 8899         1900, February 1996.
 8900 
 8901    [25] Deutsch, P., "GZIP file format specification version 4.3", RFC
 8902         1952, May 1996.
 8903 
 8904 
 8905 
 8906 Fielding, et al.            Standards Track                   [Page 159]
 8907 
 8908 RFC 2616                        HTTP/1.1                       June 1999
 8909 
 8910 
 8911    [26] Venkata N. Padmanabhan, and Jeffrey C. Mogul. "Improving HTTP
 8912         Latency", Computer Networks and ISDN Systems, v. 28, pp. 25-35,
 8913         Dec. 1995. Slightly revised version of paper in Proc. 2nd
 8914         International WWW Conference '94: Mosaic and the Web, Oct. 1994,
 8915         which is available at
 8916         http://www.ncsa.uiuc.edu/SDG/IT94/Proceedings/DDay/mogul/HTTPLat
 8917         ency.html.
 8918 
 8919    [27] Joe Touch, John Heidemann, and Katia Obraczka. "Analysis of HTTP
 8920         Performance", <URL: http://www.isi.edu/touch/pubs/http-perf96/>,
 8921         ISI Research Report ISI/RR-98-463, (original report dated Aug.
 8922         1996), USC/Information Sciences Institute, August 1998.
 8923 
 8924    [28] Mills, D., "Network Time Protocol (Version 3) Specification,
 8925         Implementation and Analysis", RFC 1305, March 1992.
 8926 
 8927    [29] Deutsch, P., "DEFLATE Compressed Data Format Specification
 8928         version 1.3", RFC 1951, May 1996.
 8929 
 8930    [30] S. Spero, "Analysis of HTTP Performance Problems,"
 8931         http://sunsite.unc.edu/mdma-release/http-prob.html.
 8932 
 8933    [31] Deutsch, P. and J. Gailly, "ZLIB Compressed Data Format
 8934         Specification version 3.3", RFC 1950, May 1996.
 8935 
 8936    [32] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P.,
 8937         Luotonen, A., Sink, E. and L. Stewart, "An Extension to HTTP:
 8938         Digest Access Authentication", RFC 2069, January 1997.
 8939 
 8940    [33] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T.
 8941         Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC
 8942         2068, January 1997.
 8943 
 8944    [34] Bradner, S., "Key words for use in RFCs to Indicate Requirement
 8945         Levels", BCP 14, RFC 2119, March 1997.
 8946 
 8947    [35] Troost, R. and Dorner, S., "Communicating Presentation
 8948         Information in Internet Messages: The Content-Disposition
 8949         Header", RFC 1806, June 1995.
 8950 
 8951    [36] Mogul, J., Fielding, R., Gettys, J. and H. Frystyk, "Use and
 8952         Interpretation of HTTP Version Numbers", RFC 2145, May 1997.
 8953         [jg639]
 8954 
 8955    [37] Palme, J., "Common Internet Message Headers", RFC 2076, February
 8956         1997. [jg640]
 8957 
 8958 
 8959 
 8960 
 8961 
 8962 Fielding, et al.            Standards Track                   [Page 160]
 8963 
 8964 RFC 2616                        HTTP/1.1                       June 1999
 8965 
 8966 
 8967    [38] Yergeau, F., "UTF-8, a transformation format of Unicode and
 8968         ISO-10646", RFC 2279, January 1998. [jg641]
 8969 
 8970    [39] Nielsen, H.F., Gettys, J., Baird-Smith, A., Prud'hommeaux, E.,
 8971         Lie, H., and C. Lilley. "Network Performance Effects of
 8972         HTTP/1.1, CSS1, and PNG," Proceedings of ACM SIGCOMM '97, Cannes
 8973         France, September 1997.[jg642]
 8974 
 8975    [40] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
 8976         Extensions (MIME) Part Two: Media Types", RFC 2046, November
 8977         1996. [jg643]
 8978 
 8979    [41] Alvestrand, H., "IETF Policy on Character Sets and Languages",
 8980         BCP 18, RFC 2277, January 1998. [jg644]
 8981 
 8982    [42] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
 8983         Identifiers (URI): Generic Syntax and Semantics", RFC 2396,
 8984         August 1998. [jg645]
 8985 
 8986    [43] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
 8987         Leach, P., Luotonen, A., Sink, E. and L. Stewart, "HTTP
 8988         Authentication: Basic and Digest Access Authentication", RFC
 8989         2617, June 1999. [jg646]
 8990 
 8991    [44] Luotonen, A., "Tunneling TCP based protocols through Web proxy
 8992         servers," Work in Progress. [jg647]
 8993 
 8994    [45] Palme, J. and A. Hopmann, "MIME E-mail Encapsulation of
 8995         Aggregate Documents, such as HTML (MHTML)", RFC 2110, March
 8996         1997.
 8997 
 8998    [46] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
 8999         9, RFC 2026, October 1996.
 9000 
 9001    [47] Masinter, L., "Hyper Text Coffee Pot Control Protocol
 9002         (HTCPCP/1.0)", RFC 2324, 1 April 1998.
 9003 
 9004    [48] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
 9005         Extensions (MIME) Part Five: Conformance Criteria and Examples",
 9006         RFC 2049, November 1996.
 9007 
 9008    [49] Troost, R., Dorner, S. and K. Moore, "Communicating Presentation
 9009         Information in Internet Messages: The Content-Disposition Header
 9010         Field", RFC 2183, August 1997.
 9011 
 9012 
 9013 
 9014 
 9015 
 9016 
 9017 
 9018 Fielding, et al.            Standards Track                   [Page 161]
 9019 
 9020 RFC 2616                        HTTP/1.1                       June 1999
 9021 
 9022 
 9023 18 Authors' Addresses
 9024 
 9025    Roy T. Fielding
 9026    Information and Computer Science
 9027    University of California, Irvine
 9028    Irvine, CA 92697-3425, USA
 9029 
 9030    Fax: +1 (949) 824-1715
 9031    EMail: fielding@ics.uci.edu
 9032 
 9033 
 9034    James Gettys
 9035    World Wide Web Consortium
 9036    MIT Laboratory for Computer Science
 9037    545 Technology Square
 9038    Cambridge, MA 02139, USA
 9039 
 9040    Fax: +1 (617) 258 8682
 9041    EMail: jg@w3.org
 9042 
 9043 
 9044    Jeffrey C. Mogul
 9045    Western Research Laboratory
 9046    Compaq Computer Corporation
 9047    250 University Avenue
 9048    Palo Alto, California, 94305, USA
 9049 
 9050    EMail: mogul@wrl.dec.com
 9051 
 9052 
 9053    Henrik Frystyk Nielsen
 9054    World Wide Web Consortium
 9055    MIT Laboratory for Computer Science
 9056    545 Technology Square
 9057    Cambridge, MA 02139, USA
 9058 
 9059    Fax: +1 (617) 258 8682
 9060    EMail: frystyk@w3.org
 9061 
 9062 
 9063    Larry Masinter
 9064    Xerox Corporation
 9065    3333 Coyote Hill Road
 9066    Palo Alto, CA 94034, USA
 9067 
 9068    EMail: masinter@parc.xerox.com
 9069 
 9070 
 9071 
 9072 
 9073 
 9074 Fielding, et al.            Standards Track                   [Page 162]
 9075 
 9076 RFC 2616                        HTTP/1.1                       June 1999
 9077 
 9078 
 9079    Paul J. Leach
 9080    Microsoft Corporation
 9081    1 Microsoft Way
 9082    Redmond, WA 98052, USA
 9083 
 9084    EMail: paulle@microsoft.com
 9085 
 9086 
 9087    Tim Berners-Lee
 9088    Director, World Wide Web Consortium
 9089    MIT Laboratory for Computer Science
 9090    545 Technology Square
 9091    Cambridge, MA 02139, USA
 9092 
 9093    Fax: +1 (617) 258 8682
 9094    EMail: timbl@w3.org
 9095 
 9096 
 9097 
 9098 
 9099 
 9100 
 9101 
 9102 
 9103 
 9104 
 9105 
 9106 
 9107 
 9108 
 9109 
 9110 
 9111 
 9112 
 9113 
 9114 
 9115 
 9116 
 9117 
 9118 
 9119 
 9120 
 9121 
 9122 
 9123 
 9124 
 9125 
 9126 
 9127 
 9128 
 9129 
 9130 Fielding, et al.            Standards Track                   [Page 163]
 9131 
 9132 RFC 2616                        HTTP/1.1                       June 1999
 9133 
 9134 
 9135 19 Appendices
 9136 
 9137 19.1 Internet Media Type message/http and application/http
 9138 
 9139    In addition to defining the HTTP/1.1 protocol, this document serves
 9140    as the specification for the Internet media type "message/http" and
 9141    "application/http". The message/http type can be used to enclose a
 9142    single HTTP request or response message, provided that it obeys the
 9143    MIME restrictions for all "message" types regarding line length and
 9144    encodings. The application/http type can be used to enclose a
 9145    pipeline of one or more HTTP request or response messages (not
 9146    intermixed). The following is to be registered with IANA [17].
 9147 
 9148        Media Type name:         message
 9149        Media subtype name:      http
 9150        Required parameters:     none
 9151        Optional parameters:     version, msgtype
 9152         version: The HTTP-Version number of the enclosed message
 9153                  (e.g., "1.1"). If not present, the version can be
 9154                  determined from the first line of the body.
 9155         msgtype: The message type -- "request" or "response". If not
 9156                  present, the type can be determined from the first
 9157                  line of the body.
 9158        Encoding considerations: only "7bit", "8bit", or "binary" are
 9159                                 permitted
 9160        Security considerations: none
 9161 
 9162        Media Type name:         application
 9163        Media subtype name:      http
 9164        Required parameters:     none
 9165        Optional parameters:     version, msgtype
 9166         version: The HTTP-Version number of the enclosed messages
 9167                  (e.g., "1.1"). If not present, the version can be
 9168                  determined from the first line of the body.
 9169         msgtype: The message type -- "request" or "response". If not
 9170                  present, the type can be determined from the first
 9171                  line of the body.
 9172        Encoding considerations: HTTP messages enclosed by this type
 9173                  are in "binary" format; use of an appropriate
 9174                  Content-Transfer-Encoding is required when
 9175                  transmitted via E-mail.
 9176        Security considerations: none
 9177 
 9178 
 9179 
 9180 
 9181 
 9182 
 9183 
 9184 
 9185 
 9186 Fielding, et al.            Standards Track                   [Page 164]
 9187 
 9188 RFC 2616                        HTTP/1.1                       June 1999
 9189 
 9190 
 9191 19.2 Internet Media Type multipart/byteranges
 9192 
 9193    When an HTTP 206 (Partial Content) response message includes the
 9194    content of multiple ranges (a response to a request for multiple
 9195    non-overlapping ranges), these are transmitted as a multipart
 9196    message-body. The media type for this purpose is called
 9197    "multipart/byteranges".
 9198 
 9199    The multipart/byteranges media type includes two or more parts, each
 9200    with its own Content-Type and Content-Range fields. The required
 9201    boundary parameter specifies the boundary string used to separate
 9202    each body-part.
 9203 
 9204        Media Type name:         multipart
 9205        Media subtype name:      byteranges
 9206        Required parameters:     boundary
 9207        Optional parameters:     none
 9208        Encoding considerations: only "7bit", "8bit", or "binary" are
 9209                                 permitted
 9210        Security considerations: none
 9211 
 9212 
 9213    For example:
 9214 
 9215    HTTP/1.1 206 Partial Content
 9216    Date: Wed, 15 Nov 1995 06:25:24 GMT
 9217    Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
 9218    Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
 9219 
 9220    --THIS_STRING_SEPARATES
 9221    Content-type: application/pdf
 9222    Content-range: bytes 500-999/8000
 9223 
 9224    ...the first range...
 9225    --THIS_STRING_SEPARATES
 9226    Content-type: application/pdf
 9227    Content-range: bytes 7000-7999/8000
 9228 
 9229    ...the second range
 9230    --THIS_STRING_SEPARATES--
 9231 
 9232       Notes:
 9233 
 9234       1) Additional CRLFs may precede the first boundary string in the
 9235          entity.
 9236 
 9237 
 9238 
 9239 
 9240 
 9241 
 9242 Fielding, et al.            Standards Track                   [Page 165]
 9243 
 9244 RFC 2616                        HTTP/1.1                       June 1999
 9245 
 9246 
 9247       2) Although RFC 2046 [40] permits the boundary string to be
 9248          quoted, some existing implementations handle a quoted boundary
 9249          string incorrectly.
 9250 
 9251       3) A number of browsers and servers were coded to an early draft
 9252          of the byteranges specification to use a media type of
 9253          multipart/x-byteranges, which is almost, but not quite
 9254          compatible with the version documented in HTTP/1.1.
 9255 
 9256 19.3 Tolerant Applications
 9257 
 9258    Although this document specifies the requirements for the generation
 9259    of HTTP/1.1 messages, not all applications will be correct in their
 9260    implementation. We therefore recommend that operational applications
 9261    be tolerant of deviations whenever those deviations can be
 9262    interpreted unambiguously.
 9263 
 9264    Clients SHOULD be tolerant in parsing the Status-Line and servers
 9265    tolerant when parsing the Request-Line. In particular, they SHOULD
 9266    accept any amount of SP or HT characters between fields, even though
 9267    only a single SP is required.
 9268 
 9269    The line terminator for message-header fields is the sequence CRLF.
 9270    However, we recommend that applications, when parsing such headers,
 9271    recognize a single LF as a line terminator and ignore the leading CR.
 9272 
 9273    The character set of an entity-body SHOULD be labeled as the lowest
 9274    common denominator of the character codes used within that body, with
 9275    the exception that not labeling the entity is preferred over labeling
 9276    the entity with the labels US-ASCII or ISO-8859-1. See section 3.7.1
 9277    and 3.4.1.
 9278 
 9279    Additional rules for requirements on parsing and encoding of dates
 9280    and other potential problems with date encodings include:
 9281 
 9282       - HTTP/1.1 clients and caches SHOULD assume that an RFC-850 date
 9283         which appears to be more than 50 years in the future is in fact
 9284         in the past (this helps solve the "year 2000" problem).
 9285 
 9286       - An HTTP/1.1 implementation MAY internally represent a parsed
 9287         Expires date as earlier than the proper value, but MUST NOT
 9288         internally represent a parsed Expires date as later than the
 9289         proper value.
 9290 
 9291       - All expiration-related calculations MUST be done in GMT. The
 9292         local time zone MUST NOT influence the calculation or comparison
 9293         of an age or expiration time.
 9294 
 9295 
 9296 
 9297 
 9298 Fielding, et al.            Standards Track                   [Page 166]
 9299 
 9300 RFC 2616                        HTTP/1.1                       June 1999
 9301 
 9302 
 9303       - If an HTTP header incorrectly carries a date value with a time
 9304         zone other than GMT, it MUST be converted into GMT using the
 9305         most conservative possible conversion.
 9306 
 9307 19.4 Differences Between HTTP Entities and RFC 2045 Entities
 9308 
 9309    HTTP/1.1 uses many of the constructs defined for Internet Mail (RFC
 9310    822 [9]) and the Multipurpose Internet Mail Extensions (MIME [7]) to
 9311    allow entities to be transmitted in an open variety of
 9312    representations and with extensible mechanisms. However, RFC 2045
 9313    discusses mail, and HTTP has a few features that are different from
 9314    those described in RFC 2045. These differences were carefully chosen
 9315    to optimize performance over binary connections, to allow greater
 9316    freedom in the use of new media types, to make date comparisons
 9317    easier, and to acknowledge the practice of some early HTTP servers
 9318    and clients.
 9319 
 9320    This appendix describes specific areas where HTTP differs from RFC
 9321    2045. Proxies and gateways to strict MIME environments SHOULD be
 9322    aware of these differences and provide the appropriate conversions
 9323    where necessary. Proxies and gateways from MIME environments to HTTP
 9324    also need to be aware of the differences because some conversions
 9325    might be required.
 9326 
 9327 19.4.1 MIME-Version
 9328 
 9329    HTTP is not a MIME-compliant protocol. However, HTTP/1.1 messages MAY
 9330    include a single MIME-Version general-header field to indicate what
 9331    version of the MIME protocol was used to construct the message. Use
 9332    of the MIME-Version header field indicates that the message is in
 9333    full compliance with the MIME protocol (as defined in RFC 2045[7]).
 9334    Proxies/gateways are responsible for ensuring full compliance (where
 9335    possible) when exporting HTTP messages to strict MIME environments.
 9336 
 9337        MIME-Version   = "MIME-Version" ":" 1*DIGIT "." 1*DIGIT
 9338 
 9339    MIME version "1.0" is the default for use in HTTP/1.1. However,
 9340    HTTP/1.1 message parsing and semantics are defined by this document
 9341    and not the MIME specification.
 9342 
 9343 19.4.2 Conversion to Canonical Form
 9344 
 9345    RFC 2045 [7] requires that an Internet mail entity be converted to
 9346    canonical form prior to being transferred, as described in section 4
 9347    of RFC 2049 [48]. Section 3.7.1 of this document describes the forms
 9348    allowed for subtypes of the "text" media type when transmitted over
 9349    HTTP. RFC 2046 requires that content with a type of "text" represent
 9350    line breaks as CRLF and forbids the use of CR or LF outside of line
 9351 
 9352 
 9353 
 9354 Fielding, et al.            Standards Track                   [Page 167]
 9355 
 9356 RFC 2616                        HTTP/1.1                       June 1999
 9357 
 9358 
 9359    break sequences. HTTP allows CRLF, bare CR, and bare LF to indicate a
 9360    line break within text content when a message is transmitted over
 9361    HTTP.
 9362 
 9363    Where it is possible, a proxy or gateway from HTTP to a strict MIME
 9364    environment SHOULD translate all line breaks within the text media
 9365    types described in section 3.7.1 of this document to the RFC 2049
 9366    canonical form of CRLF. Note, however, that this might be complicated
 9367    by the presence of a Content-Encoding and by the fact that HTTP
 9368    allows the use of some character sets which do not use octets 13 and
 9369    10 to represent CR and LF, as is the case for some multi-byte
 9370    character sets.
 9371 
 9372    Implementors should note that conversion will break any cryptographic
 9373    checksums applied to the original content unless the original content
 9374    is already in canonical form. Therefore, the canonical form is
 9375    recommended for any content that uses such checksums in HTTP.
 9376 
 9377 19.4.3 Conversion of Date Formats
 9378 
 9379    HTTP/1.1 uses a restricted set of date formats (section 3.3.1) to
 9380    simplify the process of date comparison. Proxies and gateways from
 9381    other protocols SHOULD ensure that any Date header field present in a
 9382    message conforms to one of the HTTP/1.1 formats and rewrite the date
 9383    if necessary.
 9384 
 9385 19.4.4 Introduction of Content-Encoding
 9386 
 9387    RFC 2045 does not include any concept equivalent to HTTP/1.1's
 9388    Content-Encoding header field. Since this acts as a modifier on the
 9389    media type, proxies and gateways from HTTP to MIME-compliant
 9390    protocols MUST either change the value of the Content-Type header
 9391    field or decode the entity-body before forwarding the message. (Some
 9392    experimental applications of Content-Type for Internet mail have used
 9393    a media-type parameter of ";conversions=<content-coding>" to perform
 9394    a function equivalent to Content-Encoding. However, this parameter is
 9395    not part of RFC 2045.)
 9396 
 9397 19.4.5 No Content-Transfer-Encoding
 9398 
 9399    HTTP does not use the Content-Transfer-Encoding (CTE) field of RFC
 9400    2045. Proxies and gateways from MIME-compliant protocols to HTTP MUST
 9401    remove any non-identity CTE ("quoted-printable" or "base64") encoding
 9402    prior to delivering the response message to an HTTP client.
 9403 
 9404    Proxies and gateways from HTTP to MIME-compliant protocols are
 9405    responsible for ensuring that the message is in the correct format
 9406    and encoding for safe transport on that protocol, where "safe
 9407 
 9408 
 9409 
 9410 Fielding, et al.            Standards Track                   [Page 168]
 9411 
 9412 RFC 2616                        HTTP/1.1                       June 1999
 9413 
 9414 
 9415    transport" is defined by the limitations of the protocol being used.
 9416    Such a proxy or gateway SHOULD label the data with an appropriate
 9417    Content-Transfer-Encoding if doing so will improve the likelihood of
 9418    safe transport over the destination protocol.
 9419 
 9420 19.4.6 Introduction of Transfer-Encoding
 9421 
 9422    HTTP/1.1 introduces the Transfer-Encoding header field (section
 9423    14.41). Proxies/gateways MUST remove any transfer-coding prior to
 9424    forwarding a message via a MIME-compliant protocol.
 9425 
 9426    A process for decoding the "chunked" transfer-coding (section 3.6)
 9427    can be represented in pseudo-code as:
 9428 
 9429        length := 0
 9430        read chunk-size, chunk-extension (if any) and CRLF
 9431        while (chunk-size > 0) {
 9432           read chunk-data and CRLF
 9433           append chunk-data to entity-body
 9434           length := length + chunk-size
 9435           read chunk-size and CRLF
 9436        }
 9437        read entity-header
 9438        while (entity-header not empty) {
 9439           append entity-header to existing header fields
 9440           read entity-header
 9441        }
 9442        Content-Length := length
 9443        Remove "chunked" from Transfer-Encoding
 9444 
 9445 19.4.7 MHTML and Line Length Limitations
 9446 
 9447    HTTP implementations which share code with MHTML [45] implementations
 9448    need to be aware of MIME line length limitations. Since HTTP does not
 9449    have this limitation, HTTP does not fold long lines. MHTML messages
 9450    being transported by HTTP follow all conventions of MHTML, including
 9451    line length limitations and folding, canonicalization, etc., since
 9452    HTTP transports all message-bodies as payload (see section 3.7.2) and
 9453    does not interpret the content or any MIME header lines that might be
 9454    contained therein.
 9455 
 9456 19.5 Additional Features
 9457 
 9458    RFC 1945 and RFC 2068 document protocol elements used by some
 9459    existing HTTP implementations, but not consistently and correctly
 9460    across most HTTP/1.1 applications. Implementors are advised to be
 9461    aware of these features, but cannot rely upon their presence in, or
 9462    interoperability with, other HTTP/1.1 applications. Some of these
 9463 
 9464 
 9465 
 9466 Fielding, et al.            Standards Track                   [Page 169]
 9467 
 9468 RFC 2616                        HTTP/1.1                       June 1999
 9469 
 9470 
 9471    describe proposed experimental features, and some describe features
 9472    that experimental deployment found lacking that are now addressed in
 9473    the base HTTP/1.1 specification.
 9474 
 9475    A number of other headers, such as Content-Disposition and Title,
 9476    from SMTP and MIME are also often implemented (see RFC 2076 [37]).
 9477 
 9478 19.5.1 Content-Disposition
 9479 
 9480    The Content-Disposition response-header field has been proposed as a
 9481    means for the origin server to suggest a default filename if the user
 9482    requests that the content is saved to a file. This usage is derived
 9483    from the definition of Content-Disposition in RFC 1806 [35].
 9484 
 9485         content-disposition = "Content-Disposition" ":"
 9486                               disposition-type *( ";" disposition-parm )
 9487         disposition-type = "attachment" | disp-extension-token
 9488         disposition-parm = filename-parm | disp-extension-parm
 9489         filename-parm = "filename" "=" quoted-string
 9490         disp-extension-token = token
 9491         disp-extension-parm = token "=" ( token | quoted-string )
 9492 
 9493    An example is
 9494 
 9495         Content-Disposition: attachment; filename="fname.ext"
 9496 
 9497    The receiving user agent SHOULD NOT respect any directory path
 9498    information present in the filename-parm parameter, which is the only
 9499    parameter believed to apply to HTTP implementations at this time. The
 9500    filename SHOULD be treated as a terminal component only.
 9501 
 9502    If this header is used in a response with the application/octet-
 9503    stream content-type, the implied suggestion is that the user agent
 9504    should not display the response, but directly enter a `save response
 9505    as...' dialog.
 9506 
 9507    See section 15.5 for Content-Disposition security issues.
 9508 
 9509 19.6 Compatibility with Previous Versions
 9510 
 9511    It is beyond the scope of a protocol specification to mandate
 9512    compliance with previous versions. HTTP/1.1 was deliberately
 9513    designed, however, to make supporting previous versions easy. It is
 9514    worth noting that, at the time of composing this specification
 9515    (1996), we would expect commercial HTTP/1.1 servers to:
 9516 
 9517       - recognize the format of the Request-Line for HTTP/0.9, 1.0, and
 9518         1.1 requests;
 9519 
 9520 
 9521 
 9522 Fielding, et al.            Standards Track                   [Page 170]
 9523 
 9524 RFC 2616                        HTTP/1.1                       June 1999
 9525 
 9526 
 9527       - understand any valid request in the format of HTTP/0.9, 1.0, or
 9528         1.1;
 9529 
 9530       - respond appropriately with a message in the same major version
 9531         used by the client.
 9532 
 9533    And we would expect HTTP/1.1 clients to:
 9534 
 9535       - recognize the format of the Status-Line for HTTP/1.0 and 1.1
 9536         responses;
 9537 
 9538       - understand any valid response in the format of HTTP/0.9, 1.0, or
 9539         1.1.
 9540 
 9541    For most implementations of HTTP/1.0, each connection is established
 9542    by the client prior to the request and closed by the server after
 9543    sending the response. Some implementations implement the Keep-Alive
 9544    version of persistent connections described in section 19.7.1 of RFC
 9545    2068 [33].
 9546 
 9547 19.6.1 Changes from HTTP/1.0
 9548 
 9549    This section summarizes major differences between versions HTTP/1.0
 9550    and HTTP/1.1.
 9551 
 9552 19.6.1.1 Changes to Simplify Multi-homed Web Servers and Conserve IP
 9553          Addresses
 9554 
 9555    The requirements that clients and servers support the Host request-
 9556    header, report an error if the Host request-header (section 14.23) is
 9557    missing from an HTTP/1.1 request, and accept absolute URIs (section
 9558    5.1.2) are among the most important changes defined by this
 9559    specification.
 9560 
 9561    Older HTTP/1.0 clients assumed a one-to-one relationship of IP
 9562    addresses and servers; there was no other established mechanism for
 9563    distinguishing the intended server of a request than the IP address
 9564    to which that request was directed. The changes outlined above will
 9565    allow the Internet, once older HTTP clients are no longer common, to
 9566    support multiple Web sites from a single IP address, greatly
 9567    simplifying large operational Web servers, where allocation of many
 9568    IP addresses to a single host has created serious problems. The
 9569    Internet will also be able to recover the IP addresses that have been
 9570    allocated for the sole purpose of allowing special-purpose domain
 9571    names to be used in root-level HTTP URLs. Given the rate of growth of
 9572    the Web, and the number of servers already deployed, it is extremely
 9573 
 9574 
 9575 
 9576 
 9577 
 9578 Fielding, et al.            Standards Track                   [Page 171]
 9579 
 9580 RFC 2616                        HTTP/1.1                       June 1999
 9581 
 9582 
 9583    important that all implementations of HTTP (including updates to
 9584    existing HTTP/1.0 applications) correctly implement these
 9585    requirements:
 9586 
 9587       - Both clients and servers MUST support the Host request-header.
 9588 
 9589       - A client that sends an HTTP/1.1 request MUST send a Host header.
 9590 
 9591       - Servers MUST report a 400 (Bad Request) error if an HTTP/1.1
 9592         request does not include a Host request-header.
 9593 
 9594       - Servers MUST accept absolute URIs.
 9595 
 9596 19.6.2 Compatibility with HTTP/1.0 Persistent Connections
 9597 
 9598    Some clients and servers might wish to be compatible with some
 9599    previous implementations of persistent connections in HTTP/1.0
 9600    clients and servers. Persistent connections in HTTP/1.0 are
 9601    explicitly negotiated as they are not the default behavior. HTTP/1.0
 9602    experimental implementations of persistent connections are faulty,
 9603    and the new facilities in HTTP/1.1 are designed to rectify these
 9604    problems. The problem was that some existing 1.0 clients may be
 9605    sending Keep-Alive to a proxy server that doesn't understand
 9606    Connection, which would then erroneously forward it to the next
 9607    inbound server, which would establish the Keep-Alive connection and
 9608    result in a hung HTTP/1.0 proxy waiting for the close on the
 9609    response. The result is that HTTP/1.0 clients must be prevented from
 9610    using Keep-Alive when talking to proxies.
 9611 
 9612    However, talking to proxies is the most important use of persistent
 9613    connections, so that prohibition is clearly unacceptable. Therefore,
 9614    we need some other mechanism for indicating a persistent connection
 9615    is desired, which is safe to use even when talking to an old proxy
 9616    that ignores Connection. Persistent connections are the default for
 9617    HTTP/1.1 messages; we introduce a new keyword (Connection: close) for
 9618    declaring non-persistence. See section 14.10.
 9619 
 9620    The original HTTP/1.0 form of persistent connections (the Connection:
 9621    Keep-Alive and Keep-Alive header) is documented in RFC 2068. [33]
 9622 
 9623 19.6.3 Changes from RFC 2068
 9624 
 9625    This specification has been carefully audited to correct and
 9626    disambiguate key word usage; RFC 2068 had many problems in respect to
 9627    the conventions laid out in RFC 2119 [34].
 9628 
 9629    Clarified which error code should be used for inbound server failures
 9630    (e.g. DNS failures). (Section 10.5.5).
 9631 
 9632 
 9633 
 9634 Fielding, et al.            Standards Track                   [Page 172]
 9635 
 9636 RFC 2616                        HTTP/1.1                       June 1999
 9637 
 9638 
 9639    CREATE had a race that required an Etag be sent when a resource is
 9640    first created. (Section 10.2.2).
 9641 
 9642    Content-Base was deleted from the specification: it was not
 9643    implemented widely, and there is no simple, safe way to introduce it
 9644    without a robust extension mechanism. In addition, it is used in a
 9645    similar, but not identical fashion in MHTML [45].
 9646 
 9647    Transfer-coding and message lengths all interact in ways that
 9648    required fixing exactly when chunked encoding is used (to allow for
 9649    transfer encoding that may not be self delimiting); it was important
 9650    to straighten out exactly how message lengths are computed. (Sections
 9651    3.6, 4.4, 7.2.2, 13.5.2, 14.13, 14.16)
 9652 
 9653    A content-coding of "identity" was introduced, to solve problems
 9654    discovered in caching. (section 3.5)
 9655 
 9656    Quality Values of zero should indicate that "I don't want something"
 9657    to allow clients to refuse a representation. (Section 3.9)
 9658 
 9659    The use and interpretation of HTTP version numbers has been clarified
 9660    by RFC 2145. Require proxies to upgrade requests to highest protocol
 9661    version they support to deal with problems discovered in HTTP/1.0
 9662    implementations (Section 3.1)
 9663 
 9664    Charset wildcarding is introduced to avoid explosion of character set
 9665    names in accept headers. (Section 14.2)
 9666 
 9667    A case was missed in the Cache-Control model of HTTP/1.1; s-maxage
 9668    was introduced to add this missing case. (Sections 13.4, 14.8, 14.9,
 9669    14.9.3)
 9670 
 9671    The Cache-Control: max-age directive was not properly defined for
 9672    responses. (Section 14.9.3)
 9673 
 9674    There are situations where a server (especially a proxy) does not
 9675    know the full length of a response but is capable of serving a
 9676    byterange request. We therefore need a mechanism to allow byteranges
 9677    with a content-range not indicating the full length of the message.
 9678    (Section 14.16)
 9679 
 9680    Range request responses would become very verbose if all meta-data
 9681    were always returned; by allowing the server to only send needed
 9682    headers in a 206 response, this problem can be avoided. (Section
 9683    10.2.7, 13.5.3, and 14.27)
 9684 
 9685 
 9686 
 9687 
 9688 
 9689 
 9690 Fielding, et al.            Standards Track                   [Page 173]
 9691 
 9692 RFC 2616                        HTTP/1.1                       June 1999
 9693 
 9694 
 9695    Fix problem with unsatisfiable range requests; there are two cases:
 9696    syntactic problems, and range doesn't exist in the document. The 416
 9697    status code was needed to resolve this ambiguity needed to indicate
 9698    an error for a byte range request that falls outside of the actual
 9699    contents of a document. (Section 10.4.17, 14.16)
 9700 
 9701    Rewrite of message transmission requirements to make it much harder
 9702    for implementors to get it wrong, as the consequences of errors here
 9703    can have significant impact on the Internet, and to deal with the
 9704    following problems:
 9705 
 9706       1. Changing "HTTP/1.1 or later" to "HTTP/1.1", in contexts where
 9707          this was incorrectly placing a requirement on the behavior of
 9708          an implementation of a future version of HTTP/1.x
 9709 
 9710       2. Made it clear that user-agents should retry requests, not
 9711          "clients" in general.
 9712 
 9713       3. Converted requirements for clients to ignore unexpected 100
 9714          (Continue) responses, and for proxies to forward 100 responses,
 9715          into a general requirement for 1xx responses.
 9716 
 9717       4. Modified some TCP-specific language, to make it clearer that
 9718          non-TCP transports are possible for HTTP.
 9719 
 9720       5. Require that the origin server MUST NOT wait for the request
 9721          body before it sends a required 100 (Continue) response.
 9722 
 9723       6. Allow, rather than require, a server to omit 100 (Continue) if
 9724          it has already seen some of the request body.
 9725 
 9726       7. Allow servers to defend against denial-of-service attacks and
 9727          broken clients.
 9728 
 9729    This change adds the Expect header and 417 status code. The message
 9730    transmission requirements fixes are in sections 8.2, 10.4.18,
 9731    8.1.2.2, 13.11, and 14.20.
 9732 
 9733    Proxies should be able to add Content-Length when appropriate.
 9734    (Section 13.5.2)
 9735 
 9736    Clean up confusion between 403 and 404 responses. (Section 10.4.4,
 9737    10.4.5, and 10.4.11)
 9738 
 9739    Warnings could be cached incorrectly, or not updated appropriately.
 9740    (Section 13.1.2, 13.2.4, 13.5.2, 13.5.3, 14.9.3, and 14.46) Warning
 9741    also needed to be a general header, as PUT or other methods may have
 9742    need for it in requests.
 9743 
 9744 
 9745 
 9746 Fielding, et al.            Standards Track                   [Page 174]
 9747 
 9748 RFC 2616                        HTTP/1.1                       June 1999
 9749 
 9750 
 9751    Transfer-coding had significant problems, particularly with
 9752    interactions with chunked encoding. The solution is that transfer-
 9753    codings become as full fledged as content-codings. This involves
 9754    adding an IANA registry for transfer-codings (separate from content
 9755    codings), a new header field (TE) and enabling trailer headers in the
 9756    future. Transfer encoding is a major performance benefit, so it was
 9757    worth fixing [39]. TE also solves another, obscure, downward
 9758    interoperability problem that could have occurred due to interactions
 9759    between authentication trailers, chunked encoding and HTTP/1.0
 9760    clients.(Section 3.6, 3.6.1, and 14.39)
 9761 
 9762    The PATCH, LINK, UNLINK methods were defined but not commonly
 9763    implemented in previous versions of this specification. See RFC 2068
 9764    [33].
 9765 
 9766    The Alternates, Content-Version, Derived-From, Link, URI, Public and
 9767    Content-Base header fields were defined in previous versions of this
 9768    specification, but not commonly implemented. See RFC 2068 [33].
 9769 
 9770 20 Index
 9771 
 9772    Please see the PostScript version of this RFC for the INDEX.
 9773 
 9774 
 9775 
 9776 
 9777 
 9778 
 9779 
 9780 
 9781 
 9782 
 9783 
 9784 
 9785 
 9786 
 9787 
 9788 
 9789 
 9790 
 9791 
 9792 
 9793 
 9794 
 9795 
 9796 
 9797 
 9798 
 9799 
 9800 
 9801 
 9802 Fielding, et al.            Standards Track                   [Page 175]
 9803 
 9804 RFC 2616                        HTTP/1.1                       June 1999
 9805 
 9806 
 9807 21.  Full Copyright Statement
 9808 
 9809    Copyright (C) The Internet Society (1999).  All Rights Reserved.
 9810 
 9811    This document and translations of it may be copied and furnished to
 9812    others, and derivative works that comment on or otherwise explain it
 9813    or assist in its implementation may be prepared, copied, published
 9814    and distributed, in whole or in part, without restriction of any
 9815    kind, provided that the above copyright notice and this paragraph are
 9816    included on all such copies and derivative works.  However, this
 9817    document itself may not be modified in any way, such as by removing
 9818    the copyright notice or references to the Internet Society or other
 9819    Internet organizations, except as needed for the purpose of
 9820    developing Internet standards in which case the procedures for
 9821    copyrights defined in the Internet Standards process must be
 9822    followed, or as required to translate it into languages other than
 9823    English.
 9824 
 9825    The limited permissions granted above are perpetual and will not be
 9826    revoked by the Internet Society or its successors or assigns.
 9827 
 9828    This document and the information contained herein is provided on an
 9829    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 9830    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 9831    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 9832    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 9833    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 9834 
 9835 Acknowledgement
 9836 
 9837    Funding for the RFC Editor function is currently provided by the
 9838    Internet Society.
 9839 
 9840 
 9841 
 9842 
 9843 
 9844 
 9845 
 9846 
 9847 
 9848 
 9849 
 9850 
 9851 
 9852 
 9853 
 9854 
 9855 
 9856 
 9857 
 9858 Fielding, et al.            Standards Track                   [Page 176]
 9859