Network Working Group
`Request for Comments: 2068
`Category: Standards Track
`
`R. Fielding
`UC Irvine
`J. Gettys
`J. Mogul
`DEC
`H. Frystyk
`T. Berners-Lee
`MIT/LCS
`January 1997
`
`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.
`
`Abstract
`
` The Hypertext Transfer Protocol (HTTP) is an application-level
` protocol for distributed, collaborative, hypermedia information
` systems. It is a generic, stateless, object-oriented protocol which
` can be used for many tasks, such as name servers and distributed
` object management systems, through extension of its request methods.
` 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".
`
`Table of Contents
`
` 1 Introduction.............................................7
` 1.1 Purpose ..............................................7
` 1.2 Requirements .........................................7
` 1.3 Terminology ..........................................8
` 1.4 Overall Operation ...................................11
` 2 Notational Conventions and Generic Grammar..............13
` 2.1 Augmented BNF .......................................13
` 2.2 Basic Rules .........................................15
` 3 Protocol Parameters.....................................17
` 3.1 HTTP Version ........................................17
`
`Fielding, et. al.
`
`Standards Track
`
`[Page 1]
`
`Juniper Ex. 1031-p. 1
`Juniper v Implicit
`
`

`

`
`RFC 2068 HTTP/1.1 January 1997
`
` 3.2 Uniform Resource Identifiers ........................18
` 3.2.1 General Syntax ...................................18
` 3.2.2 http URL .........................................19
` 3.2.3 URI Comparison ...................................20
` 3.3 Date/Time Formats ...................................21
` 3.3.1 Full Date ........................................21
` 3.3.2 Delta Seconds ....................................22
` 3.4 Character Sets ......................................22
` 3.5 Content Codings .....................................23
` 3.6 Transfer Codings ....................................24
` 3.7 Media Types .........................................25
` 3.7.1 Canonicalization and Text Defaults ...............26
` 3.7.2 Multipart Types ..................................27
` 3.8 Product Tokens ......................................28
` 3.9 Quality Values ......................................28
` 3.10 Language Tags ......................................28
` 3.11 Entity Tags ........................................29
` 3.12 Range Units ........................................30
` 4 HTTP Message............................................30
` 4.1 Message Types .......................................30
` 4.2 Message Headers .....................................31
` 4.3 Message Body ........................................32
` 4.4 Message Length ......................................32
` 4.5 General Header Fields ...............................34
` 5 Request.................................................34
` 5.1 Request-Line ........................................34
` 5.1.1 Method ...........................................35
` 5.1.2 Request-URI ......................................35
` 5.2 The Resource Identified by a Request ................37
` 5.3 Request Header Fields ...............................37
` 6 Response................................................38
` 6.1 Status-Line .........................................38
` 6.1.1 Status Code and Reason Phrase ....................39
` 6.2 Response Header Fields ..............................41
` 7 Entity..................................................41
` 7.1 Entity Header Fields ................................41
` 7.2 Entity Body .........................................42
` 7.2.1 Type .............................................42
` 7.2.2 Length ...........................................43
` 8 Connections.............................................43
` 8.1 Persistent Connections ..............................43
` 8.1.1 Purpose ..........................................43
` 8.1.2 Overall Operation ................................44
` 8.1.3 Proxy Servers ....................................45
` 8.1.4 Practical Considerations .........................45
` 8.2 Message Transmission Requirements ...................46
` 9 Method Definitions......................................48
` 9.1 Safe and Idempotent Methods .........................48
`
`Fielding, et. al. Standards Track [Page 2]
`
`Juniper Ex. 1031-p. 2
`Juniper v Implicit
`
`

`

`
`RFC 2068 HTTP/1.1 January 1997
`
` 9.1.1 Safe Methods .....................................48
` 9.1.2 Idempotent Methods ...............................49
` 9.2 OPTIONS .............................................49
` 9.3 GET .................................................50
` 9.4 HEAD ................................................50
` 9.5 POST ................................................51
` 9.6 PUT .................................................52
` 9.7 DELETE ..............................................53
` 9.8 TRACE ...............................................53
` 10 Status Code Definitions................................53
` 10.1 Informational 1xx ..................................54
` 10.1.1 100 Continue ....................................54
` 10.1.2 101 Switching Protocols .........................54
` 10.2 Successful 2xx .....................................54
` 10.2.1 200 OK ..........................................54
` 10.2.2 201 Created .....................................55
` 10.2.3 202 Accepted ....................................55
` 10.2.4 203 Non-Authoritative Information ...............55
` 10.2.5 204 No Content ..................................55
` 10.2.6 205 Reset Content ...............................56
` 10.2.7 206 Partial Content .............................56
` 10.3 Redirection 3xx ....................................56
` 10.3.1 300 Multiple Choices ............................57
` 10.3.2 301 Moved Permanently ...........................57
` 10.3.3 302 Moved Temporarily ...........................58
` 10.3.4 303 See Other ...................................58
` 10.3.5 304 Not Modified ................................58
` 10.3.6 305 Use Proxy ...................................59
` 10.4 Client Error 4xx ...................................59
` 10.4.1 400 Bad Request .................................60
` 10.4.2 401 Unauthorized ................................60
` 10.4.3 402 Payment Required ............................60
` 10.4.4 403 Forbidden ...................................60
` 10.4.5 404 Not Found ...................................60
` 10.4.6 405 Method Not Allowed ..........................61
` 10.4.7 406 Not Acceptable ..............................61
` 10.4.8 407 Proxy Authentication Required ...............61
` 10.4.9 408 Request Timeout .............................62
` 10.4.10 409 Conflict ...................................62
` 10.4.11 410 Gone .......................................62
` 10.4.12 411 Length Required ............................63
` 10.4.13 412 Precondition Failed ........................63
` 10.4.14 413 Request Entity Too Large ...................63
` 10.4.15 414 Request-URI Too Long .......................63
` 10.4.16 415 Unsupported Media Type .....................63
` 10.5 Server Error 5xx ...................................64
` 10.5.1 500 Internal Server Error .......................64
` 10.5.2 501 Not Implemented .............................64
`
`Fielding, et. al. Standards Track [Page 3]
`
`Juniper Ex. 1031-p. 3
`Juniper v Implicit
`
`

`

`
`RFC 2068 HTTP/1.1 January 1997
`
` 10.5.3 502 Bad Gateway .................................64
` 10.5.4 503 Service Unavailable .........................64
` 10.5.5 504 Gateway Timeout .............................64
` 10.5.6 505 HTTP Version Not Supported ..................65
` 11 Access Authentication..................................65
` 11.1 Basic Authentication Scheme ........................66
` 11.2 Digest Authentication Scheme .......................67
` 12 Content Negotiation....................................67
` 12.1 Server-driven Negotiation ..........................68
` 12.2 Agent-driven Negotiation ...........................69
` 12.3 Transparent Negotiation ............................70
` 13 Caching in HTTP........................................70
` 13.1.1 Cache Correctness ...............................72
` 13.1.2 Warnings ........................................73
` 13.1.3 Cache-control Mechanisms ........................74
` 13.1.4 Explicit User Agent Warnings ....................74
` 13.1.5 Exceptions to the Rules and Warnings ............75
` 13.1.6 Client-controlled Behavior ......................75
` 13.2 Expiration Model ...................................75
` 13.2.1 Server-Specified Expiration .....................75
` 13.2.2 Heuristic Expiration ............................76
` 13.2.3 Age Calculations ................................77
` 13.2.4 Expiration Calculations .........................79
` 13.2.5 Disambiguating Expiration Values ................80
` 13.2.6 Disambiguating Multiple Responses ...............80
` 13.3 Validation Model ...................................81
` 13.3.1 Last-modified Dates .............................82
` 13.3.2 Entity Tag Cache Validators .....................82
` 13.3.3 Weak and Strong Validators ......................82
` 13.3.4 Rules for When to Use Entity Tags and Last-
` modified Dates..........................................85
` 13.3.5 Non-validating Conditionals .....................86
` 13.4 Response Cachability ...............................86
` 13.5 Constructing Responses From Caches .................87
` 13.5.1 End-to-end and Hop-by-hop Headers ...............88
` 13.5.2 Non-modifiable Headers ..........................88
` 13.5.3 Combining Headers ...............................89
` 13.5.4 Combining Byte Ranges ...........................90
` 13.6 Caching Negotiated Responses .......................90
` 13.7 Shared and Non-Shared Caches .......................91
` 13.8 Errors or Incomplete Response Cache Behavior .......91
` 13.9 Side Effects of GET and HEAD .......................92
` 13.10 Invalidation After Updates or Deletions ...........92
` 13.11 Write-Through Mandatory ...........................93
` 13.12 Cache Replacement .................................93
` 13.13 History Lists .....................................93
` 14 Header Field Definitions...............................94
` 14.1 Accept .............................................95
`
`Fielding, et. al. Standards Track [Page 4]
`
`Juniper Ex. 1031-p. 4
`Juniper v Implicit
`
`

`

`
`RFC 2068 HTTP/1.1 January 1997
`
` 14.2 Accept-Charset .....................................97
` 14.3 Accept-Encoding ....................................97
` 14.4 Accept-Language ....................................98
` 14.5 Accept-Ranges ......................................99
` 14.6 Age ................................................99
` 14.7 Allow .............................................100
` 14.8 Authorization .....................................100
` 14.9 Cache-Control .....................................101
` 14.9.1 What is Cachable ...............................103
` 14.9.2 What May be Stored by Caches ...................103
` 14.9.3 Modifications of the Basic Expiration Mechanism 104
` 14.9.4 Cache Revalidation and Reload Controls .........105
` 14.9.5 No-Transform Directive .........................107
` 14.9.6 Cache Control Extensions .......................108
` 14.10 Connection .......................................109
` 14.11 Content-Base .....................................109
` 14.12 Content-Encoding .................................110
` 14.13 Content-Language .................................110
` 14.14 Content-Length ...................................111
` 14.15 Content-Location .................................112
` 14.16 Content-MD5 ......................................113
` 14.17 Content-Range ....................................114
` 14.18 Content-Type .....................................116
` 14.19 Date .............................................116
` 14.20 ETag .............................................117
` 14.21 Expires ..........................................117
` 14.22 From .............................................118
` 14.23 Host .............................................119
` 14.24 If-Modified-Since ................................119
` 14.25 If-Match .........................................121
` 14.26 If-None-Match ....................................122
` 14.27 If-Range .........................................123
` 14.28 If-Unmodified-Since ..............................124
` 14.29 Last-Modified ....................................124
` 14.30 Location .........................................125
` 14.31 Max-Forwards .....................................125
` 14.32 Pragma ...........................................126
` 14.33 Proxy-Authenticate ...............................127
` 14.34 Proxy-Authorization ..............................127
` 14.35 Public ...........................................127
` 14.36 Range ............................................128
` 14.36.1 Byte Ranges ...................................128
` 14.36.2 Range Retrieval Requests ......................130
` 14.37 Referer ..........................................131
` 14.38 Retry-After ......................................131
` 14.39 Server ...........................................132
` 14.40 Transfer-Encoding ................................132
` 14.41 Upgrade ..........................................132
`
`Fielding, et. al. Standards Track [Page 5]
`
`Juniper Ex. 1031-p. 5
`Juniper v Implicit
`
`

`

`
`RFC 2068 HTTP/1.1 January 1997
`
` 14.42 User-Agent .......................................134
` 14.43 Vary .............................................134
` 14.44 Via ..............................................135
` 14.45 Warning ..........................................137
` 14.46 WWW-Authenticate .................................139
` 15 Security Considerations...............................139
` 15.1 Authentication of Clients .........................139
` 15.2 Offering a Choice of Authentication Schemes .......140
` 15.3 Abuse of Server Log Information ...................141
` 15.4 Transfer of Sensitive Information .................141
` 15.5 Attacks Based On File and Path Names ..............142
` 15.6 Personal Information ..............................143
` 15.7 Privacy Issues Connected to Accept Headers ........143
` 15.8 DNS Spoofing ......................................144
` 15.9 Location Headers and Spoofing .....................144
` 16 Acknowledgments.......................................144
` 17 References............................................146
` 18 Authors’ Addresses....................................149
` 19 Appendices............................................150
` 19.1 Internet Media Type message/http ..................150
` 19.2 Internet Media Type multipart/byteranges ..........150
` 19.3 Tolerant Applications .............................151
` 19.4 Differences Between HTTP Entities and
` MIME Entities...........................................152
` 19.4.1 Conversion to Canonical Form ...................152
` 19.4.2 Conversion of Date Formats .....................153
` 19.4.3 Introduction of Content-Encoding ...............153
` 19.4.4 No Content-Transfer-Encoding ...................153
` 19.4.5 HTTP Header Fields in Multipart Body-Parts .....153
` 19.4.6 Introduction of Transfer-Encoding ..............154
` 19.4.7 MIME-Version ...................................154
` 19.5 Changes from HTTP/1.0 .............................154
` 19.5.1 Changes to Simplify Multi-homed Web Servers and
` Conserve IP Addresses .................................155
` 19.6 Additional Features ...............................156
` 19.6.1 Additional Request Methods .....................156
` 19.6.2 Additional Header Field Definitions ............156
` 19.7 Compatibility with Previous Versions ..............160
` 19.7.1 Compatibility with HTTP/1.0 Persistent
` Connections............................................161
`
`Fielding, et. al. Standards Track [Page 6]
`
`Juniper Ex. 1031-p. 6
`Juniper v Implicit
`
`

`

`
`RFC 2068 HTTP/1.1 January 1997
`
`1 Introduction
`
`1.1 Purpose
`
` The Hypertext Transfer Protocol (HTTP) is an application-level
` protocol for distributed, collaborative, hypermedia information
` systems. HTTP has been in use by the World-Wide Web global
` information initiative since 1990. The first version of HTTP,
` referred to as HTTP/0.9, was a simple protocol for raw data transfer
` across the Internet. HTTP/1.0, as defined by RFC 1945 [6], improved
` the protocol by allowing messages to be in the format of MIME-like
` messages, containing metainformation about the data transferred and
` modifiers on the request/response semantics. However, HTTP/1.0 does
` not sufficiently take into consideration the effects of hierarchical
` proxies, caching, the need for persistent connections, and virtual
` hosts. In addition, the proliferation of incompletely-implemented
` applications calling themselves "HTTP/1.0" has necessitated a
` protocol version change in order for two communicating applications
` to determine each other’s true capabilities.
`
` This specification defines the protocol referred to as "HTTP/1.1".
` This protocol includes more stringent requirements than HTTP/1.0 in
` order to ensure reliable implementation of its features.
`
` Practical information systems require more functionality than simple
` retrieval, including search, front-end update, and annotation. HTTP
` allows an open-ended set of methods that indicate the purpose of a
` request. It builds on the discipline of reference provided by the
` Uniform Resource Identifier (URI) [3][20], as a location (URL) [4] or
` name (URN) , for indicating the resource to which a method is to be
` applied. Messages are passed in a format similar to that used by
` Internet mail as defined by the Multipurpose Internet Mail Extensions
` (MIME).
`
` HTTP is also used as a generic protocol for communication between
` user agents and proxies/gateways to other Internet systems, including
` those supported by the SMTP [16], NNTP [13], FTP [18], Gopher [2],
` and WAIS [10] protocols. In this way, HTTP allows basic hypermedia
` access to resources available from diverse applications.
`
`1.2 Requirements
`
` This specification uses the same words as RFC 1123 [8] for defining
` the significance of each particular requirement. These words are:
`
` MUST
` This word or the adjective "required" means that the item is an
` absolute requirement of the specification.
`
`Fielding, et. al. Standards Track [Page 7]
`
`Juniper Ex. 1031-p. 7
`Juniper v Implicit
`
`

`

`
`RFC 2068 HTTP/1.1 January 1997
`
` SHOULD
` This word or the adjective "recommended" means that there may
` exist valid reasons in particular circumstances to ignore this
` item, but the full implications should be understood and the case
` carefully weighed before choosing a different course.
`
` MAY
` This word or the adjective "optional" means that this item is
` truly optional. One vendor may choose to include the item because
` a particular marketplace requires it or because it enhances the
` product, for example; another vendor may omit the same item.
`
` An implementation is not compliant if it fails to satisfy one or more
` of the MUST requirements for the protocols it implements. An
` implementation that satisfies all the MUST and all the SHOULD
` requirements for its protocols is said to be "unconditionally
` compliant"; one that satisfies all the MUST requirements but not all
` the SHOULD requirements for its protocols is said to be
` "conditionally compliant."
`
`1.3 Terminology
`
` This specification uses a number of terms to refer to the roles
` played by participants in, and objects of, the HTTP communication.
`
` connection
` A transport layer virtual circuit established between two programs
` for the purpose of communication.
`
` message
` The basic unit of HTTP communication, consisting of a structured
` sequence of octets matching the syntax defined in section 4 and
` transmitted via the connection.
`
` request
` An HTTP request message, as defined in section 5.
`
` response
` An HTTP response message, as defined in section 6.
`
` resource
` A network data object or service that can be identified by a URI,
` as defined in section 3.2. Resources may be available in multiple
` representations (e.g. multiple languages, data formats, size,
` resolutions) or vary in other ways.
`
`Fielding, et. al. Standards Track [Page 8]
`
`Juniper Ex. 1031-p. 8
`Juniper v Implicit
`
`

`

`
`RFC 2068 HTTP/1.1 January 1997
`
` entity
` The information transferred as the payload of a request or
` response. An entity consists of metainformation in the form of
` entity-header fields and content in the form of an entity-body, as
` described in section 7.
`
` representation
` An entity included with a response that is subject to content
` negotiation, as described in section 12. There may exist multiple
` representations associated with a particular response status.
`
` content negotiation
` The mechanism for selecting the appropriate representation when
` servicing a request, as described in section 12. The
` representation of entities in any response can be negotiated
` (including error responses).
`
` variant
` A resource may have one, or more than one, representation(s)
` associated with it at any given instant. Each of these
` representations is termed a ‘variant.’ Use of the term ‘variant’
` does not necessarily imply that the resource is subject to content
` negotiation.
`
` client
` A program that establishes connections for the purpose of sending
` requests.
`
` user agent
` The client which initiates a request. These are often browsers,
` editors, spiders (web-traversing robots), or other end user tools.
`
` server
` An application program that accepts connections in order to
` service requests by sending back responses. Any given program may
` be capable of being both a client and a server; our use of these
` terms refers only to the role being performed by the program for a
` particular connection, rather than to the program’s capabilities
` in general. Likewise, any server may act as an origin server,
` proxy, gateway, or tunnel, switching behavior based on the nature
` of each request.
`
` origin server
` The server on which a given resource resides or is to be created.
`
`Fielding, et. al. Standards Track [Page 9]
`
`Juniper Ex. 1031-p. 9
`Juniper v Implicit
`
`

`

`
`RFC 2068 HTTP/1.1 January 1997
`
` proxy
` An intermediary program which acts as both a server and a client
` for the purpose of making requests on behalf of other clients.
` Requests are serviced internally or by passing them on, with
` possible translation, to other servers. A proxy must implement
` both the client and server requirements of this specification.
`
` gateway
` A server which acts as an intermediary for some other server.
` Unlike a proxy, a gateway receives requests as if it were the
` origin server for the requested resource; the requesting client
` may not be aware that it is communicating with a gateway.
`
` tunnel
` An intermediary program which is acting as a blind relay between
` two connections. Once active, a tunnel is not considered a party
` to the HTTP communication, though the tunnel may have been
` initiated by an HTTP request. The tunnel ceases to exist when both
` ends of the relayed connections are closed.
`
` cache
` A program’s local store of response messages and the subsystem
` that controls its message storage, retrieval, and deletion. A
` cache stores cachable responses in order to reduce the response
` time and network bandwidth consumption on future, equivalent
` requests. Any client or server may include a cache, though a cache
` cannot be used by a server that is acting as a tunnel.
`
` cachable
` A response is cachable if a cache is allowed to store a copy of
` the response message for use in answering subsequent requests. The
` rules for determining the cachability of HTTP responses are
` defined in section 13. Even if a resource is cachable, there may
` be additional constraints on whether a cache can use the cached
` copy for a particular request.
`
` first-hand
` A response is first-hand if it comes directly and without
` unnecessary delay from the origin server, perhaps via one or more
` proxies. A response is also first-hand if its validity has just
` been checked directly with the origin server.
`
` explicit expiration time
` The time at which the origin server intends that an entity should
` no longer be returned by a cache without further validation.
`
`Fielding, et. al. Standards Track [Page 10]
`
`Juniper Ex. 1031-p. 10
`Juniper v Implicit
`
`

`

`
`RFC 2068 HTTP/1.1 January 1997
`
` heuristic expiration time
` An expiration time assigned by a cache when no explicit expiration
` time is available.
`
` age
` The age of a response is the time since it was sent by, or
` successfully validated with, the origin server.
`
` freshness lifetime
` The length of time between the generation of a response and its
` expiration time.
`
` fresh
` A response is fresh if its age has not yet exceeded its freshness
` lifetime.
`
` stale
` A response is stale if its age has passed its freshness lifetime.
`
` semantically transparent
` A cache behaves in a "semantically transparent" manner, with
` respect to a particular response, when its use affects neither the
` requesting client nor the origin server, except to improve
` performance. When a cache is semantically transparent, the client
` receives exactly the same response (except for hop-by-hop headers)
` that it would have received had its request been handled directly
` by the origin server.
`
` validator
` A protocol element (e.g., an entity tag or a Last-Modified time)
` that is used to find out whether a cache entry is an equivalent
` copy of an entity.
`
`1.4 Overall Operation
`
` The HTTP protocol is a request/response protocol. A client sends a
` request to the server in the form of a request method, URI, and
` protocol version, followed by a MIME-like message containing request
` modifiers, client information, and possible body content over a
` connection with a server. The server responds with a status line,
` including the message’s protocol version and a success or error code,
` followed by a MIME-like message containing server information, entity
` metainformation, and possible entity-body content. The relationship
` between HTTP and MIME is described in appendix 19.4.
`
`Fielding, et. al. Standards Track [Page 11]
`
`Juniper Ex. 1031-p. 11
`Juniper v Implicit
`
`

`

`
`RFC 2068 HTTP/1.1 January 1997
`
` Most HTTP communication is initiated by a user agent and consists of
` a request to be applied to a resource on some origin server. In the
` simplest case, this may be accomplished via a single connection (v)
` between the user agent (UA) and the origin server (O).
`
` request chain ------------------------>
` UA -------------------v------------------- O
` <----------------------- response chain
`
` A more complicated situation occurs when one or more intermediaries
` are present in the request/response chain. There are three common
` forms of intermediary: proxy, gateway, and tunnel. A proxy is a
` forwarding agent, receiving requests for a URI in its absolute form,
` rewriting all or part of the message, and forwarding the reformatted
` request toward the server identified by the URI. A gateway is a
` receiving agent, acting as a layer above some other server(s) and, if
` necessary, translating the requests to the underlying server’s
` protocol. A tunnel acts as a relay point between two connections
` without changing the messages; tunnels are used when the
` communication needs to pass through an intermediary (such as a
` firewall) even when the intermediary cannot understand the contents
` of the messages.
`
` request chain -------------------------------------->
` UA -----v----- A -----v----- B -----v----- C -----v----- O
` <------------------------------------- response chain
`
` The figure above shows three intermediaries (A, B, and C) between the
` user agent and origin server. A request or response message that
` travels the whole chain will pass through four separate connections.
` This distinction is important because some HTTP communication options
` may apply only to the connection with the nearest, non-tunnel
` neighbor, only to the end-points of the chain, or to all connections
` along the chain. Although the diagram is linear, each participant
` may be engaged in multiple, simultaneous communications. For example,
` B may be receiving requests from many clients other than A, and/or
` forwarding requests to servers other than C, at the same time that it
` is handling A’s request.
`
` Any party to the communication which is not acting as a tunnel may
` employ an internal cache for handling requests. The effect of a cache
` is that the request/response chain is shortened if one of the
` participants along the chain has a cached response applicable to that
` request. The following illustrates the resulting chain if B has a
` cached copy of an earlier response from O (via C) for a request which
` has not been cached by UA or A.
`
`Fielding, et. al. Standards Track [Page 12]
`
`Juniper Ex. 1031-p. 12
`Juniper v Implicit
`
`

`

`
`RFC 2068 HTTP/1.1 January 1997
`
` request chain ---------->
` UA -----v----- A -----v----- B - - - - - - C - - - - - - O
` <--------- response chain
`
` Not all responses are usefully cachable, and some requests may
` contain modifiers which place special requirements on cache behavior.
` HTTP requirements for cache behavior and cachable responses are
` defined in section 13.
`
` In fact, there are a wide variety of architectures and configurations
` of caches and proxies currently being experimented with or deployed
` across the World Wide Web; these systems include national hierarchies
` of proxy caches to save transoceanic bandwidth, systems that
` broadcast or multicast cache entries