rfc9110v1.txt   rfc9110.txt 
Internet Engineering Task Force (IETF) R. Fielding, Ed. Internet Engineering Task Force (IETF) R. Fielding, Ed.
Request for Comments: 9110 Adobe Request for Comments: 9110 Adobe
STD: 97 M. Nottingham, Ed. STD: 97 M. Nottingham, Ed.
Obsoletes: 2818, 7230, 7231, 7232, 7233, 7235, Fastly Obsoletes: 2818, 7230, 7231, 7232, 7233, 7235, Fastly
7538, 7615, 7694 J. Reschke, Ed. 7538, 7615, 7694 J. Reschke, Ed.
Updates: 3864 greenbytes Updates: 3864 greenbytes
Category: Standards Track December 2021 Category: Standards Track February 2022
ISSN: 2070-1721 ISSN: 2070-1721
HTTP Semantics HTTP Semantics
Abstract Abstract
The Hypertext Transfer Protocol (HTTP) is a stateless application- The Hypertext Transfer Protocol (HTTP) is a stateless application-
level protocol for distributed, collaborative, hypertext information level protocol for distributed, collaborative, hypertext information
systems. This document describes the overall architecture of HTTP, systems. This document describes the overall architecture of HTTP,
establishes common terminology, and defines aspects of the protocol establishes common terminology, and defines aspects of the protocol
skipping to change at line 42 skipping to change at line 42
received public review and has been approved for publication by the received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841. Internet Standards is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata, Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9110. https://www.rfc-editor.org/info/rfc9110.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Revised BSD License text as described in Section 4.e of the include Revised BSD License text as described in Section 4.e of the
Trust Legal Provisions and are provided without warranty as described Trust Legal Provisions and are provided without warranty as described
skipping to change at line 434 skipping to change at line 434
syntax, improving its interoperability, scalability, and robustness syntax, improving its interoperability, scalability, and robustness
across the Internet. This included length-based data delimiters for across the Internet. This included length-based data delimiters for
both fixed and dynamic (chunked) content, a consistent framework for both fixed and dynamic (chunked) content, a consistent framework for
content negotiation, opaque validators for conditional requests, content negotiation, opaque validators for conditional requests,
cache controls for better cache consistency, range requests for cache controls for better cache consistency, range requests for
partial updates, and default persistent connections. HTTP/1.1 was partial updates, and default persistent connections. HTTP/1.1 was
introduced in 1995 and published on the Standards Track in 1997 introduced in 1995 and published on the Standards Track in 1997
[RFC2068], revised in 1999 [RFC2616], and revised again in 2014 [RFC2068], revised in 1999 [RFC2616], and revised again in 2014
([RFC7230] through [RFC7235]). ([RFC7230] through [RFC7235]).
HTTP/2 [HTTP/2] introduced a multiplexed session layer on top of the HTTP/2 ([HTTP/2]) introduced a multiplexed session layer on top of
existing TLS and TCP protocols for exchanging concurrent HTTP the existing TLS and TCP protocols for exchanging concurrent HTTP
messages with efficient field compression and server push. HTTP/3 messages with efficient field compression and server push. HTTP/3
[HTTP/3] provides greater independence for concurrent messages by ([HTTP/3]) provides greater independence for concurrent messages by
using QUIC as a secure multiplexed transport over UDP instead of TCP. using QUIC as a secure multiplexed transport over UDP instead of TCP.
All three major versions of HTTP rely on the semantics defined by All three major versions of HTTP rely on the semantics defined by
this document. They have not obsoleted each other because each one this document. They have not obsoleted each other because each one
has specific benefits and limitations depending on the context of has specific benefits and limitations depending on the context of
use. Implementations are expected to choose the most appropriate use. Implementations are expected to choose the most appropriate
transport and messaging syntax for their particular context. transport and messaging syntax for their particular context.
This revision of HTTP separates the definition of semantics (this This revision of HTTP separates the definition of semantics (this
document) and caching [CACHING] from the current HTTP/1.1 messaging document) and caching ([CACHING]) from the current HTTP/1.1 messaging
syntax [HTTP/1.1] to allow each major protocol version to progress syntax ([HTTP/1.1]) to allow each major protocol version to progress
independently while referring to the same core semantics. independently while referring to the same core semantics.
1.3. Core Semantics 1.3. Core Semantics
HTTP provides a uniform interface for interacting with a resource HTTP provides a uniform interface for interacting with a resource
(Section 3.1) -- regardless of its type, nature, or implementation -- (Section 3.1) -- regardless of its type, nature, or implementation --
by sending messages that manipulate or transfer representations by sending messages that manipulate or transfer representations
(Section 3.2). (Section 3.2).
Each message is either a request or a response. A client constructs Each message is either a request or a response. A client constructs
skipping to change at line 477 skipping to change at line 477
HTTP semantics include the intentions defined by each request method HTTP semantics include the intentions defined by each request method
(Section 9), extensions to those semantics that might be described in (Section 9), extensions to those semantics that might be described in
request header fields, status codes that describe the response request header fields, status codes that describe the response
(Section 15), and other control data and resource metadata that might (Section 15), and other control data and resource metadata that might
be given in response fields. be given in response fields.
Semantics also include representation metadata that describe how Semantics also include representation metadata that describe how
content is intended to be interpreted by a recipient, request header content is intended to be interpreted by a recipient, request header
fields that might influence content selection, and the various fields that might influence content selection, and the various
selection algorithms that are collectively referred to as _content selection algorithms that are collectively referred to as "content
negotiation_ (Section 12). negotiation" (Section 12).
1.4. Specifications Obsoleted by This Document 1.4. Specifications Obsoleted by This Document
+=============================+===========+================+ +============================================+===========+=====+
| Title | Reference | Changes Listed | | Title | Reference | See |
| | | in Appendix: | +============================================+===========+=====+
+=============================+===========+================+ | HTTP Over TLS | [RFC2818] | B.1 |
| HTTP Over TLS | [RFC2818] | B.1 | +--------------------------------------------+-----------+-----+
+-----------------------------+-----------+----------------+ | HTTP/1.1 Message Syntax and Routing [*] | [RFC7230] | B.2 |
| HTTP/1.1 Message Syntax and | [RFC7230] | B.2 | +--------------------------------------------+-----------+-----+
| Routing [*] | | | | HTTP/1.1 Semantics and Content | [RFC7231] | B.3 |
+-----------------------------+-----------+----------------+ +--------------------------------------------+-----------+-----+
| HTTP/1.1 Semantics and | [RFC7231] | B.3 | | HTTP/1.1 Conditional Requests | [RFC7232] | B.4 |
| Content | | | +--------------------------------------------+-----------+-----+
+-----------------------------+-----------+----------------+ | HTTP/1.1 Range Requests | [RFC7233] | B.5 |
| HTTP/1.1 Conditional | [RFC7232] | B.4 | +--------------------------------------------+-----------+-----+
| Requests | | | | HTTP/1.1 Authentication | [RFC7235] | B.6 |
+-----------------------------+-----------+----------------+ +--------------------------------------------+-----------+-----+
| HTTP/1.1 Range Requests | [RFC7233] | B.5 | | HTTP Status Code 308 (Permanent Redirect) | [RFC7538] | B.7 |
+-----------------------------+-----------+----------------+ +--------------------------------------------+-----------+-----+
| HTTP/1.1 Authentication | [RFC7235] | B.6 | | HTTP Authentication-Info and Proxy- | [RFC7615] | B.8 |
+-----------------------------+-----------+----------------+ | Authentication-Info Response Header Fields | | |
| HTTP Status Code 308 | [RFC7538] | B.7 | +--------------------------------------------+-----------+-----+
| (Permanent Redirect) | | | | HTTP Client-Initiated Content-Encoding | [RFC7694] | B.9 |
+-----------------------------+-----------+----------------+ +--------------------------------------------+-----------+-----+
| HTTP Authentication-Info | [RFC7615] | B.8 |
| and Proxy-Authentication- | | |
| Info Response Header Fields | | |
+-----------------------------+-----------+----------------+
| HTTP Client-Initiated | [RFC7694] | B.9 |
| Content-Encoding | | |
+-----------------------------+-----------+----------------+
Table 1: Specifications Obsoleted by This Document Table 1: Specifications Obsoleted by This Document
[*] This document only obsoletes the portions of RFC 7230 that are [*] This document only obsoletes the portions of RFC 7230 that are
independent of the HTTP/1.1 messaging syntax and connection independent of the HTTP/1.1 messaging syntax and connection
management; the remaining bits of RFC 7230 are obsoleted by management; the remaining bits of RFC 7230 are obsoleted by
"HTTP/1.1" [HTTP/1.1]. "HTTP/1.1" [HTTP/1.1].
2. Conformance 2. Conformance
2.1. Syntax Notation 2.1. Syntax Notation
This specification uses the Augmented Backus-Naur Form (ABNF) This specification uses the Augmented Backus-Naur Form (ABNF)
notation of [RFC5234], extended with the notation for case- notation of [RFC5234], extended with the notation for case-
sensitivity in strings defined in [RFC7405]. sensitivity in strings defined in [RFC7405].
It also uses a list extension, defined in Section 5.6.1, that allows It also uses a list extension, defined in Section 5.6.1, that allows
for compact definition of comma-separated lists using a "#" operator for compact definition of comma-separated lists using a "#" operator
(similar to how the "*" operator indicates repetition). Appendix A (similar to how the "*" operator indicates repetition). Appendix A
shows the collected grammar with all list operators expanded to shows the collected grammar with all list operators expanded to
standard ABNF notation. standard ABNF notation.
As a convention, ABNF rule names prefixed with "obs-" denote As a convention, ABNF rule names prefixed with "obs-" denote obsolete
"obsolete" grammar rules that appear for historical reasons. grammar rules that appear for historical reasons.
The following core rules are included by reference, as defined in The following core rules are included by reference, as defined in
Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return), Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return),
CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double
quote), HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF 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 (line feed), OCTET (any 8-bit sequence of data), SP (space), and
VCHAR (any visible US-ASCII character). VCHAR (any visible US-ASCII character).
Section 5.6 defines some generic syntactic components for field Section 5.6 defines some generic syntactic components for field
values. values.
skipping to change at line 659 skipping to change at line 652
Location header field doesn't parse according to the ABNF, whereas a Location header field doesn't parse according to the ABNF, whereas a
systems control client might consider any form of error recovery to systems control client might consider any form of error recovery to
be dangerous. be dangerous.
Some requests can be automatically retried by a client in the event Some requests can be automatically retried by a client in the event
of an underlying connection failure, as described in Section 9.2.2. of an underlying connection failure, as described in Section 9.2.2.
2.5. Protocol Version 2.5. Protocol Version
HTTP's version number consists of two decimal digits separated by a HTTP's version number consists of two decimal digits separated by a
"." (period or decimal point). The first digit ("major version") "." (period or decimal point). The first digit (major version)
indicates the messaging syntax, whereas the second digit ("minor indicates the messaging syntax, whereas the second digit (minor
version") indicates the highest minor version within that major version) indicates the highest minor version within that major
version to which the sender is conformant (able to understand for version to which the sender is conformant (able to understand for
future communication). future communication).
While HTTP's core semantics don't change between protocol versions, While HTTP's core semantics don't change between protocol versions,
the expression of them "on the wire" can change, and so the HTTP their expression "on the wire" can change, and so the HTTP version
version number changes when incompatible changes are made to the wire number changes when incompatible changes are made to the wire format.
format. Additionally, HTTP allows incremental, backwards-compatible Additionally, HTTP allows incremental, backwards-compatible changes
changes to be made to the protocol without changing its version to be made to the protocol without changing its version through the
through the use of defined extension points (Section 16). use of defined extension points (Section 16).
The protocol version as a whole indicates the sender's conformance The protocol version as a whole indicates the sender's conformance
with the set of requirements laid out in that version's corresponding with the set of requirements laid out in that version's corresponding
specification of HTTP. For example, the version "HTTP/1.1" is specification(s). For example, the version "HTTP/1.1" is defined by
defined by the combined specifications of this document, "HTTP the combined specifications of this document, "HTTP Caching"
Caching" [CACHING], and "HTTP/1.1" [HTTP/1.1]. [CACHING], and "HTTP/1.1" [HTTP/1.1].
HTTP's major version number is incremented when an incompatible HTTP's major version number is incremented when an incompatible
message syntax is introduced. The minor number is incremented when message syntax is introduced. The minor number is incremented when
changes made to the protocol have the effect of adding to the message changes made to the protocol have the effect of adding to the message
semantics or implying additional capabilities of the sender. semantics or implying additional capabilities of the sender.
The minor version advertises the sender's communication capabilities The minor version advertises the sender's communication capabilities
even when the sender is only using a backwards-compatible subset of even when the sender is only using a backwards-compatible subset of
the protocol, thereby letting the recipient know that more advanced the protocol, thereby letting the recipient know that more advanced
features can be used in response (by servers) or in future requests features can be used in response (by servers) or in future requests
skipping to change at line 702 skipping to change at line 695
3. Terminology and Core Concepts 3. Terminology and Core Concepts
HTTP was created for the World Wide Web (WWW) architecture and has HTTP was created for the World Wide Web (WWW) architecture and has
evolved over time to support the scalability needs of a worldwide evolved over time to support the scalability needs of a worldwide
hypertext system. Much of that architecture is reflected in the hypertext system. Much of that architecture is reflected in the
terminology used to define HTTP. terminology used to define HTTP.
3.1. Resources 3.1. Resources
The target of an HTTP request is called a _resource_. HTTP does not The target of an HTTP request is called a "resource". HTTP does not
limit the nature of a resource; it merely defines an interface that limit the nature of a resource; it merely defines an interface that
might be used to interact with resources. Most resources are might be used to interact with resources. Most resources are
identified by a Uniform Resource Identifier (URI), as described in identified by a Uniform Resource Identifier (URI), as described in
Section 4. Section 4.
One design goal of HTTP is to separate resource identification from One design goal of HTTP is to separate resource identification from
request semantics, which is made possible by vesting the request request semantics, which is made possible by vesting the request
semantics in the request method (Section 9) and a few request- semantics in the request method (Section 9) and a few request-
modifying header fields. A resource cannot treat a request in a modifying header fields. A resource cannot treat a request in a
manner inconsistent with the semantics of the method of the request. manner inconsistent with the semantics of the method of the request.
skipping to change at line 724 skipping to change at line 717
are not safe, a client can expect the resource to avoid actions that are not safe, a client can expect the resource to avoid actions that
are unsafe when processing a request with a safe method (see are unsafe when processing a request with a safe method (see
Section 9.2.1). Section 9.2.1).
HTTP relies upon the Uniform Resource Identifier (URI) standard [URI] HTTP relies upon the Uniform Resource Identifier (URI) standard [URI]
to indicate the target resource (Section 7.1) and relationships to indicate the target resource (Section 7.1) and relationships
between resources. between resources.
3.2. Representations 3.2. Representations
A _representation_ is information that is intended to reflect a past, A "representation" is information that is intended to reflect a past,
current, or desired state of a given resource, in a format that can current, or desired state of a given resource, in a format that can
be readily communicated via the protocol. A representation consists be readily communicated via the protocol. A representation consists
of a set of representation metadata and a potentially unbounded of a set of representation metadata and a potentially unbounded
stream of representation data (Section 8). stream of representation data (Section 8).
HTTP allows "information hiding" behind its uniform interface by HTTP allows "information hiding" behind its uniform interface by
defining communication with respect to a transferable representation defining communication with respect to a transferable representation
of the resource state, rather than transferring the resource itself. of the resource state, rather than transferring the resource itself.
This allows the resource identified by a URI to be anything, This allows the resource identified by a URI to be anything,
including temporal functions like "the current weather in Laguna including temporal functions like "the current weather in Laguna
skipping to change at line 752 skipping to change at line 745
or desired state of that thing in our communications. When a or desired state of that thing in our communications. When a
representation is hypertext, it can provide both a representation of representation is hypertext, it can provide both a representation of
the resource state and processing instructions that help guide the the resource state and processing instructions that help guide the
recipient's future interactions. recipient's future interactions.
A target resource might be provided with, or be capable of A target resource might be provided with, or be capable of
generating, multiple representations that are each intended to generating, multiple representations that are each intended to
reflect the resource's current state. An algorithm, usually based on reflect the resource's current state. An algorithm, usually based on
content negotiation (Section 12), would be used to select one of content negotiation (Section 12), would be used to select one of
those representations as being most applicable to a given request. those representations as being most applicable to a given request.
This _selected representation_ provides the data and metadata for This "selected representation" provides the data and metadata for
evaluating conditional requests (Section 13) and constructing the evaluating conditional requests (Section 13) and constructing the
content for 200 (OK), 206 (Partial Content), and 304 (Not Modified) content for 200 (OK), 206 (Partial Content), and 304 (Not Modified)
responses to GET (Section 9.3.1). responses to GET (Section 9.3.1).
3.3. Connections, Clients, and Servers 3.3. Connections, Clients, and Servers
HTTP is a client/server protocol that operates over a reliable HTTP is a client/server protocol that operates over a reliable
transport- or session-layer _connection_. transport- or session-layer "connection".
An HTTP _client_ is a program that establishes a connection to a 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 for the purpose of sending one or more HTTP requests. An HTTP
_server_ is a program that accepts connections in order to service "server" is a program that accepts connections in order to service
HTTP requests by sending HTTP responses. HTTP requests by sending HTTP responses.
The terms "client" and "server" refer only to the roles that these The terms client and server refer only to the roles that these
programs perform for a particular connection. The same program might programs perform for a particular connection. The same program might
act as a client on some connections and a server on others. act as a client on some connections and a server on others.
HTTP is defined as a stateless protocol, meaning that each request HTTP is defined as a stateless protocol, meaning that each request
message's semantics can be understood in isolation, and that the message's semantics can be understood in isolation, and that the
relationship between connections and messages on them has no impact relationship between connections and messages on them has no impact
on the interpretation of those messages. For example, a CONNECT on the interpretation of those messages. For example, a CONNECT
request (Section 9.3.6) or a request with the Upgrade header field request (Section 9.3.6) or a request with the Upgrade header field
(Section 7.8) can occur at any time, not just in the first message on (Section 7.8) can occur at any time, not just in the first message on
a connection. Many implementations depend on HTTP's stateless design a connection. Many implementations depend on HTTP's stateless design
skipping to change at line 790 skipping to change at line 783
As a result, a server MUST NOT assume that two requests on the same As a result, a server MUST NOT assume that two requests on the same
connection are from the same user agent unless the connection is connection are from the same user agent unless the connection is
secured and specific to that agent. Some non-standard HTTP secured and specific to that agent. Some non-standard HTTP
extensions (e.g., [RFC4559]) have been known to violate this extensions (e.g., [RFC4559]) have been known to violate this
requirement, resulting in security and interoperability problems. requirement, resulting in security and interoperability problems.
3.4. Messages 3.4. Messages
HTTP is a stateless request/response protocol for exchanging HTTP is a stateless request/response protocol for exchanging
_messages_ across a connection. The terms _sender_ and _recipient_ "messages" across a connection. The terms "sender" and "recipient"
refer to any implementation that sends or receives a given message, refer to any implementation that sends or receives a given message,
respectively. respectively.
A client sends requests to a server in the form of a _request_ A client sends requests to a server in the form of a "request"
message with a method (Section 9) and request target (Section 7.1). message with a method (Section 9) and request target (Section 7.1).
The request might also contain header fields (Section 6.3) for The request might also contain header fields (Section 6.3) for
request modifiers, client information, and representation metadata, request modifiers, client information, and representation metadata,
content (Section 6.4) intended for processing in accordance with the content (Section 6.4) intended for processing in accordance with the
method, and trailer fields (Section 6.5) to communicate information method, and trailer fields (Section 6.5) to communicate information
collected while sending the content. collected while sending the content.
A server responds to a client's request by sending one or more A server responds to a client's request by sending one or more
_response_ messages, each including a status code (Section 15). The "response" messages, each including a status code (Section 15). The
response might also contain header fields for server information, response might also contain header fields for server information,
resource metadata, and representation metadata, content to be resource metadata, and representation metadata, content to be
interpreted in accordance with the status code, and trailer fields to interpreted in accordance with the status code, and trailer fields to
communicate information collected while sending the content. communicate information collected while sending the content.
3.5. User Agents 3.5. User Agents
The term _user agent_ refers to any of the various client programs The term "user agent" refers to any of the various client programs
that initiate a request. that initiate a request.
The most familiar form of user agent is the general-purpose Web The most familiar form of user agent is the general-purpose Web
browser, but that's only a small percentage of implementations. browser, but that's only a small percentage of implementations.
Other common user agents include spiders (web-traversing robots), Other common user agents include spiders (web-traversing robots),
command-line tools, billboard screens, household appliances, scales, command-line tools, billboard screens, household appliances, scales,
light bulbs, firmware update scripts, mobile apps, and communication light bulbs, firmware update scripts, mobile apps, and communication
devices in a multitude of shapes and sizes. devices in a multitude of shapes and sizes.
Being a user agent does not imply that there is a human user directly Being a user agent does not imply that there is a human user directly
skipping to change at line 843 skipping to change at line 836
reporting of errors to the user, it is acceptable for such reporting reporting of errors to the user, it is acceptable for such reporting
to only be observable in an error console or log file. Likewise, to only be observable in an error console or log file. Likewise,
requirements that an automated action be confirmed by the user before requirements that an automated action be confirmed by the user before
proceeding might be met via advance configuration choices, run-time proceeding might be met via advance configuration choices, run-time
options, or simple avoidance of the unsafe action; confirmation does options, or simple avoidance of the unsafe action; confirmation does
not imply any specific user interface or interruption of normal not imply any specific user interface or interruption of normal
processing if the user has already made that choice. processing if the user has already made that choice.
3.6. Origin Server 3.6. Origin Server
The term _origin server_ refers to a program that can originate The term "origin server" refers to a program that can originate
authoritative responses for a given target resource. authoritative responses for a given target resource.
The most familiar form of origin server are large public websites. The most familiar form of origin server are large public websites.
However, like user agents being equated with browsers, it is easy to However, like user agents being equated with browsers, it is easy to
be misled into thinking that all origin servers are alike. Common be misled into thinking that all origin servers are alike. Common
origin servers also include home automation units, configurable origin servers also include home automation units, configurable
networking components, office machines, autonomous robots, news networking components, office machines, autonomous robots, news
feeds, traffic cameras, real-time ad selectors, and video-on-demand feeds, traffic cameras, real-time ad selectors, and video-on-demand
platforms. platforms.
skipping to change at line 870 skipping to change at line 863
request > request >
UA ======================================= O UA ======================================= O
< response < response
Figure 1 Figure 1
3.7. Intermediaries 3.7. Intermediaries
HTTP enables the use of intermediaries to satisfy requests through a HTTP enables the use of intermediaries to satisfy requests through a
chain of connections. There are three common forms of HTTP chain of connections. There are three common forms of HTTP
_intermediary_: proxy, gateway, and tunnel. In some cases, a single "intermediary": proxy, gateway, and tunnel. In some cases, a single
intermediary might act as an origin server, proxy, gateway, or intermediary might act as an origin server, proxy, gateway, or
tunnel, switching behavior based on the nature of each request. tunnel, switching behavior based on the nature of each request.
> > > > > > > >
UA =========== A =========== B =========== C =========== O UA =========== A =========== B =========== C =========== O
< < < < < < < <
Figure 2 Figure 2
The figure above shows three intermediaries (A, B, and C) between the The figure above shows three intermediaries (A, B, and C) between the
skipping to change at line 894 skipping to change at line 887
with the nearest, non-tunnel neighbor, only to the endpoints of the with the nearest, non-tunnel neighbor, only to the endpoints of the
chain, or to all connections along the chain. Although the diagram chain, or to all connections along the chain. Although the diagram
is linear, each participant might be engaged in multiple, is linear, each participant might be engaged in multiple,
simultaneous communications. For example, B might be receiving simultaneous communications. For example, B might be receiving
requests from many clients other than A, and/or forwarding requests 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 to servers other than C, at the same time that it is handling A's
request. Likewise, later requests might be sent through a different request. Likewise, later requests might be sent through a different
path of connections, often based on dynamic configuration for load path of connections, often based on dynamic configuration for load
balancing. balancing.
The terms _upstream_ and _downstream_ are used to describe The terms "upstream" and "downstream" are used to describe
directional requirements in relation to the message flow: all directional requirements in relation to the message flow: all
messages flow from upstream to downstream. The terms "inbound" and messages flow from upstream to downstream. The terms "inbound" and
"outbound" are used to describe directional requirements in relation "outbound" are used to describe directional requirements in relation
to the request route: _inbound_ means toward the origin server and to the request route: inbound means "toward the origin server",
_outbound_ means toward the user agent. whereas outbound means "toward the user agent".
A _proxy_ is a message-forwarding agent that is chosen by the client, A "proxy" is a message-forwarding agent that is chosen by the client,
usually via local configuration rules, to receive requests for some usually via local configuration rules, to receive requests for some
type(s) of absolute URI and attempt to satisfy those requests via type(s) of absolute URI and attempt to satisfy those requests via
translation through the HTTP interface. Some translations are translation through the HTTP interface. Some translations are
minimal, such as for proxy requests for "http" URIs, whereas other minimal, such as for proxy requests for "http" URIs, whereas other
requests might require translation to and from entirely different requests might require translation to and from entirely different
application-level protocols. Proxies are often used to group an application-level protocols. Proxies are often used to group an
organization's HTTP requests through a common intermediary for the organization's HTTP requests through a common intermediary for the
sake of security services, annotation services, or shared caching. sake of security services, annotation services, or shared caching.
Some proxies are designed to apply transformations to selected Some proxies are designed to apply transformations to selected
messages or content while they are being forwarded, as described in messages or content while they are being forwarded, as described in
Section 7.7. Section 7.7.
A _gateway_ (a.k.a. _reverse proxy_) is an intermediary that acts as A "gateway" (a.k.a. "reverse proxy") is an intermediary that acts as
an origin server for the outbound connection but translates received an origin server for the outbound connection but translates received
requests and forwards them inbound to another server or servers. requests and forwards them inbound to another server or servers.
Gateways are often used to encapsulate legacy or untrusted Gateways are often used to encapsulate legacy or untrusted
information services, to improve server performance through information services, to improve server performance through
_accelerator_ caching, and to enable partitioning or load balancing "accelerator" caching, and to enable partitioning or load balancing
of HTTP services across multiple machines. of HTTP services across multiple machines.
All HTTP requirements applicable to an origin server also apply to All HTTP requirements applicable to an origin server also apply to
the outbound communication of a gateway. A gateway communicates with the outbound communication of a gateway. A gateway communicates with
inbound servers using any protocol that it desires, including private inbound servers using any protocol that it desires, including private
extensions to HTTP that are outside the scope of this specification. extensions to HTTP that are outside the scope of this specification.
However, an HTTP-to-HTTP gateway that wishes to interoperate with However, an HTTP-to-HTTP gateway that wishes to interoperate with
third-party HTTP servers needs to conform to user agent requirements third-party HTTP servers needs to conform to user agent requirements
on the gateway's inbound connection. on the gateway's inbound connection.
A _tunnel_ acts as a blind relay between two connections without A "tunnel" acts as a blind relay between two connections without
changing the messages. Once active, a tunnel is not considered a changing the messages. Once active, a tunnel is not considered a
party to the HTTP communication, though the tunnel might have been party to the HTTP communication, though the tunnel might have been
initiated by an HTTP request. A tunnel ceases to exist when both initiated by an HTTP request. A tunnel ceases to exist when both
ends of the relayed connection are closed. Tunnels are used to ends of the relayed connection are closed. Tunnels are used to
extend a virtual connection through an intermediary, such as when extend a virtual connection through an intermediary, such as when
Transport Layer Security (TLS, [TLS13]) is used to establish Transport Layer Security (TLS, [TLS13]) is used to establish
confidential communication through a shared firewall proxy. confidential communication through a shared firewall proxy.
The above categories for intermediary only consider those acting as The above categories for intermediary only consider those acting as
participants in the HTTP communication. There are also participants in the HTTP communication. There are also
intermediaries that can act on lower layers of the network protocol intermediaries that can act on lower layers of the network protocol
stack, filtering or redirecting HTTP traffic without the knowledge or stack, filtering or redirecting HTTP traffic without the knowledge or
permission of message senders. Network intermediaries are permission of message senders. Network intermediaries are
indistinguishable (at a protocol level) from an on-path attacker, indistinguishable (at a protocol level) from an on-path attacker,
often introducing security flaws or interoperability problems due to often introducing security flaws or interoperability problems due to
mistakenly violating HTTP semantics. mistakenly violating HTTP semantics.
For example, an _interception proxy_ [RFC3040] (also commonly known For example, an "interception proxy" [RFC3040] (also commonly known
as a _transparent proxy_ [RFC1919]) differs from an HTTP proxy as a "transparent proxy" [RFC1919]) differs from an HTTP proxy
because it is not chosen by the client. Instead, an interception because it is not chosen by the client. Instead, an interception
proxy filters or redirects outgoing TCP port 80 packets (and proxy filters or redirects outgoing TCP port 80 packets (and
occasionally other common port traffic). Interception proxies are occasionally other common port traffic). Interception proxies are
commonly found on public network access points, as a means of commonly found on public network access points, as a means of
enforcing account subscription prior to allowing use of non-local enforcing account subscription prior to allowing use of non-local
Internet services, and within corporate firewalls to enforce network Internet services, and within corporate firewalls to enforce network
usage policies. usage policies.
3.8. Caches 3.8. Caches
A _cache_ is a local store of previous response messages and the A "cache" is a local store of previous response messages and the
subsystem that controls its message storage, retrieval, and deletion. subsystem that controls its message storage, retrieval, and deletion.
A cache stores cacheable responses in order to reduce the response A cache stores cacheable responses in order to reduce the response
time and network bandwidth consumption on future, equivalent time and network bandwidth consumption on future, equivalent
requests. Any client or server MAY employ a cache, though a cache requests. Any client or server MAY employ a cache, though a cache
cannot be used while acting as a tunnel. cannot be used while acting as a tunnel.
The effect of a cache is that the request/response chain is shortened 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 if one of the participants along the chain has a cached response
applicable to that request. The following illustrates the resulting applicable to that request. The following illustrates the resulting
chain if B has a cached copy of an earlier response from O (via C) 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. for a request that has not been cached by UA or A.
> > > >
UA =========== A =========== B - - - - - - C - - - - - - O UA =========== A =========== B - - - - - - C - - - - - - O
< < < <
Figure 3 Figure 3
A response is _cacheable_ if a cache is allowed to store a copy of A response is "cacheable" if a cache is allowed to store a copy of
the response message for use in answering subsequent requests. Even the response message for use in answering subsequent requests. Even
when a response is cacheable, there might be additional constraints when a response is cacheable, there might be additional constraints
placed by the client or by the origin server on when that cached placed by the client or by the origin server on when that cached
response can be used for a particular request. HTTP requirements for response can be used for a particular request. HTTP requirements for
cache behavior and cacheable responses are defined in [CACHING]. cache behavior and cacheable responses are defined in [CACHING].
There is a wide variety of architectures and configurations of caches There is a wide variety of architectures and configurations of caches
deployed across the World Wide Web and inside large organizations. deployed across the World Wide Web and inside large organizations.
These include national hierarchies of proxy caches to save bandwidth These include national hierarchies of proxy caches to save bandwidth
and reduce latency, content delivery networks that use gateway and reduce latency, content delivery networks that use gateway
skipping to change at line 1097 skipping to change at line 1090
listening for connections. Anyone can mint a URI, whether or not a listening for connections. Anyone can mint a URI, whether or not a
server exists and whether or not that server currently maps that server exists and whether or not that server currently maps that
identifier to a resource. The delegated nature of registered names identifier to a resource. The delegated nature of registered names
and IP addresses creates a federated namespace whether or not an HTTP and IP addresses creates a federated namespace whether or not an HTTP
server is present. server is present.
4.2.1. http URI Scheme 4.2.1. http URI Scheme
The "http" URI scheme is hereby defined for minting identifiers The "http" URI scheme is hereby defined for minting identifiers
within the hierarchical namespace governed by a potential HTTP origin within the hierarchical namespace governed by a potential HTTP origin
server listening for TCP [TCP] connections on a given port. server listening for TCP ([TCP]) connections on a given port.
http-URI = "http" "://" authority path-abempty [ "?" query ] http-URI = "http" "://" authority path-abempty [ "?" query ]
The origin server for an "http" URI is identified by the authority The origin server for an "http" URI is identified by the authority
component, which includes a host identifier ([URI], Section 3.2.2) component, which includes a host identifier ([URI], Section 3.2.2)
and optional port number ([URI], Section 3.2.3). If the port and optional port number ([URI], Section 3.2.3). If the port
subcomponent is empty or not given, TCP port 80 (the reserved port subcomponent is empty or not given, TCP port 80 (the reserved port
for WWW services) is the default. The origin determines who has the for WWW services) is the default. The origin determines who has the
right to respond authoritatively to requests that target the right to respond authoritatively to requests that target the
identified resource, as defined in Section 4.3.2. identified resource, as defined in Section 4.3.2.
skipping to change at line 1121 skipping to change at line 1114
reject it as invalid. reject it as invalid.
The hierarchical path component and optional query component identify The hierarchical path component and optional query component identify
the target resource within that origin server's namespace. the target resource within that origin server's namespace.
4.2.2. https URI Scheme 4.2.2. https URI Scheme
The "https" URI scheme is hereby defined for minting identifiers The "https" URI scheme is hereby defined for minting identifiers
within the hierarchical namespace governed by a potential origin within the hierarchical namespace governed by a potential origin
server listening for TCP connections on a given port and capable of server listening for TCP connections on a given port and capable of
establishing a TLS [TLS13] connection that has been secured for HTTP establishing a TLS ([TLS13]) connection that has been secured for
communication. In this context, _secured_ specifically means that HTTP communication. In this context, "secured" specifically means
the server has been authenticated as acting on behalf of the that the server has been authenticated as acting on behalf of the
identified authority and all HTTP communication with that server has identified authority and all HTTP communication with that server has
confidentiality and integrity protection that is acceptable to both confidentiality and integrity protection that is acceptable to both
client and server. client and server.
https-URI = "https" "://" authority path-abempty [ "?" query ] https-URI = "https" "://" authority path-abempty [ "?" query ]
The origin server for an "https" URI is identified by the authority The origin server for an "https" URI is identified by the authority
component, which includes a host identifier ([URI], Section 3.2.2) component, which includes a host identifier ([URI], Section 3.2.2)
and optional port number ([URI], Section 3.2.3). If the port and optional port number ([URI], Section 3.2.3). If the port
subcomponent is empty or not given, TCP port 443 (the reserved port subcomponent is empty or not given, TCP port 443 (the reserved port
skipping to change at line 1256 skipping to change at line 1249
Section 4.3.1 defines the concept of an origin as an aid to such Section 4.3.1 defines the concept of an origin as an aid to such
uses, and the subsequent subsections explain how to establish that a uses, and the subsequent subsections explain how to establish that a
peer has the authority to represent an origin. peer has the authority to represent an origin.
See Section 17.1 for security considerations related to establishing See Section 17.1 for security considerations related to establishing
authority. authority.
4.3.1. URI Origin 4.3.1. URI Origin
The _origin_ for a given URI is the triple of scheme, host, and port The "origin" for a given URI is the triple of scheme, host, and port
after normalizing the scheme and host to lowercase and normalizing after normalizing the scheme and host to lowercase and normalizing
the port to remove any leading zeros. If port is elided from the the port to remove any leading zeros. If port is elided from the
URI, the default port for that scheme is used. For example, the URI URI, the default port for that scheme is used. For example, the URI
https://Example.Com/happy.js https://Example.Com/happy.js
would have the origin would have the origin
{ "https", "example.com", "443" } { "https", "example.com", "443" }
which can also be described as the normalized URI prefix with port which can also be described as the normalized URI prefix with port
always present: always present:
https://example.com:443 https://example.com:443
Each origin defines its own namespace and controls how identifiers Each origin defines its own namespace and controls how identifiers
within that namespace are mapped to resources. In turn, how the within that namespace are mapped to resources. In turn, how the
origin responds to valid requests, consistently over time, determines origin responds to valid requests, consistently over time, determines
the semantics that users will associate with a URI, and the the semantics that users will associate with a URI, and the
usefulness of those semantics is what ultimately transforms these usefulness of those semantics is what ultimately transforms these
mechanisms into a "resource" for users to reference and access in the mechanisms into a resource for users to reference and access in the
future. future.
Two origins are distinct if they differ in scheme, host, or port. Two origins are distinct if they differ in scheme, host, or port.
Even when it can be verified that the same entity controls two Even when it can be verified that the same entity controls two
distinct origins, the two namespaces under those origins are distinct distinct origins, the two namespaces under those origins are distinct
unless explicitly aliased by a server authoritative for that origin. unless explicitly aliased by a server authoritative for that origin.
Origin is also used within HTML and related Web protocols, beyond the Origin is also used within HTML and related Web protocols, beyond the
scope of this document, as described in [RFC6454]. scope of this document, as described in [RFC6454].
skipping to change at line 1457 skipping to change at line 1450
not explicitly include the IP version and so relies on the length of not explicitly include the IP version and so relies on the length of
the address to distinguish versions; see Section 4.2.1.6 of the address to distinguish versions; see Section 4.2.1.6 of
[RFC5280]. [RFC5280].
A reference identity of type IP-ID matches if the address is A reference identity of type IP-ID matches if the address is
identical to an iPAddress value of the subjectAltName extension of identical to an iPAddress value of the subjectAltName extension of
the certificate. the certificate.
5. Fields 5. Fields
HTTP uses _fields_ to provide data in the form of extensible key/ HTTP uses "fields" to provide data in the form of extensible key/
value pairs with a registered key namespace. Fields are sent and value pairs with a registered key namespace. Fields are sent and
received within the header and trailer sections of messages received within the header and trailer sections of messages
(Section 6). (Section 6).
5.1. Field Names 5.1. Field Names
A field name labels the corresponding field value as having the A field name labels the corresponding field value as having the
semantics defined by that name. For example, the Date header field semantics defined by that name. For example, the Date header field
is defined in Section 6.6.1 as containing the origination timestamp is defined in Section 6.6.1 as containing the origination timestamp
for the message in which it appears. for the message in which it appears.
skipping to change at line 1497 skipping to change at line 1490
A proxy MUST forward unrecognized header fields unless the field name A proxy MUST forward unrecognized header fields unless the field name
is listed in the Connection header field (Section 7.6.1) or the proxy is listed in the Connection header field (Section 7.6.1) or the proxy
is specifically configured to block, or otherwise transform, such is specifically configured to block, or otherwise transform, such
fields. Other recipients SHOULD ignore unrecognized header and fields. Other recipients SHOULD ignore unrecognized header and
trailer fields. Adhering to these requirements allows HTTP's trailer fields. Adhering to these requirements allows HTTP's
functionality to be extended without updating or removing deployed functionality to be extended without updating or removing deployed
intermediaries. intermediaries.
5.2. Field Lines and Combined Field Value 5.2. Field Lines and Combined Field Value
Field sections are composed of any number of _field lines_, each with Field sections are composed of any number of "field lines", each with
a _field name_ (see Section 5.1) identifying the field, and a _field a "field name" (see Section 5.1) identifying the field, and a "field
line value_ that conveys data for that instance of the field. line value" that conveys data for that instance of the field.
When a field name is only present once in a section, the combined When a field name is only present once in a section, the combined
_field value_ for that field consists of the corresponding field line "field value" for that field consists of the corresponding field line
value. When a field name is repeated within a section, its combined value. When a field name is repeated within a section, its combined
field value consists of the list of corresponding field line values field value consists of the list of corresponding field line values
within that section, concatenated in order, with each field line within that section, concatenated in order, with each field line
value separated by a comma. value separated by a comma.
For example, this section: For example, this section:
Example-Field: Foo, Bar Example-Field: Foo, Bar
Example-Field: Baz Example-Field: Baz
skipping to change at line 1541 skipping to change at line 1534
This means that, aside from the well-known exception noted below, a This means that, aside from the well-known exception noted below, a
sender MUST NOT generate multiple field lines with the same name in a sender MUST NOT generate multiple field lines with the same name in a
message (whether in the headers or trailers) or append a field line message (whether in the headers or trailers) or append a field line
when a field line of the same name already exists in the message, when a field line of the same name already exists in the message,
unless that field's definition allows multiple field line values to unless that field's definition allows multiple field line values to
be recombined as a comma-separated list (i.e., at least one be recombined as a comma-separated list (i.e., at least one
alternative of the field's definition allows a comma-separated list, alternative of the field's definition allows a comma-separated list,
such as an ABNF rule of #(values) defined in Section 5.6.1). such as an ABNF rule of #(values) defined in Section 5.6.1).
| *Note:* In practice, the "Set-Cookie" header field [COOKIE] | *Note:* In practice, the "Set-Cookie" header field ([COOKIE])
| often appears in a response message across multiple field lines | often appears in a response message across multiple field lines
| and does not use the list syntax, violating the above | and does not use the list syntax, violating the above
| requirements on multiple field lines with the same field name. | requirements on multiple field lines with the same field name.
| Since it cannot be combined into a single field value, | Since it cannot be combined into a single field value,
| recipients ought to handle "Set-Cookie" as a special case while | recipients ought to handle "Set-Cookie" as a special case while
| processing fields. (See Appendix A.2.3 of [Kri2001] for | processing fields. (See Appendix A.2.3 of [Kri2001] for
| details.) | details.)
The order in which field lines with differing field names are The order in which field lines with differing field names are
received in a section is not significant. However, it is good received in a section is not significant. However, it is good
skipping to change at line 1586 skipping to change at line 1579
A client MAY discard or truncate received field lines that are larger A client MAY discard or truncate received field lines that are larger
than the client wishes to process if the field semantics are such than the client wishes to process if the field semantics are such
that the dropped value(s) can be safely ignored without changing the that the dropped value(s) can be safely ignored without changing the
message framing or response semantics. message framing or response semantics.
5.5. Field Values 5.5. Field Values
HTTP field values consist of a sequence of characters in a format HTTP field values consist of a sequence of characters in a format
defined by the field's grammar. Each field's grammar is usually defined by the field's grammar. Each field's grammar is usually
defined using ABNF [RFC5234]. defined using ABNF ([RFC5234]).
field-value = *field-content field-value = *field-content
field-content = field-vchar field-content = field-vchar
[ 1*( SP / HTAB / field-vchar ) field-vchar ] [ 1*( SP / HTAB / field-vchar ) field-vchar ]
field-vchar = VCHAR / obs-text field-vchar = VCHAR / obs-text
obs-text = %x80-FF obs-text = %x80-FF
A field value does not include leading or trailing whitespace. When A field value does not include leading or trailing whitespace. When
a specific version of HTTP allows such whitespace to appear in a a specific version of HTTP allows such whitespace to appear in a
message, a field parsing implementation MUST exclude such whitespace message, a field parsing implementation MUST exclude such whitespace
skipping to change at line 1621 skipping to change at line 1614
and interpret those characters; a recipient of CR, LF, or NUL within and interpret those characters; a recipient of CR, LF, or NUL within
a field value MUST either reject the message or replace each of those a field value MUST either reject the message or replace each of those
characters with SP before further processing or forwarding of that characters with SP before further processing or forwarding of that
message. Field values containing other CTL characters are also message. Field values containing other CTL characters are also
invalid; however, recipients MAY retain such characters for the sake invalid; however, recipients MAY retain such characters for the sake
of robustness when they appear within a safe context (e.g., an of robustness when they appear within a safe context (e.g., an
application-specific quoted string that will not be processed by any application-specific quoted string that will not be processed by any
downstream HTTP parser). downstream HTTP parser).
Fields that only anticipate a single member as the field value are Fields that only anticipate a single member as the field value are
referred to as _singleton fields_. referred to as "singleton fields".
Fields that allow multiple members as the field value are referred to Fields that allow multiple members as the field value are referred to
as _list-based fields_. The list operator extension of Section 5.6.1 as "list-based fields". The list operator extension of Section 5.6.1
is used as a common notation for defining field values that can is used as a common notation for defining field values that can
contain multiple members. contain multiple members.
Because commas (",") are used as the delimiter between members, they Because commas (",") are used as the delimiter between members, they
need to be treated with care if they are allowed as data within a need to be treated with care if they are allowed as data within a
member. This is true for both list-based and singleton fields, since member. This is true for both list-based and singleton fields, since
a singleton field might be erroneously sent with multiple members and a singleton field might be erroneously sent with multiple members and
detecting such errors improves interoperability. Fields that expect detecting such errors improves interoperability. Fields that expect
to contain a comma within a member, such as within an HTTP-date or to contain a comma within a member, such as within an HTTP-date or
URI-reference element, ought to be defined with delimiters around URI-reference element, ought to be defined with delimiters around
skipping to change at line 1869 skipping to change at line 1862
accept all three HTTP-date formats. When a sender generates a field accept all three HTTP-date formats. When a sender generates a field
that contains one or more timestamps defined as HTTP-date, the sender that contains one or more timestamps defined as HTTP-date, the sender
MUST generate those timestamps in the IMF-fixdate format. MUST generate those timestamps in the IMF-fixdate format.
An HTTP-date value represents time as an instance of Coordinated An HTTP-date value represents time as an instance of Coordinated
Universal Time (UTC). The first two formats indicate UTC by the Universal Time (UTC). The first two formats indicate UTC by the
three-letter abbreviation for Greenwich Mean Time, "GMT", a three-letter abbreviation for Greenwich Mean Time, "GMT", a
predecessor of the UTC name; values in the asctime format are assumed predecessor of the UTC name; values in the asctime format are assumed
to be in UTC. to be in UTC.
A _clock_ is an implementation capable of providing a reasonable A "clock" is an implementation capable of providing a reasonable
approximation of the current instant in UTC. A clock implementation approximation of the current instant in UTC. A clock implementation
ought to use NTP [RFC5905], or some similar protocol, to synchronize ought to use NTP ([RFC5905]), or some similar protocol, to
with UTC. synchronize with UTC.
Preferred format: Preferred format:
IMF-fixdate = day-name "," SP date1 SP time-of-day SP GMT IMF-fixdate = day-name "," SP date1 SP time-of-day SP GMT
; fixed length/zone/capitalization subset of the format ; fixed length/zone/capitalization subset of the format
; see Section 3.3 of [RFC5322] ; see Section 3.3 of [RFC5322]
day-name = %s"Mon" / %s"Tue" / %s"Wed" day-name = %s"Mon" / %s"Tue" / %s"Wed"
/ %s"Thu" / %s"Fri" / %s"Sat" / %s"Sun" / %s"Thu" / %s"Fri" / %s"Sat" / %s"Sun"
skipping to change at line 1937 skipping to change at line 1930
two-digit year, MUST interpret a timestamp that appears to be more two-digit year, MUST interpret a timestamp that appears to be more
than 50 years in the future as representing the most recent year in than 50 years in the future as representing the most recent year in
the past that had the same last two digits. the past that had the same last two digits.
Recipients of timestamp values are encouraged to be robust in parsing Recipients of timestamp values are encouraged to be robust in parsing
timestamps unless otherwise restricted by the field definition. For timestamps unless otherwise restricted by the field definition. For
example, messages are occasionally forwarded over HTTP from a non- example, messages are occasionally forwarded over HTTP from a non-
HTTP source that might generate any of the date and time HTTP source that might generate any of the date and time
specifications defined by the Internet Message Format. specifications defined by the Internet Message Format.
| *Note:* HTTP requirements for the date/timestamp format apply | *Note:* HTTP requirements for timestamp formats apply only to
| only to their usage within the protocol stream. | their usage within the protocol stream. Implementations are
| Implementations are not required to use these formats for user | not required to use these formats for user presentation,
| presentation, request logging, etc. | request logging, etc.
6. Message Abstraction 6. Message Abstraction
Each major version of HTTP defines its own syntax for communicating Each major version of HTTP defines its own syntax for communicating
messages. This section defines an abstract data type for HTTP messages. This section defines an abstract data type for HTTP
messages based on a generalization of those message characteristics, messages based on a generalization of those message characteristics,
common structure, and capacity for conveying semantics. This common structure, and capacity for conveying semantics. This
abstraction is used to define requirements on senders and recipients abstraction is used to define requirements on senders and recipients
that are independent of the HTTP version, such that a message in one that are independent of the HTTP version, such that a message in one
version can be relayed through other versions without changing its version can be relayed through other versions without changing its
meaning. meaning.
A _message_ consists of control data to describe and route the A "message" consists of control data to describe and route the
message, a headers lookup table of key/value pairs for extending that message, a headers lookup table of key/value pairs for extending that
control data and conveying additional information about the sender, control data and conveying additional information about the sender,
message, content, or context, a potentially unbounded stream of message, content, or context, a potentially unbounded stream of
content, and a trailers lookup table of key/value pairs for content, and a trailers lookup table of key/value pairs for
communicating information obtained while sending the content. communicating information obtained while sending the content.
Framing and control data is sent first, followed by a header section Framing and control data is sent first, followed by a header section
containing fields for the headers table. When a message includes containing fields for the headers table. When a message includes
content, the content is sent after the header section, potentially content, the content is sent after the header section, potentially
followed by a trailer section that might contain fields for the followed by a trailer section that might contain fields for the
skipping to change at line 1975 skipping to change at line 1968
Messages are expected to be processed as a stream, wherein the Messages are expected to be processed as a stream, wherein the
purpose of that stream and its continued processing is revealed while purpose of that stream and its continued processing is revealed while
being read. Hence, control data describes what the recipient needs being read. Hence, control data describes what the recipient needs
to know immediately, header fields describe what needs to be known to know immediately, header fields describe what needs to be known
before receiving content, the content (when present) presumably before receiving content, the content (when present) presumably
contains what the recipient wants or needs to fulfill the message contains what the recipient wants or needs to fulfill the message
semantics, and trailer fields provide optional metadata that was semantics, and trailer fields provide optional metadata that was
unknown prior to sending the content. unknown prior to sending the content.
Messages are intended to be _self-descriptive_: everything a Messages are intended to be "self-descriptive": everything a
recipient needs to know about the message can be determined by recipient needs to know about the message can be determined by
looking at the message itself, after decoding or reconstituting parts looking at the message itself, after decoding or reconstituting parts
that have been compressed or elided in transit, without requiring an that have been compressed or elided in transit, without requiring an
understanding of the sender's current application state (established understanding of the sender's current application state (established
via prior messages). However, a client MUST retain knowledge of the via prior messages). However, a client MUST retain knowledge of the
request when parsing, interpreting, or caching a corresponding request when parsing, interpreting, or caching a corresponding
response. For example, responses to the HEAD method look just like response. For example, responses to the HEAD method look just like
the beginning of a response to GET but cannot be parsed in the same the beginning of a response to GET but cannot be parsed in the same
manner. manner.
skipping to change at line 2008 skipping to change at line 2001
mechanism. mechanism.
HTTP/0.9 and early deployments of HTTP/1.0 used closure of the HTTP/0.9 and early deployments of HTTP/1.0 used closure of the
underlying connection to end a response. For backwards underlying connection to end a response. For backwards
compatibility, this implicit framing is also allowed in HTTP/1.1. compatibility, this implicit framing is also allowed in HTTP/1.1.
However, implicit framing can fail to distinguish an incomplete However, implicit framing can fail to distinguish an incomplete
response if the connection closes early. For that reason, almost all response if the connection closes early. For that reason, almost all
modern implementations use explicit framing in the form of length- modern implementations use explicit framing in the form of length-
delimited sequences of message data. delimited sequences of message data.
A message is considered _complete_ when all of the octets indicated A message is considered "complete" when all of the octets indicated
by its framing are available. Note that, when no explicit framing is by its framing are available. Note that, when no explicit framing is
used, a response message that is ended by the underlying connection's used, a response message that is ended by the underlying connection's
close is considered complete even though it might be close is considered complete even though it might be
indistinguishable from an incomplete response, unless a transport- indistinguishable from an incomplete response, unless a transport-
level error indicates that it is not complete. level error indicates that it is not complete.
6.2. Control Data 6.2. Control Data
Messages start with control data that describe its primary purpose. Messages start with control data that describe its primary purpose.
Request message control data includes a request method (Section 9), Request message control data includes a request method (Section 9),
request target (Section 7.1), and protocol version (Section 2.5). request target (Section 7.1), and protocol version (Section 2.5).
Response message control data includes a status code (Section 15), Response message control data includes a status code (Section 15),
optional reason phrase, and protocol version. optional reason phrase, and protocol version.
In HTTP/1.1 [HTTP/1.1] and earlier, control data is sent as the first In HTTP/1.1 ([HTTP/1.1]) and earlier, control data is sent as the
line of a message. In HTTP/2 [HTTP/2] and HTTP/3 [HTTP/3], control first line of a message. In HTTP/2 ([HTTP/2]) and HTTP/3 ([HTTP/3]),
data is sent as pseudo-header fields with a reserved name prefix control data is sent as pseudo-header fields with a reserved name
(e.g., ":authority"). prefix (e.g., ":authority").
Every HTTP message has a protocol version. Depending on the version Every HTTP message has a protocol version. Depending on the version
in use, it might be identified within the message explicitly or in use, it might be identified within the message explicitly or
inferred by the connection over which the message is received. inferred by the connection over which the message is received.
Recipients use that version information to determine limitations or Recipients use that version information to determine limitations or
potential for later communication with that sender. potential for later communication with that sender.
When a message is forwarded by an intermediary, the protocol version When a message is forwarded by an intermediary, the protocol version
is updated to reflect the version used by that intermediary. The Via is updated to reflect the version used by that intermediary. The Via
header field (Section 7.6.3) is used to communicate upstream protocol header field (Section 7.6.3) is used to communicate upstream protocol
skipping to change at line 2073 skipping to change at line 2066
minor version, when sent to a recipient that has not yet indicated minor version, when sent to a recipient that has not yet indicated
support for that higher version, is sufficiently backwards-compatible support for that higher version, is sufficiently backwards-compatible
to be safely processed by any implementation of the same major to be safely processed by any implementation of the same major
version. version.
6.3. Header Fields 6.3. Header Fields
Fields (Section 5) that are sent or received before the content are Fields (Section 5) that are sent or received before the content are
referred to as "header fields" (or just "headers", colloquially). referred to as "header fields" (or just "headers", colloquially).
The _header section_ of a message consists of a sequence of header The "header section" of a message consists of a sequence of header
field lines. Each header field might modify or extend message field lines. Each header field might modify or extend message
semantics, describe the sender, define the content, or provide semantics, describe the sender, define the content, or provide
additional context. additional context.
| *Note:* We refer to named fields specifically as a "header | *Note:* We refer to named fields specifically as a "header
| field" when they are only allowed to be sent in the header | field" when they are only allowed to be sent in the header
| section. | section.
6.4. Content 6.4. Content
HTTP messages often transfer a complete or partial representation as HTTP messages often transfer a complete or partial representation as
the message _content_: a stream of octets sent after the header the message "content": a stream of octets sent after the header
section, as delineated by the message framing. section, as delineated by the message framing.
This abstract definition of content reflects the data after it has This abstract definition of content reflects the data after it has
been extracted from the message framing. For example, an HTTP/1.1 been extracted from the message framing. For example, an HTTP/1.1
message body (Section 6 of [HTTP/1.1]) might consist of a stream of message body (Section 6 of [HTTP/1.1]) might consist of a stream of
data encoded with the chunked transfer coding -- a sequence of data data encoded with the chunked transfer coding -- a sequence of data
chunks, one zero-length chunk, and a trailer section -- whereas the chunks, one zero-length chunk, and a trailer section -- whereas the
content of that same message includes only the data stream after the content of that same message includes only the data stream after the
transfer coding has been decoded; it does not include the chunk transfer coding has been decoded; it does not include the chunk
lengths, chunked framing syntax, nor the trailer fields lengths, chunked framing syntax, nor the trailer fields
skipping to change at line 2208 skipping to change at line 2201
the sender asserts that the content is a representation of the the sender asserts that the content is a representation of the
resource identified by the Content-Location field value. resource identified by the Content-Location field value.
However, such an assertion cannot be trusted unless it can be However, such an assertion cannot be trusted unless it can be
verified by other means (not defined by this specification). verified by other means (not defined by this specification).
7. Otherwise, the content is unidentified by HTTP, but a more 7. Otherwise, the content is unidentified by HTTP, but a more
specific identifier might be supplied within the content itself. specific identifier might be supplied within the content itself.
6.5. Trailer Fields 6.5. Trailer Fields
Fields (Section 5) that are located within a _trailer section_ are Fields (Section 5) that are located within a "trailer section" are
referred to as "trailer fields" (or just "trailers", colloquially). referred to as "trailer fields" (or just "trailers", colloquially).
Trailer fields can be useful for supplying message integrity checks, Trailer fields can be useful for supplying message integrity checks,
digital signatures, delivery metrics, or post-processing status digital signatures, delivery metrics, or post-processing status
information. information.
Trailer fields ought to be processed and stored separately from the Trailer fields ought to be processed and stored separately from the
fields in the header section to avoid contradicting message semantics fields in the header section to avoid contradicting message semantics
known at the time the header section was complete. The presence or known at the time the header section was complete. The presence or
absence of certain header fields might impact choices made for the absence of certain header fields might impact choices made for the
routing or processing of the message as a whole before the trailers routing or processing of the message as a whole before the trailers
skipping to change at line 2376 skipping to change at line 2369
7.1. Determining the Target Resource 7.1. Determining the Target Resource
Although HTTP is used in a wide variety of applications, most clients Although HTTP is used in a wide variety of applications, most clients
rely on the same resource identification mechanism and configuration rely on the same resource identification mechanism and configuration
techniques as general-purpose Web browsers. Even when communication techniques as general-purpose Web browsers. Even when communication
options are hard-coded in a client's configuration, we can think of options are hard-coded in a client's configuration, we can think of
their combined effect as a URI reference (Section 4.1). their combined effect as a URI reference (Section 4.1).
A URI reference is resolved to its absolute form in order to obtain A URI reference is resolved to its absolute form in order to obtain
the _target URI_. The target URI excludes the reference's fragment the "target URI". The target URI excludes the reference's fragment
component, if any, since fragment identifiers are reserved for component, if any, since fragment identifiers are reserved for
client-side processing ([URI], Section 3.5). client-side processing ([URI], Section 3.5).
To perform an action on a _target resource_, the client sends a To perform an action on a "target resource", the client sends a
request message containing enough components of its parsed target URI request message containing enough components of its parsed target URI
to enable recipients to identify that same resource. For historical to enable recipients to identify that same resource. For historical
reasons, the parsed target URI components, collectively referred to reasons, the parsed target URI components, collectively referred to
as the _request target_, are sent within the message control data and as the "request target", are sent within the message control data and
the Host header field (Section 7.2). the Host header field (Section 7.2).
There are two unusual cases for which the request target components There are two unusual cases for which the request target components
are in a method-specific form: are in a method-specific form:
* For CONNECT (Section 9.3.6), the request target is the host name * For CONNECT (Section 9.3.6), the request target is the host name
and port number of the tunnel destination, separated by a colon. and port number of the tunnel destination, separated by a colon.
* For OPTIONS (Section 9.3.7), the request target can be a single * For OPTIONS (Section 9.3.7), the request target can be a single
asterisk ("*"). asterisk ("*").
skipping to change at line 2407 skipping to change at line 2400
NOT be used with other methods. NOT be used with other methods.
Upon receipt of a client's request, a server reconstructs the target Upon receipt of a client's request, a server reconstructs the target
URI from the received components in accordance with their local URI from the received components in accordance with their local
configuration and incoming connection context. This reconstruction configuration and incoming connection context. This reconstruction
is specific to each major protocol version. For example, Section 3.3 is specific to each major protocol version. For example, Section 3.3
of [HTTP/1.1] defines how a server determines the target URI of an of [HTTP/1.1] defines how a server determines the target URI of an
HTTP/1.1 request. HTTP/1.1 request.
| *Note:* Previous specifications defined the recomposed target | *Note:* Previous specifications defined the recomposed target
| URI as a distinct concept, the _effective request URI_. | URI as a distinct concept, the "effective request URI".
7.2. Host and :authority 7.2. Host and :authority
The "Host" header field in a request provides the host and port The "Host" header field in a request provides the host and port
information from the target URI, enabling the origin server to information from the target URI, enabling the origin server to
distinguish among resources while servicing requests for multiple distinguish among resources while servicing requests for multiple
host names. host names.
In HTTP/2 [HTTP/2] and HTTP/3 [HTTP/3], the Host header field is, in In HTTP/2 [HTTP/2] and HTTP/3 [HTTP/3], the Host header field is, in
some cases, supplanted by the ":authority" pseudo-header field of a some cases, supplanted by the ":authority" pseudo-header field of a
skipping to change at line 2575 skipping to change at line 2568
or forwarding downstream. However, senders and recipients cannot or forwarding downstream. However, senders and recipients cannot
rely on incremental delivery of partial messages, since some rely on incremental delivery of partial messages, since some
implementations will buffer or delay message forwarding for the sake implementations will buffer or delay message forwarding for the sake
of network efficiency, security checks, or content transformations. of network efficiency, security checks, or content transformations.
7.6.1. Connection 7.6.1. Connection
The "Connection" header field allows the sender to list desired The "Connection" header field allows the sender to list desired
control options for the current connection. control options for the current connection.
Connection = #connection-option
connection-option = token
Connection options are case-insensitive.
When a field aside from Connection is used to supply control When a field aside from Connection is used to supply control
information for or about the current connection, the sender MUST list information for or about the current connection, the sender MUST list
the corresponding field name within the Connection header field. the corresponding field name within the Connection header field.
Note that some versions of HTTP prohibit the use of fields for such Note that some versions of HTTP prohibit the use of fields for such
information, and therefore do not allow the Connection field. information, and therefore do not allow the Connection field.
Intermediaries MUST parse a received Connection header field before a Intermediaries MUST parse a received Connection header field before a
message is forwarded and, for each connection-option in this field, message is forwarded and, for each connection-option in this field,
remove any header or trailer field(s) from the message with the same remove any header or trailer field(s) from the message with the same
name as the connection-option, and then remove the Connection header name as the connection-option, and then remove the Connection header
field itself (or replace it with the intermediary's own connection field itself (or replace it with the intermediary's own control
options for the forwarded message). options for the forwarded message).
Hence, the Connection header field provides a declarative way of Hence, the Connection header field provides a declarative way of
distinguishing fields that are only intended for the immediate distinguishing fields that are only intended for the immediate
recipient ("hop-by-hop") from those fields that are intended for all recipient ("hop-by-hop") from those fields that are intended for all
recipients on the chain ("end-to-end"), enabling the message to be recipients on the chain ("end-to-end"), enabling the message to be
self-descriptive and allowing future connection-specific extensions self-descriptive and allowing future connection-specific extensions
to be deployed without fear that they will be blindly forwarded by to be deployed without fear that they will be blindly forwarded by
older intermediaries. older intermediaries.
Furthermore, intermediaries SHOULD remove or replace field(s) whose Furthermore, intermediaries SHOULD remove or replace fields that are
semantics are known to require removal before forwarding, whether or known to require removal before forwarding, whether or not they
not they appear as a connection option, after applying those fields' appear as a connection-option, after applying those fields'
semantics. This includes but is not limited to: semantics. This includes but is not limited to:
* Proxy-Connection (Appendix C.2.2 of [HTTP/1.1]) * Proxy-Connection (Appendix C.2.2 of [HTTP/1.1])
* Keep-Alive (Section 19.7.1 of [RFC2068]) * Keep-Alive (Section 19.7.1 of [RFC2068])
* TE (Section 10.1.4) * TE (Section 10.1.4)
* Transfer-Encoding (Section 6.1 of [HTTP/1.1]) * Transfer-Encoding (Section 6.1 of [HTTP/1.1])
* Upgrade (Section 7.8) * Upgrade (Section 7.8)
The Connection header field's value has the following grammar:
Connection = #connection-option
connection-option = token
Connection options are case-insensitive.
A sender MUST NOT send a connection option corresponding to a field A sender MUST NOT send a connection option corresponding to a field
that is intended for all recipients of the content. For example, that is intended for all recipients of the content. For example,
Cache-Control is never appropriate as a connection option Cache-Control is never appropriate as a connection option
(Section 5.2 of [CACHING]). (Section 5.2 of [CACHING]).
Connection options do not always correspond to a field present in the Connection options do not always correspond to a field present in the
message, since a connection-specific field might not be needed if message, since a connection-specific field might not be needed if
there are no parameters associated with a connection option. In there are no parameters associated with a connection option. In
contrast, a connection-specific field received without a contrast, a connection-specific field received without a
corresponding connection option usually indicates that the field has corresponding connection option usually indicates that the field has
skipping to change at line 2755 skipping to change at line 2746
Some intermediaries include features for transforming messages and Some intermediaries include features for transforming messages and
their content. A proxy might, for example, convert between image their content. A proxy might, for example, convert between image
formats in order to save cache space or to reduce the amount of formats in order to save cache space or to reduce the amount of
traffic on a slow link. However, operational problems might occur traffic on a slow link. However, operational problems might occur
when these transformations are applied to content intended for when these transformations are applied to content intended for
critical applications, such as medical imaging or scientific data critical applications, such as medical imaging or scientific data
analysis, particularly when integrity checks or digital signatures analysis, particularly when integrity checks or digital signatures
are used to ensure that the content received is identical to the are used to ensure that the content received is identical to the
original. original.
An HTTP-to-HTTP proxy is called a _transforming proxy_ if it is An HTTP-to-HTTP proxy is called a "transforming proxy" if it is
designed or configured to modify messages in a semantically designed or configured to modify messages in a semantically
meaningful way (i.e., modifications, beyond those required by normal meaningful way (i.e., modifications, beyond those required by normal
HTTP processing, that change the message in a way that would be HTTP processing, that change the message in a way that would be
significant to the original sender or potentially significant to significant to the original sender or potentially significant to
downstream recipients). For example, a transforming proxy might be downstream recipients). For example, a transforming proxy might be
acting as a shared annotation server (modifying responses to include acting as a shared annotation server (modifying responses to include
references to a local annotation database), a malware filter, a references to a local annotation database), a malware filter, a
format transcoder, or a privacy filter. Such transformations are format transcoder, or a privacy filter. Such transformations are
presumed to be desired by whichever client (or client organization) presumed to be desired by whichever client (or client organization)
chose the proxy. chose the proxy.
skipping to change at line 2779 skipping to change at line 2770
received when forwarding the request. A proxy MUST NOT change the received when forwarding the request. A proxy MUST NOT change the
host name if the target URI contains a fully qualified domain name. host name if the target URI contains a fully qualified domain name.
A proxy MUST NOT modify the "absolute-path" and "query" parts of the A proxy MUST NOT modify the "absolute-path" and "query" parts of the
received target URI when forwarding it to the next inbound server received target URI when forwarding it to the next inbound server
except as required by that forwarding protocol. For example, a proxy except as required by that forwarding protocol. For example, a proxy
forwarding a request to an origin server via HTTP/1.1 will replace an forwarding a request to an origin server via HTTP/1.1 will replace an
empty path with "/" (Section 3.2.1 of [HTTP/1.1]) or "*" empty path with "/" (Section 3.2.1 of [HTTP/1.1]) or "*"
(Section 3.2.4 of [HTTP/1.1]), depending on the request method. (Section 3.2.4 of [HTTP/1.1]), depending on the request method.
A proxy MUST NOT transform the content (Section 6.4) of a message A proxy MUST NOT transform the content (Section 6.4) of a response
that contains a no-transform Cache-Control response directive message that contains a no-transform cache directive (Section 5.2.2.6
(Section 5.2 of [CACHING]). Note that this does not include changes of [CACHING]). Note that this does not apply to message
to the message body that do not affect the content, such as transfer transformations that do not change the content, such as the addition
codings (Section 7 of [HTTP/1.1]). or removal of transfer codings (Section 7 of [HTTP/1.1]).
A proxy MAY transform the content of a message that does not contain A proxy MAY transform the content of a message that does not contain
a no-transform Cache-Control directive. A proxy that transforms the a no-transform cache directive. A proxy that transforms the content
content of a 200 (OK) response can inform downstream recipients that of a 200 (OK) response can inform downstream recipients that a
a transformation has been applied by changing the response status transformation has been applied by changing the response status code
code to 203 (Non-Authoritative Information) (Section 15.3.4). to 203 (Non-Authoritative Information) (Section 15.3.4).
A proxy SHOULD NOT modify header fields that provide information A proxy SHOULD NOT modify header fields that provide information
about the endpoints of the communication chain, the resource state, about the endpoints of the communication chain, the resource state,
or the selected representation (other than the content) unless the or the selected representation (other than the content) unless the
field's definition specifically allows such modification or the field's definition specifically allows such modification or the
modification is deemed necessary for privacy or security. modification is deemed necessary for privacy or security.
7.8. Upgrade 7.8. Upgrade
The "Upgrade" header field is intended to provide a simple mechanism The "Upgrade" header field is intended to provide a simple mechanism
skipping to change at line 3007 skipping to change at line 2998
text/html;charset=utf-8 text/html;charset=utf-8
Text/HTML;Charset="utf-8" Text/HTML;Charset="utf-8"
text/html; charset="utf-8" text/html; charset="utf-8"
text/html;charset=UTF-8 text/html;charset=UTF-8
Media types ought to be registered with IANA according to the Media types ought to be registered with IANA according to the
procedures defined in [BCP13]. procedures defined in [BCP13].
8.3.2. Charset 8.3.2. Charset
HTTP uses _charset_ names to indicate or negotiate the character HTTP uses "charset" names to indicate or negotiate the character
encoding scheme ([RFC6365], Section 1.3) of a textual representation. encoding scheme ([RFC6365], Section 2) of a textual representation.
In the fields defined by this document, charset names appear either In the fields defined by this document, charset names appear either
in parameters (Content-Type), or, for Accept-Encoding, in the form of in parameters (Content-Type), or, for Accept-Encoding, in the form of
a plain token. In both cases, charset names are matched case- a plain token. In both cases, charset names are matched case-
insensitively. insensitively.
Charset names ought to be registered in the IANA "Character Sets" Charset names ought to be registered in the IANA "Character Sets"
registry (<https://www.iana.org/assignments/character-sets>) registry (<https://www.iana.org/assignments/character-sets>)
according to the procedures defined in Section 2 of [RFC2978]. according to the procedures defined in Section 2 of [RFC2978].
| *Note:* In theory, charset names are defined by the "mime- | *Note:* In theory, charset names are defined by the "mime-
skipping to change at line 3209 skipping to change at line 3200
8.6. Content-Length 8.6. Content-Length
The "Content-Length" header field indicates the associated The "Content-Length" header field indicates the associated
representation's data length as a decimal non-negative integer number representation's data length as a decimal non-negative integer number
of octets. When transferring a representation as content, Content- of octets. When transferring a representation as content, Content-
Length refers specifically to the amount of data enclosed so that it Length refers specifically to the amount of data enclosed so that it
can be used to delimit framing (e.g., Section 6.2 of [HTTP/1.1]). In can be used to delimit framing (e.g., Section 6.2 of [HTTP/1.1]). In
other cases, Content-Length indicates the selected representation's other cases, Content-Length indicates the selected representation's
current length, which can be used by recipients to estimate transfer current length, which can be used by recipients to estimate transfer
time or to compare to previously stored representations. time or to compare with previously stored representations.
Content-Length = 1*DIGIT Content-Length = 1*DIGIT
An example is An example is
Content-Length: 3495 Content-Length: 3495
A user agent SHOULD send Content-Length in a request when the method A user agent SHOULD send Content-Length in a request when the method
defines a meaning for enclosed content and it is not sending defines a meaning for enclosed content and it is not sending
Transfer-Encoding. For example, a user agent normally sends Content- Transfer-Encoding. For example, a user agent normally sends Content-
skipping to change at line 3363 skipping to change at line 3354
and the origin server accepts that PUT (without redirection), then and the origin server accepts that PUT (without redirection), then
the new state of that resource is expected to be consistent with the the new state of that resource is expected to be consistent with the
one representation supplied in that PUT; the Content-Location cannot one representation supplied in that PUT; the Content-Location cannot
be used as a form of reverse content selection identifier to update be used as a form of reverse content selection identifier to update
only one of the negotiated representations. If the user agent had only one of the negotiated representations. If the user agent had
wanted the latter semantics, it would have applied the PUT directly wanted the latter semantics, it would have applied the PUT directly
to the Content-Location URI. to the Content-Location URI.
8.8. Validator Fields 8.8. Validator Fields
Resource metadata is referred to as a _validator_ if it can be used Resource metadata is referred to as a "validator" if it can be used
within a precondition (Section 13.1) to make a conditional request within a precondition (Section 13.1) to make a conditional request
(Section 13). Validator fields convey a current validator for the (Section 13). Validator fields convey a current validator for the
selected representation (Section 3.2). selected representation (Section 3.2).
In responses to safe requests, validator fields describe the selected In responses to safe requests, validator fields describe the selected
representation chosen by the origin server while handling the representation chosen by the origin server while handling the
response. Note that, depending on the method and status code response. Note that, depending on the method and status code
semantics, the selected representation for a given response is not semantics, the selected representation for a given response is not
necessarily the same as the representation enclosed as response necessarily the same as the representation enclosed as response
content. content.
skipping to change at line 3402 skipping to change at line 3393
8.8.1. Weak versus Strong 8.8.1. Weak versus Strong
Validators come in two flavors: strong or weak. Weak validators are Validators come in two flavors: strong or weak. Weak validators are
easy to generate but are far less useful for comparisons. Strong easy to generate but are far less useful for comparisons. Strong
validators are ideal for comparisons but can be very difficult (and validators are ideal for comparisons but can be very difficult (and
occasionally impossible) to generate efficiently. Rather than impose occasionally impossible) to generate efficiently. Rather than impose
that all forms of resource adhere to the same strength of validator, that all forms of resource adhere to the same strength of validator,
HTTP exposes the type of validator in use and imposes restrictions on HTTP exposes the type of validator in use and imposes restrictions on
when weak validators can be used as preconditions. when weak validators can be used as preconditions.
A _strong validator_ is representation metadata that changes value A "strong validator" is representation metadata that changes value
whenever a change occurs to the representation data that would be whenever a change occurs to the representation data that would be
observable in the content of a 200 (OK) response to GET. observable in the content of a 200 (OK) response to GET.
A strong validator might change for reasons other than a change to A strong validator might change for reasons other than a change to
the representation data, such as when a semantically significant part the representation data, such as when a semantically significant part
of the representation metadata is changed (e.g., Content-Type), but of the representation metadata is changed (e.g., Content-Type), but
it is in the best interests of the origin server to only change the it is in the best interests of the origin server to only change the
value when it is necessary to invalidate the stored responses held by value when it is necessary to invalidate the stored responses held by
remote caches and authoring tools. remote caches and authoring tools.
skipping to change at line 3437 skipping to change at line 3428
accessible to GET. A collision-resistant hash function applied to accessible to GET. A collision-resistant hash function applied to
the representation data is also sufficient if the data is available the representation data is also sufficient if the data is available
prior to the response header fields being sent and the digest does prior to the response header fields being sent and the digest does
not need to be recalculated every time a validation request is not need to be recalculated every time a validation request is
received. However, if a resource has distinct representations that received. However, if a resource has distinct representations that
differ only in their metadata, such as might occur with content differ only in their metadata, such as might occur with content
negotiation over media types that happen to share the same data negotiation over media types that happen to share the same data
format, then the origin server needs to incorporate additional format, then the origin server needs to incorporate additional
information in the validator to distinguish those representations. information in the validator to distinguish those representations.
In contrast, a _weak validator_ is representation metadata that might In contrast, a "weak validator" is representation metadata that might
not change for every change to the representation data. This not change for every change to the representation data. This
weakness might be due to limitations in how the value is calculated weakness might be due to limitations in how the value is calculated
(e.g., clock resolution), an inability to ensure uniqueness for all (e.g., clock resolution), an inability to ensure uniqueness for all
possible representations of the resource, or a desire of the resource possible representations of the resource, or a desire of the resource
owner to group representations by some self-determined set of owner to group representations by some self-determined set of
equivalency rather than unique sequences of data. equivalency rather than unique sequences of data.
An origin server SHOULD change a weak entity-tag whenever it An origin server SHOULD change a weak entity-tag whenever it
considers prior representations to be unacceptable as a substitute considers prior representations to be unacceptable as a substitute
for the current representation. In other words, a weak entity-tag for the current representation. In other words, a weak entity-tag
skipping to change at line 3497 skipping to change at line 3488
An example of its use is An example of its use is
Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
8.8.2.1. Generation 8.8.2.1. Generation
An origin server SHOULD send Last-Modified for any selected An origin server SHOULD send Last-Modified for any selected
representation for which a last modification date can be reasonably representation for which a last modification date can be reasonably
and consistently determined, since its use in conditional requests and consistently determined, since its use in conditional requests
and evaluating cache freshness [CACHING] can substantially reduce and evaluating cache freshness ([CACHING]) can substantially reduce
unnecessary transfers and significantly improve service availability unnecessary transfers and significantly improve service availability
and scalability. and scalability.
A representation is typically the sum of many parts behind the A representation is typically the sum of many parts behind the
resource interface. The last-modified time would usually be the most resource interface. The last-modified time would usually be the most
recent time that any of those parts were changed. How that value is recent time that any of those parts were changed. How that value is
determined for any given resource is an implementation detail beyond determined for any given resource is an implementation detail beyond
the scope of this specification. the scope of this specification.
An origin server SHOULD obtain the Last-Modified value of the An origin server SHOULD obtain the Last-Modified value of the
skipping to change at line 3638 skipping to change at line 3629
applied to all changes might use an internal revision number, perhaps applied to all changes might use an internal revision number, perhaps
combined with a variance identifier for content negotiation, to combined with a variance identifier for content negotiation, to
accurately differentiate between representations. Other accurately differentiate between representations. Other
implementations might use a collision-resistant hash of implementations might use a collision-resistant hash of
representation content, a combination of various file attributes, or representation content, a combination of various file attributes, or
a modification timestamp that has sub-second resolution. a modification timestamp that has sub-second resolution.
An origin server SHOULD send an ETag for any selected representation An origin server SHOULD send an ETag for any selected representation
for which detection of changes can be reasonably and consistently for which detection of changes can be reasonably and consistently
determined, since the entity-tag's use in conditional requests and determined, since the entity-tag's use in conditional requests and
evaluating cache freshness [CACHING] can substantially reduce evaluating cache freshness ([CACHING]) can substantially reduce
unnecessary transfers and significantly improve service availability, unnecessary transfers and significantly improve service availability,
scalability, and reliability. scalability, and reliability.
8.8.3.2. Comparison 8.8.3.2. Comparison
There are two entity-tag comparison functions, depending on whether There are two entity-tag comparison functions, depending on whether
or not the comparison context allows the use of weak validators: or not the comparison context allows the use of weak validators:
_Strong comparison_: two entity-tags are equivalent if both are not "Strong comparison": two entity-tags are equivalent if both are not
weak and their opaque-tags match character-by-character. weak and their opaque-tags match character-by-character.
_Weak comparison_: two entity-tags are equivalent if their opaque- "Weak comparison": two entity-tags are equivalent if their opaque-
tags match character-by-character, regardless of either or both tags match character-by-character, regardless of either or both
being tagged as "weak". being tagged as "weak".
The example below shows the results for a set of entity-tag pairs and The example below shows the results for a set of entity-tag pairs and
both the weak and strong comparison function results: both the weak and strong comparison function results:
+========+========+===================+=================+ +========+========+===================+=================+
| ETag 1 | ETag 2 | Strong Comparison | Weak Comparison | | ETag 1 | ETag 2 | Strong Comparison | Weak Comparison |
+========+========+===================+=================+ +========+========+===================+=================+
| W/"1" | W/"1" | no match | match | | W/"1" | W/"1" | no match | match |
skipping to change at line 3813 skipping to change at line 3804
Additional methods, outside the scope of this specification, have Additional methods, outside the scope of this specification, have
been specified for use in HTTP. All such methods ought to be been specified for use in HTTP. All such methods ought to be
registered within the "Hypertext Transfer Protocol (HTTP) Method registered within the "Hypertext Transfer Protocol (HTTP) Method
Registry", as described in Section 16.1. Registry", as described in Section 16.1.
9.2. Common Method Properties 9.2. Common Method Properties
9.2.1. Safe Methods 9.2.1. Safe Methods
Request methods are considered _safe_ if their defined semantics are Request methods are considered "safe" if their defined semantics are
essentially read-only; i.e., the client does not request, and does essentially read-only; i.e., the client does not request, and does
not expect, any state change on the origin server as a result of not expect, any state change on the origin server as a result of
applying a safe method to a target resource. Likewise, reasonable applying a safe method to a target resource. Likewise, reasonable
use of a safe method is not expected to cause any harm, loss of use of a safe method is not expected to cause any harm, loss of
property, or unusual burden on the origin server. property, or unusual burden on the origin server.
This definition of safe methods does not prevent an implementation This definition of safe methods does not prevent an implementation
from including behavior that is potentially harmful, that is not from including behavior that is potentially harmful, that is not
entirely read-only, or that causes side effects while invoking a safe entirely read-only, or that causes side effects while invoking a safe
method. What is important, however, is that the client did not method. What is important, however, is that the client did not
skipping to change at line 3861 skipping to change at line 3852
parameters, such as "page?do=delete". If the purpose of such a parameters, such as "page?do=delete". If the purpose of such a
resource is to perform an unsafe action, then the resource owner MUST resource is to perform an unsafe action, then the resource owner MUST
disable or disallow that action when it is accessed using a safe disable or disallow that action when it is accessed using a safe
request method. Failure to do so will result in unfortunate side request method. Failure to do so will result in unfortunate side
effects when automated processes perform a GET on every URI reference effects when automated processes perform a GET on every URI reference
for the sake of link maintenance, pre-fetching, building a search for the sake of link maintenance, pre-fetching, building a search
index, etc. index, etc.
9.2.2. Idempotent Methods 9.2.2. Idempotent Methods
A request method is considered _idempotent_ if the intended effect on A request method is considered "idempotent" if the intended effect on
the server of multiple identical requests with that method is the the server of multiple identical requests with that method is the
same as the effect for a single such request. Of the request methods same as the effect for a single such request. Of the request methods
defined by this specification, PUT, DELETE, and safe request methods defined by this specification, PUT, DELETE, and safe request methods
are idempotent. are idempotent.
Like the definition of safe, the idempotent property only applies to Like the definition of safe, the idempotent property only applies to
what has been requested by the user; a server is free to log each what has been requested by the user; a server is free to log each
request separately, retain a revision control history, or implement request separately, retain a revision control history, or implement
other non-idempotent side effects for each idempotent request. other non-idempotent side effects for each idempotent request.
skipping to change at line 4433 skipping to change at line 4424
The Expect field value is case-insensitive. The Expect field value is case-insensitive.
The only expectation defined by this specification is "100-continue" The only expectation defined by this specification is "100-continue"
(with no defined parameters). (with no defined parameters).
A server that receives an Expect field value containing a member A server that receives an Expect field value containing a member
other than 100-continue MAY respond with a 417 (Expectation Failed) other than 100-continue MAY respond with a 417 (Expectation Failed)
status code to indicate that the unexpected expectation cannot be status code to indicate that the unexpected expectation cannot be
met. met.
A _100-continue_ expectation informs recipients that the client is A "100-continue" expectation informs recipients that the client is
about to send (presumably large) content in this request and wishes about to send (presumably large) content in this request and wishes
to receive a 100 (Continue) interim response if the method, target to receive a 100 (Continue) interim response if the method, target
URI, and header fields are not sufficient to cause an immediate URI, and header fields are not sufficient to cause an immediate
success, redirect, or error response. This allows the client to wait success, redirect, or error response. This allows the client to wait
for an indication that it is worthwhile to send the content before for an indication that it is worthwhile to send the content before
actually doing so, which can improve efficiency when the data is huge actually doing so, which can improve efficiency when the data is huge
or when the client anticipates that an error is likely (e.g., when or when the client anticipates that an error is likely (e.g., when
sending a state-changing method, for the first time, without sending a state-changing method, for the first time, without
previously verified authentication credentials). previously verified authentication credentials).
skipping to change at line 4532 skipping to change at line 4523
human user who controls the requesting user agent. The address ought human user who controls the requesting user agent. The address ought
to be machine-usable, as defined by "mailbox" in Section 3.4 of to be machine-usable, as defined by "mailbox" in Section 3.4 of
[RFC5322]: [RFC5322]:
From = mailbox From = mailbox
mailbox = <mailbox, see [RFC5322], Section 3.4> mailbox = <mailbox, see [RFC5322], Section 3.4>
An example is: An example is:
From: webmaster@example.org From: spider-admin@example.org
The From header field is rarely sent by non-robotic user agents. A The From header field is rarely sent by non-robotic user agents. A
user agent SHOULD NOT send a From header field without explicit user agent SHOULD NOT send a From header field without explicit
configuration by the user, since that might conflict with the user's configuration by the user, since that might conflict with the user's
privacy interests or their site's security policy. privacy interests or their site's security policy.
A robotic user agent SHOULD send a valid From header field so that A robotic user agent SHOULD send a valid From header field so that
the person responsible for running the robot can be contacted if the person responsible for running the robot can be contacted if
problems occur on servers, such as if the robot is sending excessive, problems occur on servers, such as if the robot is sending excessive,
unwanted, or invalid requests. unwanted, or invalid requests.
skipping to change at line 4874 skipping to change at line 4865
11.2. Authentication Parameters 11.2. Authentication Parameters
The authentication scheme is followed by additional information The authentication scheme is followed by additional information
necessary for achieving authentication via that scheme as either a necessary for achieving authentication via that scheme as either a
comma-separated list of parameters or a single sequence of characters comma-separated list of parameters or a single sequence of characters
capable of holding base64-encoded information. capable of holding base64-encoded information.
token68 = 1*( ALPHA / DIGIT / token68 = 1*( ALPHA / DIGIT /
"-" / "." / "_" / "~" / "+" / "/" ) *"=" "-" / "." / "_" / "~" / "+" / "/" ) *"="
The token68 syntax allows the 66 unreserved URI characters [URI], The token68 syntax allows the 66 unreserved URI characters ([URI]),
plus a few others, so that it can hold a base64, base64url (URL and plus a few others, so that it can hold a base64, base64url (URL and
filename safe alphabet), base32, or base16 (hex) encoding, with or filename safe alphabet), base32, or base16 (hex) encoding, with or
without padding, but excluding whitespace [RFC4648]. without padding, but excluding whitespace ([RFC4648]).
Authentication parameters are name=value pairs, where the name token Authentication parameters are name=value pairs, where the name token
is matched case-insensitively and each parameter name MUST only occur is matched case-insensitively and each parameter name MUST only occur
once per challenge. once per challenge.
auth-param = token BWS "=" BWS ( token / quoted-string ) auth-param = token BWS "=" BWS ( token / quoted-string )
Parameter values can be expressed either as "token" or as "quoted- Parameter values can be expressed either as "token" or as "quoted-
string" (Section 5.6). Authentication scheme definitions need to string" (Section 5.6). Authentication scheme definitions need to
accept both notations, both for senders and recipients, to allow accept both notations, both for senders and recipients, to allow
skipping to change at line 4970 skipping to change at line 4961
encapsulation, and with additional header fields specifying encapsulation, and with additional header fields specifying
authentication information. However, such additional mechanisms are authentication information. However, such additional mechanisms are
not defined by this specification. not defined by this specification.
Note that various custom mechanisms for user authentication use the Note that various custom mechanisms for user authentication use the
Set-Cookie and Cookie header fields, defined in [COOKIE], for passing Set-Cookie and Cookie header fields, defined in [COOKIE], for passing
tokens related to authentication. tokens related to authentication.
11.5. Establishing a Protection Space (Realm) 11.5. Establishing a Protection Space (Realm)
The _realm_ authentication parameter is reserved for use by The "realm" authentication parameter is reserved for use by
authentication schemes that wish to indicate a scope of protection. authentication schemes that wish to indicate a scope of protection.
A _protection space_ is defined by the origin (see Section 4.3.1) of A "protection space" is defined by the origin (see Section 4.3.1) of
the server being accessed, in combination with the realm value if the server being accessed, in combination with the realm value if
present. These realms allow the protected resources on a server to present. These realms allow the protected resources on a server to
be partitioned into a set of protection spaces, each with its own be partitioned into a set of protection spaces, each with its own
authentication scheme and/or authorization database. The realm value authentication scheme and/or authorization database. The realm value
is a string, generally assigned by the origin server, that can have is a string, generally assigned by the origin server, that can have
additional semantics specific to the authentication scheme. Note additional semantics specific to the authentication scheme. Note
that a response can have multiple challenges with the same auth- that a response can have multiple challenges with the same auth-
scheme but with different realms. scheme but with different realms.
The protection space determines the domain over which credentials can The protection space determines the domain over which credentials can
skipping to change at line 5209 skipping to change at line 5200
The consistency with which an origin server responds to requests, The consistency with which an origin server responds to requests,
over time and over the varying dimensions of content negotiation, and over time and over the varying dimensions of content negotiation, and
thus the "sameness" of a resource's observed representations over thus the "sameness" of a resource's observed representations over
time, is determined entirely by whatever entity or algorithm selects time, is determined entirely by whatever entity or algorithm selects
or generates those responses. or generates those responses.
12.1. Proactive Negotiation 12.1. Proactive Negotiation
When content negotiation preferences are sent by the user agent in a When content negotiation preferences are sent by the user agent in a
request to encourage an algorithm located at the server to select the request to encourage an algorithm located at the server to select the
preferred representation, it is called _proactive negotiation_ preferred representation, it is called "proactive negotiation"
(a.k.a., _server-driven negotiation_). Selection is based on the (a.k.a., "server-driven negotiation"). Selection is based on the
available representations for a response (the dimensions over which available representations for a response (the dimensions over which
it might vary, such as language, content coding, etc.) compared to it might vary, such as language, content coding, etc.) compared to
various information supplied in the request, including both the various information supplied in the request, including both the
explicit negotiation header fields below and implicit explicit negotiation header fields below and implicit
characteristics, such as the client's network address or parts of the characteristics, such as the client's network address or parts of the
User-Agent field. User-Agent field.
Proactive negotiation is advantageous when the algorithm for Proactive negotiation is advantageous when the algorithm for
selecting from among the available representations is difficult to selecting from among the available representations is difficult to
describe to a user agent, or when the server desires to send its describe to a user agent, or when the server desires to send its
skipping to change at line 5265 skipping to change at line 5256
The request header fields Accept, Accept-Charset, Accept-Encoding, The request header fields Accept, Accept-Charset, Accept-Encoding,
and Accept-Language are defined below for a user agent to engage in and Accept-Language are defined below for a user agent to engage in
proactive negotiation of the response content. The preferences sent proactive negotiation of the response content. The preferences sent
in these fields apply to any content in the response, including in these fields apply to any content in the response, including
representations of the target resource, representations of error or representations of the target resource, representations of error or
processing status, and potentially even the miscellaneous text processing status, and potentially even the miscellaneous text
strings that might appear within the protocol. strings that might appear within the protocol.
12.2. Reactive Negotiation 12.2. Reactive Negotiation
With _reactive negotiation_ (a.k.a., _agent-driven negotiation_), With "reactive negotiation" (a.k.a., "agent-driven negotiation"),
selection of content (regardless of the status code) is performed by selection of content (regardless of the status code) is performed by
the user agent after receiving an initial response. The mechanism the user agent after receiving an initial response. The mechanism
for reactive negotiation might be as simple as a list of references for reactive negotiation might be as simple as a list of references
to alternative representations. to alternative representations.
If the user agent is not satisfied by the initial response content, If the user agent is not satisfied by the initial response content,
it can perform a GET request on one or more of the alternative it can perform a GET request on one or more of the alternative
resources to obtain a different representation. Selection of such resources to obtain a different representation. Selection of such
alternatives might be performed automatically (by the user agent) or alternatives might be performed automatically (by the user agent) or
manually (e.g., by the user selecting from a hypertext menu). manually (e.g., by the user selecting from a hypertext menu).
skipping to change at line 5302 skipping to change at line 5293
list of alternatives to the user agent, which degrades user-perceived list of alternatives to the user agent, which degrades user-perceived
latency if transmitted in the header section, and needing a second latency if transmitted in the header section, and needing a second
request to obtain an alternate representation. Furthermore, this request to obtain an alternate representation. Furthermore, this
specification does not define a mechanism for supporting automatic specification does not define a mechanism for supporting automatic
selection, though it does not prevent such a mechanism from being selection, though it does not prevent such a mechanism from being
developed. developed.
12.3. Request Content Negotiation 12.3. Request Content Negotiation
When content negotiation preferences are sent in a server's response, When content negotiation preferences are sent in a server's response,
the listed preferences are called _request content negotiation_ the listed preferences are called "request content negotiation"
because they intend to influence selection of an appropriate content because they intend to influence selection of an appropriate content
for subsequent requests to that resource. For example, the Accept for subsequent requests to that resource. For example, the Accept
(Section 12.5.1) and Accept-Encoding (Section 12.5.3) header fields (Section 12.5.1) and Accept-Encoding (Section 12.5.3) header fields
can be sent in a response to indicate preferred media types and can be sent in a response to indicate preferred media types and
content codings for subsequent requests to that resource. content codings for subsequent requests to that resource.
Similarly, Section 3.1 of [RFC5789] defines the "Accept-Patch" Similarly, Section 3.1 of [RFC5789] defines the "Accept-Patch"
response header field, which allows discovery of which content types response header field, which allows discovery of which content types
are accepted in PATCH requests. are accepted in PATCH requests.
skipping to change at line 5568 skipping to change at line 5559
defined in Section 12.4.2, a qvalue of 0 means "not acceptable".) defined in Section 12.4.2, a qvalue of 0 means "not acceptable".)
A representation could be encoded with multiple content codings. A representation could be encoded with multiple content codings.
However, most content codings are alternative ways to accomplish the However, most content codings are alternative ways to accomplish the
same purpose (e.g., data compression). When selecting between same purpose (e.g., data compression). When selecting between
multiple content codings that have the same purpose, the acceptable multiple content codings that have the same purpose, the acceptable
content coding with the highest non-zero qvalue is preferred. content coding with the highest non-zero qvalue is preferred.
An Accept-Encoding header field with a field value that is empty An Accept-Encoding header field with a field value that is empty
implies that the user agent does not want any content coding in implies that the user agent does not want any content coding in
response. If an Accept-Encoding header field is present in a request response. If a non-empty Accept-Encoding header field is present in
and none of the available representations for the response have a a request and none of the available representations for the response
content coding that is listed as acceptable, the origin server SHOULD have a content coding that is listed as acceptable, the origin server
send a response without any content coding. SHOULD send a response without any content coding unless the identity
coding is indicated as unacceptable.
When the Accept-Encoding header field is present in a response, it When the Accept-Encoding header field is present in a response, it
indicates what content codings the resource was willing to accept in indicates what content codings the resource was willing to accept in
the associated request. The field value is evaluated the same way as the associated request. The field value is evaluated the same way as
in a request. in a request.
Note that this information is specific to the associated request; the Note that this information is specific to the associated request; the
set of supported encodings might be different for other resources on set of supported encodings might be different for other resources on
the same server and could change over time or depend on other aspects the same server and could change over time or depend on other aspects
of the request (such as the request method). of the request (such as the request method).
skipping to change at line 5711 skipping to change at line 5703
response when it wishes that response to be selectively reused for response when it wishes that response to be selectively reused for
subsequent requests. Generally, that is the case when the response subsequent requests. Generally, that is the case when the response
content has been tailored to better fit the preferences expressed by content has been tailored to better fit the preferences expressed by
those selecting header fields, such as when an origin server has those selecting header fields, such as when an origin server has
selected the response's language based on the request's selected the response's language based on the request's
Accept-Language header field. Accept-Language header field.
Vary might be elided when an origin server considers variance in Vary might be elided when an origin server considers variance in
content selection to be less significant than Vary's performance content selection to be less significant than Vary's performance
impact on caching, particularly when reuse is already limited by impact on caching, particularly when reuse is already limited by
Cache-Control response directives (Section 5.2 of [CACHING]). cache response directives (Section 5.2 of [CACHING]).
There is no need to send the Authorization field name in Vary because There is no need to send the Authorization field name in Vary because
reuse of that response for a different user is prohibited by the reuse of that response for a different user is prohibited by the
field definition (Section 11.6.2). Likewise, if the response content field definition (Section 11.6.2). Likewise, if the response content
has been selected or influenced by network region, but the origin has been selected or influenced by network region, but the origin
server wants the cached response to be reused even if recipients move server wants the cached response to be reused even if recipients move
from one region to another, then there is no need for the origin from one region to another, then there is no need for the origin
server to indicate such variance in Vary. server to indicate such variance in Vary.
13. Conditional Requests 13. Conditional Requests
skipping to change at line 6197 skipping to change at line 6189
specification, and it MUST forward them if the request is forwarded, specification, and it MUST forward them if the request is forwarded,
since the generating client intends that they be evaluated by a since the generating client intends that they be evaluated by a
server that can provide a current representation. Likewise, a server server that can provide a current representation. Likewise, a server
MUST ignore the conditional request header fields defined by this MUST ignore the conditional request header fields defined by this
specification when received with a request method that does not specification when received with a request method that does not
involve the selection or modification of a selected representation, involve the selection or modification of a selected representation,
such as CONNECT, OPTIONS, or TRACE. such as CONNECT, OPTIONS, or TRACE.
Note that protocol extensions can modify the conditions under which Note that protocol extensions can modify the conditions under which
preconditions are evaluated or the consequences of their evaluation. preconditions are evaluated or the consequences of their evaluation.
For example, the "immutable" cache directive (defined by [RFC8246]) For example, the immutable cache directive (defined by [RFC8246])
instructs caches to forgo forwarding conditional requests when they instructs caches to forgo forwarding conditional requests when they
hold a fresh response. hold a fresh response.
Although conditional request header fields are defined as being Although conditional request header fields are defined as being
usable with the HEAD method (to keep HEAD's semantics consistent with usable with the HEAD method (to keep HEAD's semantics consistent with
those of GET), there is no point in sending a conditional HEAD those of GET), there is no point in sending a conditional HEAD
because a successful response is around the same size as a 304 (Not because a successful response is around the same size as a 304 (Not
Modified) response and more useful than a 412 (Precondition Failed) Modified) response and more useful than a 412 (Precondition Failed)
response. response.
skipping to change at line 6303 skipping to change at line 6295
14.1. Range Units 14.1. Range Units
Representation data can be partitioned into subranges when there are Representation data can be partitioned into subranges when there are
addressable structural units inherent to that data's content coding addressable structural units inherent to that data's content coding
or media type. For example, octet (a.k.a. byte) boundaries are a or media type. For example, octet (a.k.a. byte) boundaries are a
structural unit common to all representation data, allowing structural unit common to all representation data, allowing
partitions of the data to be identified as a range of bytes at some partitions of the data to be identified as a range of bytes at some
offset from the start or end of that data. offset from the start or end of that data.
This general notion of a _range unit_ is used in the Accept-Ranges This general notion of a "range unit" is used in the Accept-Ranges
(Section 14.3) response header field to advertise support for range (Section 14.3) response header field to advertise support for range
requests, the Range (Section 14.2) request header field to delineate requests, the Range (Section 14.2) request header field to delineate
the parts of a representation that are requested, and the the parts of a representation that are requested, and the
Content-Range (Section 14.4) header field to describe which part of a Content-Range (Section 14.4) header field to describe which part of a
representation is being transferred. representation is being transferred.
range-unit = token range-unit = token
All range unit names are case-insensitive and ought to be registered All range unit names are case-insensitive and ought to be registered
within the "HTTP Range Unit Registry", as defined in Section 16.5.1. within the "HTTP Range Unit Registry", as defined in Section 16.5.1.
skipping to change at line 6673 skipping to change at line 6665
specifically defined for partial updates (for example, the PATCH specifically defined for partial updates (for example, the PATCH
method defined in [RFC5789]). method defined in [RFC5789]).
14.6. Media Type multipart/byteranges 14.6. Media Type multipart/byteranges
When a 206 (Partial Content) response message includes the content of When a 206 (Partial Content) response message includes the content of
multiple ranges, they are transmitted as body parts in a multipart multiple ranges, they are transmitted as body parts in a multipart
message body ([RFC2046], Section 5.1) with the media type of message body ([RFC2046], Section 5.1) with the media type of
"multipart/byteranges". "multipart/byteranges".
The multipart/byteranges media type includes one or more body parts, The "multipart/byteranges" media type includes one or more body
each with its own Content-Type and Content-Range fields. The parts, each with its own Content-Type and Content-Range fields. The
required boundary parameter specifies the boundary string used to required boundary parameter specifies the boundary string used to
separate each body part. separate each body part.
Implementation Notes: Implementation Notes:
1. Additional CRLFs might precede the first boundary string in the 1. Additional CRLFs might precede the first boundary string in the
body. body.
2. Although [RFC2046] permits the boundary string to be quoted, some 2. Although [RFC2046] permits the boundary string to be quoted, some
existing implementations handle a quoted boundary string existing implementations handle a quoted boundary string
incorrectly. incorrectly.
3. A number of clients and servers were coded to an early draft of 3. A number of clients and servers were coded to an early draft of
the byteranges specification that used a media type of multipart/ the byteranges specification that used a media type of
x-byteranges, which is almost (but not quite) compatible with "multipart/x-byteranges", which is almost (but not quite)
this type. compatible with this type.
Despite the name, the "multipart/byteranges" media type is not Despite the name, the "multipart/byteranges" media type is not
limited to byte ranges. The following example uses an "exampleunit" limited to byte ranges. The following example uses an "exampleunit"
range unit: range unit:
HTTP/1.1 206 Partial Content HTTP/1.1 206 Partial Content
Date: Tue, 14 Nov 1995 06:25:24 GMT Date: Tue, 14 Nov 1995 06:25:24 GMT
Last-Modified: Tue, 14 July 04:58:08 GMT Last-Modified: Tue, 14 July 04:58:08 GMT
Content-Length: 2331785 Content-Length: 2331785
Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
skipping to change at line 6715 skipping to change at line 6707
...the first range... ...the first range...
--THIS_STRING_SEPARATES --THIS_STRING_SEPARATES
Content-Type: video/example Content-Type: video/example
Content-Range: exampleunit 11.2-14.3/25 Content-Range: exampleunit 11.2-14.3/25
...the second range ...the second range
--THIS_STRING_SEPARATES-- --THIS_STRING_SEPARATES--
The following information serves as the registration form for the The following information serves as the registration form for the
multipart/byteranges media type. "multipart/byteranges" media type.
Type name: multipart Type name: multipart
Subtype name: byteranges Subtype name: byteranges
Required parameters: boundary Required parameters: boundary
Optional parameters: N/A Optional parameters: N/A
Encoding considerations: only "7bit", "8bit", or "binary" are Encoding considerations: only "7bit", "8bit", or "binary" are
permitted permitted
Security considerations: see Section 17 Security considerations: see Section 17
Interoperability considerations: N/A Interoperability considerations: N/A
Published specification: This specification (see Section 14.6) Published specification: RFC 9110 (see Section 14.6)
Applications that use this media type: HTTP components supporting Applications that use this media type: HTTP components supporting
multiple ranges in a single request multiple ranges in a single request
Fragment identifier considerations: N/A Fragment identifier considerations: N/A
Additional information: Deprecated alias names for this type: N/A Additional information: Deprecated alias names for this type: N/A
Magic number(s): N/A Magic number(s): N/A
skipping to change at line 6804 skipping to change at line 6796
Request) status code. The response message will usually contain a Request) status code. The response message will usually contain a
representation that explains the status. representation that explains the status.
Values outside the range 100..599 are invalid. Implementations often Values outside the range 100..599 are invalid. Implementations often
use three-digit integer values outside of that range (i.e., 600..999) use three-digit integer values outside of that range (i.e., 600..999)
for internal communication of non-HTTP status (e.g., library errors). for internal communication of non-HTTP status (e.g., library errors).
A client that receives a response with an invalid status code SHOULD A client that receives a response with an invalid status code SHOULD
process the response as if it had a 5xx (Server Error) status code. process the response as if it had a 5xx (Server Error) status code.
A single request can have multiple associated responses: zero or more A single request can have multiple associated responses: zero or more
_interim_ (non-final) responses with status codes in the "interim" (non-final) responses with status codes in the
"informational" (1xx) range, followed by exactly one _final_ response "informational" (1xx) range, followed by exactly one "final" response
with a status code in one of the other ranges. with a status code in one of the other ranges.
15.1. Overview of Status Codes 15.1. Overview of Status Codes
The status codes listed below are defined in this specification. The The status codes listed below are defined in this specification. The
reason phrases listed here are only recommendations -- they can be reason phrases listed here are only recommendations -- they can be
replaced by local equivalents or left out altogether without replaced by local equivalents or left out altogether without
affecting the protocol. affecting the protocol.
Responses with status codes that are defined as heuristically Responses with status codes that are defined as heuristically
skipping to change at line 6829 skipping to change at line 6821
definition or explicit cache controls [CACHING]; all other status definition or explicit cache controls [CACHING]; all other status
codes are not heuristically cacheable. codes are not heuristically cacheable.
Additional status codes, outside the scope of this specification, Additional status codes, outside the scope of this specification,
have been specified for use in HTTP. All such status codes ought to have been specified for use in HTTP. All such status codes ought to
be registered within the "Hypertext Transfer Protocol (HTTP) Status be registered within the "Hypertext Transfer Protocol (HTTP) Status
Code Registry", as described in Section 16.2. Code Registry", as described in Section 16.2.
15.2. Informational 1xx 15.2. Informational 1xx
The _1xx (Informational)_ class of status code indicates an interim The 1xx (Informational) class of status code indicates an interim
response for communicating connection status or request progress response for communicating connection status or request progress
prior to completing the requested action and sending a final prior to completing the requested action and sending a final
response. Since HTTP/1.0 did not define any 1xx status codes, a response. Since HTTP/1.0 did not define any 1xx status codes, a
server MUST NOT send a 1xx response to an HTTP/1.0 client. server MUST NOT send a 1xx response to an HTTP/1.0 client.
A 1xx response is terminated by the end of the header section; it A 1xx response is terminated by the end of the header section; it
cannot contain content or trailers. cannot contain content or trailers.
A client MUST be able to parse one or more 1xx responses received A client MUST be able to parse one or more 1xx responses received
prior to a final response, even if the client does not expect one. A prior to a final response, even if the client does not expect one. A
user agent MAY ignore unexpected 1xx responses. user agent MAY ignore unexpected 1xx responses.
A proxy MUST forward 1xx responses unless the proxy itself requested A proxy MUST forward 1xx responses unless the proxy itself requested
the generation of the 1xx response. For example, if a proxy adds an the generation of the 1xx response. For example, if a proxy adds an
"Expect: 100-continue" header field when it forwards a request, then "Expect: 100-continue" header field when it forwards a request, then
it need not forward the corresponding 100 (Continue) response(s). it need not forward the corresponding 100 (Continue) response(s).
15.2.1. 100 Continue 15.2.1. 100 Continue
The _100 (Continue)_ status code indicates that the initial part of a The 100 (Continue) status code indicates that the initial part of a
request has been received and has not yet been rejected by the request has been received and has not yet been rejected by the
server. The server intends to send a final response after the server. The server intends to send a final response after the
request has been fully received and acted upon. request has been fully received and acted upon.
When the request contains an Expect header field that includes a When the request contains an Expect header field that includes a
100-continue expectation, the 100 response indicates that the server 100-continue expectation, the 100 response indicates that the server
wishes to receive the request content, as described in wishes to receive the request content, as described in
Section 10.1.1. The client ought to continue sending the request and Section 10.1.1. The client ought to continue sending the request and
discard the 100 response. discard the 100 response.
If the request did not contain an Expect header field containing the If the request did not contain an Expect header field containing the
100-continue expectation, the client can simply discard this interim 100-continue expectation, the client can simply discard this interim
response. response.
15.2.2. 101 Switching Protocols 15.2.2. 101 Switching Protocols
The _101 (Switching Protocols)_ status code indicates that the server The 101 (Switching Protocols) status code indicates that the server
understands and is willing to comply with the client's request, via understands and is willing to comply with the client's request, via
the Upgrade header field (Section 7.8), for a change in the the Upgrade header field (Section 7.8), for a change in the
application protocol being used on this connection. The server MUST application protocol being used on this connection. The server MUST
generate an Upgrade header field in the response that indicates which generate an Upgrade header field in the response that indicates which
protocol(s) will be in effect after this response. protocol(s) will be in effect after this response.
It is assumed that the server will only agree to switch protocols It is assumed that the server will only agree to switch protocols
when it is advantageous to do so. For example, switching to a newer when it is advantageous to do so. For example, switching to a newer
version of HTTP might be advantageous over older versions, and version of HTTP might be advantageous over older versions, and
switching to a real-time, synchronous protocol might be advantageous switching to a real-time, synchronous protocol might be advantageous
when delivering resources that use such features. when delivering resources that use such features.
15.3. Successful 2xx 15.3. Successful 2xx
The _2xx (Successful)_ class of status code indicates that the The 2xx (Successful) class of status code indicates that the client's
client's request was successfully received, understood, and accepted. request was successfully received, understood, and accepted.
15.3.1. 200 OK 15.3.1. 200 OK
The _200 (OK)_ status code indicates that the request has succeeded. The 200 (OK) status code indicates that the request has succeeded.
The content sent in a 200 response depends on the request method. The content sent in a 200 response depends on the request method.
For the methods defined by this specification, the intended meaning For the methods defined by this specification, the intended meaning
of the content can be summarized as: of the content can be summarized as:
+================+============================================+ +================+============================================+
| Request Method | Response content is a representation of: | | Request Method | Response content is a representation of: |
+================+============================================+ +================+============================================+
| GET | the target resource | | GET | the target resource |
+----------------+--------------------------------------------+ +----------------+--------------------------------------------+
| HEAD | the target resource, like GET, but without | | HEAD | the target resource, like GET, but without |
skipping to change at line 6917 skipping to change at line 6909
| TRACE | the request message as received by the | | TRACE | the request message as received by the |
| | server returning the trace | | | server returning the trace |
+----------------+--------------------------------------------+ +----------------+--------------------------------------------+
Table 6 Table 6
Aside from responses to CONNECT, a 200 response is expected to Aside from responses to CONNECT, a 200 response is expected to
contain message content unless the message framing explicitly contain message content unless the message framing explicitly
indicates that the content has zero length. If some aspect of the indicates that the content has zero length. If some aspect of the
request indicates a preference for no content upon success, the request indicates a preference for no content upon success, the
origin server ought to send a _204 (No Content)_ response instead. origin server ought to send a 204 (No Content) response instead. For
For CONNECT, there is no content because the successful result is a CONNECT, there is no content because the successful result is a
tunnel, which begins immediately after the 200 response header tunnel, which begins immediately after the 200 response header
section. section.
A 200 response is heuristically cacheable; i.e., unless otherwise A 200 response is heuristically cacheable; i.e., unless otherwise
indicated by the method definition or explicit cache controls (see indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [CACHING]). Section 4.2.2 of [CACHING]).
In 200 responses to GET or HEAD, an origin server SHOULD send any In 200 responses to GET or HEAD, an origin server SHOULD send any
available validator fields (Section 8.8) for the selected available validator fields (Section 8.8) for the selected
representation, with both a strong entity-tag and a Last-Modified representation, with both a strong entity-tag and a Last-Modified
date being preferred. date being preferred.
In 200 responses to state-changing methods, any validator fields In 200 responses to state-changing methods, any validator fields
(Section 8.8) sent in the response convey the current validators for (Section 8.8) sent in the response convey the current validators for
the new representation formed as a result of successfully applying the new representation formed as a result of successfully applying
the request semantics. Note that the PUT method (Section 9.3.4) has the request semantics. Note that the PUT method (Section 9.3.4) has
additional requirements that might preclude sending such validators. additional requirements that might preclude sending such validators.
15.3.2. 201 Created 15.3.2. 201 Created
The _201 (Created)_ status code indicates that the request has been The 201 (Created) status code indicates that the request has been
fulfilled and has resulted in one or more new resources being fulfilled and has resulted in one or more new resources being
created. The primary resource created by the request is identified created. The primary resource created by the request is identified
by either a Location header field in the response or, if no Location by either a Location header field in the response or, if no Location
header field is received, by the target URI. header field is received, by the target URI.
The 201 response content typically describes and links to the The 201 response content typically describes and links to the
resource(s) created. Any validator fields (Section 8.8) sent in the resource(s) created. Any validator fields (Section 8.8) sent in the
response convey the current validators for a new representation response convey the current validators for a new representation
created by the request. Note that the PUT method (Section 9.3.4) has created by the request. Note that the PUT method (Section 9.3.4) has
additional requirements that might preclude sending such validators. additional requirements that might preclude sending such validators.
15.3.3. 202 Accepted 15.3.3. 202 Accepted
The _202 (Accepted)_ status code indicates that the request has been The 202 (Accepted) status code indicates that the request has been
accepted for processing, but the processing has not been completed. accepted for processing, but the processing has not been completed.
The request might or might not eventually be acted upon, as it might The request might or might not eventually be acted upon, as it might
be disallowed when processing actually takes place. There is no be disallowed when processing actually takes place. There is no
facility in HTTP for re-sending a status code from an asynchronous facility in HTTP for re-sending a status code from an asynchronous
operation. operation.
The 202 response is intentionally noncommittal. Its purpose is to The 202 response is intentionally noncommittal. Its purpose is to
allow a server to accept a request for some other process (perhaps a allow a server to accept a request for some other process (perhaps a
batch-oriented process that is only run once per day) without batch-oriented process that is only run once per day) without
requiring that the user agent's connection to the server persist requiring that the user agent's connection to the server persist
until the process is completed. The representation sent with this until the process is completed. The representation sent with this
response ought to describe the request's current status and point to response ought to describe the request's current status and point to
(or embed) a status monitor that can provide the user with an (or embed) a status monitor that can provide the user with an
estimate of when the request will be fulfilled. estimate of when the request will be fulfilled.
15.3.4. 203 Non-Authoritative Information 15.3.4. 203 Non-Authoritative Information
The _203 (Non-Authoritative Information)_ status code indicates that The 203 (Non-Authoritative Information) status code indicates that
the request was successful but the enclosed content has been modified the request was successful but the enclosed content has been modified
from that of the origin server's 200 (OK) response by a transforming from that of the origin server's 200 (OK) response by a transforming
proxy (Section 7.7). This status code allows the proxy to notify proxy (Section 7.7). This status code allows the proxy to notify
recipients when a transformation has been applied, since that recipients when a transformation has been applied, since that
knowledge might impact later decisions regarding the content. For knowledge might impact later decisions regarding the content. For
example, future cache validation requests for the content might only example, future cache validation requests for the content might only
be applicable along the same request path (through the same proxies). be applicable along the same request path (through the same proxies).
A 203 response is heuristically cacheable; i.e., unless otherwise A 203 response is heuristically cacheable; i.e., unless otherwise
indicated by the method definition or explicit cache controls (see indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [CACHING]). Section 4.2.2 of [CACHING]).
15.3.5. 204 No Content 15.3.5. 204 No Content
The _204 (No Content)_ status code indicates that the server has The 204 (No Content) status code indicates that the server has
successfully fulfilled the request and that there is no additional successfully fulfilled the request and that there is no additional
content to send in the response content. Metadata in the response content to send in the response content. Metadata in the response
header fields refer to the target resource and its selected header fields refer to the target resource and its selected
representation after the requested action was applied. representation after the requested action was applied.
For example, if a 204 status code is received in response to a PUT For example, if a 204 status code is received in response to a PUT
request and the response contains an ETag field, then the PUT was request and the response contains an ETag field, then the PUT was
successful and the ETag field value contains the entity-tag for the successful and the ETag field value contains the entity-tag for the
new representation of that target resource. new representation of that target resource.
skipping to change at line 7020 skipping to change at line 7012
A 204 response is terminated by the end of the header section; it A 204 response is terminated by the end of the header section; it
cannot contain content or trailers. cannot contain content or trailers.
A 204 response is heuristically cacheable; i.e., unless otherwise A 204 response is heuristically cacheable; i.e., unless otherwise
indicated by the method definition or explicit cache controls (see indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [CACHING]). Section 4.2.2 of [CACHING]).
15.3.6. 205 Reset Content 15.3.6. 205 Reset Content
The _205 (Reset Content)_ status code indicates that the server has The 205 (Reset Content) status code indicates that the server has
fulfilled the request and desires that the user agent reset the fulfilled the request and desires that the user agent reset the
"document view", which caused the request to be sent, to its original "document view", which caused the request to be sent, to its original
state as received from the origin server. state as received from the origin server.
This response is intended to support a common data entry use case This response is intended to support a common data entry use case
where the user receives content that supports data entry (a form, where the user receives content that supports data entry (a form,
notepad, canvas, etc.), enters or manipulates data in that space, notepad, canvas, etc.), enters or manipulates data in that space,
causes the entered data to be submitted in a request, and then the causes the entered data to be submitted in a request, and then the
data entry mechanism is reset for the next entry so that the user can data entry mechanism is reset for the next entry so that the user can
easily initiate another input action. easily initiate another input action.
Since the 205 status code implies that no additional content will be Since the 205 status code implies that no additional content will be
provided, a server MUST NOT generate content in a 205 response. provided, a server MUST NOT generate content in a 205 response.
15.3.7. 206 Partial Content 15.3.7. 206 Partial Content
The _206 (Partial Content)_ status code indicates that the server is The 206 (Partial Content) status code indicates that the server is
successfully fulfilling a range request for the target resource by successfully fulfilling a range request for the target resource by
transferring one or more parts of the selected representation. transferring one or more parts of the selected representation.
A server that supports range requests (Section 14) will usually A server that supports range requests (Section 14) will usually
attempt to satisfy all of the requested ranges, since sending less attempt to satisfy all of the requested ranges, since sending less
data will likely result in another client request for the remainder. data will likely result in another client request for the remainder.
However, a server might want to send only a subset of the data However, a server might want to send only a subset of the data
requested for reasons of its own, such as temporary unavailability, requested for reasons of its own, such as temporary unavailability,
cache efficiency, load balancing, etc. Since a 206 response is self- cache efficiency, load balancing, etc. Since a 206 response is self-
descriptive, the client can still understand a response that only descriptive, the client can still understand a response that only
skipping to change at line 7098 skipping to change at line 7090
Content-Length: 26012 Content-Length: 26012
Content-Type: image/gif Content-Type: image/gif
... 26012 bytes of partial image data ... ... 26012 bytes of partial image data ...
15.3.7.2. Multiple Parts 15.3.7.2. Multiple Parts
If multiple parts are being transferred, the server generating the If multiple parts are being transferred, the server generating the
206 response MUST generate "multipart/byteranges" content, as defined 206 response MUST generate "multipart/byteranges" content, as defined
in Section 14.6, and a Content-Type header field containing the in Section 14.6, and a Content-Type header field containing the
multipart/byteranges media type and its required boundary parameter. "multipart/byteranges" media type and its required boundary
To avoid confusion with single-part responses, a server MUST NOT parameter. To avoid confusion with single-part responses, a server
generate a Content-Range header field in the HTTP header section of a MUST NOT generate a Content-Range header field in the HTTP header
multiple part response (this field will be sent in each part section of a multiple part response (this field will be sent in each
instead). part instead).
Within the header area of each body part in the multipart content, Within the header area of each body part in the multipart content,
the server MUST generate a Content-Range header field corresponding the server MUST generate a Content-Range header field corresponding
to the range being enclosed in that body part. If the selected to the range being enclosed in that body part. If the selected
representation would have had a Content-Type header field in a 200 representation would have had a Content-Type header field in a 200
(OK) response, the server SHOULD generate that same Content-Type (OK) response, the server SHOULD generate that same Content-Type
header field in the header area of each body part. For example: header field in the header area of each body part. For example:
HTTP/1.1 206 Partial Content HTTP/1.1 206 Partial Content
Date: Wed, 15 Nov 1995 06:25:24 GMT Date: Wed, 15 Nov 1995 06:25:24 GMT
skipping to change at line 7134 skipping to change at line 7126
Content-Range: bytes 7000-7999/8000 Content-Range: bytes 7000-7999/8000
...the second range ...the second range
--THIS_STRING_SEPARATES-- --THIS_STRING_SEPARATES--
When multiple ranges are requested, a server MAY coalesce any of the When multiple ranges are requested, a server MAY coalesce any of the
ranges that overlap, or that are separated by a gap that is smaller ranges that overlap, or that are separated by a gap that is smaller
than the overhead of sending multiple parts, regardless of the order than the overhead of sending multiple parts, regardless of the order
in which the corresponding range-spec appeared in the received Range in which the corresponding range-spec appeared in the received Range
header field. Since the typical overhead between each part of a header field. Since the typical overhead between each part of a
multipart/byteranges is around 80 bytes, depending on the selected "multipart/byteranges" is around 80 bytes, depending on the selected
representation's media type and the chosen boundary parameter length, representation's media type and the chosen boundary parameter length,
it can be less efficient to transfer many small disjoint parts than it can be less efficient to transfer many small disjoint parts than
it is to transfer the entire selected representation. it is to transfer the entire selected representation.
A server MUST NOT generate a multipart response to a request for a A server MUST NOT generate a multipart response to a request for a
single range, since a client that does not request multiple parts single range, since a client that does not request multiple parts
might not support multipart responses. However, a server MAY might not support multipart responses. However, a server MAY
generate a multipart/byteranges response with only a single body part generate a "multipart/byteranges" response with only a single body
if multiple ranges were requested and only one range was found to be part if multiple ranges were requested and only one range was found
satisfiable or only one range remained after coalescing. A client to be satisfiable or only one range remained after coalescing. A
that cannot process a multipart/byteranges response MUST NOT generate client that cannot process a "multipart/byteranges" response MUST NOT
a request that asks for multiple ranges. generate a request that asks for multiple ranges.
A server that generates a multipart response SHOULD send the parts in A server that generates a multipart response SHOULD send the parts in
the same order that the corresponding range-spec appeared in the the same order that the corresponding range-spec appeared in the
received Range header field, excluding those ranges that were deemed received Range header field, excluding those ranges that were deemed
unsatisfiable or that were coalesced into other ranges. A client unsatisfiable or that were coalesced into other ranges. A client
that receives a multipart response MUST inspect the Content-Range that receives a multipart response MUST inspect the Content-Range
header field present in each body part in order to determine which header field present in each body part in order to determine which
range is contained in that body part; a client cannot rely on range is contained in that body part; a client cannot rely on
receiving the same ranges that it requested, nor the same order that receiving the same ranges that it requested, nor the same order that
it requested. it requested.
skipping to change at line 7195 skipping to change at line 7187
The combined response content consists of the union of partial The combined response content consists of the union of partial
content ranges within the new response and all of the matching stored content ranges within the new response and all of the matching stored
responses. If the union consists of the entire range of the responses. If the union consists of the entire range of the
representation, then the client MUST process the combined response as representation, then the client MUST process the combined response as
if it were a complete 200 (OK) response, including a Content-Length if it were a complete 200 (OK) response, including a Content-Length
header field that reflects the complete length. Otherwise, the header field that reflects the complete length. Otherwise, the
client MUST process the set of continuous ranges as one of the client MUST process the set of continuous ranges as one of the
following: an incomplete 200 (OK) response if the combined response following: an incomplete 200 (OK) response if the combined response
is a prefix of the representation, a single 206 (Partial Content) is a prefix of the representation, a single 206 (Partial Content)
response containing multipart/byteranges content, or multiple 206 response containing "multipart/byteranges" content, or multiple 206
(Partial Content) responses, each with one continuous range that is (Partial Content) responses, each with one continuous range that is
indicated by a Content-Range header field. indicated by a Content-Range header field.
15.4. Redirection 3xx 15.4. Redirection 3xx
The _3xx (Redirection)_ class of status code indicates that further The 3xx (Redirection) class of status code indicates that further
action needs to be taken by the user agent in order to fulfill the action needs to be taken by the user agent in order to fulfill the
request. There are several types of redirects: request. There are several types of redirects:
1. Redirects that indicate this resource might be available at a 1. Redirects that indicate this resource might be available at a
different URI, as provided by the Location header field, as in different URI, as provided by the Location header field, as in
the status codes 301 (Moved Permanently), 302 (Found), 307 the status codes 301 (Moved Permanently), 302 (Found), 307
(Temporary Redirect), and 308 (Permanent Redirect). (Temporary Redirect), and 308 (Permanent Redirect).
2. Redirection that offers a choice among matching resources capable 2. Redirection that offers a choice among matching resources capable
of representing this resource, as in the 300 (Multiple Choices) of representing this resource, as in the 300 (Multiple Choices)
skipping to change at line 7293 skipping to change at line 7285
A client SHOULD detect and intervene in cyclical redirections (i.e., A client SHOULD detect and intervene in cyclical redirections (i.e.,
"infinite" redirection loops). "infinite" redirection loops).
| *Note:* An earlier version of this specification recommended a | *Note:* An earlier version of this specification recommended a
| maximum of five redirections ([RFC2068], Section 10.3). | maximum of five redirections ([RFC2068], Section 10.3).
| Content developers need to be aware that some clients might | Content developers need to be aware that some clients might
| implement such a fixed limitation. | implement such a fixed limitation.
15.4.1. 300 Multiple Choices 15.4.1. 300 Multiple Choices
The _300 (Multiple Choices)_ status code indicates that the target The 300 (Multiple Choices) status code indicates that the target
resource has more than one representation, each with its own more resource has more than one representation, each with its own more
specific identifier, and information about the alternatives is being specific identifier, and information about the alternatives is being
provided so that the user (or user agent) can select a preferred provided so that the user (or user agent) can select a preferred
representation by redirecting its request to one or more of those representation by redirecting its request to one or more of those
identifiers. In other words, the server desires that the user agent identifiers. In other words, the server desires that the user agent
engage in reactive negotiation to select the most appropriate engage in reactive negotiation to select the most appropriate
representation(s) for its needs (Section 12). representation(s) for its needs (Section 12).
If the server has a preferred choice, the server SHOULD generate a If the server has a preferred choice, the server SHOULD generate a
Location header field containing a preferred choice's URI reference. Location header field containing a preferred choice's URI reference.
skipping to change at line 7336 skipping to change at line 7328
| 406 responses and be transferred in responses to the HEAD | 406 responses and be transferred in responses to the HEAD
| method. However, lack of deployment and disagreement over | method. However, lack of deployment and disagreement over
| syntax led to both URI and Alternates (a subsequent proposal) | syntax led to both URI and Alternates (a subsequent proposal)
| being dropped from this specification. It is possible to | being dropped from this specification. It is possible to
| communicate the list as a Link header field value [RFC8288] | communicate the list as a Link header field value [RFC8288]
| whose members have a relationship of "alternate", though | whose members have a relationship of "alternate", though
| deployment is a chicken-and-egg problem. | deployment is a chicken-and-egg problem.
15.4.2. 301 Moved Permanently 15.4.2. 301 Moved Permanently
The _301 (Moved Permanently)_ status code indicates that the target The 301 (Moved Permanently) status code indicates that the target
resource has been assigned a new permanent URI and any future resource has been assigned a new permanent URI and any future
references to this resource ought to use one of the enclosed URIs. references to this resource ought to use one of the enclosed URIs.
The server is suggesting that a user agent with link-editing The server is suggesting that a user agent with link-editing
capability can permanently replace references to the target URI with capability can permanently replace references to the target URI with
one of the new references sent by the server. However, this one of the new references sent by the server. However, this
suggestion is usually ignored unless the user agent is actively suggestion is usually ignored unless the user agent is actively
editing references (e.g., engaged in authoring content), the editing references (e.g., engaged in authoring content), the
connection is secured, and the origin server is a trusted authority connection is secured, and the origin server is a trusted authority
for the content being edited. for the content being edited.
skipping to change at line 7364 skipping to change at line 7356
| request method from POST to GET for the subsequent request. If | request method from POST to GET for the subsequent request. If
| this behavior is undesired, the 308 (Permanent Redirect) status | this behavior is undesired, the 308 (Permanent Redirect) status
| code can be used instead. | code can be used instead.
A 301 response is heuristically cacheable; i.e., unless otherwise A 301 response is heuristically cacheable; i.e., unless otherwise
indicated by the method definition or explicit cache controls (see indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [CACHING]). Section 4.2.2 of [CACHING]).
15.4.3. 302 Found 15.4.3. 302 Found
The _302 (Found)_ status code indicates that the target resource The 302 (Found) status code indicates that the target resource
resides temporarily under a different URI. Since the redirection resides temporarily under a different URI. Since the redirection
might be altered on occasion, the client ought to continue to use the might be altered on occasion, the client ought to continue to use the
target URI for future requests. target URI for future requests.
The server SHOULD generate a Location header field in the response The server SHOULD generate a Location header field in the response
containing a URI reference for the different URI. The user agent MAY containing a URI reference for the different URI. The user agent MAY
use the Location field value for automatic redirection. The server's use the Location field value for automatic redirection. The server's
response content usually contains a short hypertext note with a response content usually contains a short hypertext note with a
hyperlink to the different URI(s). hyperlink to the different URI(s).
| *Note:* For historical reasons, a user agent MAY change the | *Note:* For historical reasons, a user agent MAY change the
| request method from POST to GET for the subsequent request. If | request method from POST to GET for the subsequent request. If
| this behavior is undesired, the 307 (Temporary Redirect) status | this behavior is undesired, the 307 (Temporary Redirect) status
| code can be used instead. | code can be used instead.
15.4.4. 303 See Other 15.4.4. 303 See Other
The _303 (See Other)_ status code indicates that the server is The 303 (See Other) status code indicates that the server is
redirecting the user agent to a different resource, as indicated by a redirecting the user agent to a different resource, as indicated by a
URI in the Location header field, which is intended to provide an URI in the Location header field, which is intended to provide an
indirect response to the original request. A user agent can perform indirect response to the original request. A user agent can perform
a retrieval request targeting that URI (a GET or HEAD request if a retrieval request targeting that URI (a GET or HEAD request if
using HTTP), which might also be redirected, and present the eventual using HTTP), which might also be redirected, and present the eventual
result as an answer to the original request. Note that the new URI result as an answer to the original request. Note that the new URI
in the Location header field is not considered equivalent to the in the Location header field is not considered equivalent to the
target URI. target URI.
This status code is applicable to any HTTP method. It is primarily This status code is applicable to any HTTP method. It is primarily
skipping to change at line 7415 skipping to change at line 7407
answers to the questions of what can be represented, what answers to the questions of what can be represented, what
representations are adequate, and what might be a useful description representations are adequate, and what might be a useful description
are outside the scope of HTTP. are outside the scope of HTTP.
Except for responses to a HEAD request, the representation of a 303 Except for responses to a HEAD request, the representation of a 303
response ought to contain a short hypertext note with a hyperlink to response ought to contain a short hypertext note with a hyperlink to
the same URI reference provided in the Location header field. the same URI reference provided in the Location header field.
15.4.5. 304 Not Modified 15.4.5. 304 Not Modified
The _304 (Not Modified)_ status code indicates that a conditional GET The 304 (Not Modified) status code indicates that a conditional GET
or HEAD request has been received and would have resulted in a 200 or HEAD request has been received and would have resulted in a 200
(OK) response if it were not for the fact that the condition (OK) response if it were not for the fact that the condition
evaluated to false. In other words, there is no need for the server evaluated to false. In other words, there is no need for the server
to transfer a representation of the target resource because the to transfer a representation of the target resource because the
request indicates that the client, which made the request request indicates that the client, which made the request
conditional, already has a valid representation; the server is conditional, already has a valid representation; the server is
therefore redirecting the client to make use of that stored therefore redirecting the client to make use of that stored
representation as if it were the content of a 200 (OK) response. representation as if it were the content of a 200 (OK) response.
The server generating a 304 response MUST generate any of the The server generating a 304 response MUST generate any of the
skipping to change at line 7448 skipping to change at line 7440
Section 4.3.4 of [CACHING]. If the conditional request originated Section 4.3.4 of [CACHING]. If the conditional request originated
with an outbound client, such as a user agent with its own cache with an outbound client, such as a user agent with its own cache
sending a conditional GET to a shared proxy, then the proxy SHOULD sending a conditional GET to a shared proxy, then the proxy SHOULD
forward the 304 response to that client. forward the 304 response to that client.
A 304 response is terminated by the end of the header section; it A 304 response is terminated by the end of the header section; it
cannot contain content or trailers. cannot contain content or trailers.
15.4.6. 305 Use Proxy 15.4.6. 305 Use Proxy
The _305 (Use Proxy)_ status code was defined in a previous version The 305 (Use Proxy) status code was defined in a previous version of
of this specification and is now deprecated (Appendix B of this specification and is now deprecated (Appendix B of [RFC7231]).
[RFC7231]).
15.4.7. 306 (Unused) 15.4.7. 306 (Unused)
The 306 status code was defined in a previous version of this The 306 status code was defined in a previous version of this
specification, is no longer used, and the code is reserved. specification, is no longer used, and the code is reserved.
15.4.8. 307 Temporary Redirect 15.4.8. 307 Temporary Redirect
The _307 (Temporary Redirect)_ status code indicates that the target The 307 (Temporary Redirect) status code indicates that the target
resource resides temporarily under a different URI and the user agent resource resides temporarily under a different URI and the user agent
MUST NOT change the request method if it performs an automatic MUST NOT change the request method if it performs an automatic
redirection to that URI. Since the redirection can change over time, redirection to that URI. Since the redirection can change over time,
the client ought to continue using the original target URI for future the client ought to continue using the original target URI for future
requests. requests.
The server SHOULD generate a Location header field in the response The server SHOULD generate a Location header field in the response
containing a URI reference for the different URI. The user agent MAY containing a URI reference for the different URI. The user agent MAY
use the Location field value for automatic redirection. The server's use the Location field value for automatic redirection. The server's
response content usually contains a short hypertext note with a response content usually contains a short hypertext note with a
hyperlink to the different URI(s). hyperlink to the different URI(s).
15.4.9. 308 Permanent Redirect 15.4.9. 308 Permanent Redirect
The _308 (Permanent Redirect)_ status code indicates that the target The 308 (Permanent Redirect) status code indicates that the target
resource has been assigned a new permanent URI and any future resource has been assigned a new permanent URI and any future
references to this resource ought to use one of the enclosed URIs. references to this resource ought to use one of the enclosed URIs.
The server is suggesting that a user agent with link-editing The server is suggesting that a user agent with link-editing
capability can permanently replace references to the target URI with capability can permanently replace references to the target URI with
one of the new references sent by the server. However, this one of the new references sent by the server. However, this
suggestion is usually ignored unless the user agent is actively suggestion is usually ignored unless the user agent is actively
editing references (e.g., engaged in authoring content), the editing references (e.g., engaged in authoring content), the
connection is secured, and the origin server is a trusted authority connection is secured, and the origin server is a trusted authority
for the content being edited. for the content being edited.
skipping to change at line 7501 skipping to change at line 7492
A 308 response is heuristically cacheable; i.e., unless otherwise A 308 response is heuristically cacheable; i.e., unless otherwise
indicated by the method definition or explicit cache controls (see indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [CACHING]). Section 4.2.2 of [CACHING]).
| *Note:* This status code is much younger (June 2014) than its | *Note:* This status code is much younger (June 2014) than its
| sibling codes and thus might not be recognized everywhere. See | sibling codes and thus might not be recognized everywhere. See
| Section 4 of [RFC7538] for deployment considerations. | Section 4 of [RFC7538] for deployment considerations.
15.5. Client Error 4xx 15.5. Client Error 4xx
The _4xx (Client Error)_ class of status code indicates that the The 4xx (Client Error) class of status code indicates that the client
client seems to have erred. Except when responding to a HEAD seems to have erred. Except when responding to a HEAD request, the
request, the server SHOULD send a representation containing an server SHOULD send a representation containing an explanation of the
explanation of the error situation, and whether it is a temporary or error situation, and whether it is a temporary or permanent
permanent condition. These status codes are applicable to any condition. These status codes are applicable to any request method.
request method. User agents SHOULD display any included User agents SHOULD display any included representation to the user.
representation to the user.
15.5.1. 400 Bad Request 15.5.1. 400 Bad Request
The _400 (Bad Request)_ status code indicates that the server cannot The 400 (Bad Request) status code indicates that the server cannot or
or will not process the request due to something that is perceived to will not process the request due to something that is perceived to be
be a client error (e.g., malformed request syntax, invalid request a client error (e.g., malformed request syntax, invalid request
message framing, or deceptive request routing). message framing, or deceptive request routing).
15.5.2. 401 Unauthorized 15.5.2. 401 Unauthorized
The _401 (Unauthorized)_ status code indicates that the request has The 401 (Unauthorized) status code indicates that the request has not
not been applied because it lacks valid authentication credentials been applied because it lacks valid authentication credentials for
for the target resource. The server generating a 401 response MUST the target resource. The server generating a 401 response MUST send
send a WWW-Authenticate header field (Section 11.6.1) containing at a WWW-Authenticate header field (Section 11.6.1) containing at least
least one challenge applicable to the target resource. one challenge applicable to the target resource.
If the request included authentication credentials, then the 401 If the request included authentication credentials, then the 401
response indicates that authorization has been refused for those response indicates that authorization has been refused for those
credentials. The user agent MAY repeat the request with a new or credentials. The user agent MAY repeat the request with a new or
replaced Authorization header field (Section 11.6.2). If the 401 replaced Authorization header field (Section 11.6.2). If the 401
response contains the same challenge as the prior response, and the response contains the same challenge as the prior response, and the
user agent has already attempted authentication at least once, then user agent has already attempted authentication at least once, then
the user agent SHOULD present the enclosed representation to the the user agent SHOULD present the enclosed representation to the
user, since it usually contains relevant diagnostic information. user, since it usually contains relevant diagnostic information.
15.5.3. 402 Payment Required 15.5.3. 402 Payment Required
The _402 (Payment Required)_ status code is reserved for future use. The 402 (Payment Required) status code is reserved for future use.
15.5.4. 403 Forbidden 15.5.4. 403 Forbidden
The _403 (Forbidden)_ status code indicates that the server The 403 (Forbidden) status code indicates that the server understood
understood the request but refuses to fulfill it. A server that the request but refuses to fulfill it. A server that wishes to make
wishes to make public why the request has been forbidden can describe public why the request has been forbidden can describe that reason in
that reason in the response content (if any). the response content (if any).
If authentication credentials were provided in the request, the If authentication credentials were provided in the request, the
server considers them insufficient to grant access. The client server considers them insufficient to grant access. The client
SHOULD NOT automatically repeat the request with the same SHOULD NOT automatically repeat the request with the same
credentials. The client MAY repeat the request with new or different credentials. The client MAY repeat the request with new or different
credentials. However, a request might be forbidden for reasons credentials. However, a request might be forbidden for reasons
unrelated to the credentials. unrelated to the credentials.
An origin server that wishes to "hide" the current existence of a An origin server that wishes to "hide" the current existence of a
forbidden target resource MAY instead respond with a status code of forbidden target resource MAY instead respond with a status code of
404 (Not Found). 404 (Not Found).
15.5.5. 404 Not Found 15.5.5. 404 Not Found
The _404 (Not Found)_ status code indicates that the origin server The 404 (Not Found) status code indicates that the origin server did
did not find a current representation for the target resource or is not find a current representation for the target resource or is not
not willing to disclose that one exists. A 404 status code does not willing to disclose that one exists. A 404 status code does not
indicate whether this lack of representation is temporary or indicate whether this lack of representation is temporary or
permanent; the 410 (Gone) status code is preferred over 404 if the permanent; the 410 (Gone) status code is preferred over 404 if the
origin server knows, presumably through some configurable means, that origin server knows, presumably through some configurable means, that
the condition is likely to be permanent. the condition is likely to be permanent.
A 404 response is heuristically cacheable; i.e., unless otherwise A 404 response is heuristically cacheable; i.e., unless otherwise
indicated by the method definition or explicit cache controls (see indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [CACHING]). Section 4.2.2 of [CACHING]).
15.5.6. 405 Method Not Allowed 15.5.6. 405 Method Not Allowed
The _405 (Method Not Allowed)_ status code indicates that the method The 405 (Method Not Allowed) status code indicates that the method
received in the request-line is known by the origin server but not received in the request-line is known by the origin server but not
supported by the target resource. The origin server MUST generate an supported by the target resource. The origin server MUST generate an
Allow header field in a 405 response containing a list of the target Allow header field in a 405 response containing a list of the target
resource's currently supported methods. resource's currently supported methods.
A 405 response is heuristically cacheable; i.e., unless otherwise A 405 response is heuristically cacheable; i.e., unless otherwise
indicated by the method definition or explicit cache controls (see indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [CACHING]). Section 4.2.2 of [CACHING]).
15.5.7. 406 Not Acceptable 15.5.7. 406 Not Acceptable
The _406 (Not Acceptable)_ status code indicates that the target The 406 (Not Acceptable) status code indicates that the target
resource does not have a current representation that would be resource does not have a current representation that would be
acceptable to the user agent, according to the proactive negotiation acceptable to the user agent, according to the proactive negotiation
header fields received in the request (Section 12.1), and the server header fields received in the request (Section 12.1), and the server
is unwilling to supply a default representation. is unwilling to supply a default representation.
The server SHOULD generate content containing a list of available The server SHOULD generate content containing a list of available
representation characteristics and corresponding resource identifiers representation characteristics and corresponding resource identifiers
from which the user or user agent can choose the one most from which the user or user agent can choose the one most
appropriate. A user agent MAY automatically select the most appropriate. A user agent MAY automatically select the most
appropriate choice from that list. However, this specification does appropriate choice from that list. However, this specification does
not define any standard for such automatic selection, as described in not define any standard for such automatic selection, as described in
Section 15.4.1. Section 15.4.1.
15.5.8. 407 Proxy Authentication Required 15.5.8. 407 Proxy Authentication Required
The _407 (Proxy Authentication Required)_ status code is similar to The 407 (Proxy Authentication Required) status code is similar to 401
401 (Unauthorized), but it indicates that the client needs to (Unauthorized), but it indicates that the client needs to
authenticate itself in order to use a proxy for this request. The authenticate itself in order to use a proxy for this request. The
proxy MUST send a Proxy-Authenticate header field (Section 11.7.1) proxy MUST send a Proxy-Authenticate header field (Section 11.7.1)
containing a challenge applicable to that proxy for the request. The containing a challenge applicable to that proxy for the request. The
client MAY repeat the request with a new or replaced client MAY repeat the request with a new or replaced
Proxy-Authorization header field (Section 11.7.2). Proxy-Authorization header field (Section 11.7.2).
15.5.9. 408 Request Timeout 15.5.9. 408 Request Timeout
The _408 (Request Timeout)_ status code indicates that the server did The 408 (Request Timeout) status code indicates that the server did
not receive a complete request message within the time that it was not receive a complete request message within the time that it was
prepared to wait. prepared to wait.
If the client has an outstanding request in transit, it MAY repeat If the client has an outstanding request in transit, it MAY repeat
that request. If the current connection is not usable (e.g., as it that request. If the current connection is not usable (e.g., as it
would be in HTTP/1.1 because request delimitation is lost), a new would be in HTTP/1.1 because request delimitation is lost), a new
connection will be used. connection will be used.
15.5.10. 409 Conflict 15.5.10. 409 Conflict
The _409 (Conflict)_ status code indicates that the request could not The 409 (Conflict) status code indicates that the request could not
be completed due to a conflict with the current state of the target be completed due to a conflict with the current state of the target
resource. This code is used in situations where the user might be resource. This code is used in situations where the user might be
able to resolve the conflict and resubmit the request. The server able to resolve the conflict and resubmit the request. The server
SHOULD generate content that includes enough information for a user SHOULD generate content that includes enough information for a user
to recognize the source of the conflict. to recognize the source of the conflict.
Conflicts are most likely to occur in response to a PUT request. For Conflicts are most likely to occur in response to a PUT request. For
example, if versioning were being used and the representation being example, if versioning were being used and the representation being
PUT included changes to a resource that conflict with those made by PUT included changes to a resource that conflict with those made by
an earlier (third-party) request, the origin server might use a 409 an earlier (third-party) request, the origin server might use a 409
response to indicate that it can't complete the request. In this response to indicate that it can't complete the request. In this
case, the response representation would likely contain information case, the response representation would likely contain information
useful for merging the differences based on the revision history. useful for merging the differences based on the revision history.
15.5.11. 410 Gone 15.5.11. 410 Gone
The _410 (Gone)_ status code indicates that access to the target The 410 (Gone) status code indicates that access to the target
resource is no longer available at the origin server and that this resource is no longer available at the origin server and that this
condition is likely to be permanent. If the origin server does not condition is likely to be permanent. If the origin server does not
know, or has no facility to determine, whether or not the condition know, or has no facility to determine, whether or not the condition
is permanent, the status code 404 (Not Found) ought to be used is permanent, the status code 404 (Not Found) ought to be used
instead. instead.
The 410 response is primarily intended to assist the task of web The 410 response is primarily intended to assist the task of web
maintenance by notifying the recipient that the resource is maintenance by notifying the recipient that the resource is
intentionally unavailable and that the server owners desire that intentionally unavailable and that the server owners desire that
remote links to that resource be removed. Such an event is common remote links to that resource be removed. Such an event is common
skipping to change at line 7660 skipping to change at line 7650
is not necessary to mark all permanently unavailable resources as is not necessary to mark all permanently unavailable resources as
"gone" or to keep the mark for any length of time -- that is left to "gone" or to keep the mark for any length of time -- that is left to
the discretion of the server owner. the discretion of the server owner.
A 410 response is heuristically cacheable; i.e., unless otherwise A 410 response is heuristically cacheable; i.e., unless otherwise
indicated by the method definition or explicit cache controls (see indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [CACHING]). Section 4.2.2 of [CACHING]).
15.5.12. 411 Length Required 15.5.12. 411 Length Required
The _411 (Length Required)_ status code indicates that the server The 411 (Length Required) status code indicates that the server
refuses to accept the request without a defined Content-Length refuses to accept the request without a defined Content-Length
(Section 8.6). The client MAY repeat the request if it adds a valid (Section 8.6). The client MAY repeat the request if it adds a valid
Content-Length header field containing the length of the request Content-Length header field containing the length of the request
content. content.
15.5.13. 412 Precondition Failed 15.5.13. 412 Precondition Failed
The _412 (Precondition Failed)_ status code indicates that one or The 412 (Precondition Failed) status code indicates that one or more
more conditions given in the request header fields evaluated to false conditions given in the request header fields evaluated to false when
when tested on the server (Section 13). This response status code tested on the server (Section 13). This response status code allows
allows the client to place preconditions on the current resource the client to place preconditions on the current resource state (its
state (its current representations and metadata) and, thus, prevent current representations and metadata) and, thus, prevent the request
the request method from being applied if the target resource is in an method from being applied if the target resource is in an unexpected
unexpected state. state.
15.5.14. 413 Content Too Large 15.5.14. 413 Content Too Large
The _413 (Content Too Large)_ status code indicates that the server The 413 (Content Too Large) status code indicates that the server is
is refusing to process a request because the request content is refusing to process a request because the request content is larger
larger than the server is willing or able to process. The server MAY than the server is willing or able to process. The server MAY
terminate the request, if the protocol version in use allows it; terminate the request, if the protocol version in use allows it;
otherwise, the server MAY close the connection. otherwise, the server MAY close the connection.
If the condition is temporary, the server SHOULD generate a If the condition is temporary, the server SHOULD generate a
Retry-After header field to indicate that it is temporary and after Retry-After header field to indicate that it is temporary and after
what time the client MAY try again. what time the client MAY try again.
15.5.15. 414 URI Too Long 15.5.15. 414 URI Too Long
The _414 (URI Too Long)_ status code indicates that the server is The 414 (URI Too Long) status code indicates that the server is
refusing to service the request because the target URI is longer than refusing to service the request because the target URI is longer than
the server is willing to interpret. This rare condition is only the server is willing to interpret. This rare condition is only
likely to occur when a client has improperly converted a POST request likely to occur when a client has improperly converted a POST request
to a GET request with long query information, when the client has to a GET request with long query information, when the client has
descended into a "black hole" of redirection (e.g., a redirected URI descended into an infinite loop of redirection (e.g., a redirected
prefix that points to a suffix of itself) or when the server is under URI prefix that points to a suffix of itself) or when the server is
attack by a client attempting to exploit potential security holes. under attack by a client attempting to exploit potential security
holes.
A 414 response is heuristically cacheable; i.e., unless otherwise A 414 response is heuristically cacheable; i.e., unless otherwise
indicated by the method definition or explicit cache controls (see indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [CACHING]). Section 4.2.2 of [CACHING]).
15.5.16. 415 Unsupported Media Type 15.5.16. 415 Unsupported Media Type
The _415 (Unsupported Media Type)_ status code indicates that the The 415 (Unsupported Media Type) status code indicates that the
origin server is refusing to service the request because the content origin server is refusing to service the request because the content
is in a format not supported by this method on the target resource. is in a format not supported by this method on the target resource.
The format problem might be due to the request's indicated The format problem might be due to the request's indicated
Content-Type or Content-Encoding, or as a result of inspecting the Content-Type or Content-Encoding, or as a result of inspecting the
data directly. data directly.
If the problem was caused by an unsupported content coding, the If the problem was caused by an unsupported content coding, the
Accept-Encoding response header field (Section 12.5.3) ought to be Accept-Encoding response header field (Section 12.5.3) ought to be
used to indicate which (if any) content codings would have been used to indicate which (if any) content codings would have been
accepted in the request. accepted in the request.
On the other hand, if the cause was an unsupported media type, the On the other hand, if the cause was an unsupported media type, the
Accept response header field (Section 12.5.1) can be used to indicate Accept response header field (Section 12.5.1) can be used to indicate
which media types would have been accepted in the request. which media types would have been accepted in the request.
15.5.17. 416 Range Not Satisfiable 15.5.17. 416 Range Not Satisfiable
The _416 (Range Not Satisfiable)_ status code indicates that the set The 416 (Range Not Satisfiable) status code indicates that the set of
of ranges in the request's Range header field (Section 14.2) has been ranges in the request's Range header field (Section 14.2) has been
rejected either because none of the requested ranges are satisfiable rejected either because none of the requested ranges are satisfiable
or because the client has requested an excessive number of small or or because the client has requested an excessive number of small or
overlapping ranges (a potential denial of service attack). overlapping ranges (a potential denial of service attack).
Each range unit defines what is required for its own range sets to be Each range unit defines what is required for its own range sets to be
satisfiable. For example, Section 14.1.2 defines what makes a bytes satisfiable. For example, Section 14.1.2 defines what makes a bytes
range set satisfiable. range set satisfiable.
A server that generates a 416 response to a byte-range request SHOULD A server that generates a 416 response to a byte-range request SHOULD
generate a Content-Range header field specifying the current length generate a Content-Range header field specifying the current length
skipping to change at line 7756 skipping to change at line 7747
| representation in a 200 (OK) response. That is partly because | representation in a 200 (OK) response. That is partly because
| most clients are prepared to receive a 200 (OK) to complete the | most clients are prepared to receive a 200 (OK) to complete the
| task (albeit less efficiently) and partly because clients might | task (albeit less efficiently) and partly because clients might
| not stop making an invalid range request until they have | not stop making an invalid range request until they have
| received a complete representation. Thus, clients cannot | received a complete representation. Thus, clients cannot
| depend on receiving a 416 (Range Not Satisfiable) response even | depend on receiving a 416 (Range Not Satisfiable) response even
| when it is most appropriate. | when it is most appropriate.
15.5.18. 417 Expectation Failed 15.5.18. 417 Expectation Failed
The _417 (Expectation Failed)_ status code indicates that the The 417 (Expectation Failed) status code indicates that the
expectation given in the request's Expect header field expectation given in the request's Expect header field
(Section 10.1.1) could not be met by at least one of the inbound (Section 10.1.1) could not be met by at least one of the inbound
servers. servers.
15.5.19. 418 (Unused) 15.5.19. 418 (Unused)
[RFC2324] is an April 1st RFC that lampoons the various ways HTTP has [RFC2324] is an April 1st RFC that lampoons the various ways HTTP has
been abused; one such abuse is the definition of an application- been abused; one such abuse is the definition of an application-
specific 418 status code. In the intervening years, this status code specific 418 status code. In the intervening years, this status code
has been widely implemented as an "Easter egg" and therefore is has been widely implemented as an "Easter egg" and therefore is
effectively consumed by this use. effectively consumed by this use.
Therefore, the 418 status code is reserved in the IANA "Hypertext Therefore, the 418 status code is reserved in the IANA HTTP Status
Transfer Protocol (HTTP) Status Code Registry". This indicates that Code Registry. This indicates that the status code cannot be
the status code cannot be assigned to other applications currently. assigned to other applications currently. If future circumstances
If future circumstances require its use (e.g., exhaustion of 4NN require its use (e.g., exhaustion of 4NN status codes), it can be re-
status codes), it can be re-assigned to another use. assigned to another use.
15.5.20. 421 Misdirected Request 15.5.20. 421 Misdirected Request
The _421 (Misdirected Request)_ status code indicates that the The 421 (Misdirected Request) status code indicates that the request
request was directed at a server that is unable or unwilling to was directed at a server that is unable or unwilling to produce an
produce an authoritative response for the target URI. An origin authoritative response for the target URI. An origin server (or
server (or gateway acting on behalf of the origin server) sends 421 gateway acting on behalf of the origin server) sends 421 to reject a
to reject a target URI that does not match an origin for which the target URI that does not match an origin for which the server has
server has been configured (Section 4.3.1) or does not match the been configured (Section 4.3.1) or does not match the connection
connection context over which the request was received (Section 7.4). context over which the request was received (Section 7.4).
A client that receives a 421 (Misdirected Request) response MAY retry A client that receives a 421 (Misdirected Request) response MAY retry
the request, whether or not the request method is idempotent, over a the request, whether or not the request method is idempotent, over a
different connection, such as a fresh connection specific to the different connection, such as a fresh connection specific to the
target resource's origin, or via an alternative service [ALTSVC]. target resource's origin, or via an alternative service [ALTSVC].
A proxy MUST NOT generate a 421 response. A proxy MUST NOT generate a 421 response.
15.5.21. 422 Unprocessable Content 15.5.21. 422 Unprocessable Content
The _422 (Unprocessable Content)_ status code indicates that the The 422 (Unprocessable Content) status code indicates that the server
server understands the content type of the request content (hence a understands the content type of the request content (hence a 415
415 (Unsupported Media Type) status code is inappropriate), and the (Unsupported Media Type) status code is inappropriate), and the
syntax of the request content is correct, but it was unable to syntax of the request content is correct, but it was unable to
process the contained instructions. For example, this status code process the contained instructions. For example, this status code
can be sent if an XML request content contains well-formed (i.e., can be sent if an XML request content contains well-formed (i.e.,
syntactically correct), but semantically erroneous XML instructions. syntactically correct), but semantically erroneous XML instructions.
15.5.22. 426 Upgrade Required 15.5.22. 426 Upgrade Required
The _426 (Upgrade Required)_ status code indicates that the server The 426 (Upgrade Required) status code indicates that the server
refuses to perform the request using the current protocol but might refuses to perform the request using the current protocol but might
be willing to do so after the client upgrades to a different be willing to do so after the client upgrades to a different
protocol. The server MUST send an Upgrade header field in a 426 protocol. The server MUST send an Upgrade header field in a 426
response to indicate the required protocol(s) (Section 7.8). response to indicate the required protocol(s) (Section 7.8).
Example: Example:
HTTP/1.1 426 Upgrade Required HTTP/1.1 426 Upgrade Required
Upgrade: HTTP/3.0 Upgrade: HTTP/3.0
Connection: Upgrade Connection: Upgrade
Content-Length: 53 Content-Length: 53
Content-Type: text/plain Content-Type: text/plain
This service requires use of the HTTP/3.0 protocol. This service requires use of the HTTP/3.0 protocol.
15.6. Server Error 5xx 15.6. Server Error 5xx
The _5xx (Server Error)_ class of status code indicates that the The 5xx (Server Error) class of status code indicates that the server
server is aware that it has erred or is incapable of performing the is aware that it has erred or is incapable of performing the
requested method. Except when responding to a HEAD request, the requested method. Except when responding to a HEAD request, the
server SHOULD send a representation containing an explanation of the server SHOULD send a representation containing an explanation of the
error situation, and whether it is a temporary or permanent error situation, and whether it is a temporary or permanent
condition. A user agent SHOULD display any included representation condition. A user agent SHOULD display any included representation
to the user. These status codes are applicable to any request to the user. These status codes are applicable to any request
method. method.
15.6.1. 500 Internal Server Error 15.6.1. 500 Internal Server Error
The _500 (Internal Server Error)_ status code indicates that the The 500 (Internal Server Error) status code indicates that the server
server encountered an unexpected condition that prevented it from encountered an unexpected condition that prevented it from fulfilling
fulfilling the request. the request.
15.6.2. 501 Not Implemented 15.6.2. 501 Not Implemented
The _501 (Not Implemented)_ status code indicates that the server The 501 (Not Implemented) status code indicates that the server does
does not support the functionality required to fulfill the request. not support the functionality required to fulfill the request. This
This is the appropriate response when the server does not recognize is the appropriate response when the server does not recognize the
the request method and is not capable of supporting it for any request method and is not capable of supporting it for any resource.
resource.
A 501 response is heuristically cacheable; i.e., unless otherwise A 501 response is heuristically cacheable; i.e., unless otherwise
indicated by the method definition or explicit cache controls (see indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [CACHING]). Section 4.2.2 of [CACHING]).
15.6.3. 502 Bad Gateway 15.6.3. 502 Bad Gateway
The _502 (Bad Gateway)_ status code indicates that the server, while The 502 (Bad Gateway) status code indicates that the server, while
acting as a gateway or proxy, received an invalid response from an acting as a gateway or proxy, received an invalid response from an
inbound server it accessed while attempting to fulfill the request. inbound server it accessed while attempting to fulfill the request.
15.6.4. 503 Service Unavailable 15.6.4. 503 Service Unavailable
The _503 (Service Unavailable)_ status code indicates that the server The 503 (Service Unavailable) status code indicates that the server
is currently unable to handle the request due to a temporary overload is currently unable to handle the request due to a temporary overload
or scheduled maintenance, which will likely be alleviated after some or scheduled maintenance, which will likely be alleviated after some
delay. The server MAY send a Retry-After header field delay. The server MAY send a Retry-After header field
(Section 10.2.3) to suggest an appropriate amount of time for the (Section 10.2.3) to suggest an appropriate amount of time for the
client to wait before retrying the request. client to wait before retrying the request.
| *Note:* The existence of the 503 status code does not imply | *Note:* The existence of the 503 status code does not imply
| that a server has to use it when becoming overloaded. Some | that a server has to use it when becoming overloaded. Some
| servers might simply refuse the connection. | servers might simply refuse the connection.
15.6.5. 504 Gateway Timeout 15.6.5. 504 Gateway Timeout
The _504 (Gateway Timeout)_ status code indicates that the server, The 504 (Gateway Timeout) status code indicates that the server,
while acting as a gateway or proxy, did not receive a timely response while acting as a gateway or proxy, did not receive a timely response
from an upstream server it needed to access in order to complete the from an upstream server it needed to access in order to complete the
request. request.
15.6.6. 505 HTTP Version Not Supported 15.6.6. 505 HTTP Version Not Supported
The _505 (HTTP Version Not Supported)_ status code indicates that the The 505 (HTTP Version Not Supported) status code indicates that the
server does not support, or refuses to support, the major version of server does not support, or refuses to support, the major version of
HTTP that was used in the request message. The server is indicating HTTP that was used in the request message. The server is indicating
that it is unable or unwilling to complete the request using the same that it is unable or unwilling to complete the request using the same
major version as the client, as described in Section 2.5, other than major version as the client, as described in Section 2.5, other than
with this error message. The server SHOULD generate a representation with this error message. The server SHOULD generate a representation
for the 505 response that describes why that version is not supported for the 505 response that describes why that version is not supported
and what other protocols are supported by that server. and what other protocols are supported by that server.
16. Extending HTTP 16. Extending HTTP
skipping to change at line 7905 skipping to change at line 7895
protocol in use does not affect their semantics. protocol in use does not affect their semantics.
Version-independent extensions are discouraged from depending on or Version-independent extensions are discouraged from depending on or
interacting with the specific version of the protocol in use. When interacting with the specific version of the protocol in use. When
this is unavoidable, careful consideration needs to be given to how this is unavoidable, careful consideration needs to be given to how
the extension can interoperate across versions. the extension can interoperate across versions.
Additionally, specific versions of HTTP might have their own Additionally, specific versions of HTTP might have their own
extensibility points, such as transfer-codings in HTTP/1.1 extensibility points, such as transfer-codings in HTTP/1.1
(Section 6.1 of [HTTP/1.1]) and HTTP/2 SETTINGS or frame types (Section 6.1 of [HTTP/1.1]) and HTTP/2 SETTINGS or frame types
[HTTP/2]. These extension points are specific to the version of the ([HTTP/2]). These extension points are specific to the version of
protocol they occur within. the protocol they occur within.
Version-specific extensions cannot override or modify the semantics Version-specific extensions cannot override or modify the semantics
of a version-independent mechanism or extension point (like a method of a version-independent mechanism or extension point (like a method
or header field) without explicitly being allowed by that protocol or header field) without explicitly being allowed by that protocol
element. For example, the CONNECT method (Section 9.3.6) allows element. For example, the CONNECT method (Section 9.3.6) allows
this. this.
These guidelines assure that the protocol operates correctly and These guidelines assure that the protocol operates correctly and
predictably, even when parts of the path implement different versions predictably, even when parts of the path implement different versions
of HTTP. of HTTP.
skipping to change at line 8041 skipping to change at line 8031
explicitly specified. When doing so, it should be noted that not all explicitly specified. When doing so, it should be noted that not all
clients can be expected to consistently apply a larger scope because clients can be expected to consistently apply a larger scope because
they might not understand the new status code. they might not understand the new status code.
The definition of a new final status code ought to specify whether or The definition of a new final status code ought to specify whether or
not it is heuristically cacheable. Note that all final status codes not it is heuristically cacheable. Note that all final status codes
can be cached if the response they occur in has explicit freshness can be cached if the response they occur in has explicit freshness
information; however, those status codes that are defined as being information; however, those status codes that are defined as being
heuristically cacheable are allowed to be cached without explicit heuristically cacheable are allowed to be cached without explicit
freshness information. Likewise, the definition of a status code can freshness information. Likewise, the definition of a status code can
place constraints upon cache behavior if the 'must-understand' cache place constraints upon cache behavior if the must-understand cache
directive is used. See [CACHING] for more information. directive is used. See [CACHING] for more information.
Finally, the definition of a new status code ought to indicate Finally, the definition of a new status code ought to indicate
whether the content has any implied association with an identified whether the content has any implied association with an identified
resource (Section 6.4.2). resource (Section 6.4.2).
16.3. Field Extensibility 16.3. Field Extensibility
HTTP's most widely used extensibility point is the definition of new HTTP's most widely used extensibility point is the definition of new
header and trailer fields. header and trailer fields.
skipping to change at line 8114 skipping to change at line 8104
is not required. is not required.
And optionally: And optionally:
Comments: Additional information, such as about reserved entries. Comments: Additional information, such as about reserved entries.
The expert(s) can define additional fields to be collected in the The expert(s) can define additional fields to be collected in the
registry, in consultation with the community. registry, in consultation with the community.
Standards-defined names have a status of "permanent". Other names Standards-defined names have a status of "permanent". Other names
can also be registered as permanent if the expert(s) find that they can also be registered as permanent if the expert(s) finds that they
are in use, in consultation with the community. Other names should are in use, in consultation with the community. Other names should
be registered as "provisional". be registered as "provisional".
Provisional entries can be removed by the expert(s) if -- in Provisional entries can be removed by the expert(s) if -- in
consultation with the community -- the expert(s) finds that they are consultation with the community -- the expert(s) find that they are
not in use. The expert(s) can change a provisional entry's status to not in use. The expert(s) can change a provisional entry's status to
permanent at any time. permanent at any time.
Note that names can be registered by third parties (including the Note that names can be registered by third parties (including the
expert(s)) if the expert(s) determines that an unregistered name is expert(s)) if the expert(s) determines that an unregistered name is
widely deployed and not likely to be registered in a timely manner widely deployed and not likely to be registered in a timely manner
otherwise. otherwise.
16.3.2. Considerations for New Fields 16.3.2. Considerations for New Fields
HTTP header and trailer fields are widely used extension points for HTTP header and trailer fields are a widely used extension point for
the protocol. While they can be used in an ad hoc fashion, fields the protocol. While they can be used in an ad hoc fashion, fields
that are intended for wider use need to be carefully documented to that are intended for wider use need to be carefully documented to
ensure interoperability. ensure interoperability.
In particular, authors of specifications defining new fields are In particular, authors of specifications defining new fields are
advised to consider and, where appropriate, document the following advised to consider and, where appropriate, document the following
aspects: aspects:
* Under what conditions the field can be used; e.g., only in * Under what conditions the field can be used; e.g., only in
responses or requests, in all messages, only on responses to a responses or requests, in all messages, only on responses to a
skipping to change at line 8319 skipping to change at line 8309
recipients. Furthermore, it's good to describe the policy for recipients. Furthermore, it's good to describe the policy for
defining new parameters (such as "update the specification" or defining new parameters (such as "update the specification" or
"use this registry"). "use this registry").
* Authentication schemes need to document whether they are usable in * Authentication schemes need to document whether they are usable in
origin-server authentication (i.e., using WWW-Authenticate), and/ origin-server authentication (i.e., using WWW-Authenticate), and/
or proxy authentication (i.e., using Proxy-Authenticate). or proxy authentication (i.e., using Proxy-Authenticate).
* The credentials carried in an Authorization header field are * The credentials carried in an Authorization header field are
specific to the user agent and, therefore, have the same effect on specific to the user agent and, therefore, have the same effect on
HTTP caches as the "private" Cache-Control response directive HTTP caches as the "private" cache response directive
(Section 5.2.2.7 of [CACHING]), within the scope of the request in (Section 5.2.2.7 of [CACHING]), within the scope of the request in
which they appear. which they appear.
Therefore, new authentication schemes that choose not to carry Therefore, new authentication schemes that choose not to carry
credentials in the Authorization header field (e.g., using a newly credentials in the Authorization header field (e.g., using a newly
defined header field) will need to explicitly disallow caching, by defined header field) will need to explicitly disallow caching, by
mandating the use of Cache-Control response directives (e.g., mandating the use of cache response directives (e.g., "private").
"private").
* Schemes using Authentication-Info, Proxy-Authentication-Info, or * Schemes using Authentication-Info, Proxy-Authentication-Info, or
any other authentication related response header field need to any other authentication related response header field need to
consider and document the related security considerations (see consider and document the related security considerations (see
Section 17.16.4). Section 17.16.4).
16.5. Range Unit Extensibility 16.5. Range Unit Extensibility
16.5.1. Range Unit Registry 16.5.1. Range Unit Registry
skipping to change at line 8453 skipping to change at line 8442
applications (code behind the HTTP interface), securing user agent applications (code behind the HTTP interface), securing user agent
processing of content received via HTTP, or secure use of the processing of content received via HTTP, or secure use of the
Internet in general, rather than security of the protocol. The Internet in general, rather than security of the protocol. The
security considerations for URIs, which are fundamental to HTTP security considerations for URIs, which are fundamental to HTTP
operation, are discussed in Section 7 of [URI]. Various operation, are discussed in Section 7 of [URI]. Various
organizations maintain topical information and links to current organizations maintain topical information and links to current
research on Web application security (e.g., [OWASP]). research on Web application security (e.g., [OWASP]).
17.1. Establishing Authority 17.1. Establishing Authority
HTTP relies on the notion of an _authoritative response_: a response HTTP relies on the notion of an "authoritative response": a response
that has been determined by (or at the direction of) the origin that has been determined by (or at the direction of) the origin
server identified within the target URI to be the most appropriate server identified within the target URI to be the most appropriate
response for that request given the state of the target resource at response for that request given the state of the target resource at
the time of response message origination. the time of response message origination.
When a registered name is used in the authority component, the "http" When a registered name is used in the authority component, the "http"
URI scheme (Section 4.2.1) relies on the user's local name resolution URI scheme (Section 4.2.1) relies on the user's local name resolution
service to determine where it can find authoritative responses. This service to determine where it can find authoritative responses. This
means that any attack on a user's network host table, cached names, means that any attack on a user's network host table, cached names,
or name resolution libraries becomes an avenue for attack on or name resolution libraries becomes an avenue for attack on
skipping to change at line 8495 skipping to change at line 8484
extensions; for example, [ALTSVC]. Likewise, the set of servers for extensions; for example, [ALTSVC]. Likewise, the set of servers for
which a connection is considered authoritative can be changed with a which a connection is considered authoritative can be changed with a
protocol extension like [RFC8336]. protocol extension like [RFC8336].
Providing a response from a non-authoritative source, such as a Providing a response from a non-authoritative source, such as a
shared proxy cache, is often useful to improve performance and shared proxy cache, is often useful to improve performance and
availability, but only to the extent that the source can be trusted availability, but only to the extent that the source can be trusted
or the distrusted response can be safely used. or the distrusted response can be safely used.
Unfortunately, communicating authority to users can be difficult. Unfortunately, communicating authority to users can be difficult.
For example, _phishing_ is an attack on the user's perception of For example, "phishing" is an attack on the user's perception of
authority, where that perception can be misled by presenting similar authority, where that perception can be misled by presenting similar
branding in hypertext, possibly aided by userinfo obfuscating the branding in hypertext, possibly aided by userinfo obfuscating the
authority component (see Section 4.2.1). User agents can reduce the authority component (see Section 4.2.1). User agents can reduce the
impact of phishing attacks by enabling users to easily inspect a impact of phishing attacks by enabling users to easily inspect a
target URI prior to making an action, by prominently distinguishing target URI prior to making an action, by prominently distinguishing
(or rejecting) userinfo when present, and by not sending stored (or rejecting) userinfo when present, and by not sending stored
credentials and cookies when the referring document is from an credentials and cookies when the referring document is from an
unknown or untrusted source. unknown or untrusted source.
17.2. Risks of Intermediaries 17.2. Risks of Intermediaries
skipping to change at line 8627 skipping to change at line 8616
HTTP messages can be compressed in a number of ways, including using HTTP messages can be compressed in a number of ways, including using
TLS compression, content codings, transfer codings, and other TLS compression, content codings, transfer codings, and other
extension or version-specific mechanisms. extension or version-specific mechanisms.
The most effective mitigation for this risk is to disable compression The most effective mitigation for this risk is to disable compression
on sensitive data, or to strictly separate sensitive data from on sensitive data, or to strictly separate sensitive data from
attacker-controlled data so that they cannot share the same attacker-controlled data so that they cannot share the same
compression dictionary. With careful design, a compression scheme compression dictionary. With careful design, a compression scheme
can be designed in a way that is not considered exploitable in can be designed in a way that is not considered exploitable in
limited use cases, such as HPACK [HPACK]. limited use cases, such as HPACK ([HPACK]).
17.7. Disclosure of Personal Information 17.7. Disclosure of Personal Information
Clients are often privy to large amounts of personal information, Clients are often privy to large amounts of personal information,
including both information provided by the user to interact with including both information provided by the user to interact with
resources (e.g., the user's name, location, mail address, passwords, resources (e.g., the user's name, location, mail address, passwords,
encryption keys, etc.) and information about the user's browsing encryption keys, etc.) and information about the user's browsing
activity over time (e.g., history, bookmarks, etc.). Implementations activity over time (e.g., history, bookmarks, etc.). Implementations
need to prevent unintentional disclosure of personal information. need to prevent unintentional disclosure of personal information.
skipping to change at line 8777 skipping to change at line 8766
17.13. Browser Fingerprinting 17.13. Browser Fingerprinting
Browser fingerprinting is a set of techniques for identifying a Browser fingerprinting is a set of techniques for identifying a
specific user agent over time through its unique set of specific user agent over time through its unique set of
characteristics. These characteristics might include information characteristics. These characteristics might include information
related to how it uses the underlying transport protocol, feature related to how it uses the underlying transport protocol, feature
capabilities, and scripting environment, though of particular capabilities, and scripting environment, though of particular
interest here is the set of unique characteristics that might be interest here is the set of unique characteristics that might be
communicated via HTTP. Fingerprinting is considered a privacy communicated via HTTP. Fingerprinting is considered a privacy
concern because it enables tracking of a user agent's behavior over concern because it enables tracking of a user agent's behavior over
time [Bujlow] without the corresponding controls that the user might time ([Bujlow]) without the corresponding controls that the user
have over other forms of data collection (e.g., cookies). Many might have over other forms of data collection (e.g., cookies). Many
general-purpose user agents (i.e., Web browsers) have taken steps to general-purpose user agents (i.e., Web browsers) have taken steps to
reduce their fingerprints. reduce their fingerprints.
There are a number of request header fields that might reveal There are a number of request header fields that might reveal
information to servers that is sufficiently unique to enable information to servers that is sufficiently unique to enable
fingerprinting. The From header field is the most obvious, though it fingerprinting. The From header field is the most obvious, though it
is expected that From will only be sent when self-identification is is expected that From will only be sent when self-identification is
desired by the user. Likewise, Cookie header fields are deliberately desired by the user. Likewise, Cookie header fields are deliberately
designed to enable re-identification, so fingerprinting concerns only designed to enable re-identification, so fingerprinting concerns only
apply to situations where cookies are disabled or restricted by the apply to situations where cookies are disabled or restricted by the
skipping to change at line 8942 skipping to change at line 8931
channel can affect security and privacy. The presence of the channel can affect security and privacy. The presence of the
Authentication-Info and Proxy-Authentication-Info header fields alone Authentication-Info and Proxy-Authentication-Info header fields alone
indicates that HTTP authentication is in use. Additional information indicates that HTTP authentication is in use. Additional information
could be exposed by the contents of the authentication-scheme could be exposed by the contents of the authentication-scheme
specific parameters; this will have to be considered in the specific parameters; this will have to be considered in the
definitions of these schemes. definitions of these schemes.
18. IANA Considerations 18. IANA Considerations
The change controller for the following registrations is: "IETF The change controller for the following registrations is: "IETF
(iesg@ietf.org) -- Internet Engineering Task Force". (iesg@ietf.org) - Internet Engineering Task Force".
18.1. URI Scheme Registration 18.1. URI Scheme Registration
IANA has updated the "Uniform Resource Identifier (URI) Schemes" IANA has updated the "Uniform Resource Identifier (URI) Schemes"
registry [BCP35] at <https://www.iana.org/assignments/uri-schemes/> registry [BCP35] at <https://www.iana.org/assignments/uri-schemes/>
with the permanent schemes listed in Table 2 in Section 4.2. with the permanent schemes listed in Table 2 in Section 4.2.
18.2. Method Registration 18.2. Method Registration
IANA has updated the "Hypertext Transfer Protocol (HTTP) Method IANA has updated the "Hypertext Transfer Protocol (HTTP) Method
skipping to change at line 9102 skipping to change at line 9091
This specification updates the HTTP-related aspects of the existing This specification updates the HTTP-related aspects of the existing
registration procedures for message header fields defined in registration procedures for message header fields defined in
[RFC3864]. It replaces the old procedures as they relate to HTTP by [RFC3864]. It replaces the old procedures as they relate to HTTP by
defining a new registration procedure and moving HTTP field defining a new registration procedure and moving HTTP field
definitions into a separate registry. definitions into a separate registry.
IANA has created a new registry titled "Hypertext Transfer Protocol IANA has created a new registry titled "Hypertext Transfer Protocol
(HTTP) Field Name Registry" as outlined in Section 16.3.1. (HTTP) Field Name Registry" as outlined in Section 16.3.1.
IANA has moved all entries in the "Permanent Message Header Field IANA has moved all entries in the "Permanent Message Header Field
Names" and "Provisional Message Header Field Names" registries with Names" and "Provisional Message Header Field Names" registries (see
the protocol 'http' to this registry and has applied the following <https://www.iana.org/assignments/message-headers/>) with the
protocol 'http' to this registry and has applied the following
changes: changes:
1. The 'Applicable Protocol' field has been omitted. 1. The 'Applicable Protocol' field has been omitted.
2. Entries that had a status of 'standard', 'experimental', 2. Entries that had a status of 'standard', 'experimental',
'reserved', or 'informational' have been made to have a status of 'reserved', or 'informational' have been made to have a status of
'permanent'. 'permanent'.
3. Provisional entries without a status have been made to have a 3. Provisional entries without a status have been made to have a
status of 'provisional'. status of 'provisional'.
skipping to change at line 9126 skipping to change at line 9116
registration document did not define one) have been made to have registration document did not define one) have been made to have
a status of 'provisional'. The expert(s) can choose to update a status of 'provisional'. The expert(s) can choose to update
the entries' status if there is evidence that another is more the entries' status if there is evidence that another is more
appropriate. appropriate.
IANA has annotated the "Permanent Message Header Field Names" and IANA has annotated the "Permanent Message Header Field Names" and
"Provisional Message Header Field Names" registries with the "Provisional Message Header Field Names" registries with the
following note to indicate that HTTP field name registrations have following note to indicate that HTTP field name registrations have
moved: moved:
| *Note* HTTP field name registrations have been moved to | *Note*
|
| HTTP field name registrations have been moved to
| [https://www.iana.org/assignments/http-fields] per [RFC9110]. | [https://www.iana.org/assignments/http-fields] per [RFC9110].
IANA has updated the "Hypertext Transfer Protocol (HTTP) Field Name IANA has updated the "Hypertext Transfer Protocol (HTTP) Field Name
Registry" with the field names listed in the following table. Registry" with the field names listed in the following table.
+===========================+============+========+============+ +===========================+============+========+============+
| Field Name | Status | Ref. | Comments | | Field Name | Status | Ref. | Comments |
+===========================+============+========+============+ +===========================+============+========+============+
| Accept | standard | 12.5.1 | | | Accept | permanent | 12.5.1 | |
+---------------------------+------------+--------+------------+ +---------------------------+------------+--------+------------+
| Accept-Charset | deprecated | 12.5.2 | | | Accept-Charset | deprecated | 12.5.2 | |
+---------------------------+------------+--------+------------+ +---------------------------+------------+--------+------------+
| Accept-Encoding | standard | 12.5.3 | | | Accept-Encoding | permanent | 12.5.3 | |
+---------------------------+------------+--------+------------+ +---------------------------+------------+--------+------------+
| Accept-Language | standard | 12.5.4 | | | Accept-Language | permanent | 12.5.4 | |
+---------------------------+------------+--------+------------+ +---------------------------+------------+--------+------------+
| Accept-Ranges | standard | 14.3 | | | Accept-Ranges | permanent | 14.3 | |
+---------------------------+------------+--------+------------+ +---------------------------+------------+--------+------------+
| Allow | standard | 10.2.1 | | | Allow | permanent | 10.2.1 | |
+---------------------------+------------+--------+------------+ +---------------------------+------------+--------+------------+
| Authentication-Info | standard | 11.6.3 | | | Authentication-Info | permanent | 11.6.3 | |
+---------------------------+------------+--------+------------+ +---------------------------+------------+--------+------------+
| Authorization | standard | 11.6.2 | | | Authorization | permanent | 11.6.2 | |
+---------------------------+------------+--------+------------+ +---------------------------+------------+--------+------------+
| Connection | standard | 7.6.1 | | | Connection | permanent | 7.6.1 | |
+---------------------------+------------+--------+------------+ +---------------------------+------------+--------+------------+
| Content-Encoding | standard | 8.4 | | | Content-Encoding | permanent | 8.4 | |
+---------------------------+------------+--------+------------+ +---------------------------+------------+--------+------------+
| Content-Language | standard | 8.5 | | | Content-Language | permanent | 8.5 | |
+---------------------------+------------+--------+------------+ +---------------------------+------------+--------+------------+
| Content-Length | standard | 8.6 | | | Content-Length | permanent | 8.6 | |
+---------------------------+------------+--------+------------+ +---------------------------+------------+--------+------------+
| Content-Location | standard | 8.7 | | | Content-Location | permanent | 8.7 | |
+---------------------------+------------+--------+------------+ +---------------------------+------------+--------+------------+
| Content-Range | standard | 14.4 | | | Content-Range | permanent | 14.4 | |
+---------------------------+------------+--------+------------+ +---------------------------+------------+--------+------------+
| Content-Type | standard | 8.3 | | | Content-Type | permanent | 8.3 | |
+---------------------------+------------+--------+------------+ +---------------------------+------------+--------+------------+
| Date | standard | 6.6.1 | | | Date | permanent | 6.6.1 | |
+---------------------------+------------+--------+------------+ +---------------------------+------------+--------+------------+
| ETag | standard | 8.8.3 | | | ETag | permanent | 8.8.3 | |
+---------------------------+------------+--------+------------+ +---------------------------+------------+--------+------------+
| Expect | standard | 10.1.1 | | | Expect | permanent | 10.1.1 | |
+---------------------------+------------+--------+------------+ +---------------------------+------------+--------+------------+
| From | standard | 10.1.2 | | | From | permanent | 10.1.2 | |
+---------------------------+------------+--------+------------+ +---------------------------+------------+--------+------------+
| Host | standard | 7.2 | | | Host | permanent | 7.2 | |
+---------------------------+------------+--------+------------+ +---------------------------+------------+--------+------------+
| If-Match | standard | 13.1.1 | | | If-Match | permanent | 13.1.1 | |
+---------------------------+------------+--------+------------+ +---------------------------+------------+--------+------------+
| If-Modified-Since | standard | 13.1.3 | | | If-Modified-Since | permanent | 13.1.3 | |
+---------------------------+------------+--------+------------+ +---------------------------+------------+--------+------------+
| If-None-Match | standard | 13.1.2 | | | If-None-Match | permanent | 13.1.2 | |
+---------------------------+------------+--------+------------+ +---------------------------+------------+--------+------------+
| If-Range | standard | 13.1.5 | | | If-Range | permanent | 13.1.5 | |
+---------------------------+------------+--------+------------+ +---------------------------+------------+--------+------------+
| If-Unmodified-Since | standard | 13.1.4 | | | If-Unmodified-Since | permanent | 13.1.4 | |
+---------------------------+------------+--------+------------+ +---------------------------+------------+--------+------------+
| Last-Modified | standard | 8.8.2 | | | Last-Modified | permanent | 8.8.2 | |
+---------------------------+------------+--------+------------+ +---------------------------+------------+--------+------------+
| Location | standard | 10.2.2 | | | Location | permanent | 10.2.2 | |
+---------------------------+------------+--------+------------+ +---------------------------+------------+--------+------------+
| Max-Forwards | standard | 7.6.2 | | | Max-Forwards | permanent | 7.6.2 | |
+---------------------------+------------+--------+------------+ +---------------------------+------------+--------+------------+
| Proxy-Authenticate | standard | 11.7.1 | | | Proxy-Authenticate | permanent | 11.7.1 | |
+---------------------------+------------+--------+------------+ +---------------------------+------------+--------+------------+
| Proxy-Authentication-Info | standard | 11.7.3 | | | Proxy-Authentication-Info | permanent | 11.7.3 | |
+---------------------------+------------+--------+------------+ +---------------------------+------------+--------+------------+
| Proxy-Authorization | standard | 11.7.2 | | | Proxy-Authorization | permanent | 11.7.2 | |
+---------------------------+------------+--------+------------+ +---------------------------+------------+--------+------------+
| Range | standard | 14.2 | | | Range | permanent | 14.2 | |
+---------------------------+------------+--------+------------+ +---------------------------+------------+--------+------------+
| Referer | standard | 10.1.3 | | | Referer | permanent | 10.1.3 | |
+---------------------------+------------+--------+------------+ +---------------------------+------------+--------+------------+
| Retry-After | standard | 10.2.3 | | | Retry-After | permanent | 10.2.3 | |
+---------------------------+------------+--------+------------+ +---------------------------+------------+--------+------------+
| Server | standard | 10.2.4 | | | Server | permanent | 10.2.4 | |
+---------------------------+------------+--------+------------+ +---------------------------+------------+--------+------------+
| TE | standard | 10.1.4 | | | TE | permanent | 10.1.4 | |
+---------------------------+------------+--------+------------+ +---------------------------+------------+--------+------------+
| Trailer | standard | 6.6.2 | | | Trailer | permanent | 6.6.2 | |
+---------------------------+------------+--------+------------+ +---------------------------+------------+--------+------------+
| Upgrade | standard | 7.8 | | | Upgrade | permanent | 7.8 | |
+---------------------------+------------+--------+------------+ +---------------------------+------------+--------+------------+
| User-Agent | standard | 10.1.5 | | | User-Agent | permanent | 10.1.5 | |
+---------------------------+------------+--------+------------+ +---------------------------+------------+--------+------------+
| Vary | standard | 12.5.5 | | | Vary | permanent | 12.5.5 | |
+---------------------------+------------+--------+------------+ +---------------------------+------------+--------+------------+
| Via | standard | 7.6.3 | | | Via | permanent | 7.6.3 | |
+---------------------------+------------+--------+------------+ +---------------------------+------------+--------+------------+
| WWW-Authenticate | standard | 11.6.1 | | | WWW-Authenticate | permanent | 11.6.1 | |
+---------------------------+------------+--------+------------+ +---------------------------+------------+--------+------------+
| * | standard | 12.5.5 | (reserved) | | * | permanent | 12.5.5 | (reserved) |
+---------------------------+------------+--------+------------+ +---------------------------+------------+--------+------------+
Table 9 Table 9
The field name "*" is reserved because using that name as an HTTP The field name "*" is reserved because using that name as an HTTP
header field might conflict with its special semantics in the Vary header field might conflict with its special semantics in the Vary
header field (Section 12.5.5). header field (Section 12.5.5).
IANA has updated the "Content-MD5" entry in the new registry to have IANA has updated the "Content-MD5" entry in the new registry to have
a status of 'obsoleted' with references to Section 14.15 of [RFC2616] a status of 'obsoleted' with references to Section 14.15 of [RFC2616]
skipping to change at line 9328 skipping to change at line 9320
+------+-------------------+-------------------------+------+ +------+-------------------+-------------------------+------+
Table 12 Table 12
19. References 19. References
19.1. Normative References 19.1. Normative References
[CACHING] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [CACHING] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Caching", RFC 9111, DOI 10.17487/RFC9111, Ed., "HTTP Caching", RFC 9111, DOI 10.17487/RFC9111,
December 2021, <https://www.rfc-editor.org/info/rfc9111>. February 2022, <https://www.rfc-editor.org/info/rfc9111>.
[RFC1950] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data Format [RFC1950] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data Format
Specification version 3.3", RFC 1950, Specification version 3.3", RFC 1950,
DOI 10.17487/RFC1950, May 1996, DOI 10.17487/RFC1950, May 1996,
<https://www.rfc-editor.org/info/rfc1950>. <https://www.rfc-editor.org/info/rfc1950>.
[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification
version 1.3", RFC 1951, DOI 10.17487/RFC1951, May 1996, version 1.3", RFC 1951, DOI 10.17487/RFC1951, May 1996,
<https://www.rfc-editor.org/info/rfc1951>. <https://www.rfc-editor.org/info/rfc1951>.
skipping to change at line 9428 skipping to change at line 9420
Compression", IEEE Computer 17(6), Compression", IEEE Computer 17(6),
DOI 10.1109/MC.1984.1659158, June 1984, DOI 10.1109/MC.1984.1659158, June 1984,
<https://ieeexplore.ieee.org/document/1659158/>. <https://ieeexplore.ieee.org/document/1659158/>.
19.2. Informative References 19.2. Informative References
[ALTSVC] Nottingham, M., McManus, P., and J. Reschke, "HTTP [ALTSVC] Nottingham, M., McManus, P., and J. Reschke, "HTTP
Alternative Services", RFC 7838, DOI 10.17487/RFC7838, Alternative Services", RFC 7838, DOI 10.17487/RFC7838,
April 2016, <https://www.rfc-editor.org/info/rfc7838>. April 2016, <https://www.rfc-editor.org/info/rfc7838>.
[BCP13] Freed, N., Klensin, J., and T. Hansen, "Media Type [BCP13] Freed, N. and J. Klensin, "Multipurpose Internet Mail
Extensions (MIME) Part Four: Registration Procedures",
BCP 13, RFC 4289, December 2005.
Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13, Specifications and Registration Procedures", BCP 13,
RFC 6838, January 2013, RFC 6838, January 2013.
<https://www.rfc-editor.org/info/bcp13>.
<https://www.rfc-editor.org/info/bcp13>
[BCP178] Saint-Andre, P., Crocker, D., and M. Nottingham, [BCP178] Saint-Andre, P., Crocker, D., and M. Nottingham,
"Deprecating the "X-" Prefix and Similar Constructs in "Deprecating the "X-" Prefix and Similar Constructs in
Application Protocols", BCP 178, RFC 6648, June 2012. Application Protocols", BCP 178, RFC 6648, June 2012.
<https://www.rfc-editor.org/info/bcp178> <https://www.rfc-editor.org/info/bcp178>
[BCP35] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines [BCP35] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines
and Registration Procedures for URI Schemes", BCP 35, and Registration Procedures for URI Schemes", BCP 35,
RFC 7595, June 2015. RFC 7595, June 2015.
skipping to change at line 9484 skipping to change at line 9481
[HPACK] Peon, R. and H. Ruellan, "HPACK: Header Compression for [HPACK] Peon, R. and H. Ruellan, "HPACK: Header Compression for
HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015, HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015,
<https://www.rfc-editor.org/info/rfc7541>. <https://www.rfc-editor.org/info/rfc7541>.
[HTTP/1.0] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext [HTTP/1.0] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext
Transfer Protocol -- HTTP/1.0", RFC 1945, Transfer Protocol -- HTTP/1.0", RFC 1945,
DOI 10.17487/RFC1945, May 1996, DOI 10.17487/RFC1945, May 1996,
<https://www.rfc-editor.org/info/rfc1945>. <https://www.rfc-editor.org/info/rfc1945>.
[HTTP/1.1] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [HTTP/1.1] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP/1.1", RFC 9112, DOI 10.17487/RFC9112, December Ed., "HTTP/1.1", RFC 9112, DOI 10.17487/RFC9112, February
2021, <https://www.rfc-editor.org/info/rfc9112>. 2022, <https://www.rfc-editor.org/info/rfc9112>.
[HTTP/2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext [HTTP/2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540, Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015, DOI 10.17487/RFC7540, May 2015,
<https://www.rfc-editor.org/info/rfc7540>. <https://www.rfc-editor.org/info/rfc7540>.
[HTTP/3] Bishop, M., Ed., "Hypertext Transfer Protocol Version 3 [HTTP/3] Bishop, M., Ed., "Hypertext Transfer Protocol Version 3
(HTTP/3)", RFC 9113, DOI 10.17487/RFC9113, December 2021, (HTTP/3)", RFC 9114, DOI 10.17487/RFC9114, February 2022,
<https://www.rfc-editor.org/info/rfc9113>. <https://www.rfc-editor.org/info/rfc9114>.
[ISO-8859-1] [ISO-8859-1]
International Organization for Standardization, International Organization for Standardization,
"Information technology -- 8-bit single-byte coded graphic "Information technology -- 8-bit single-byte coded graphic
character sets -- Part 1: Latin alphabet No. 1", ISO/ character sets -- Part 1: Latin alphabet No. 1", ISO/
IEC 8859-1:1998, 1998. IEC 8859-1:1998, 1998.
[Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and [Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and
Politics", ACM Transactions on Internet Technology 1(2), Politics", ACM Transactions on Internet Technology 1(2),
November 2001, <http://arxiv.org/abs/cs.SE/0105018>. November 2001, <http://arxiv.org/abs/cs.SE/0105018>.
skipping to change at line 9540 skipping to change at line 9537
[RFC2145] Mogul, J. C., Fielding, R., Gettys, J., and H. Frystyk, [RFC2145] Mogul, J. C., Fielding, R., Gettys, J., and H. Frystyk,
"Use and Interpretation of HTTP Version Numbers", "Use and Interpretation of HTTP Version Numbers",
RFC 2145, DOI 10.17487/RFC2145, May 1997, RFC 2145, DOI 10.17487/RFC2145, May 1997,
<https://www.rfc-editor.org/info/rfc2145>. <https://www.rfc-editor.org/info/rfc2145>.
[RFC2295] Holtman, K. and A. Mutz, "Transparent Content Negotiation [RFC2295] Holtman, K. and A. Mutz, "Transparent Content Negotiation
in HTTP", RFC 2295, DOI 10.17487/RFC2295, March 1998, in HTTP", RFC 2295, DOI 10.17487/RFC2295, March 1998,
<https://www.rfc-editor.org/info/rfc2295>. <https://www.rfc-editor.org/info/rfc2295>.
[RFC2324] Masinter, L., "Hyper Text Coffee Pot Control Protocol [RFC2324] Masinter, L., "Hyper Text Coffee Pot Control Protocol
(HTCPCP/1.0)", RFC 2324, DOI 10.17487/RFC2324, April 1998, (HTCPCP/1.0)", RFC 2324, DOI 10.17487/RFC2324, 1 April
<https://www.rfc-editor.org/info/rfc2324>. 1998, <https://www.rfc-editor.org/info/rfc2324>.
[RFC2557] Palme, J., Hopmann, A., and N. Shelness, "MIME [RFC2557] Palme, J., Hopmann, A., and N. Shelness, "MIME
Encapsulation of Aggregate Documents, such as HTML Encapsulation of Aggregate Documents, such as HTML
(MHTML)", RFC 2557, DOI 10.17487/RFC2557, March 1999, (MHTML)", RFC 2557, DOI 10.17487/RFC2557, March 1999,
<https://www.rfc-editor.org/info/rfc2557>. <https://www.rfc-editor.org/info/rfc2557>.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, Transfer Protocol -- HTTP/1.1", RFC 2616,
DOI 10.17487/RFC2616, June 1999, DOI 10.17487/RFC2616, June 1999,
skipping to change at line 9951 skipping to change at line 9948
None. None.
B.2. Changes from RFC 7230 B.2. Changes from RFC 7230
The sections introducing HTTP's design goals, history, architecture, The sections introducing HTTP's design goals, history, architecture,
conformance criteria, protocol versioning, URIs, message routing, and conformance criteria, protocol versioning, URIs, message routing, and
header fields have been moved here. header fields have been moved here.
The requirement on semantic conformance has been replaced with The requirement on semantic conformance has been replaced with
permission to ignore or work around implementation-specific failures permission to ignore or work around implementation-specific failures.
(Section 2.2). (Section 2.2)
The description of an origin and authoritative access to origin The description of an origin and authoritative access to origin
servers has been extended for both "http" and "https" URIs to account servers has been extended for both "http" and "https" URIs to account
for alternative services and secured connections that are not for alternative services and secured connections that are not
necessarily based on TCP (Sections 4.2.1, 4.2.2, 4.3.1, and 7.3.3). necessarily based on TCP. (Sections 4.2.1, 4.2.2, 4.3.1, and 7.3.3)
Explicit requirements have been added to check the target URI Explicit requirements have been added to check the target URI
scheme's semantics and reject requests that don't meet any associated scheme's semantics and reject requests that don't meet any associated
requirements (Section 7.4). requirements. (Section 7.4)
Parameters in media type, media range, and expectation can be empty Parameters in media type, media range, and expectation can be empty
via one or more trailing semicolons (Section 5.6.6). via one or more trailing semicolons. (Section 5.6.6)
"Field value" now refers to the value after multiple field lines are "Field value" now refers to the value after multiple field lines are
combined with commas -- by far the most common use. To refer to a combined with commas -- by far the most common use. To refer to a
single header line's value, use "field line value" (Section 6.3). single header line's value, use "field line value". (Section 6.3)
Trailer field semantics now transcend the specifics of chunked Trailer field semantics now transcend the specifics of chunked
encoding. The use of trailer fields has been further limited to encoding. The use of trailer fields has been further limited to
allow generation as a trailer field only when the sender knows the allow generation as a trailer field only when the sender knows the
field defines that usage and to allow merging into the header section field defines that usage and to allow merging into the header section
only if the recipient knows the corresponding field definition only if the recipient knows the corresponding field definition
permits and defines how to merge. In all other cases, permits and defines how to merge. In all other cases,
implementations are encouraged either to store the trailer fields implementations are encouraged either to store the trailer fields
separately or to discard them instead of merging (Section 6.5.1). separately or to discard them instead of merging. (Section 6.5.1)
The priority of the absolute form of the request URI over the Host The priority of the absolute form of the request URI over the Host
header field by origin servers has been made explicit to align with header field by origin servers has been made explicit to align with
proxy handling (Section 7.2). proxy handling. (Section 7.2)
The grammar definition for the Via field's "received-by" was expanded The grammar definition for the Via field's "received-by" was expanded
in RFC 7230 due to changes in the URI grammar for host [URI] that are in RFC 7230 due to changes in the URI grammar for host [URI] that are
not desirable for Via. For simplicity, we have removed uri-host from not desirable for Via. For simplicity, we have removed uri-host from
the received-by production because it can be encompassed by the the received-by production because it can be encompassed by the
existing grammar for pseudonym. In particular, this change removed existing grammar for pseudonym. In particular, this change removed
comma from the allowed set of characters for a host name in received- comma from the allowed set of characters for a host name in received-
by (Section 7.6.3). by. (Section 7.6.3)
B.3. Changes from RFC 7231 B.3. Changes from RFC 7231
Minimum URI lengths to be supported by implementations are now Minimum URI lengths to be supported by implementations are now
recommended (Section 3.1). recommended. (Section 3.1)
The following have been clarified: CR and NUL in field values are to The following have been clarified: CR and NUL in field values are to
be rejected or mapped to SP, and leading and trailing whitespaces be rejected or mapped to SP, and leading and trailing whitespace
need to be stripped from field values before they are consumed needs to be stripped from field values before they are consumed.
(Section 5.5). (Section 5.5)
Parameters in media type, media range, and expectation can be empty Parameters in media type, media range, and expectation can be empty
via one or more trailing semicolons (Section 5.6.6). via one or more trailing semicolons. (Section 5.6.6)
An abstract data type for HTTP messages has been introduced to define An abstract data type for HTTP messages has been introduced to define
the components of a message and their semantics as an abstraction the components of a message and their semantics as an abstraction
across multiple HTTP versions, rather than in terms of the specific across multiple HTTP versions, rather than in terms of the specific
syntax form of HTTP/1.1 in [HTTP/1.1], and reflect the contents after syntax form of HTTP/1.1 in [HTTP/1.1], and reflect the contents after
the message is parsed. This makes it easier to distinguish between the message is parsed. This makes it easier to distinguish between
requirements on the content (what is conveyed) versus requirements on requirements on the content (what is conveyed) versus requirements on
the messaging syntax (how it is conveyed) and avoids baking the messaging syntax (how it is conveyed) and avoids baking
limitations of early protocol versions into the future of HTTP limitations of early protocol versions into the future of HTTP.
(Section 6). (Section 6)
The terms "payload" and "payload body" have been replaced with The terms "payload" and "payload body" have been replaced with
"content", to better align with its usage elsewhere (e.g., in field "content", to better align with its usage elsewhere (e.g., in field
names) and to avoid confusion with frame payloads in HTTP/2 and names) and to avoid confusion with frame payloads in HTTP/2 and
HTTP/3 (Section 6.4). HTTP/3. (Section 6.4)
The term "effective request URI" has been replaced with "target URI" The term "effective request URI" has been replaced with "target URI".
(Section 7.1). (Section 7.1)
Restrictions on client retries have been loosened to reflect Restrictions on client retries have been loosened to reflect
implementation behavior (Section 9.2.2). implementation behavior. (Section 9.2.2)
The fact that request bodies on GET, HEAD, and DELETE are not The fact that request bodies on GET, HEAD, and DELETE are not
interoperable has been clarified (Sections 9.3.1, 9.3.2, and 9.3.5). interoperable has been clarified. (Sections 9.3.1, 9.3.2, and 9.3.5)
The use of the Content-Range header field (Section 14.4) as a request The use of the Content-Range header field (Section 14.4) as a request
modifier on PUT is allowed (Section 9.3.4). modifier on PUT is allowed. (Section 9.3.4)
A superfluous requirement about setting Content-Length has been A superfluous requirement about setting Content-Length has been
removed from the description of the OPTIONS method (Section 9.3.7). removed from the description of the OPTIONS method. (Section 9.3.7)
The normative requirement to use the "message/http" media type in The normative requirement to use the "message/http" media type in
TRACE responses has been removed (Section 9.3.8). TRACE responses has been removed. (Section 9.3.8)
List-based grammar for Expect has been restored for compatibility List-based grammar for Expect has been restored for compatibility
with RFC 2616 (Section 10.1.1). with RFC 2616. (Section 10.1.1)
Accept and Accept-Encoding are allowed in response messages; the Accept and Accept-Encoding are allowed in response messages; the
latter was introduced by [RFC7694] (Section 12.3). latter was introduced by [RFC7694]. (Section 12.3)
"Accept Parameters" (accept-params and accept-ext ABNF production) "Accept Parameters" (accept-params and accept-ext ABNF production)
have been removed from the definition of the Accept field have been removed from the definition of the Accept field.
(Section 12.5.1). (Section 12.5.1)
The Accept-Charset field now is deprecated (Section 12.5.2). The Accept-Charset field is now deprecated. (Section 12.5.2)
The semantics of "*" in the Vary header field when other values are The semantics of "*" in the Vary header field when other values are
present was clarified (Section 12.5.5). present was clarified. (Section 12.5.5)
Range units are compared in a case-insensitive fashion Range units are compared in a case-insensitive fashion.
(Section 14.1). (Section 14.1)
The use of the Accept-Ranges field is not restricted to origin The use of the Accept-Ranges field is not restricted to origin
servers (Section 14.3). servers. (Section 14.3)
The process of creating a redirected request has been clarified The process of creating a redirected request has been clarified.
(Section 15.4). (Section 15.4)
Status code 308 (previously defined in [RFC7538]) has been added so Status code 308 (previously defined in [RFC7538]) has been added so
that it's defined closer to status codes 301, 302, and 307 that it's defined closer to status codes 301, 302, and 307.
(Section 15.4.9). (Section 15.4.9)
Status code 421 (previously defined in Section 9.1.2 of [HTTP/2]) has Status code 421 (previously defined in Section 9.1.2 of [HTTP/2]) has
been added because of its general applicability. 421 is no longer been added because of its general applicability. 421 is no longer
defined as heuristically cacheable since the response is specific to defined as heuristically cacheable since the response is specific to
the connection (not the target resource) (Section 15.5.20). the connection (not the target resource). (Section 15.5.20)
Status code 422 (previously defined in Section 11.2 of [WEBDAV]) has Status code 422 (previously defined in Section 11.2 of [WEBDAV]) has
been added because of its general applicability (Section 15.5.21). been added because of its general applicability. (Section 15.5.21)
B.4. Changes from RFC 7232 B.4. Changes from RFC 7232
Previous revisions of HTTP imposed an arbitrary 60-second limit on Previous revisions of HTTP imposed an arbitrary 60-second limit on
the determination of whether Last-Modified was a strong validator to the determination of whether Last-Modified was a strong validator to
guard against the possibility that the Date and Last-Modified values guard against the possibility that the Date and Last-Modified values
are generated from different clocks or at somewhat different times are generated from different clocks or at somewhat different times
during the preparation of the response. This specification has during the preparation of the response. This specification has
relaxed that to allow reasonable discretion (Section 8.8.2.2). relaxed that to allow reasonable discretion. (Section 8.8.2.2)
Removed edge-case requirement on If-Match and If-Unmodified-Since Removed edge-case requirement on If-Match and If-Unmodified-Since
that a validator not be sent in a 2xx response when validation fails that a validator not be sent in a 2xx response when validation fails
and the server decides that the same change request has already been and the server decides that the same change request has already been
applied (Sections 13.1.1 and 13.1.4). applied. (Sections 13.1.1 and 13.1.4)
The fact that If-Unmodified-Since does not apply to a resource The fact that If-Unmodified-Since does not apply to a resource
without a concept of modification time has been clarified without a concept of modification time has been clarified.
(Section 13.1.4). (Section 13.1.4)
Preconditions can now be evaluated before the request content is Preconditions can now be evaluated before the request content is
processed rather than waiting until the response would otherwise be processed rather than waiting until the response would otherwise be
successful (Section 13.2). successful. (Section 13.2)
B.5. Changes from RFC 7233 B.5. Changes from RFC 7233
Refactored the range-unit and ranges-specifier grammars to simplify Refactored the range-unit and ranges-specifier grammars to simplify
and reduce artificial distinctions between bytes and other and reduce artificial distinctions between bytes and other
(extension) range units, removing the overlapping grammar of other- (extension) range units, removing the overlapping grammar of other-
range-unit by defining range units generically as a token and placing range-unit by defining range units generically as a token and placing
extensions within the scope of a range-spec (other-range). This extensions within the scope of a range-spec (other-range). This
disambiguates the role of list syntax (commas) in all range sets, disambiguates the role of list syntax (commas) in all range sets,
including extension range units, for indicating a range-set of more including extension range units, for indicating a range-set of more
than one range. Moving the extension grammar into range specifiers than one range. Moving the extension grammar into range specifiers
also allows protocol specific to byte ranges to be specified also allows protocol specific to byte ranges to be specified
separately. separately.
It is now possible to define Range handling on extension methods It is now possible to define Range handling on extension methods.
(Section 14.2). (Section 14.2)
Described use of the Content-Range header field (Section 14.4) as a Described use of the Content-Range header field (Section 14.4) as a
request modifier to perform a partial PUT (Section 14.5). request modifier to perform a partial PUT. (Section 14.5)
B.6. Changes from RFC 7235 B.6. Changes from RFC 7235
None. None.
B.7. Changes from RFC 7538 B.7. Changes from RFC 7538
None. None.
B.8. Changes from RFC 7615 B.8. Changes from RFC 7615
skipping to change at line 10725 skipping to change at line 10722
x-compress (content coding) Section 8.4.1 x-compress (content coding) Section 8.4.1
x-gzip (content coding) Section 8.4.1 x-gzip (content coding) Section 8.4.1
Authors' Addresses Authors' Addresses
Roy T. Fielding (editor) Roy T. Fielding (editor)
Adobe Adobe
345 Park Ave 345 Park Ave
San Jose, CA 95110 San Jose, CA 95110
United States of America United States of America
Email: fielding@gbiv.com Email: fielding@gbiv.com
URI: https://roy.gbiv.com/ URI: https://roy.gbiv.com/
Mark Nottingham (editor) Mark Nottingham (editor)
Fastly Fastly
Prahran VIC Prahran
Australia Australia
Email: mnot@mnot.net Email: mnot@mnot.net
URI: https://www.mnot.net/ URI: https://www.mnot.net/
Julian Reschke (editor) Julian Reschke (editor)
greenbytes GmbH greenbytes GmbH
Hafenweg 16 Hafenweg 16
48155 Münster 48155 Münster
Germany Germany
Email: julian.reschke@greenbytes.de Email: julian.reschke@greenbytes.de
URI: https://greenbytes.de/tech/webdav/ URI: https://greenbytes.de/tech/webdav/
 End of changes. 253 change blocks. 
408 lines changed or deleted 402 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/