RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
`
`Page 1 of 90
`
`Internet Engineering Task Force (IETF) R. Fielding, Ed.
`Request for Comments: 7230 Adobe
`Obsoletes: 2145, 2616 J. Reschke, Ed.
`Updates: 2817, 2818 greenbytes
`Category: Standards Track June 2014
`ISSN: 2070-1721
`
`Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
`Abstract
` The Hypertext Transfer Protocol (HTTP) is a stateless application-
` level protocol for distributed, collaborative, hypertext information
` systems. This document provides an overview of HTTP architecture and
` its associated terminology, defines the "http" and "https" Uniform
` Resource Identifier (URI) schemes, defines the HTTP/1.1 message
` syntax and parsing requirements, and describes related security
` concerns for implementations.
`Status of This Memo
` This is an Internet Standards Track document.
` This document is a product of the Internet Engineering Task Force
` (IETF). It represents the consensus of the IETF community. It has
` received public review and has been approved for publication by the
` Internet Engineering Steering Group (IESG). Further information on
` Internet Standards is available in Section 2 of RFC 5741.
` Information about the current status of this document, any errata,
` and how to provide feedback on it may be obtained at
` http://www.rfc-editor.org/info/rfc7230.
`
`Fielding & Reschke Standards Track [Page 1]
`
`https://tools.ietf.org/html/rfc7230
`
`10/14/2019
`
`IPR2019-00131
`PANASONIC EX. 1030, p. 1 of 90
`
`

`

`RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
`
`Page 2 of 90
`
`RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
`
`Copyright Notice
` Copyright (c) 2014 IETF Trust and the persons identified as the
` document authors. All rights reserved.
` This document is subject to BCP 78 and the IETF Trust's Legal
` Provisions Relating to IETF Documents
` (http://trustee.ietf.org/license-info) in effect on the date of
` publication of this document. Please review these documents
` carefully, as they describe your rights and restrictions with respect
` to this document. Code Components extracted from this document must
` include Simplified BSD License text as described in Section 4.e of
` the Trust Legal Provisions and are provided without warranty as
` described in the Simplified BSD License.
` This document may contain material from IETF Documents or IETF
` Contributions published or made publicly available before November
` 10, 2008. The person(s) controlling the copyright in some of this
` material may not have granted the IETF Trust the right to allow
` modifications of such material outside the IETF Standards Process.
` Without obtaining an adequate license from the person(s) controlling
` the copyright in such materials, this document may not be modified
` outside the IETF Standards Process, and derivative works of it may
` not be created outside the IETF Standards Process, except to format
` it for publication as an RFC or to translate it into languages other
` than English.
`Table of Contents
` 1. Introduction ....................................................5
` 1.1. Requirements Notation ......................................6
` 1.2. Syntax Notation ............................................6
` 2. Architecture ....................................................6
` 2.1. Client/Server Messaging ....................................7
` 2.2. Implementation Diversity ...................................8
` 2.3. Intermediaries .............................................9
` 2.4. Caches ....................................................11
` 2.5. Conformance and Error Handling ............................12
` 2.6. Protocol Versioning .......................................13
` 2.7. Uniform Resource Identifiers ..............................16
` 2.7.1. http URI Scheme ....................................17
` 2.7.2. https URI Scheme ...................................18
` 2.7.3. http and https URI Normalization and Comparison ....19
` 3. Message Format .................................................19
` 3.1. Start Line ................................................20
` 3.1.1. Request Line .......................................21
` 3.1.2. Status Line ........................................22
` 3.2. Header Fields .............................................22
`
`Fielding & Reschke Standards Track [Page 2]
`
`https://tools.ietf.org/html/rfc7230
`
`10/14/2019
`
`IPR2019-00131
`PANASONIC EX. 1030, p. 2 of 90
`
`

`

`RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
`
`Page 3 of 90
`
`RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
`
` 3.2.1. Field Extensibility ................................23
` 3.2.2. Field Order ........................................23
` 3.2.3. Whitespace .........................................24
` 3.2.4. Field Parsing ......................................25
` 3.2.5. Field Limits .......................................26
` 3.2.6. Field Value Components .............................27
` 3.3. Message Body ..............................................28
` 3.3.1. Transfer-Encoding ..................................28
` 3.3.2. Content-Length .....................................30
` 3.3.3. Message Body Length ................................32
` 3.4. Handling Incomplete Messages ..............................34
` 3.5. Message Parsing Robustness ................................34
` 4. Transfer Codings ...............................................35
` 4.1. Chunked Transfer Coding ...................................36
` 4.1.1. Chunk Extensions ...................................36
` 4.1.2. Chunked Trailer Part ...............................37
` 4.1.3. Decoding Chunked ...................................38
` 4.2. Compression Codings .......................................38
` 4.2.1. Compress Coding ....................................38
` 4.2.2. Deflate Coding .....................................38
` 4.2.3. Gzip Coding ........................................39
` 4.3. TE ........................................................39
` 4.4. Trailer ...................................................40
` 5. Message Routing ................................................40
` 5.1. Identifying a Target Resource .............................40
` 5.2. Connecting Inbound ........................................41
` 5.3. Request Target ............................................41
` 5.3.1. origin-form ........................................42
` 5.3.2. absolute-form ......................................42
` 5.3.3. authority-form .....................................43
` 5.3.4. asterisk-form ......................................43
` 5.4. Host ......................................................44
` 5.5. Effective Request URI .....................................45
` 5.6. Associating a Response to a Request .......................46
` 5.7. Message Forwarding ........................................47
` 5.7.1. Via ................................................47
` 5.7.2. Transformations ....................................49
` 6. Connection Management ..........................................50
` 6.1. Connection ................................................51
` 6.2. Establishment .............................................52
` 6.3. Persistence ...............................................52
` 6.3.1. Retrying Requests ..................................53
` 6.3.2. Pipelining .........................................54
` 6.4. Concurrency ...............................................55
` 6.5. Failures and Timeouts .....................................55
` 6.6. Tear-down .................................................56
` 6.7. Upgrade ...................................................57
` 7. ABNF List Extension: #rule .....................................59
`
`Fielding & Reschke Standards Track [Page 3]
`
`https://tools.ietf.org/html/rfc7230
`
`10/14/2019
`
`IPR2019-00131
`PANASONIC EX. 1030, p. 3 of 90
`
`

`

`RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
`
`Page 4 of 90
`
`RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
`
` 8. IANA Considerations ............................................61
` 8.1. Header Field Registration .................................61
` 8.2. URI Scheme Registration ...................................62
` 8.3. Internet Media Type Registration ..........................62
` 8.3.1. Internet Media Type message/http ...................62
` 8.3.2. Internet Media Type application/http ...............63
` 8.4. Transfer Coding Registry ..................................64
` 8.4.1. Procedure ..........................................65
` 8.4.2. Registration .......................................65
` 8.5. Content Coding Registration ...............................66
` 8.6. Upgrade Token Registry ....................................66
` 8.6.1. Procedure ..........................................66
` 8.6.2. Upgrade Token Registration .........................67
` 9. Security Considerations ........................................67
` 9.1. Establishing Authority ....................................67
` 9.2. Risks of Intermediaries ...................................68
` 9.3. Attacks via Protocol Element Length .......................69
` 9.4. Response Splitting ........................................69
` 9.5. Request Smuggling .........................................70
` 9.6. Message Integrity .........................................70
` 9.7. Message Confidentiality ...................................71
` 9.8. Privacy of Server Log Information .........................71
` 10. Acknowledgments ...............................................72
` 11. References ....................................................74
` 11.1. Normative References .....................................74
` 11.2. Informative References ...................................75
` Appendix A. HTTP Version History ..................................78
` A.1. Changes from HTTP/1.0 ....................................78
` A.1.1. Multihomed Web Servers ............................78
` A.1.2. Keep-Alive Connections ............................79
` A.1.3. Introduction of Transfer-Encoding .................79
` A.2. Changes from RFC 2616 ....................................80
` Appendix B. Collected ABNF ........................................82
` Index .............................................................85
`
`Fielding & Reschke Standards Track [Page 4]
`
`https://tools.ietf.org/html/rfc7230
`
`10/14/2019
`
`IPR2019-00131
`PANASONIC EX. 1030, p. 4 of 90
`
`

`

`RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
`
`Page 5 of 90
`
`RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
`1. Introduction
` The Hypertext Transfer Protocol (HTTP) is a stateless application-
` level request/response protocol that uses extensible semantics and
` self-descriptive message payloads for flexible interaction with
` network-based hypertext information systems. This document is the
` first in a series of documents that collectively form the HTTP/1.1
` specification:
` 1. "Message Syntax and Routing" (this document)
` 2. "Semantics and Content" [RFC7231]
` 3. "Conditional Requests" [RFC7232]
` 4. "Range Requests" [RFC7233]
` 5. "Caching" [RFC7234]
` 6. "Authentication" [RFC7235]
` This HTTP/1.1 specification obsoletes RFC 2616 and RFC 2145 (on HTTP
` versioning). This specification also updates the use of CONNECT to
` establish a tunnel, previously defined in RFC 2817, and defines the
` "https" URI scheme that was described informally in RFC 2818.
` HTTP is a generic interface protocol for information systems. It is
` designed to hide the details of how a service is implemented by
` presenting a uniform interface to clients that is independent of the
` types of resources provided. Likewise, servers do not need to be
` aware of each client's purpose: an HTTP request can be considered in
` isolation rather than being associated with a specific type of client
` or a predetermined sequence of application steps. The result is a
` protocol that can be used effectively in many different contexts and
` for which implementations can evolve independently over time.
` HTTP is also designed for use as an intermediation protocol for
` translating communication to and from non-HTTP information systems.
` HTTP proxies and gateways can provide access to alternative
` information services by translating their diverse protocols into a
` hypertext format that can be viewed and manipulated by clients in the
` same way as HTTP services.
` One consequence of this flexibility is that the protocol cannot be
` defined in terms of what occurs behind the interface. Instead, we
` are limited to defining the syntax of communication, the intent of
` received communication, and the expected behavior of recipients. If
` the communication is considered in isolation, then successful actions
`
`Fielding & Reschke Standards Track [Page 5]
`
`https://tools.ietf.org/html/rfc7230
`
`10/14/2019
`
`IPR2019-00131
`PANASONIC EX. 1030, p. 5 of 90
`
`

`

`RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
`
`Page 6 of 90
`
`RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
`
` ought to be reflected in corresponding changes to the observable
` interface provided by servers. However, since multiple clients might
` act in parallel and perhaps at cross-purposes, we cannot require that
` such changes be observable beyond the scope of a single response.
` This document describes the architectural elements that are used or
` referred to in HTTP, defines the "http" and "https" URI schemes,
` describes overall network operation and connection management, and
` defines HTTP message framing and forwarding requirements. Our goal
` is to define all of the mechanisms necessary for HTTP message
` handling that are independent of message semantics, thereby defining
` the complete set of requirements for message parsers and message-
` forwarding intermediaries.
`1.1. Requirements Notation
` 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 [RFC2119].
` Conformance criteria and considerations regarding error handling are
` defined in Section 2.5.
`1.2. Syntax Notation
` This specification uses the Augmented Backus-Naur Form (ABNF)
` notation of [RFC5234] with a list extension, defined in Section 7,
` that allows for compact definition of comma-separated lists using a
` '#' operator (similar to how the '*' operator indicates repetition).
` Appendix B shows the collected grammar with all list operators
` expanded to standard ABNF notation.
` The following core rules are included by reference, as defined in
` [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
` (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
` HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line
` feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any
` visible [USASCII] character).
` As a convention, ABNF rule names prefixed with "obs-" denote
` "obsolete" grammar rules that appear for historical reasons.
`2. Architecture
` HTTP was created for the World Wide Web (WWW) architecture and has
` evolved over time to support the scalability needs of a worldwide
` hypertext system. Much of that architecture is reflected in the
` terminology and syntax productions used to define HTTP.
`
`Fielding & Reschke Standards Track [Page 6]
`
`https://tools.ietf.org/html/rfc7230
`
`10/14/2019
`
`IPR2019-00131
`PANASONIC EX. 1030, p. 6 of 90
`
`

`

`RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
`
`Page 7 of 90
`
`RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
`2.1. Client/Server Messaging
` HTTP is a stateless request/response protocol that operates by
` exchanging messages (Section 3) across a reliable transport- or
` session-layer "connection" (Section 6). An HTTP "client" is a
` program that establishes a connection to a server for the purpose of
` sending one or more HTTP requests. An HTTP "server" is a program
` that accepts connections in order to service HTTP requests by sending
` HTTP responses.
` The terms "client" and "server" refer only to the roles that these
` programs perform for a particular connection. The same program might
` act as a client on some connections and a server on others. The term
` "user agent" refers to any of the various client programs that
` initiate a request, including (but not limited to) browsers, spiders
` (web-based robots), command-line tools, custom applications, and
` mobile apps. The term "origin server" refers to the program that can
` originate authoritative responses for a given target resource. The
` terms "sender" and "recipient" refer to any implementation that sends
` or receives a given message, respectively.
` HTTP relies upon the Uniform Resource Identifier (URI) standard
` [RFC3986] to indicate the target resource (Section 5.1) and
` relationships between resources. Messages are passed in a format
` similar to that used by Internet mail [RFC5322] and the Multipurpose
` Internet Mail Extensions (MIME) [RFC2045] (see Appendix A of
` [RFC7231] for the differences between HTTP and MIME messages).
` Most HTTP communication consists of a retrieval request (GET) for a
` representation of some resource identified by a URI. In the simplest
` case, this might be accomplished via a single bidirectional
` connection (===) between the user agent (UA) and the origin
` server (O).
` request >
` UA ======================================= O
` < response
` A client sends an HTTP request to a server in the form of a request
` message, beginning with a request-line that includes a method, URI,
` and protocol version (Section 3.1.1), followed by header fields
` containing request modifiers, client information, and representation
` metadata (Section 3.2), an empty line to indicate the end of the
` header section, and finally a message body containing the payload
` body (if any, Section 3.3).
`
`Fielding & Reschke Standards Track [Page 7]
`
`https://tools.ietf.org/html/rfc7230
`
`10/14/2019
`
`IPR2019-00131
`PANASONIC EX. 1030, p. 7 of 90
`
`

`

`RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
`
`Page 8 of 90
`
`RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
`
` A server responds to a client's request by sending one or more HTTP
` response messages, each beginning with a status line that includes
` the protocol version, a success or error code, and textual reason
` phrase (Section 3.1.2), possibly followed by header fields containing
` server information, resource metadata, and representation metadata
` (Section 3.2), an empty line to indicate the end of the header
` section, and finally a message body containing the payload body (if
` any, Section 3.3).
` A connection might be used for multiple request/response exchanges,
` as defined in Section 6.3.
` The following example illustrates a typical message exchange for a
` GET request (Section 4.3.1 of [RFC7231]) on the URI
` "http://www.example.com/hello.txt":
` Client request:
` GET /hello.txt HTTP/1.1
` User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
` Host: www.example.com
` Accept-Language: en, mi
`
` Server response:
` HTTP/1.1 200 OK
` Date: Mon, 27 Jul 2009 12:28:53 GMT
` Server: Apache
` Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
` ETag: "34aa387-d-1568eb00"
` Accept-Ranges: bytes
` Content-Length: 51
` Vary: Accept-Encoding
` Content-Type: text/plain
` Hello World! My payload includes a trailing CRLF.
`2.2. Implementation Diversity
` When considering the design of HTTP, it is easy to fall into a trap
` of thinking that all user agents are general-purpose browsers and all
` origin servers are large public websites. That is not the case in
` practice. Common HTTP user agents include household appliances,
` stereos, scales, firmware update scripts, command-line programs,
` mobile apps, and communication devices in a multitude of shapes and
` sizes. Likewise, common HTTP origin servers include home automation
`
`Fielding & Reschke Standards Track [Page 8]
`
`https://tools.ietf.org/html/rfc7230
`
`10/14/2019
`
`IPR2019-00131
`PANASONIC EX. 1030, p. 8 of 90
`
`

`

`RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
`
`Page 9 of 90
`
`RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
`
` units, configurable networking components, office machines,
` autonomous robots, news feeds, traffic cameras, ad selectors, and
` video-delivery platforms.
` The term "user agent" does not imply that there is a human user
` directly interacting with the software agent at the time of a
` request. In many cases, a user agent is installed or configured to
` run in the background and save its results for later inspection (or
` save only a subset of those results that might be interesting or
` erroneous). Spiders, for example, are typically given a start URI
` and configured to follow certain behavior while crawling the Web as a
` hypertext graph.
` The implementation diversity of HTTP means that not all user agents
` can make interactive suggestions to their user or provide adequate
` warning for security or privacy concerns. In the few cases where
` this specification requires reporting of errors to the user, it is
` acceptable for such reporting to only be observable in an error
` console or log file. Likewise, requirements that an automated action
` be confirmed by the user before proceeding might be met via advance
` configuration choices, run-time options, or simple avoidance of the
` unsafe action; confirmation does not imply any specific user
` interface or interruption of normal processing if the user has
` already made that choice.
`2.3. Intermediaries
` HTTP enables the use of intermediaries to satisfy requests through a
` chain of connections. There are three common forms of HTTP
` intermediary: proxy, gateway, and tunnel. In some cases, a single
` intermediary might act as an origin server, proxy, gateway, or
` tunnel, switching behavior based on the nature of each request.
` > > > >
` UA =========== A =========== B =========== C =========== O
` < < < <
` 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.
` Some HTTP communication options might apply only to the connection
` with the nearest, non-tunnel neighbor, only to the endpoints of the
` chain, or to all connections along the chain. Although the diagram
` is linear, each participant might be engaged in multiple,
` simultaneous communications. For example, B might 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
`
`Fielding & Reschke Standards Track [Page 9]
`
`https://tools.ietf.org/html/rfc7230
`
`10/14/2019
`
`IPR2019-00131
`PANASONIC EX. 1030, p. 9 of 90
`
`

`

`RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
`
`Page 10 of 90
`
`RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
`
` request. Likewise, later requests might be sent through a different
` path of connections, often based on dynamic configuration for load
` balancing.
` The terms "upstream" and "downstream" are used to describe
` directional requirements in relation to the message flow: all
` messages flow from upstream to downstream. The terms "inbound" and
` "outbound" are used to describe directional requirements in relation
` to the request route: "inbound" means toward the origin server and
` "outbound" means toward the user agent.
` A "proxy" is a message-forwarding agent that is selected by the
` client, usually via local configuration rules, to receive requests
` for some type(s) of absolute URI and attempt to satisfy those
` requests via translation through the HTTP interface. Some
` translations are minimal, such as for proxy requests for "http" URIs,
` whereas other requests might require translation to and from entirely
` different application-level protocols. Proxies are often used to
` group an organization's HTTP requests through a common intermediary
` for the sake of security, annotation services, or shared caching.
` Some proxies are designed to apply transformations to selected
` messages or payloads while they are being forwarded, as described in
` Section 5.7.2.
` A "gateway" (a.k.a. "reverse proxy") is an intermediary that acts as
` an origin server for the outbound connection but translates received
` requests and forwards them inbound to another server or servers.
` Gateways are often used to encapsulate legacy or untrusted
` information services, to improve server performance through
` "accelerator" caching, and to enable partitioning or load balancing
` of HTTP services across multiple machines.
` All HTTP requirements applicable to an origin server also apply to
` the outbound communication of a gateway. A gateway communicates with
` inbound servers using any protocol that it desires, including private
` extensions to HTTP that are outside the scope of this specification.
` However, an HTTP-to-HTTP gateway that wishes to interoperate with
` third-party HTTP servers ought to conform to user agent requirements
` on the gateway's inbound connection.
` A "tunnel" acts as a blind relay between two connections without
` changing the messages. Once active, a tunnel is not considered a
` party to the HTTP communication, though the tunnel might have been
` initiated by an HTTP request. A tunnel ceases to exist when both
` ends of the relayed connection are closed. Tunnels are used to
` extend a virtual connection through an intermediary, such as when
` Transport Layer Security (TLS, [RFC5246]) is used to establish
` confidential communication through a shared firewall proxy.
`
`Fielding & Reschke Standards Track [Page 10]
`
`https://tools.ietf.org/html/rfc7230
`
`10/14/2019
`
`IPR2019-00131
`PANASONIC EX. 1030, p. 10 of 90
`
`

`

`RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
`
`Page 11 of 90
`
`RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
`
` The above categories for intermediary only consider those acting as
` participants in the HTTP communication. There are also
` intermediaries that can act on lower layers of the network protocol
` stack, filtering or redirecting HTTP traffic without the knowledge or
` permission of message senders. Network intermediaries are
` indistinguishable (at a protocol level) from a man-in-the-middle
` attack, often introducing security flaws or interoperability problems
` due to mistakenly violating HTTP semantics.
` For example, an "interception proxy" [RFC3040] (also commonly known
` as a "transparent proxy" [RFC1919] or "captive portal") differs from
` an HTTP proxy because it is not selected by the client. Instead, an
` interception proxy filters or redirects outgoing TCP port 80 packets
` (and occasionally other common port traffic). Interception proxies
` are commonly found on public network access points, as a means of
` enforcing account subscription prior to allowing use of non-local
` Internet services, and within corporate firewalls to enforce network
` usage policies.
` HTTP is defined as a stateless protocol, meaning that each request
` message can be understood in isolation. Many implementations depend
` on HTTP's stateless design in order to reuse proxied connections or
` dynamically load balance requests across multiple servers. Hence, a
` server MUST NOT assume that two requests on the same connection are
` from the same user agent unless the connection is secured and
` specific to that agent. Some non-standard HTTP extensions (e.g.,
` [RFC4559]) have been known to violate this requirement, resulting in
` security and interoperability problems.
`2.4. Caches
` A "cache" is a local store of previous 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 employ a cache, though a cache
` cannot be used by a server while it is acting as a tunnel.
` 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 that has not been cached by UA or A.
` > >
` UA =========== A =========== B - - - - - - C - - - - - - O
` < <
`
`Fielding & Reschke Standards Track [Page 11]
`
`https://tools.ietf.org/html/rfc7230
`
`10/14/2019
`
`IPR2019-00131
`PANASONIC EX. 1030, p. 11 of 90
`
`

`

`RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
`
`Page 12 of 90
`
`RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
`
` A response is "cacheable" if a cache is allowed to store a copy of
` the response message for use in answering subsequent requests. Even
` when a response is cacheable, there might be additional constraints
` placed by the client or by the origin server on when that cached
` response can be used for a particular request. HTTP requirements for
` cache behavior and cacheable responses are defined in Section 2 of
` [RFC7234].
` There is a wide variety of architectures and configurations of caches
` deployed across the World Wide Web and inside large organizations.
` These include national hierarchies of proxy caches to save
` transoceanic bandwidth, collaborative systems that broadcast or
` multicast cache entries, archives of pre-fetched cache entries for
` use in off-line or high-latency environments, and so on.
`2.5. Conformance and Error Handling
` This specification targets conformance criteria according to the role
` of a participant in HTTP communication. Hence, HTTP requirements are
` placed on senders, recipients, clients, servers, user agents,
` intermediaries, origin servers, proxies, gateways, or caches,
` depending on what behavior is being constrained by the requirement.
` Additional (social) requirements are placed on implementations,
` resource owners, and protocol element registrations when they apply
`