8/24/2016
`
`https://www.ietf.org/rfc/rfc2616.txt
`
`Network Working Group
`Request for Comments: 2616
`Obsoletes: 2068
`Category: Standards Track
`
`R. Fielding
`UC Irvine
`J. Gettys
`Compaq/W3C
`J. Mogul
`Compaq
`H. Frystyk
`W3C/MIT
`L. Masinter
`  Xerox
`P. Leach
`Microsoft
`T. Berners‐Lee
`W3C/MIT
`June 1999
`
`Hypertext Transfer Protocol ‐‐ HTTP/1.1
`
`Status of this Memo
`
`   This document specifies an Internet standards track protocol for the
`   Internet community, and requests discussion and suggestions for
`   improvements.  Please refer to the current edition of the "Internet
`   Official Protocol Standards" (STD 1) for the standardization state
`   and status of this protocol.  Distribution of this memo is unlimited.
`
`Copyright Notice
`
`   Copyright (C) The Internet Society (1999).  All Rights Reserved.
`
`Abstract
`
`   The Hypertext Transfer Protocol (HTTP) is an application‐level
`   protocol for distributed, collaborative, hypermedia information
`   systems. It is a generic, stateless, protocol which can be used for
`   many tasks beyond its use for hypertext, such as name servers and
`   distributed object management systems, through extension of its
`   request methods, error codes and headers [47]. A feature of HTTP is
`   the typing and negotiation of data representation, allowing systems
`   to be built independently of the data being transferred.
`
`   HTTP has been in use by the World‐Wide Web global information
`   initiative since 1990. This specification defines the protocol
`   referred to as "HTTP/1.1", and is an update to RFC 2068 [33].
`
`Fielding, et al.
`
`Standards Track
`
`RFC 2616
`
`HTTP/1.1
`
` [Page 1]
`
`June 1999
`
`Table of Contents
`
`https://www.ietf.org/rfc/rfc2616.txt
`
`1/152
`
`Netflix 1025 - Page 1
`
`

`
`https://www.ietf.org/rfc/rfc2616.txt
`8/24/2016
`   1   Introduction ...................................................7
`   1.1    Purpose......................................................7
`   1.2   Requirements .................................................8
`   1.3   Terminology ..................................................8
`   1.4   Overall Operation ...........................................12
`   2   Notational Conventions and Generic Grammar ....................14
`   2.1   Augmented BNF ...............................................14
`   2.2   Basic Rules .................................................15
`   3   Protocol Parameters ...........................................17
`   3.1   HTTP Version ................................................17
`   3.2   Uniform Resource Identifiers ................................18
`   3.2.1    General Syntax ...........................................19
`   3.2.2    http URL .................................................19
`   3.2.3    URI Comparison ...........................................20
`   3.3   Date/Time Formats ...........................................20
`   3.3.1    Full Date ................................................20
`   3.3.2    Delta Seconds ............................................21
`   3.4   Character Sets ..............................................21
`   3.4.1    Missing Charset ..........................................22
`   3.5   Content Codings .............................................23
`   3.6   Transfer Codings ............................................24
`   3.6.1    Chunked Transfer Coding ..................................25
`   3.7   Media Types .................................................26
`   3.7.1    Canonicalization and Text Defaults .......................27
`   3.7.2    Multipart Types ..........................................27
`   3.8   Product Tokens ..............................................28
`   3.9   Quality Values ..............................................29
`   3.10  Language Tags ...............................................29
`   3.11  Entity Tags .................................................30
`   3.12  Range Units .................................................30
`   4   HTTP Message ..................................................31
`   4.1   Message Types ...............................................31
`   4.2   Message Headers .............................................31
`   4.3   Message Body ................................................32
`   4.4   Message Length ..............................................33
`   4.5   General Header Fields .......................................34
`   5   Request .......................................................35
`   5.1   Request‐Line ................................................35
`   5.1.1    Method ...................................................36
`   5.1.2    Request‐URI ..............................................36
`   5.2   The Resource Identified by a Request ........................38
`   5.3   Request Header Fields .......................................38
`   6   Response ......................................................39
`   6.1   Status‐Line .................................................39
`   6.1.1    Status Code and Reason Phrase ............................39
`   6.2   Response Header Fields ......................................41
`
`Fielding, et al.            Standards Track                     [Page 2]
`
`RFC 2616                        HTTP/1.1                       June 1999
`
`   7   Entity ........................................................42
`   7.1   Entity Header Fields ........................................42
`   7.2   Entity Body .................................................43
`   7.2.1    Type .....................................................43
`   7.2.2    Entity Length ............................................43
`   8   Connections ...................................................44
`   8.1   Persistent Connections ......................................44
`   8.1.1    Purpose ..................................................44
`   8.1.2    Overall Operation ........................................45
`   8.1.3    Proxy Servers ............................................46
`   8.1.4    Practical Considerations .................................46
`https://www.ietf.org/rfc/rfc2616.txt
`
`2/152
`
`Netflix 1025 - Page 2
`
`

`
`https://www.ietf.org/rfc/rfc2616.txt
`8/24/2016
`   8.2   Message Transmission Requirements ...........................47
`   8.2.1    Persistent Connections and Flow Control ..................47
`   8.2.2    Monitoring Connections for Error Status Messages .........48
`   8.2.3    Use of the 100 (Continue) Status .........................48
`   8.2.4    Client Behavior if Server Prematurely Closes Connection ..50
`   9   Method Definitions ............................................51
`   9.1   Safe and Idempotent Methods .................................51
`   9.1.1    Safe Methods .............................................51
`   9.1.2    Idempotent Methods .......................................51
`   9.2   OPTIONS .....................................................52
`   9.3   GET .........................................................53
`   9.4   HEAD ........................................................54
`   9.5   POST ........................................................54
`   9.6   PUT .........................................................55
`   9.7   DELETE ......................................................56
`   9.8   TRACE .......................................................56
`   9.9   CONNECT .....................................................57
`   10   Status Code Definitions ......................................57
`   10.1  Informational 1xx ...........................................57
`   10.1.1   100 Continue .............................................58
`   10.1.2   101 Switching Protocols ..................................58
`   10.2  Successful 2xx ..............................................58
`   10.2.1   200 OK ...................................................58
`   10.2.2   201 Created ..............................................59
`   10.2.3   202 Accepted .............................................59
`   10.2.4   203 Non‐Authoritative Information ........................59
`   10.2.5   204 No Content ...........................................60
`   10.2.6   205 Reset Content ........................................60
`   10.2.7   206 Partial Content ......................................60
`   10.3  Redirection 3xx .............................................61
`   10.3.1   300 Multiple Choices .....................................61
`   10.3.2   301 Moved Permanently ....................................62
`   10.3.3   302 Found ................................................62
`   10.3.4   303 See Other ............................................63
`   10.3.5   304 Not Modified .........................................63
`   10.3.6   305 Use Proxy ............................................64
`   10.3.7   306 (Unused) .............................................64
`
`Fielding, et al.            Standards Track                     [Page 3]
`
`RFC 2616                        HTTP/1.1                       June 1999
`
`   10.3.8   307 Temporary Redirect ...................................65
`   10.4  Client Error 4xx ............................................65
`   10.4.1    400 Bad Request .........................................65
`   10.4.2    401 Unauthorized ........................................66
`   10.4.3    402 Payment Required ....................................66
`   10.4.4    403 Forbidden ...........................................66
`   10.4.5    404 Not Found ...........................................66
`   10.4.6    405 Method Not Allowed ..................................66
`   10.4.7    406 Not Acceptable ......................................67
`   10.4.8    407 Proxy Authentication Required .......................67
`   10.4.9    408 Request Timeout .....................................67
`   10.4.10   409 Conflict ............................................67
`   10.4.11   410 Gone ................................................68
`   10.4.12   411 Length Required .....................................68
`   10.4.13   412 Precondition Failed .................................68
`   10.4.14   413 Request Entity Too Large ............................69
`   10.4.15   414 Request‐URI Too Long ................................69
`   10.4.16   415 Unsupported Media Type ..............................69
`   10.4.17   416 Requested Range Not Satisfiable .....................69
`   10.4.18   417 Expectation Failed ..................................70
`https://www.ietf.org/rfc/rfc2616.txt
`
`3/152
`
`Netflix 1025 - Page 3
`
`

`
`https://www.ietf.org/rfc/rfc2616.txt
`8/24/2016
`   10.5  Server Error 5xx ............................................70
`   10.5.1   500 Internal Server Error ................................70
`   10.5.2   501 Not Implemented ......................................70
`   10.5.3   502 Bad Gateway ..........................................70
`   10.5.4   503 Service Unavailable ..................................70
`   10.5.5   504 Gateway Timeout ......................................71
`   10.5.6   505 HTTP Version Not Supported ...........................71
`   11   Access Authentication ........................................71
`   12   Content Negotiation ..........................................71
`   12.1  Server‐driven Negotiation ...................................72
`   12.2  Agent‐driven Negotiation ....................................73
`   12.3  Transparent Negotiation .....................................74
`   13   Caching in HTTP ..............................................74
`   13.1.1   Cache Correctness ........................................75
`   13.1.2   Warnings .................................................76
`   13.1.3   Cache‐control Mechanisms .................................77
`   13.1.4   Explicit User Agent Warnings .............................78
`   13.1.5   Exceptions to the Rules and Warnings .....................78
`   13.1.6   Client‐controlled Behavior ...............................79
`   13.2  Expiration Model ............................................79
`   13.2.1   Server‐Specified Expiration ..............................79
`   13.2.2   Heuristic Expiration .....................................80
`   13.2.3   Age Calculations .........................................80
`   13.2.4   Expiration Calculations ..................................83
`   13.2.5   Disambiguating Expiration Values .........................84
`   13.2.6   Disambiguating Multiple Responses ........................84
`   13.3  Validation Model ............................................85
`   13.3.1   Last‐Modified Dates ......................................86
`
`Fielding, et al.            Standards Track                     [Page 4]
`
`RFC 2616                        HTTP/1.1                       June 1999
`
`   13.3.2   Entity Tag Cache Validators ..............................86
`   13.3.3   Weak and Strong Validators ...............................86
`   13.3.4   Rules for When to Use Entity Tags and Last‐Modified Dates.89
`   13.3.5   Non‐validating Conditionals ..............................90
`   13.4  Response Cacheability .......................................91
`   13.5  Constructing Responses From Caches ..........................92
`   13.5.1   End‐to‐end and Hop‐by‐hop Headers ........................92
`   13.5.2   Non‐modifiable Headers ...................................92
`   13.5.3   Combining Headers ........................................94
`   13.5.4   Combining Byte Ranges ....................................95
`   13.6  Caching Negotiated Responses ................................95
`   13.7  Shared and Non‐Shared Caches ................................96
`   13.8  Errors or Incomplete Response Cache Behavior ................97
`   13.9  Side Effects of GET and HEAD ................................97
`   13.10   Invalidation After Updates or Deletions ...................97
`   13.11   Write‐Through Mandatory ...................................98
`   13.12   Cache Replacement .........................................99
`   13.13   History Lists .............................................99
`   14   Header Field Definitions ....................................100
`   14.1  Accept .....................................................100
`   14.2  Accept‐Charset .............................................102
`   14.3  Accept‐Encoding ............................................102
`   14.4  Accept‐Language ............................................104
`   14.5  Accept‐Ranges ..............................................105
`   14.6  Age ........................................................106
`   14.7  Allow ......................................................106
`   14.8  Authorization ..............................................107
`   14.9  Cache‐Control ..............................................108
`   14.9.1   What is Cacheable .......................................109
`https://www.ietf.org/rfc/rfc2616.txt
`
`4/152
`
`Netflix 1025 - Page 4
`
`

`
`https://www.ietf.org/rfc/rfc2616.txt
`8/24/2016
`   14.9.2   What May be Stored by Caches ............................110
`   14.9.3   Modifications of the Basic Expiration Mechanism .........111
`   14.9.4   Cache Revalidation and Reload Controls ..................113
`   14.9.5   No‐Transform Directive ..................................115
`   14.9.6   Cache Control Extensions ................................116
`   14.10   Connection ...............................................117
`   14.11   Content‐Encoding .........................................118
`   14.12   Content‐Language .........................................118
`   14.13   Content‐Length ...........................................119
`   14.14   Content‐Location .........................................120
`   14.15   Content‐MD5 ..............................................121
`   14.16   Content‐Range ............................................122
`   14.17   Content‐Type .............................................124
`   14.18   Date .....................................................124
`   14.18.1   Clockless Origin Server Operation ......................125
`   14.19   ETag .....................................................126
`   14.20   Expect ...................................................126
`   14.21   Expires ..................................................127
`   14.22   From .....................................................128
`
`Fielding, et al.            Standards Track                     [Page 5]
`
`RFC 2616                        HTTP/1.1                       June 1999
`
`   14.23   Host .....................................................128
`   14.24   If‐Match .................................................129
`   14.25   If‐Modified‐Since ........................................130
`   14.26   If‐None‐Match ............................................132
`   14.27   If‐Range .................................................133
`   14.28   If‐Unmodified‐Since ......................................134
`   14.29   Last‐Modified ............................................134
`   14.30   Location .................................................135
`   14.31   Max‐Forwards .............................................136
`   14.32   Pragma ...................................................136
`   14.33   Proxy‐Authenticate .......................................137
`   14.34   Proxy‐Authorization ......................................137
`   14.35   Range ....................................................138
`   14.35.1    Byte Ranges ...........................................138
`   14.35.2    Range Retrieval Requests ..............................139
`   14.36   Referer ..................................................140
`   14.37   Retry‐After ..............................................141
`   14.38   Server ...................................................141
`   14.39   TE .......................................................142
`   14.40   Trailer ..................................................143
`   14.41  Transfer‐Encoding..........................................143
`   14.42   Upgrade ..................................................144
`   14.43   User‐Agent ...............................................145
`   14.44   Vary .....................................................145
`   14.45   Via ......................................................146
`   14.46   Warning ..................................................148
`   14.47   WWW‐Authenticate .........................................150
`   15 Security Considerations .......................................150
`   15.1      Personal Information....................................151
`   15.1.1   Abuse of Server Log Information .........................151
`   15.1.2   Transfer of Sensitive Information .......................151
`   15.1.3   Encoding Sensitive Information in URI's .................152
`   15.1.4   Privacy Issues Connected to Accept Headers ..............152
`   15.2  Attacks Based On File and Path Names .......................153
`   15.3  DNS Spoofing ...............................................154
`   15.4  Location Headers and Spoofing ..............................154
`   15.5  Content‐Disposition Issues .................................154
`   15.6  Authentication Credentials and Idle Clients ................155
`https://www.ietf.org/rfc/rfc2616.txt
`
`5/152
`
`Netflix 1025 - Page 5
`
`

`
`https://www.ietf.org/rfc/rfc2616.txt
`8/24/2016
`   15.7  Proxies and Caching ........................................155
`   15.7.1    Denial of Service Attacks on Proxies....................156
`   16   Acknowledgments .............................................156
`   17   References ..................................................158
`   18   Authors' Addresses ..........................................162
`   19   Appendices ..................................................164
`   19.1  Internet Media Type message/http and application/http ......164
`   19.2  Internet Media Type multipart/byteranges ...................165
`   19.3  Tolerant Applications ......................................166
`   19.4  Differences Between HTTP Entities and RFC 2045 Entities ....167
`
`Fielding, et al.            Standards Track                     [Page 6]
`
`RFC 2616                        HTTP/1.1                       June 1999
`
`   19.4.1   MIME‐Version ............................................167
`   19.4.2   Conversion to Canonical Form ............................167
`   19.4.3   Conversion of Date Formats ..............................168
`   19.4.4   Introduction of Content‐Encoding ........................168
`   19.4.5   No Content‐Transfer‐Encoding ............................168
`   19.4.6   Introduction of Transfer‐Encoding .......................169
`   19.4.7   MHTML and Line Length Limitations .......................169
`   19.5  Additional Features ........................................169
`   19.5.1   Content‐Disposition .....................................170
`   19.6  Compatibility with Previous Versions .......................170
`   19.6.1   Changes from HTTP/1.0 ...................................171
`   19.6.2   Compatibility with HTTP/1.0 Persistent Connections ......172
`   19.6.3   Changes from RFC 2068 ...................................172
`   20   Index .......................................................175
`   21   Full Copyright Statement ....................................176
`
`1 Introduction
`
`1.1 Purpose
`
`   The Hypertext Transfer Protocol (HTTP) is an application‐level
`   protocol for distributed, collaborative, hypermedia information
`   systems. HTTP has been in use by the World‐Wide Web global
`   information initiative since 1990. The first version of HTTP,
`   referred to as HTTP/0.9, was a simple protocol for raw data transfer
`   across the Internet. HTTP/1.0, as defined by RFC 1945 [6], improved
`   the protocol by allowing messages to be in the format of MIME‐like
`   messages, containing metainformation about the data transferred and
`   modifiers on the request/response semantics. However, HTTP/1.0 does
`   not sufficiently take into consideration the effects of hierarchical
`   proxies, caching, the need for persistent connections, or virtual
`   hosts. In addition, the proliferation of incompletely‐implemented
`   applications calling themselves "HTTP/1.0" has necessitated a
`   protocol version change in order for two communicating applications
`   to determine each other's true capabilities.
`
`   This specification defines the protocol referred to as "HTTP/1.1".
`   This protocol includes more stringent requirements than HTTP/1.0 in
`   order to ensure reliable implementation of its features.
`
`   Practical information systems require more functionality than simple
`   retrieval, including search, front‐end update, and annotation. HTTP
`   allows an open‐ended set of methods and headers that indicate the
`   purpose of a request [47]. It builds on the discipline of reference
`   provided by the Uniform Resource Identifier (URI) [3], as a location
`   (URL) [4] or name (URN) [20], for indicating the resource to which a
`
`https://www.ietf.org/rfc/rfc2616.txt
`
`6/152
`
`Netflix 1025 - Page 6
`
`

`
`8/24/2016
`
`https://www.ietf.org/rfc/rfc2616.txt
`
`Fielding, et al.            Standards Track                     [Page 7]
`
`RFC 2616                        HTTP/1.1                       June 1999
`
`   method is to be applied. Messages are passed in a format similar to
`   that used by Internet mail [9] as defined by the Multipurpose
`   Internet Mail Extensions (MIME) [7].
`
`   HTTP is also used as a generic protocol for communication between
`   user agents and proxies/gateways to other Internet systems, including
`   those supported by the SMTP [16], NNTP [13], FTP [18], Gopher [2],
`   and WAIS [10] protocols. In this way, HTTP allows basic hypermedia
`   access to resources available from diverse applications.
`
`1.2 Requirements
`
`   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
`   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
`   document are to be interpreted as described in RFC 2119 [34].
`
`   An implementation is not compliant if it fails to satisfy one or more
`   of the MUST or REQUIRED level requirements for the protocols it
`   implements. An implementation that satisfies all the MUST or REQUIRED
`   level and all the SHOULD level requirements for its protocols is said
`   to be "unconditionally compliant"; one that satisfies all the MUST
`   level requirements but not all the SHOULD level requirements for its
`   protocols is said to be "conditionally compliant."
`
`1.3 Terminology
`
`   This specification uses a number of terms to refer to the roles
`   played by participants in, and objects of, the HTTP communication.
`
`   connection
`      A transport layer virtual circuit established between two programs
`      for the purpose of communication.
`
`   message
`      The basic unit of HTTP communication, consisting of a structured
`      sequence of octets matching the syntax defined in section 4 and
`      transmitted via the connection.
`
`   request
`      An HTTP request message, as defined in section 5.
`
`   response
`      An HTTP response message, as defined in section 6.
`
`Fielding, et al.            Standards Track                     [Page 8]
`
`RFC 2616                        HTTP/1.1                       June 1999
`
`https://www.ietf.org/rfc/rfc2616.txt
`
`7/152
`
`Netflix 1025 - Page 7
`
`

`
`8/24/2016
`   resource
`      A network data object or service that can be identified by a URI,
`      as defined in section 3.2. Resources may be available in multiple
`      representations (e.g. multiple languages, data formats, size, and
`      resolutions) or vary in other ways.
`
`https://www.ietf.org/rfc/rfc2616.txt
`
`   entity
`      The information transferred as the payload of a request or
`      response. An entity consists of metainformation in the form of
`      entity‐header fields and content in the form of an entity‐body, as
`      described in section 7.
`
`   representation
`      An entity included with a response that is subject to content
`      negotiation, as described in section 12. There may exist multiple
`      representations associated with a particular response status.
`
`   content negotiation
`      The mechanism for selecting the appropriate representation when
`      servicing a request, as described in section 12. The
`      representation of entities in any response can be negotiated
`      (including error responses).
`
`   variant
`      A resource may have one, or more than one, representation(s)
`      associated with it at any given instant. Each of these
`      representations is termed a `varriant'.  Use of the term `variant'
`      does not necessarily imply that the resource is subject to content
`      negotiation.
`
`   client
`      A program that establishes connections for the purpose of sending
`      requests.
`
`   user agent
`      The client which initiates a request. These are often browsers,
`      editors, spiders (web‐traversing robots), or other end user tools.
`
`   server
`      An application program that accepts connections in order to
`      service requests by sending back responses. Any given program may
`      be capable of being both a client and a server; our use of these
`      terms refers only to the role being performed by the program for a
`      particular connection, rather than to the program's capabilities
`      in general. Likewise, any server may act as an origin server,
`      proxy, gateway, or tunnel, switching behavior based on the nature
`      of each request.
`
`Fielding, et al.            Standards Track                     [Page 9]
`
`RFC 2616                        HTTP/1.1                       June 1999
`
`   origin server
`      The server on which a given resource resides or is to be created.
`
`   proxy
`      An intermediary program which acts as both a server and a client
`      for the purpose of making requests on behalf of other clients.
`      Requests are serviced internally or by passing them on, with
`      possible translation, to other servers. A proxy MUST implement
`      both the client and server requirements of this specification. A
`https://www.ietf.org/rfc/rfc2616.txt
`
`8/152
`
`Netflix 1025 - Page 8
`
`

`
`https://www.ietf.org/rfc/rfc2616.txt
`8/24/2016
`      "transparent proxy" is a proxy that does not modify the request or
`      response beyond what is required for proxy authentication and
`      identification. A "non‐transparent proxy" is a proxy that modifies
`      the request or response in order to provide some added service to
`      the user agent, such as group annotation services, media type
`      transformation, protocol reduction, or anonymity filtering. Except
`      where either transparent or non‐transparent behavior is explicitly
`      stated, the HTTP proxy requirements apply to both types of
`      proxies.
`
`   gateway
`      A server which acts as an intermediary for some other server.
`      Unlike a proxy, a gateway receives requests as if it were the
`      origin server for the requested resource; the requesting client
`      may not be aware that it is communicating with a gateway.
`
`   tunnel
`      An intermediary program which is acting as a blind relay between
`      two connections. Once active, a tunnel is not considered a party
`      to the HTTP communication, though the tunnel may have been
`      initiated by an HTTP request. The tunnel ceases to exist when both
`      ends of the relayed connections are closed.
`
`   cache
`      A program's local store of response messages and the subsystem
`      that controls its message storage, retrieval, and deletion. A
`      cache stores cacheable responses in order to reduce the response
`      time and network bandwidth consumption on future, equivalent
`      requests. Any client or server may include a cache, though a cache
`      cannot be used by a server that is acting as a tunnel.
`
`   cacheable
`      A response is cacheable if a cache is allowed to store a copy of
`      the response message for use in answering subsequent requests. The
`      rules for determining the cacheability of HTTP responses are
`      defined in section 13. Even if a resource is cacheable, there may
`      be additional constraints on whether a cache can use the cached
`      copy for a particular request.
`
`Fielding, et al.            Standards Track                    [Page 10]
`
`RFC 2616                        HTTP/1.1                       June 1999
`
`   first‐hand
`      A response is first‐hand if it comes directly and without
`      unnecessary delay from the origin server, perhaps via one or more
`      proxies. A response is also first‐hand if its validity has just
`      been checked directly with the origin server.
`
`   explicit expiration time
`      The time at which the origin server intends that an entity should
`      no longer be returned by a cache without further validation.
`
`   heuristic expiration time
`      An expiration time assigned by a cache when no explicit expiration
`      time is available.
`
`   age
`      The age of a response is the time since it was sent by, or
`      successfully validated with, the origin server.
`
`https://www.ietf.org/rfc/rfc2616.txt
`
`9/152
`
`Netflix 1025 - Page 9
`
`

`
`8/24/2016
`   freshness lifetime
`      The length of time between the generation of a response and its
`      expiration time.
`
`https://www.ietf.org/rfc/rfc2616.txt
`
`   fresh
`      A response is fresh if its age has not yet exceeded its freshness
`      lifetime.
`
`   stale
`      A response is stale if its age has passed its freshness lifetime.
`
`   semantically transparent
`      A cache behaves in a "semantically transparent" manner, with
`      respect to a particular response, when its use affects neither the
`      requesting client nor the origin server, except to improve
`      performance. When a cache is semantically transparent, the client
`      receives exactly the same response (except for hop‐by‐hop headers)
`      that it would have received had its request been handled directly
`      by the origin server.
`
`   validator
`      A protocol element (e.g., an entity tag or a Last‐Modified time)
`      that is used to find out whether a cache entry is an equivalent
`      copy of an entity.
`
`   upstream/downstream
`      Upstream and downstream describe the flow of a message: all
`      messages flow from upstream to downstream.
`
`Fielding, et al.            Standards Track                    [Page 11]
`
`RFC 2616                        HTTP/1.1                       June 1999
`
`   inbound/outbound
`      Inbound and outbound refer to the request and response paths for
`      messages: "inbound" means "traveling toward the origin server",
`      and "outbound" means "traveling toward the user agent"
`
`1.4 Overall Operati