rfc9110.original.xml   rfc9110.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<!--
This XML document is the output of clean-for-DTD.xslt; a tool that strips <!DOCTYPE rfc [
extensions to RFC 7749 from documents for processing with xml2rfc. <!ENTITY nbsp "&#160;">
<!--TARGET-GENERATOR: 202007--> <!ENTITY zwsp "&#8203;">
<!--TARGET-VOCABULARY: 3--> <!ENTITY nbhy "&#8209;">
<?xml-stylesheet type='text/xsl' href='lib/myxml2rfc.xslt'?> <!ENTITY wj "&#8288;">
<?rfc toc="yes" ?> ]>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes"?>
<?rfc subcompact="no" ?>
<?rfc linkmailto="no" ?>
<?rfc editing="no" ?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc rfcedstyle="yes"?>
<rfc version="3" <rfc version="3"
tocDepth="4" tocDepth="4"
tocInclude="true"
sortRefs="true" sortRefs="true"
symRefs="true"
submissionType="IETF"
category="std" category="std"
consensus="true"
xmlns:xi="http://www.w3.org/2001/XInclude"
xml:lang="en"
ipr="pre5378Trust200902" ipr="pre5378Trust200902"
obsoletes="2818,7230,7231,7232,7233,7235,7538,7615,7694" obsoletes="2818, 7230, 7231, 7232, 7233, 7235, 7538, 7615, 7694"
updates="3864" updates="3864"
docName="draft-ietf-httpbis-semantics-19"> docName="draft-ietf-httpbis-semantics-19"
<!--see https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/420--> number="9110">
<?v3xml2rfc silence="Warning: Setting consensus="true" for IETF STD document"?>
<?v3xml2rfc silence="Warning: Expected a valid submissionType (stream) setting"?
>
<front> <front>
<title>HTTP Semantics</title> <title>HTTP Semantics</title>
<seriesInfo name="RFC" value="9110"/>
<seriesInfo name="STD" value="97"/>
<author fullname="Roy T. Fielding" <author fullname="Roy T. Fielding"
initials="R." initials="R."
surname="Fielding" surname="Fielding"
role="editor"> role="editor">
<organization>Adobe</organization> <organization>Adobe</organization>
<address> <address>
<postal> <postal>
<postalLine>345 Park Ave</postalLine> <postalLine>345 Park Ave</postalLine>
<postalLine>San Jose, CA 95110</postalLine> <postalLine>San Jose, CA 95110</postalLine>
<postalLine>United States of America</postalLine> <postalLine>United States of America</postalLine>
skipping to change at line 54 skipping to change at line 53
<uri>https://roy.gbiv.com/</uri> <uri>https://roy.gbiv.com/</uri>
</address> </address>
</author> </author>
<author fullname="Mark Nottingham" <author fullname="Mark Nottingham"
initials="M." initials="M."
surname="Nottingham" surname="Nottingham"
role="editor"> role="editor">
<organization>Fastly</organization> <organization>Fastly</organization>
<address> <address>
<postal> <postal>
<postalLine>Prahran VIC</postalLine> <postalLine>Prahran</postalLine>
<postalLine>Australia</postalLine> <postalLine>Australia</postalLine>
</postal> </postal>
<email>mnot@mnot.net</email> <email>mnot@mnot.net</email>
<uri>https://www.mnot.net/</uri> <uri>https://www.mnot.net/</uri>
</address> </address>
</author> </author>
<author fullname="Julian Reschke" <author fullname="Julian Reschke"
initials="J." initials="J."
surname="Reschke" surname="Reschke"
role="editor"> role="editor">
skipping to change at line 76 skipping to change at line 75
<address> <address>
<postal> <postal>
<postalLine>Hafenweg 16</postalLine> <postalLine>Hafenweg 16</postalLine>
<postalLine>48155 Münster</postalLine> <postalLine>48155 Münster</postalLine>
<postalLine>Germany</postalLine> <postalLine>Germany</postalLine>
</postal> </postal>
<email>julian.reschke@greenbytes.de</email> <email>julian.reschke@greenbytes.de</email>
<uri>https://greenbytes.de/tech/webdav/</uri> <uri>https://greenbytes.de/tech/webdav/</uri>
</address> </address>
</author> </author>
<date year="2021" month="September" day="10"/> <date year="2022" month="June"/>
<area>Applications and Real-Time</area> <area>Applications and Real-Time</area>
<workgroup>HTTP Working Group</workgroup> <workgroup>HTTP Working Group</workgroup>
<keyword>Hypertext Transfer Protocol</keyword> <keyword>Hypertext Transfer Protocol</keyword>
<keyword>HTTP</keyword> <keyword>HTTP</keyword>
<keyword>HTTP semantics</keyword> <keyword>HTTP semantics</keyword>
<keyword>HTTP content</keyword> <keyword>HTTP content</keyword>
<keyword>HTTP method</keyword> <keyword>HTTP method</keyword>
<keyword>HTTP status code</keyword> <keyword>HTTP status code</keyword>
<abstract> <abstract>
<t> <t>
The Hypertext Transfer Protocol (HTTP) is a stateless application-level The Hypertext Transfer Protocol (HTTP) is a stateless application-level
protocol for distributed, collaborative, hypertext information systems. protocol for distributed, collaborative, hypertext information systems.
This document describes the overall architecture of HTTP, establishes common This document describes the overall architecture of HTTP, establishes common
terminology, and defines aspects of the protocol that are shared by all terminology, and defines aspects of the protocol that are shared by all
versions. In this definition are core protocol elements, extensibility versions. In this definition are core protocol elements, extensibility
mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) mechanisms, and the "http" and "https" Uniform Resource Identifier (URI)
schemes. schemes.
</t> </t>
<t> <t>
This document updates RFC 3864 and This document updates RFC 3864 and
obsoletes RFC 2818, RFC 7231, RFC 7232, RFC 7233, obsoletes RFCs 2818, 7231, 7232, 7233,
RFC 7235, RFC 7538, RFC 7615, RFC 7694, and portions of RFC 7230. 7235, 7538, 7615, 7694, and portions of 7230.
</t> </t>
</abstract> </abstract>
<note title="Editorial Note">
<t>This note is to be removed before publishing as an RFC.</t>
<t>
Discussion of this draft takes place on the HTTP working group
mailing list (ietf-http-wg@w3.org), which is archived at
<eref target="https://lists.w3.org/Archives/Public/ietf-http-wg/"
brackets="angle"/>.
</t>
<t>
Working Group information can be found at <eref target="https://httpwg.org/"
brackets="angle"/>;
source code and issues list for this draft can be found at
<eref target="https://github.com/httpwg/http-core" brackets="angle"/>.
</t>
<t>
The changes in this draft are summarized in <xref target="changes.since.18"/
>.
</t>
</note>
</front> </front>
<middle> <middle>
<section anchor="introduction" title="Introduction"> <section anchor="introduction" title="Introduction">
<section anchor="purpose" title="Purpose"> <section anchor="purpose" title="Purpose">
<t> <t>
The Hypertext Transfer Protocol (HTTP) is a family of stateless, The Hypertext Transfer Protocol (HTTP) is a family of stateless,
application-level, request/response protocols that share a generic interface, application-level, request/response protocols that share a generic interface,
extensible semantics, and self-descriptive messages to enable flexible extensible semantics, and self-descriptive messages to enable flexible
interaction with network-based hypertext information systems. interaction with network-based hypertext information systems.
</t> </t>
skipping to change at line 158 skipping to change at line 141
If the communication is considered in isolation, then successful If the communication is considered in isolation, then successful
actions ought to be reflected in corresponding changes to the actions ought to be reflected in corresponding changes to the
observable interface provided by servers. However, since multiple observable interface provided by servers. However, since multiple
clients might act in parallel and perhaps at cross-purposes, we clients might act in parallel and perhaps at cross-purposes, we
cannot require that such changes be observable beyond the scope cannot require that such changes be observable beyond the scope
of a single response. of a single response.
</t> </t>
</section> </section>
<section anchor="history.and.evolution" title="History and Evolution"> <section anchor="history.and.evolution" title="History and Evolution">
<t> <t>
HTTP has been the primary information transfer protocol for the World Wide HTTP has been the primary information transfer protocol for the World
Web since its introduction in 1990. It began as a trivial mechanism for Wide Web since its introduction in 1990. It began as a trivial
low-latency requests, with a single method (GET) to request transfer of a mechanism for low-latency requests, with a single method (GET) to
presumed hypertext document identified by a given pathname. request transfer of a presumed hypertext document identified by a given pathn
ame.
As the Web grew, HTTP was extended to enclose requests and responses within As the Web grew, HTTP was extended to enclose requests and responses within
messages, transfer arbitrary data formats using MIME-like media types, and messages, transfer arbitrary data formats using MIME-like media types, and
route requests through intermediaries. These protocols were eventually route requests through intermediaries. These protocols were eventually
defined as HTTP/0.9 and HTTP/1.0 (see <xref target="HTTP10"/>). defined as HTTP/0.9 and HTTP/1.0 (see <xref target="HTTP10"/>).
</t> </t>
<t> <t>
HTTP/1.1 was designed to refine the protocol's features while retaining HTTP/1.1 was designed to refine the protocol's features while retaining
compatibility with the existing text-based messaging syntax, improving compatibility with the existing text-based messaging syntax, improving
its interoperability, scalability, and robustness across the Internet. its interoperability, scalability, and robustness across the Internet.
This included length-based data delimiters for both fixed and dynamic This included length-based data delimiters for both fixed and dynamic
(chunked) content, a consistent framework for content negotiation, (chunked) content, a consistent framework for content negotiation,
opaque validators for conditional requests, cache controls for better opaque validators for conditional requests, cache controls for better
cache consistency, range requests for partial updates, and default cache consistency, range requests for partial updates, and default
persistent connections. HTTP/1.1 was introduced in 1995 and published on persistent connections. HTTP/1.1 was introduced in 1995 and published on
the standards track in 1997 <xref target="RFC2068"/>, revised in the Standards Track in 1997 <xref target="RFC2068"/>, revised in
1999 <xref target="RFC2616"/>, and revised again in 2014 1999 <xref target="RFC2616"/>, and revised again in 2014
(<xref target="RFC7230"/> – <xref target="RFC7235"/>). (<xref target="RFC7230"/> through <xref target="RFC7235"/>).
</t> </t>
<t> <t>
HTTP/2 (<xref target="HTTP2"/>) introduced a multiplexed session layer HTTP/2 (<xref target="HTTP2"/>) introduced a multiplexed session layer
on top of the existing TLS and TCP protocols for exchanging concurrent on top of the existing TLS and TCP protocols for exchanging concurrent
HTTP messages with efficient field compression and server push. HTTP messages with efficient field compression and server push.
HTTP/3 (<xref target="HTTP3"/>) provides greater independence for concurrent HTTP/3 (<xref target="HTTP3"/>) provides greater independence for concurrent
messages by using QUIC as a secure multiplexed transport over UDP instead of messages by using QUIC as a secure multiplexed transport over UDP instead of
TCP. TCP.
</t> </t>
<t> <t>
skipping to change at line 205 skipping to change at line 188
<t> <t>
This revision of HTTP separates the definition of semantics (this document) This revision of HTTP separates the definition of semantics (this document)
and caching (<xref target="CACHING"/>) from the current HTTP/1.1 messaging and caching (<xref target="CACHING"/>) from the current HTTP/1.1 messaging
syntax (<xref target="HTTP11"/>) to allow each major protocol version syntax (<xref target="HTTP11"/>) to allow each major protocol version
to progress independently while referring to the same core semantics. to progress independently while referring to the same core semantics.
</t> </t>
</section> </section>
<section anchor="core.semantics" title="Core Semantics"> <section anchor="core.semantics" title="Core Semantics">
<t> <t>
HTTP provides a uniform interface for interacting with a resource HTTP provides a uniform interface for interacting with a resource
(<xref target="resources"/>) — regardless of its type, nature, or (<xref target="resources"/>) -- regardless of its type, nature, or
implementation — by sending messages that manipulate or transfer implementation -- by sending messages that manipulate or transfer
representations (<xref target="representations"/>). representations (<xref target="representations"/>).
</t> </t>
<t> <t>
Each message is either a request or a response. A client constructs request Each message is either a request or a response. A client constructs request
messages that communicate its intentions and routes those messages toward messages that communicate its intentions and routes those messages toward
an identified origin server. A server listens for requests, parses each an identified origin server. A server listens for requests, parses each
message received, interprets the message semantics in relation to the message received, interprets the message semantics in relation to the
identified target resource, and responds to that request with one or more identified target resource, and responds to that request with one or more
response messages. The client examines received responses to see if its response messages. The client examines received responses to see if its
intentions were carried out, determining what to do next based on the intentions were carried out, determining what to do next based on the
skipping to change at line 233 skipping to change at line 216
status codes that describe the response (<xref target="status.codes"/>), and status codes that describe the response (<xref target="status.codes"/>), and
other control data and resource metadata that might be given in response other control data and resource metadata that might be given in response
fields. fields.
</t> </t>
<t> <t>
<iref item="content negotiation"/> <iref item="content negotiation"/>
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 selection fields that might influence content selection, and the various selection
algorithms that are collectively referred to as algorithms that are collectively referred to as
<em>content negotiation</em> (<xref target="content.negotiation"/>). "content negotiation" (<xref target="content.negotiation"/>).
</t> </t>
</section> </section>
<section anchor="specifications.obsoleted.by.this.document" <section anchor="specifications.obsoleted.by.this.document"
title="Specifications Obsoleted by this Document"> title="Specifications Obsoleted by This Document">
<t> <table align="left">
This document obsoletes the following specifications: <thead>
</t>
<table align="left">
<thead>
<tr> <tr>
<th>Title</th> <th>Title</th>
<th>Reference</th> <th>Reference</th>
<th>Changes</th> <th>See</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td>HTTP Over TLS</td> <td>HTTP Over TLS</td>
<td> <td>
<xref target="RFC2818"/> <xref target="RFC2818"/>
</td> </td>
<td> <td>
<xref target="changes.from.rfc.2818" format="counter"/> <xref target="changes.from.rfc.2818" format="counter"/>
skipping to change at line 370 skipping to change at line 350
in strings defined in <xref target="RFC7405"/>. in strings defined in <xref target="RFC7405"/>.
</t> </t>
<t> <t>
It also uses a list extension, defined in <xref target="abnf.extension"/>, It also uses a list extension, defined in <xref target="abnf.extension"/>,
that allows for compact definition of comma-separated lists using a "#" that allows for compact definition of comma-separated lists using a "#"
operator (similar to how the "*" operator indicates repetition). <xref target ="collected.abnf"/> shows the collected grammar with all list operator (similar to how the "*" operator indicates repetition). <xref target ="collected.abnf"/> shows the collected grammar with all list
operators expanded to standard ABNF notation. operators expanded to standard ABNF notation.
</t> </t>
<t> <t>
As a convention, ABNF rule names prefixed with "obs-" denote As a convention, ABNF rule names prefixed with "obs-" denote
"obsolete" grammar rules that appear for historical reasons. obsolete grammar rules that appear for historical reasons.
</t> </t>
<t anchor="core.rules"> <t anchor="core.rules">
The following core rules are included by The following core rules are included by
reference, as defined in <xref target="RFC5234" section="B.1"/>: reference, as defined in <xref target="RFC5234" section="B.1"/>:
ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls),
DIGIT (decimal 0-9), DQUOTE (double quote), DIGIT (decimal 0-9), DQUOTE (double quote),
HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line feed), HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line feed),
OCTET (any 8-bit sequence of data), SP (space), and OCTET (any 8-bit sequence of data), SP (space), and
VCHAR (any visible US-ASCII character). VCHAR (any visible US-ASCII character).
skipping to change at line 397 skipping to change at line 377
This specification uses the terms This specification uses the terms
"character", "character",
"character encoding scheme", "character encoding scheme",
"charset", and "charset", and
"protocol element" "protocol element"
as they are defined in <xref target="RFC6365"/>. as they are defined in <xref target="RFC6365"/>.
</t> </t>
</section> </section>
<section anchor="requirements.notation" title="Requirements Notation"> <section anchor="requirements.notation" title="Requirements Notation">
<t> <t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
"MAY", and "OPTIONAL" in this document are to be interpreted as ",
described in BCP 14 <xref target="RFC2119"/> "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
<xref target="RFC8174"/> when, and only when, they "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
appear in all capitals, as shown here. "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be
interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
target="RFC8174"/> when, and only when, they appear in all capitals, as
shown here.
</t> </t>
<t> <t>
This specification targets conformance criteria according to the role of This specification targets conformance criteria according to the role of
a participant in HTTP communication. Hence, requirements are placed a participant in HTTP communication. Hence, requirements are placed
on senders, recipients, clients, servers, user agents, intermediaries, on senders, recipients, clients, servers, user agents, intermediaries,
origin servers, proxies, gateways, or caches, depending on what behavior origin servers, proxies, gateways, or caches, depending on what behavior
is being constrained by the requirement. Additional requirements is being constrained by the requirement. Additional requirements
are placed on implementations, resource owners, and protocol element are placed on implementations, resource owners, and protocol element
registrations when they apply beyond the scope of a single communication. registrations when they apply beyond the scope of a single communication.
</t> </t>
skipping to change at line 465 skipping to change at line 447
only marginal expectations that the element will conform to its ABNF only marginal expectations that the element will conform to its ABNF
grammar and fit within a reasonable buffer size. grammar and fit within a reasonable buffer size.
</t> </t>
<t> <t>
HTTP does not have specific length limitations for many of its protocol HTTP does not have specific length limitations for many of its protocol
elements because the lengths that might be appropriate will vary widely, elements because the lengths that might be appropriate will vary widely,
depending on the deployment context and purpose of the implementation. depending on the deployment context and purpose of the implementation.
Hence, interoperability between senders and recipients depends on shared Hence, interoperability between senders and recipients depends on shared
expectations regarding what is a reasonable length for each protocol expectations regarding what is a reasonable length for each protocol
element. Furthermore, what is commonly understood to be a reasonable length element. Furthermore, what is commonly understood to be a reasonable length
for some protocol elements has changed over the course of the past two for some protocol elements has changed over the course of the past three
decades of HTTP use and is expected to continue changing in the future. decades of HTTP use and is expected to continue changing in the future.
</t> </t>
<t> <t>
At a minimum, a recipient <bcp14>MUST</bcp14> be able to parse and process pr otocol At a minimum, a recipient <bcp14>MUST</bcp14> be able to parse and process pr otocol
element lengths that are at least as long as the values that it generates element lengths that are at least as long as the values that it generates
for those same protocol elements in other messages. For example, an origin for those same protocol elements in other messages. For example, an origin
server that publishes very long URI references to its own resources needs server that publishes very long URI references to its own resources needs
to be able to parse and process those same references when received as a to be able to parse and process those same references when received as a
target URI. target URI.
</t> </t>
skipping to change at line 515 skipping to change at line 497
</t> </t>
<t> <t>
Some requests can be automatically retried by a client in the event of Some requests can be automatically retried by a client in the event of
an underlying connection failure, as described in an underlying connection failure, as described in
<xref target="idempotent.methods"/>. <xref target="idempotent.methods"/>.
</t> </t>
</section> </section>
<section anchor="protocol.version" title="Protocol Version"> <section anchor="protocol.version" title="Protocol Version">
<t> <t>
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") indicates the (period or decimal point). The first digit (major version) indicates the
messaging syntax, whereas the second digit ("minor version") messaging syntax, whereas the second digit (minor version)
indicates the highest minor version within that major version to which the indicates the highest minor version within that major version to which the
sender is conformant (able to understand for future communication). sender is conformant (able to understand for future communication).
</t> </t>
<t> <t>
While HTTP's core semantics don't change between protocol versions, the While HTTP's core semantics don't change between protocol versions, their
expression of them "on the wire" can change, and so the expression "on the wire" can change, and so the
HTTP version number changes when incompatible changes are made to the wire HTTP version number changes when incompatible changes are made to the wire
format. Additionally, HTTP allows incremental, backwards-compatible format. Additionally, HTTP allows incremental, backwards-compatible
changes to be made to the protocol without changing its version through changes to be made to the protocol without changing its version through
the use of defined extension points (<xref target="extending"/>). the use of defined extension points (<xref target="extending"/>).
</t> </t>
<t> <t>
The protocol version as a whole indicates the sender's conformance with The protocol version as a whole indicates the sender's conformance with
the set of requirements laid out in that version's corresponding the set of requirements laid out in that version's corresponding
specification of HTTP. specification(s).
For example, the version "HTTP/1.1" is defined by the combined For example, the version "HTTP/1.1" is defined by the combined
specifications of this document, "HTTP Caching" <xref target="CACHING"/>, specifications of this document, "HTTP Caching" <xref target="CACHING"/>,
and "HTTP/1.1" <xref target="HTTP11"/>. and "HTTP/1.1" <xref target="HTTP11"/>.
</t> </t>
<t> <t>
HTTP's major version number is incremented when an incompatible message HTTP's major version number is incremented when an incompatible message
syntax is introduced. The minor number is incremented when changes made to syntax is introduced. The minor number is incremented when changes made to
the protocol have the effect of adding to the message semantics or the protocol have the effect of adding to the message semantics or
implying additional capabilities of the sender. implying additional capabilities of the sender.
</t> </t>
skipping to change at line 565 skipping to change at line 547
<section anchor="terminology" title="Terminology and Core Concepts"> <section anchor="terminology" title="Terminology and Core Concepts">
<t> <t>
HTTP was created for the World Wide Web (WWW) architecture HTTP was created for the World Wide Web (WWW) architecture
and has evolved over time to support the scalability needs of a worldwide and has evolved over time to support the scalability needs of a worldwide
hypertext system. Much of that architecture is reflected in the terminology hypertext system. Much of that architecture is reflected in the terminology
used to define HTTP. used to define HTTP.
</t> </t>
<section anchor="resources" title="Resources"> <section anchor="resources" title="Resources">
<iref primary="true" item="resource"/> <iref primary="true" item="resource"/>
<t> <t>
The target of an HTTP request is called a <em>resource</em>. The target of an HTTP request is called a "resource".
HTTP does not limit the nature of a resource; it merely HTTP does not limit the nature of a resource; it merely
defines an interface that might be used to interact with resources. defines an interface that might be used to interact with resources.
Most resources are identified by a Uniform Resource Identifier (URI), as Most resources are identified by a Uniform Resource Identifier (URI), as
described in <xref target="uri"/>. described in <xref target="uri"/>.
</t> </t>
<t> <t>
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 (<xref target="methods"/>) and a few semantics in the request method (<xref target="methods"/>) and a few
request-modifying header fields. request-modifying header fields.
skipping to change at line 591 skipping to change at line 573
</t> </t>
<t> <t>
HTTP relies upon the Uniform Resource Identifier (URI) HTTP relies upon the Uniform Resource Identifier (URI)
standard <xref target="URI"/> to indicate the target resource standard <xref target="URI"/> to indicate the target resource
(<xref target="target.resource"/>) and relationships between resources. (<xref target="target.resource"/>) and relationships between resources.
</t> </t>
</section> </section>
<section anchor="representations" title="Representations"> <section anchor="representations" title="Representations">
<iref primary="true" item="representation"/> <iref primary="true" item="representation"/>
<t> <t>
A <em>representation</em> is information A "representation" is information
that is intended to reflect a past, current, or desired state of a given that is intended to reflect a past, current, or desired state of a given
resource, in a format that can be readily communicated via the protocol. resource, in a format that can be readily communicated via the protocol.
A representation consists of a set of representation metadata and a A representation consists of a set of representation metadata and a
potentially unbounded stream of representation data potentially unbounded stream of representation data
(<xref target="representation.data.and.metadata"/>). (<xref target="representation.data.and.metadata"/>).
</t> </t>
<t> <t>
HTTP allows "information hiding" behind its uniform interface by defining HTTP allows "information hiding" behind its uniform interface by defining
communication with respect to a transferable representation of the resource communication with respect to a transferable representation of the resource
state, rather than transferring the resource itself. This allows the state, rather than transferring the resource itself. This allows the
skipping to change at line 624 skipping to change at line 606
that help guide the recipient's future interactions. that help guide the recipient's future interactions.
</t> </t>
<t anchor="selected.representation"> <t anchor="selected.representation">
<iref primary="true" item="selected representation"/> <iref primary="true" item="selected representation"/>
A <xref target="target.resource" format="none">target resource</xref> might b e provided with, or be capable of A <xref target="target.resource" format="none">target resource</xref> might b e provided with, or be capable of
generating, multiple representations that are each intended to reflect the generating, multiple representations that are each intended to reflect the
resource's current state. An algorithm, usually based on resource's current state. An algorithm, usually based on
<xref target="content.negotiation" format="none">content negotiation</xref> ( <xref target="content.negotiation"/>), <xref target="content.negotiation" format="none">content negotiation</xref> ( <xref target="content.negotiation"/>),
would be used to select one of those representations as being most would be used to select one of those representations as being most
applicable to a given request. applicable to a given request.
This <em>selected representation</em> provides the data and metadata This "selected representation" provides the data and metadata
for evaluating conditional requests (<xref target="conditional.requests"/>) for evaluating conditional requests (<xref target="conditional.requests"/>)
and constructing the content for <xref target="status.200" format="none">200 (OK)</xref>, and constructing the content for <xref target="status.200" format="none">200 (OK)</xref>,
<xref target="status.206" format="none">206 (Partial Content)</xref>, and <xref target="status.206" format="none">206 (Partial Content)</xref>, and
<xref target="status.304" format="none">304 (Not Modified)</xref> responses t o GET (<xref target="GET"/>). <xref target="status.304" format="none">304 (Not Modified)</xref> responses t o GET (<xref target="GET"/>).
</t> </t>
</section> </section>
<section anchor="connections" title="Connections, Clients and Servers"> <section anchor="connections" title="Connections, Clients, and Servers" >
<iref primary="true" item="client"/> <iref primary="true" item="client"/>
<iref primary="true" item="server"/> <iref primary="true" item="server"/>
<iref primary="true" item="connection"/> <iref primary="true" item="connection"/>
<t> <t>
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 <em>connection</em>. transport- or session-layer "connection".
</t> </t>
<t> <t>
An HTTP <em>client</em> is a program that establishes a connection An HTTP "client" is a program that establishes a connection
to a server for the purpose of sending one or more HTTP requests. to a server for the purpose of sending one or more HTTP requests.
An HTTP <em>server</em> is a program that accepts connections An HTTP "server" is a program that accepts connections
in order to service HTTP requests by sending HTTP responses. in order to service HTTP requests by sending HTTP responses.
</t> </t>
<t> <t>
The terms "client" and "server" refer only to the roles that The terms client and server refer only to the roles that
these programs perform for a particular connection. The same program these programs perform for a particular connection. The same program
might act as a client on some connections and a server on others. might act as a client on some connections and a server on others.
</t> </t>
<t> <t>
HTTP is defined as a stateless protocol, meaning that each request message's semantics HTTP is defined as a stateless protocol, meaning that each request message's semantics
can be understood in isolation, and that the relationship between connections can be understood in isolation, and that the relationship between connections
and messages on them has no impact on the interpretation of those messages. and messages on them has no impact on the interpretation of those messages.
For example, a CONNECT request (<xref target="CONNECT"/>) or a request with For example, a CONNECT request (<xref target="CONNECT"/>) or a request with
the Upgrade header field (<xref target="field.upgrade"/>) can occur at any ti me, the Upgrade header field (<xref target="field.upgrade"/>) can occur at any ti me,
not just in the first message on a connection. Many implementations depend on not just in the first message on a connection. Many implementations depend on
skipping to change at line 678 skipping to change at line 660
</section> </section>
<section anchor="messages" title="Messages"> <section anchor="messages" title="Messages">
<iref primary="true" item="messages"/> <iref primary="true" item="messages"/>
<iref item="message"/> <iref item="message"/>
<iref primary="true" item="sender"/> <iref primary="true" item="sender"/>
<iref primary="true" item="recipient"/> <iref primary="true" item="recipient"/>
<iref primary="true" item="request"/> <iref primary="true" item="request"/>
<iref primary="true" item="response"/> <iref primary="true" item="response"/>
<t> <t>
HTTP is a stateless request/response protocol for exchanging HTTP is a stateless request/response protocol for exchanging
<em>messages</em> across a <xref target="connections" format="none">connectio "messages" across a <xref target="connections" format="none">connection</xref
n</xref>. >.
The terms <em>sender</em> and <em>recipient</em> refer to The terms "sender" and "recipient" refer to
any implementation that sends or receives a given message, respectively. any implementation that sends or receives a given message, respectively.
</t> </t>
<t> <t>
A client sends requests to a server in the form of a <em>request</em> A client sends requests to a server in the form of a "request"
message with a method (<xref target="methods"/>) and request target message with a method (<xref target="methods"/>) and request target
(<xref target="target.resource"/>). The request might also contain (<xref target="target.resource"/>). The request might also contain
header fields (<xref target="header.fields"/>) for request modifiers, header fields (<xref target="header.fields"/>) for request modifiers,
client information, and representation metadata, client information, and representation metadata,
content (<xref target="content"/>) intended for processing content (<xref target="content"/>) intended for processing
in accordance with the method, and in accordance with the method, and
trailer fields (<xref target="trailer.fields"/>) to communicate information trailer fields (<xref target="trailer.fields"/>) to communicate information
collected while sending the content. collected while sending the content.
</t> </t>
<t> <t>
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
<em>response</em> messages, each including a status "response" messages, each including a status
code (<xref target="status.codes"/>). The response might also contain code (<xref target="status.codes"/>). The response might also contain
header fields for server information, resource metadata, and representation header fields for server information, resource metadata, and representation
metadata, content to be interpreted in accordance with the status metadata, content to be interpreted in accordance with the status
code, and trailer fields to communicate information code, and trailer fields to communicate information
collected while sending the content. collected while sending the content.
</t> </t>
</section> </section>
<section anchor="user.agent" title="User Agents"> <section anchor="user.agent" title="User Agents">
<iref primary="true" item="user agent"/> <iref primary="true" item="user agent"/>
<iref primary="true" item="browser"/> <iref primary="true" item="browser"/>
<iref primary="true" item="spider"/> <iref primary="true" item="spider"/>
<t> <t>
The term <em>user agent</em> refers to any of the various The term "user agent" refers to any of the various
client programs that initiate a request. client programs that initiate a request.
</t> </t>
<t> <t>
The most familiar form of user agent is the general-purpose Web browser, but The most familiar form of user agent is the general-purpose Web browser, but
that's only a small percentage of implementations. Other common user agents that's only a small percentage of implementations. Other common user agents
include spiders (web-traversing robots), command-line tools, billboard include spiders (web-traversing robots), command-line tools, billboard
screens, household appliances, scales, light bulbs, firmware update scripts, screens, household appliances, scales, light bulbs, firmware update scripts,
mobile apps, and communication devices in a multitude of shapes and sizes. mobile apps, and communication devices in a multitude of shapes and sizes.
</t> </t>
<t> <t>
skipping to change at line 743 skipping to change at line 725
Likewise, requirements that an automated action be confirmed by the user Likewise, requirements that an automated action be confirmed by the user
before proceeding might be met via advance configuration choices, before proceeding might be met via advance configuration choices,
run-time options, or simple avoidance of the unsafe action; confirmation run-time options, or simple avoidance of the unsafe action; confirmation
does not imply any specific user interface or interruption of normal does 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.
</t> </t>
</section> </section>
<section anchor="origin.server" title="Origin Server"> <section anchor="origin.server" title="Origin Server">
<iref primary="true" item="origin server"/> <iref primary="true" item="origin server"/>
<t> <t>
The term <em>origin server</em> refers to a program that can The term "origin server" refers to a program that can
originate authoritative responses for a given target resource. originate authoritative responses for a given target resource.
</t> </t>
<t> <t>
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 be However, like user agents being equated with browsers, it is easy to be
misled into thinking that all origin servers are alike. misled into thinking that all origin servers are alike.
Common origin servers also include home automation units, configurable Common origin servers also include home automation units, configurable
networking components, office machines, autonomous robots, news feeds, networking components, office machines, autonomous robots, news feeds,
traffic cameras, real-time ad selectors, and video-on-demand platforms. traffic cameras, real-time ad selectors, and video-on-demand platforms.
</t> </t>
<t> <t>
Most HTTP communication consists of a retrieval request (GET) for Most HTTP communication consists of a retrieval request (GET) for
a representation of some resource identified by a URI. In the a representation of some resource identified by a URI. In the
simplest case, this might be accomplished via a single bidirectional simplest case, this might be accomplished via a single bidirectional
connection (===) between the user agent (UA) and the origin server (O). connection (===) between the user agent (UA) and the origin server (O).
</t> </t>
<figure> <figure>
<artwork type="drawing"><![CDATA[ <artwork type="ascii-art"><![CDATA[
request > request >
UA ======================================= O UA ======================================= O
< response < response
]]></artwork> ]]></artwork>
</figure> </figure>
</section> </section>
<section anchor="intermediaries" title="Intermediaries"> <section anchor="intermediaries" title="Intermediaries">
<iref primary="true" item="intermediary"/> <iref primary="true" item="intermediary"/>
<t> <t>
HTTP enables the use of intermediaries to satisfy requests through HTTP enables the use of intermediaries to satisfy requests through
a chain of connections. There are three common forms of HTTP a chain of connections. There are three common forms of HTTP
<em>intermediary</em>: proxy, gateway, and tunnel. In some cases, "intermediary": proxy, gateway, and tunnel. In some cases,
a single intermediary might act as an origin server, proxy, gateway, a single intermediary might act as an origin server, proxy, gateway,
or tunnel, switching behavior based on the nature of each request. or tunnel, switching behavior based on the nature of each request.
</t> </t>
<figure> <figure>
<artwork type="drawing"><![CDATA[ <artwork type="ascii-art"><![CDATA[
> > > > > > > >
UA =========== A =========== B =========== C =========== O UA =========== A =========== B =========== C =========== O
< < < < < < < <
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>
The figure above shows three intermediaries (A, B, and C) between the The figure above shows three intermediaries (A, B, and C) between the
user agent and origin server. A request or response message that user agent and origin server. A request or response message that
travels the whole chain will pass through four separate connections. travels the whole chain will pass through four separate connections.
Some HTTP communication options Some HTTP communication options
skipping to change at line 804 skipping to change at line 786
forwarding requests to servers other than C, at the same time that it forwarding requests to servers other than C, at the same time that it
is handling A's request. Likewise, later requests might be sent through a is handling A's request. Likewise, later requests might be sent through a
different path of connections, often based on dynamic configuration for different path of connections, often based on dynamic configuration for
load balancing. load balancing.
</t> </t>
<t> <t>
<iref primary="true" item="upstream"/> <iref primary="true" item="upstream"/>
<iref primary="true" item="downstream"/> <iref primary="true" item="downstream"/>
<iref primary="true" item="inbound"/> <iref primary="true" item="inbound"/>
<iref primary="true" item="outbound"/> <iref primary="true" item="outbound"/>
The terms <em>upstream</em> and <em>downstream</em> are The terms "upstream" and "downstream" are
used to describe directional requirements in relation to the message flow: used to describe directional requirements in relation to the message flow:
all messages flow from upstream to downstream. all messages flow from upstream to downstream.
The terms "inbound" and "outbound" are used to describe directional The terms "inbound" and "outbound" are used to describe directional
requirements in relation to the request route: requirements in relation to the request route:
<em>inbound</em> means toward the origin server and inbound means "toward the origin server", whereas
<em>outbound</em> means toward the user agent. outbound means "toward the user agent".
</t> </t>
<t> <t>
<iref primary="true" item="proxy"/> <iref primary="true" item="proxy"/>
A <em>proxy</em> is a message-forwarding agent that is chosen by the A "proxy" is a message-forwarding agent that is chosen by the
client, usually via local configuration rules, to receive requests client, usually via local configuration rules, to receive requests
for some type(s) of absolute URI and attempt to satisfy those for some type(s) of absolute URI and attempt to satisfy those
requests via translation through the HTTP interface. Some translations requests via translation through the HTTP interface. Some translations
are minimal, such as for proxy requests for "http" URIs, whereas are minimal, such as for proxy requests for "http" URIs, whereas
other requests might require translation to and from entirely different other 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. Some sake of security services, annotation services, or shared caching. Some
proxies are designed to apply transformations to selected messages or proxies are designed to apply transformations to selected messages or
content while they are being forwarded, as described in content while they are being forwarded, as described in
<xref target="message.transformations"/>. <xref target="message.transformations"/>.
</t> </t>
<t> <t>
<iref primary="true" item="gateway"/> <iref primary="true" item="gateway"/>
<iref primary="true" item="reverse proxy"/> <iref primary="true" item="reverse proxy"/>
<iref primary="true" item="accelerator"/> <iref primary="true" item="accelerator"/>
A <em>gateway</em> (a.k.a. <em>reverse proxy</em>) is an A "gateway" (a.k.a. "reverse proxy") is an
intermediary that acts as an origin server for the outbound connection but intermediary that acts as an origin server for the outbound connection but
translates received requests and forwards them inbound to another server or translates received requests and forwards them inbound to another server or
servers. Gateways are often used to encapsulate legacy or untrusted servers. Gateways are often used to encapsulate legacy or untrusted
information services, to improve server performance through information services, to improve server performance through
<em>accelerator</em> caching, and to enable partitioning or load "accelerator" caching, and to enable partitioning or load
balancing of HTTP services across multiple machines. balancing of HTTP services across multiple machines.
</t> </t>
<t> <t>
All HTTP requirements applicable to an origin server All HTTP requirements applicable to an origin server
also apply to the outbound communication of a gateway. also apply to the outbound communication of a gateway.
A gateway communicates with inbound servers using any protocol that A gateway communicates with inbound servers using any protocol that
it desires, including private extensions to HTTP that are outside it desires, including private extensions to HTTP that are outside
the scope of this specification. However, an HTTP-to-HTTP gateway the scope of this specification. However, an HTTP-to-HTTP gateway
that wishes to interoperate with third-party HTTP servers needs to conform that wishes to interoperate with third-party HTTP servers needs to conform
to user agent requirements on the gateway's inbound connection. to user agent requirements on the gateway's inbound connection.
</t> </t>
<t> <t>
<iref primary="true" item="tunnel"/> <iref primary="true" item="tunnel"/>
A <em>tunnel</em> acts as a blind relay between two connections A "tunnel" acts as a blind relay between two connections
without changing the messages. Once active, a tunnel is not without changing the messages. Once active, a tunnel is not
considered a party to the HTTP communication, though the tunnel might considered a party to the HTTP communication, though the tunnel might
have been initiated by an HTTP request. A tunnel ceases to exist when have been initiated by an HTTP request. A tunnel ceases to exist when
both ends of the relayed connection are closed. Tunnels are used to both 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, <xref target="TLS13"/>) is used to Transport Layer Security (TLS, <xref target="TLS13"/>) is used to
establish confidential communication through a shared firewall proxy. establish confidential communication through a shared firewall proxy.
</t> </t>
<t> <t>
The above categories for intermediary only consider those acting as The above categories for intermediary only consider those acting as
skipping to change at line 868 skipping to change at line 850
</t> </t>
<t> <t>
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 intermediaries participants in the HTTP communication. There are also intermediaries
that can act on lower layers of the network protocol stack, filtering or that can act on lower layers of the network protocol stack, filtering or
redirecting HTTP traffic without the knowledge or permission of message redirecting HTTP traffic without the knowledge or permission of message
senders. Network intermediaries are indistinguishable (at a protocol level) senders. Network intermediaries are indistinguishable (at a protocol level)
from an on-path attacker, often introducing security flaws or from an on-path attacker, often introducing security flaws or
interoperability problems due to mistakenly violating HTTP semantics. interoperability problems due to mistakenly violating HTTP semantics.
</t> </t>
<t> <t>
<iref primary="true" item="interception proxy"/> <iref primary="true" item="interception proxy"/>
<iref primary="true" item="transparent proxy"/> <iref primary="true" item="transparent proxy"/>
For example, an For example, an "interception proxy" <xref target="RFC3040"/> (also commonly
<em>interception proxy</em> known as a "transparent proxy" <xref target="RFC1919"/>)
<xref target="RFC3040"/> (also commonly
known as a <em>transparent proxy</em>
<xref target="RFC1919"/>)
differs from an HTTP proxy because it is not chosen by the client. differs from an HTTP proxy because it is not chosen by the client.
Instead, an interception proxy filters or redirects outgoing TCP port 80 Instead, an interception proxy filters or redirects outgoing TCP port 80
packets (and occasionally other common port traffic). packets (and occasionally other common port traffic).
Interception proxies are commonly found on public network access points, Interception proxies are commonly found on public network access points,
as a means of enforcing account subscription prior to allowing use of as a means of enforcing account subscription prior to allowing use of
non-local Internet services, and within corporate firewalls to enforce non-local Internet services, and within corporate firewalls to enforce
network usage policies. network usage policies.
</t> </t>
</section> </section>
<section anchor="caches" title="Caches"> <section anchor="caches" title="Caches">
<iref primary="true" item="cache"/> <iref primary="true" item="cache"/>
<t> <t>
A <em>cache</em> 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 <bcp14>MAY</bcp14> employ a cache, though a ca che requests. Any client or server <bcp14>MAY</bcp14> employ a cache, though a ca che
cannot be used while acting as a tunnel. cannot be used while acting as a tunnel.
</t> </t>
<t> <t>
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.
</t> </t>
<figure> <figure>
<artwork type="drawing"><![CDATA[ <artwork type="ascii-art"><![CDATA[
> > > >
UA =========== A =========== B - - - - - - C - - - - - - O UA =========== A =========== B - - - - - - C - - - - - - O
< < < <
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>
<iref primary="true" item="cacheable"/> <iref primary="true" item="cacheable"/>
A response is <em>cacheable</em> 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. the response message for use in answering subsequent requests.
Even when a response is cacheable, there might be additional Even when a response is cacheable, there might be additional
constraints placed by the client or by the origin server on when constraints placed by the client or by the origin server on when
that cached response can be used for a particular request. HTTP that cached response can be used for a particular request. HTTP
requirements for cache behavior and cacheable responses are requirements for cache behavior and cacheable responses are
defined in <xref target="CACHING"/>. defined in <xref target="CACHING"/>.
</t> </t>
<t> <t>
There is a wide variety of architectures and configurations There is a wide variety of architectures and configurations
of caches deployed across the World Wide Web and of caches deployed across the World Wide Web and
inside large organizations. These include national hierarchies inside large organizations. These include national hierarchies
of proxy caches to save bandwidth and reduce latency, Content Delivery of proxy caches to save bandwidth and reduce latency, content delivery
Networks that use gateway caching to optimise regional and global distributio networks that use gateway caching to optimize regional and global distributio
n of popular sites, n of popular sites,
collaborative systems that collaborative systems that
broadcast or multicast cache entries, archives of pre-fetched cache broadcast or multicast cache entries, archives of pre-fetched cache
entries for use in off-line or high-latency environments, and so on. entries for use in off-line or high-latency environments, and so on.
</t> </t>
</section> </section>
<section anchor="example" title="Example Message Exchange"> <section anchor="example" title="Example Message Exchange">
<t> <t>
The following example illustrates a typical HTTP/1.1 message exchange for a The following example illustrates a typical HTTP/1.1 message exchange for a
GET request (<xref target="GET"/>) on the URI "http://www.example.com/hello.t xt": GET request (<xref target="GET"/>) on the URI "http://www.example.com/hello.t xt":
</t> </t>
skipping to change at line 995 skipping to change at line 975
</t> </t>
<iref primary="true" item="Grammar" subitem="URI-reference"/> <iref primary="true" item="Grammar" subitem="URI-reference"/>
<iref primary="true" item="Grammar" subitem="absolute-URI"/> <iref primary="true" item="Grammar" subitem="absolute-URI"/>
<iref primary="true" item="Grammar" subitem="authority"/> <iref primary="true" item="Grammar" subitem="authority"/>
<iref primary="true" item="Grammar" subitem="absolute-path"/> <iref primary="true" item="Grammar" subitem="absolute-path"/>
<iref primary="true" item="Grammar" subitem="port"/> <iref primary="true" item="Grammar" subitem="port"/>
<iref primary="true" item="Grammar" subitem="query"/> <iref primary="true" item="Grammar" subitem="query"/>
<iref primary="true" item="Grammar" subitem="segment"/> <iref primary="true" item="Grammar" subitem="segment"/>
<iref primary="true" item="Grammar" subitem="uri-host"/> <iref primary="true" item="Grammar" subitem="uri-host"/>
<iref primary="true" item="Grammar" subitem="partial-URI"/> <iref primary="true" item="Grammar" subitem="partial-URI"/>
<sourcecode type="abnf7230"><![CDATA[ URI-reference = <URI-referenc e, see [URI], Section 4.1> <sourcecode type="abnf9110"><![CDATA[ URI-reference = <URI-referenc e, see [URI], Section 4.1>
absolute-URI = <absolute-URI, see [URI], Section 4.3> absolute-URI = <absolute-URI, see [URI], Section 4.3>
relative-part = <relative-part, see [URI], Section 4.2> relative-part = <relative-part, see [URI], Section 4.2>
authority = <authority, see [URI], Section 3.2> authority = <authority, see [URI], Section 3.2>
uri-host = <host, see [URI], Section 3.2.2> uri-host = <host, see [URI], Section 3.2.2>
port = <port, see [URI], Section 3.2.3> port = <port, see [URI], Section 3.2.3>
path-abempty = <path-abempty, see [URI], Section 3.3> path-abempty = <path-abempty, see [URI], Section 3.3>
segment = <segment, see [URI], Section 3.3> segment = <segment, see [URI], Section 3.3>
query = <query, see [URI], Section 3.4> query = <query, see [URI], Section 3.4>
absolute-path = 1*( "/" segment ) absolute-path = 1*( "/" segment )
skipping to change at line 1031 skipping to change at line 1011
request line in HTTP/1.1) will necessarily be larger in some cases. request line in HTTP/1.1) will necessarily be larger in some cases.
</t> </t>
</section> </section>
<section anchor="uri.schemes" title="HTTP-Related URI Schemes"> <section anchor="uri.schemes" title="HTTP-Related URI Schemes">
<t> <t>
IANA maintains the registry of URI Schemes <xref target="BCP35"/> at IANA maintains the registry of URI Schemes <xref target="BCP35"/> at
<eref target="https://www.iana.org/assignments/uri-schemes/" brackets="angle" />. <eref target="https://www.iana.org/assignments/uri-schemes/" brackets="angle" />.
Although requests might target any URI scheme, the following schemes are Although requests might target any URI scheme, the following schemes are
inherent to HTTP servers: inherent to HTTP servers:
</t> </t>
<table align="left"> <table align="left" anchor="uri.scheme.table">
<thead> <thead>
<tr> <tr>
<th>URI Scheme</th> <th>URI Scheme</th>
<th>Description</th> <th>Description</th>
<th>Ref.</th> <th>Section</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td>http</td> <td>http</td>
<td>Hypertext Transfer Protocol</td> <td>Hypertext Transfer Protocol</td>
<td> <td>
<xref target="http.uri" format="counter"/> <xref target="http.uri" format="counter"/>
</td> </td>
</tr> </tr>
skipping to change at line 1073 skipping to change at line 1053
</t> </t>
<section anchor="http.uri" title="http URI Scheme"> <section anchor="http.uri" title="http URI Scheme">
<iref item="http URI scheme" primary="true"/> <iref item="http URI scheme" primary="true"/>
<iref item="URI scheme" subitem="http" primary="true"/> <iref item="URI scheme" subitem="http" primary="true"/>
<t> <t>
The "http" URI scheme is hereby defined for minting identifiers within the The "http" URI scheme is hereby defined for minting identifiers within the
hierarchical namespace governed by a potential HTTP origin server hierarchical namespace governed by a potential HTTP origin server
listening for TCP (<xref target="TCP"/>) connections on a given port. listening for TCP (<xref target="TCP"/>) connections on a given port.
</t> </t>
<iref primary="true" item="Grammar" subitem="http-URI"/> <iref primary="true" item="Grammar" subitem="http-URI"/>
<sourcecode type="abnf7230"><![CDATA[ http-URI = "http" "://" au thority path-abempty [ "?" query ] <sourcecode type="abnf9110"><![CDATA[ http-URI = "http" "://" au thority path-abempty [ "?" query ]
]]></sourcecode> ]]></sourcecode>
<t> <t>
The origin server for an "http" URI is identified by the The origin server for an "http" URI is identified by the
<xref target="uri.references" format="none">authority</xref> component, which includes a host identifier <xref target="uri.references" format="none">authority</xref> component, which includes a host identifier
(<xref target="URI" sectionFormat="comma" section="3.2.2"/>) (<xref target="URI" sectionFormat="comma" section="3.2.2"/>)
and optional port number (<xref target="URI" sectionFormat="comma" section="3 .2.3"/>). and optional port number (<xref target="URI" sectionFormat="comma" section="3 .2.3"/>).
If the port subcomponent is empty or not given, TCP port 80 (the If the port subcomponent is empty or not given, TCP port 80 (the
reserved port for WWW services) is the default. reserved port for WWW services) is the default.
The origin determines who has the right to respond authoritatively to The origin determines who has the right to respond authoritatively to
requests that target the identified resource, as defined in requests that target the identified resource, as defined in
<xref target="http.origin"/>. <xref target="http.origin"/>.
</t> </t>
<t> <t>
A sender <bcp14>MUST NOT</bcp14> generate an "http" URI with an empty host id entifier. A sender <bcp14>MUST NOT</bcp14> generate an "http" URI with an empty host id entifier.
A recipient that processes such a URI reference <bcp14>MUST</bcp14> reject it as invalid. A recipient that processes such a URI reference <bcp14>MUST</bcp14> reject it as invalid.
</t> </t>
<t> <t>
The hierarchical path component and optional query component identify the The hierarchical path component and optional query component identify the
target resource within that origin server's name space. target resource within that origin server's namespace.
</t> </t>
</section> </section>
<section anchor="https.uri" title="https URI Scheme"> <section anchor="https.uri" title="https URI Scheme">
<iref item="https URI scheme" primary="true"/> <iref item="https URI scheme" primary="true"/>
<iref item="URI scheme" subitem="https" primary="true"/> <iref item="URI scheme" subitem="https" primary="true"/>
<iref item="secured" primary="true"/> <iref item="secured" primary="true"/>
<t> <t>
The "https" URI scheme is hereby defined for minting identifiers within the The "https" URI scheme is hereby defined for minting identifiers within the
hierarchical namespace governed by a potential origin server listening for hierarchical namespace governed by a potential origin server listening for
TCP connections on a given port and capable of establishing a TLS TCP connections on a given port and capable of establishing a TLS
(<xref target="TLS13"/>) connection that has been secured for HTTP (<xref target="TLS13"/>) connection that has been secured for HTTP
communication. In this context, <em>secured</em> specifically communication. In this context, "secured" specifically
means that the server has been authenticated as acting on behalf of the means 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 client confidentiality and integrity protection that is acceptable to both client
and server. and server.
</t> </t>
<iref primary="true" item="Grammar" subitem="https-URI"/> <iref primary="true" item="Grammar" subitem="https-URI"/>
<sourcecode type="abnf7230"><![CDATA[ https-URI = "https" "://" authority path-abempty [ "?" query ] <sourcecode type="abnf9110"><![CDATA[ https-URI = "https" "://" authority path-abempty [ "?" query ]
]]></sourcecode> ]]></sourcecode>
<t> <t>
The origin server for an "https" URI is identified by the The origin server for an "https" URI is identified by the
<xref target="uri.references" format="none">authority</xref> component, which includes a host identifier <xref target="uri.references" format="none">authority</xref> component, which includes a host identifier
(<xref target="URI" sectionFormat="comma" section="3.2.2"/>) (<xref target="URI" sectionFormat="comma" section="3.2.2"/>)
and optional port number (<xref target="URI" sectionFormat="comma" section="3 .2.3"/>). and optional port number (<xref target="URI" sectionFormat="comma" section="3 .2.3"/>).
If the port subcomponent is empty or not given, TCP port 443 If the port subcomponent is empty or not given, TCP port 443
(the reserved port for HTTP over TLS) is the default. (the reserved port for HTTP over TLS) is the default.
The origin determines who has the right to respond authoritatively to The origin determines who has the right to respond authoritatively to
requests that target the identified resource, as defined in requests that target the identified resource, as defined in
<xref target="https.origin"/>. <xref target="https.origin"/>.
</t> </t>
<t> <t>
A sender <bcp14>MUST NOT</bcp14> generate an "https" URI with an empty host i dentifier. A sender <bcp14>MUST NOT</bcp14> generate an "https" URI with an empty host i dentifier.
A recipient that processes such a URI reference <bcp14>MUST</bcp14> reject it as invalid. A recipient that processes such a URI reference <bcp14>MUST</bcp14> reject it as invalid.
</t> </t>
<t> <t>
The hierarchical path component and optional query component identify the The hierarchical path component and optional query component identify the
target resource within that origin server's name space. target resource within that origin server's namespace.
</t> </t>
<t> <t>
A client <bcp14>MUST</bcp14> ensure that its HTTP requests for an "https" res ource are A client <bcp14>MUST</bcp14> ensure that its HTTP requests for an "https" res ource are
secured, prior to being communicated, and that it only accepts secured secured, prior to being communicated, and that it only accepts secured
responses to those requests. Note that the definition of what cryptographic responses to those requests. Note that the definition of what cryptographic
mechanisms are acceptable to client and server are usually negotiated and mechanisms are acceptable to client and server are usually negotiated and
can change over time. can change over time.
</t> </t>
<t> <t>
Resources made available via the "https" scheme have no shared identity Resources made available via the "https" scheme have no shared identity
skipping to change at line 1152 skipping to change at line 1132
However, extensions to HTTP that are defined as applying to all origins with However, extensions to HTTP that are defined as applying to all origins with
the same host, such as the Cookie protocol <xref target="COOKIE"/>, the same host, such as the Cookie protocol <xref target="COOKIE"/>,
allow information set by one service to impact communication with other allow information set by one service to impact communication with other
services within a matching group of host domains. Such extensions ought to services within a matching group of host domains. Such extensions ought to
be designed with great care to prevent information obtained from a secured be designed with great care to prevent information obtained from a secured
connection being inadvertently exchanged within an unsecured context. connection being inadvertently exchanged within an unsecured context.
</t> </t>
</section> </section>
<section anchor="uri.comparison" title="http(s) Normalization and Co mparison"> <section anchor="uri.comparison" title="http(s) Normalization and Co mparison">
<t> <t>
The "http" and "https" URI are normalized and compared according to the URIs with an "http" or "https" scheme are normalized and compared according t o the
methods defined in <xref target="URI" section="6"/>, using methods defined in <xref target="URI" section="6"/>, using
the defaults described above for each scheme. the defaults described above for each scheme.
</t> </t>
<t> <t>
HTTP does not require use of a specific method for determining HTTP does not require the use of a specific method for determining
equivalence. For example, a cache key might be compared as a simple equivalence. For example, a cache key might be compared as a simple
string, after syntax-based normalization, or after scheme-based string, after syntax-based normalization, or after scheme-based
normalization. normalization.
</t> </t>
<t> <t>
Scheme-based normalization (<xref target="URI" section="6.2.3"/>) of "http" a nd "https" URIs involves the following Scheme-based normalization (<xref target="URI" section="6.2.3"/>) of "http" a nd "https" URIs involves the following
additional rules: additional rules:
</t> </t>
<ul> <ul>
<li>If the port is equal to the default port for a scheme, the normal form <li>If the port is equal to the default port for a scheme, the normal form
skipping to change at line 1182 skipping to change at line 1162
<li>The scheme and host are case-insensitive and normally prov ided in <li>The scheme and host are case-insensitive and normally prov ided in
lowercase; all other components are compared in a case-sensitive lowercase; all other components are compared in a case-sensitive
manner.</li> manner.</li>
<li>Characters other than those in the "reserved" set are equi valent to <li>Characters other than those in the "reserved" set are equi valent to
their percent-encoded octets: the normal form is to not encode them (see their percent-encoded octets: the normal form is to not encode them (see
Sections <xref target="URI" sectionFormat="bare" section="2.1"/> and <xref ta rget="URI" sectionFormat="bare" section="2.2"/> of <xref target="URI"/>).</li> Sections <xref target="URI" sectionFormat="bare" section="2.1"/> and <xref ta rget="URI" sectionFormat="bare" section="2.2"/> of <xref target="URI"/>).</li>
</ul> </ul>
<t> <t>
For example, the following three URIs are equivalent: For example, the following three URIs are equivalent:
</t> </t>
<artwork type="example"><![CDATA[ <artwork><![CDATA[
http://example.com:80/~smith/home.html http://example.com:80/~smith/home.html
http://EXAMPLE.com/%7Esmith/home.html http://EXAMPLE.com/%7Esmith/home.html
http://EXAMPLE.com:/%7esmith/home.html http://EXAMPLE.com:/%7esmith/home.html
]]></artwork> ]]></artwork>
<t> <t>
Two HTTP URIs that are equivalent after normalization (using any method) Two HTTP URIs that are equivalent after normalization (using any method)
can be assumed to identify the same resource, and any HTTP component <bcp14>M AY</bcp14> can be assumed to identify the same resource, and any HTTP component <bcp14>M AY</bcp14>
perform normalization. As a result, distinct resources <bcp14>SHOULD NOT</bcp 14> be perform normalization. As a result, distinct resources <bcp14>SHOULD NOT</bcp 14> be
identified by HTTP URIs that are equivalent after normalization (using any identified by HTTP URIs that are equivalent after normalization (using any
method defined in <xref target="URI" section="6.2"/>). method defined in <xref target="URI" section="6.2"/>).
skipping to change at line 1265 skipping to change at line 1245
peer has the authority to represent an origin. peer has the authority to represent an origin.
</t> </t>
<t> <t>
See <xref target="establishing.authority"/> for security considerations See <xref target="establishing.authority"/> for security considerations
related to establishing authority. related to establishing authority.
</t> </t>
<section anchor="origin" title="URI Origin"> <section anchor="origin" title="URI Origin">
<iref primary="true" item="origin"/> <iref primary="true" item="origin"/>
<iref primary="true" item="URI" subitem="origin"/> <iref primary="true" item="URI" subitem="origin"/>
<t> <t>
The <em>origin</em> for a given URI is the triple of scheme, host, The "origin" for a given URI is the triple of scheme, host,
and port after normalizing the scheme and host to lowercase and and port after normalizing the scheme and host to lowercase and
normalizing the port to remove any leading zeros. If port is elided from normalizing 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 the URI, the default port for that scheme is used. For example, the URI
</t> </t>
<artwork type="example"><![CDATA[ <artwork><![CDATA[
https://Example.Com/happy.js https://Example.Com/happy.js
]]></artwork> ]]></artwork>
<t> <t>
would have the origin would have the origin
</t> </t>
<artwork type="example"><![CDATA[ <artwork><![CDATA[
{ "https", "example.com", "443" } { "https", "example.com", "443" }
]]></artwork> ]]></artwork>
<t> <t>
which can also be described as the normalized URI prefix with port always which can also be described as the normalized URI prefix with port always
present: present:
</t> </t>
<artwork type="example"><![CDATA[ <artwork><![CDATA[
https://example.com:443 https://example.com:443
]]></artwork> ]]></artwork>
<t> <t>
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 origin within that namespace are mapped to resources. In turn, how the origin
responds to valid requests, consistently over time, determines the responds to valid requests, consistently over time, determines the
semantics that users will associate with a URI, and the usefulness of semantics that users will associate with a URI, and the usefulness of
those semantics is what ultimately transforms these mechanisms into a those semantics is what ultimately transforms these mechanisms into a
"resource" for users to reference and access in the future. resource for users to reference and access in the future.
</t> </t>
<t> <t>
Two origins are distinct if they differ in scheme, host, or port. Even Two origins are distinct if they differ in scheme, host, or port. Even
when it can be verified that the same entity controls two distinct origins, when it can be verified that the same entity controls two distinct origins,
the two namespaces under those origins are distinct unless explicitly the two namespaces under those origins are distinct unless explicitly
aliased by a server authoritative for that origin. aliased by a server authoritative for that origin.
</t> </t>
<t> <t>
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 <xref target="RFC6454"/>. scope of this document, as described in <xref target="RFC6454"/>.
</t> </t>
</section> </section>
<section anchor="http.origin" title="http origins"> <section anchor="http.origin" title="http Origins">
<t> <t>
Although HTTP is independent of the transport protocol, the "http" scheme Although HTTP is independent of the transport protocol, the "http" scheme
(<xref target="http.uri"/>) is specific to associating authority with (<xref target="http.uri"/>) is specific to associating authority with
whomever controls the origin whomever controls the origin
server listening for TCP connections on the indicated port of whatever server listening for TCP connections on the indicated port of whatever
host is identified within the authority component. This is a very weak host is identified within the authority component. This is a very weak
sense of authority because it depends on both client-specific name sense of authority because it depends on both client-specific name
resolution mechanisms and communication that might not be secured from resolution mechanisms and communication that might not be secured from
an on-path attacker. Nevertheless, it is a sufficient minimum for an on-path attacker. Nevertheless, it is a sufficient minimum for
binding "http" identifiers to an origin server for consistent resolution binding "http" identifiers to an origin server for consistent resolution
skipping to change at line 1348 skipping to change at line 1328
<t> <t>
Note, however, that the above is not the only means for obtaining an Note, however, that the above is not the only means for obtaining an
authoritative response, nor does it imply that an authoritative response authoritative response, nor does it imply that an authoritative response
is always necessary (see <xref target="CACHING"/>). is always necessary (see <xref target="CACHING"/>).
For example, the Alt-Svc header field <xref target="ALTSVC"/> allows an For example, the Alt-Svc header field <xref target="ALTSVC"/> allows an
origin server to identify other services that are also authoritative for origin server to identify other services that are also authoritative for
that origin. Access to "http" identified resources might also be provided that origin. Access to "http" identified resources might also be provided
by protocols outside the scope of this document. by protocols outside the scope of this document.
</t> </t>
</section> </section>
<section anchor="https.origin" title="https origins"> <section anchor="https.origin" title="https Origins">
<t> <t>
The "https" scheme (<xref target="https.uri"/>) associates authority based The "https" scheme (<xref target="https.uri"/>) associates authority based
on the ability of a server to use the private key corresponding to a on the ability of a server to use the private key corresponding to a
certificate that the client considers to be trustworthy for the identified certificate that the client considers to be trustworthy for the identified
origin server. The client usually relies upon a chain of trust, conveyed origin server. The client usually relies upon a chain of trust, conveyed
from some prearranged or configured trust anchor, to deem a certificate from some prearranged or configured trust anchor, to deem a certificate
trustworthy (<xref target="https.verify"/>). trustworthy (<xref target="https.verify"/>).
</t> </t>
<t> <t>
In HTTP/1.1 and earlier, a client will only attribute authority to a server In HTTP/1.1 and earlier, a client will only attribute authority to a server
skipping to change at line 1379 skipping to change at line 1359
check that the origin's host contains the same server IP address as the check that the origin's host contains the same server IP address as the
established connection. This restriction can be removed by the origin server established connection. This restriction can be removed by the origin server
sending an equivalent ORIGIN frame <xref target="RFC8336"/>. sending an equivalent ORIGIN frame <xref target="RFC8336"/>.
</t> </t>
<t> <t>
The request target's host and port value are passed within each HTTP The request target's host and port value are passed within each HTTP
request, identifying the origin and distinguishing it from other namespaces request, identifying the origin and distinguishing it from other namespaces
that might be controlled by the same server (<xref target="field.host"/>). that might be controlled by the same server (<xref target="field.host"/>).
It is the origin's responsibility to ensure that any services provided with It is the origin's responsibility to ensure that any services provided with
control over its certificate's private key are equally responsible for control over its certificate's private key are equally responsible for
managing the corresponding "https" namespaces, or at least prepared to managing the corresponding "https" namespaces or at least prepared to
reject requests that appear to have been misdirected reject requests that appear to have been misdirected
(<xref target="routing.reject"/>). (<xref target="routing.reject"/>).
</t> </t>
<t> <t>
An origin server might be unwilling to process requests for certain target An origin server might be unwilling to process requests for certain target
URIs even when they have the authority to do so. For example, when a host URIs even when they have the authority to do so. For example, when a host
operates distinct services on different ports (e.g., 443 and 8000), checking operates distinct services on different ports (e.g., 443 and 8000), checking
the target URI at the origin server is necessary (even after the connection the target URI at the origin server is necessary (even after the connection
has been secured) because a network attacker might cause connections for one has been secured) because a network attacker might cause connections for one
port to be received at some other port. Failing to check the target URI port to be received at some other port. Failing to check the target URI
skipping to change at line 1423 skipping to change at line 1403
If the server responds to such a request with a non-interim HTTP response If the server responds to such a request with a non-interim HTTP response
message, as described in <xref target="status.codes"/>, then that response message, as described in <xref target="status.codes"/>, then that response
is considered an authoritative answer to the client's request. is considered an authoritative answer to the client's request.
</t> </t>
<t> <t>
Note, however, that the above is not the only means for obtaining an Note, however, that the above is not the only means for obtaining an
authoritative response, nor does it imply that an authoritative response authoritative response, nor does it imply that an authoritative response
is always necessary (see <xref target="CACHING"/>). is always necessary (see <xref target="CACHING"/>).
</t> </t>
</section> </section>
<section anchor="https.verify" title="https certificate verification "> <section anchor="https.verify" title="https Certificate Verification ">
<t> <t>
To establish a <xref target="https.uri" format="none">secured</xref> connecti on to dereference a URI, To establish a <xref target="https.uri" format="none">secured</xref> connecti on to dereference a URI,
a client <bcp14>MUST</bcp14> verify that the service's identity is an accepta ble a client <bcp14>MUST</bcp14> verify that the service's identity is an accepta ble
match for the URI's origin server. Certificate verification is used to match for the URI's origin server. Certificate verification is used to
prevent server impersonation by an on-path attacker or by an attacker prevent server impersonation by an on-path attacker or by an attacker
that controls name resolution. This process requires that a client be that controls name resolution. This process requires that a client be
configured with a set of trust anchors. configured with a set of trust anchors.
</t> </t>
<t> <t>
In general, a client <bcp14>MUST</bcp14> verify the service identity using th e In general, a client <bcp14>MUST</bcp14> verify the service identity using th e
verification process defined in verification process defined in
<xref target="RFC6125" section="6"/>. The client <bcp14>MUST</bcp14> construc t <xref target="RFC6125" section="6"/>. The client <bcp14>MUST</bcp14> construc t
a reference identity from the service's host: if the host is a literal IP add ress a reference identity from the service's host: if the host is a literal IP add ress
(<xref target="https.ip-id"/>), the reference identity is an IP-ID, otherwise (<xref target="https.ip-id"/>), the reference identity is an IP-ID, otherwise
the host is a name and the reference identity is a DNS-ID. the host is a name and the reference identity is a DNS-ID.
</t> </t>
<t> <t>
A reference identity of type CN-ID <bcp14>MUST NOT</bcp14> be used by clients . As noted A reference identity of type CN-ID <bcp14>MUST NOT</bcp14> be used by clients . As noted
in <xref target="RFC6125" section="6.2.1"/> a reference in <xref target="RFC6125" section="6.2.1"/>, a reference
identity of type CN-ID might be used by older clients. identity of type CN-ID might be used by older clients.
</t> </t>
<t> <t>
A client might be specially configured to accept an alternative form of A client might be specially configured to accept an alternative form of
server identity verification. For example, a client might be connecting server identity verification. For example, a client might be connecting
to a server whose address and hostname are dynamic, with an expectation that to a server whose address and hostname are dynamic, with an expectation that
the service will present a specific certificate (or a certificate matching the service will present a specific certificate (or a certificate matching
some externally defined reference identity) rather than one matching the some externally defined reference identity) rather than one matching the
target URI's origin. target URI's origin.
</t> </t>
skipping to change at line 1469 skipping to change at line 1449
If the certificate is not valid for the target URI's origin, If the certificate is not valid for the target URI's origin,
a user agent <bcp14>MUST</bcp14> either obtain confirmation from the user a user agent <bcp14>MUST</bcp14> either obtain confirmation from the user
before proceeding (see <xref target="user.agent"/>) or before proceeding (see <xref target="user.agent"/>) or
terminate the connection with a bad certificate error. Automated terminate the connection with a bad certificate error. Automated
clients <bcp14>MUST</bcp14> log the error to an appropriate audit log (if ava ilable) clients <bcp14>MUST</bcp14> log the error to an appropriate audit log (if ava ilable)
and <bcp14>SHOULD</bcp14> terminate the connection (with a bad certificate er ror). and <bcp14>SHOULD</bcp14> terminate the connection (with a bad certificate er ror).
Automated clients <bcp14>MAY</bcp14> provide a configuration setting that dis ables Automated clients <bcp14>MAY</bcp14> provide a configuration setting that dis ables
this check, but <bcp14>MUST</bcp14> provide a setting which enables it. this check, but <bcp14>MUST</bcp14> provide a setting which enables it.
</t> </t>
</section> </section>
<section anchor="https.ip-id" title="IP-ID reference identity"> <section anchor="https.ip-id" title="IP-ID Reference Identity">
<t> <t>
A server that is identified using an IP address literal in the "host" field A server that is identified using an IP address literal in the "host" field
of an "https" URI has a reference identity of type IP-ID. An IP version 4 of an "https" URI has a reference identity of type IP-ID. An IP version 4
address uses the "IPv4address" ABNF rule and an IP version 6 address uses address uses the "IPv4address" ABNF rule, and an IP version 6 address uses
the "IP-literal" production with the "IPv6address" option; see the "IP-literal" production with the "IPv6address" option; see
<xref target="URI" section="3.2.2"/>. A reference identity of <xref target="URI" section="3.2.2"/>. A reference identity of
IP-ID contains the decoded bytes of the IP address. IP-ID contains the decoded bytes of the IP address.
</t> </t>
<t> <t>
An IP version 4 address is 4 octets and an IP version 6 address is 16 octets. An IP version 4 address is 4 octets, and an IP version 6 address is 16 octets .
Use of IP-ID is not defined for any other IP version. The iPAddress Use of IP-ID is not defined for any other IP version. The iPAddress
choice in the certificate subjectAltName extension does not explicitly choice in the certificate subjectAltName extension does not explicitly
include the IP version and so relies on the length of the address to include the IP version and so relies on the length of the address to
distinguish versions; see distinguish versions; see
<xref target="RFC5280" section="4.2.1.6"/>. <xref target="RFC5280" section="4.2.1.6"/>.
</t> </t>
<t> <t>
A reference identity of type IP-ID matches if the address is identical to A reference identity of type IP-ID matches if the address is identical to
an iPAddress value of the subjectAltName extension of the certificate. an iPAddress value of the subjectAltName extension of the certificate.
</t> </t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="fields" title="Fields"> <section anchor="fields" title="Fields">
<iref primary="true" item="field"/> <iref primary="true" item="field"/>
<t> <t>
HTTP uses <em>fields</em> to provide data in the form of extensible HTTP uses "fields" to provide data in the form of extensible
key/value pairs with a registered key namespace. Fields are sent and name/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
(<xref target="message.abstraction"/>). (<xref target="message.abstraction"/>).
</t> </t>
<section anchor="fields.names" title="Field Names"> <section anchor="fields.names" title="Field Names">
<t> <t>
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 <xref target="field.date" f ormat="none">Date</xref> semantics defined by that name. For example, the <xref target="field.date" f ormat="none">Date</xref>
header field is defined in <xref target="field.date"/> as containing the header field is defined in <xref target="field.date"/> as containing the
origination timestamp for the message in which it appears. origination timestamp for the message in which it appears.
</t> </t>
<iref primary="true" item="Grammar" subitem="field-name"/> <iref primary="true" item="Grammar" subitem="field-name"/>
<sourcecode type="abnf7230"><![CDATA[ field-name = token <sourcecode type="abnf9110"><![CDATA[ field-name = token
]]></sourcecode> ]]></sourcecode>
<t> <t>
Field names are case-insensitive and ought to be registered within the Field names are case-insensitive and ought to be registered within the
"Hypertext Transfer Protocol (HTTP) Field Name Registry"; see <xref target="f ields.registry"/>. "Hypertext Transfer Protocol (HTTP) Field Name Registry"; see <xref target="f ields.registry"/>.
</t> </t>
<t> <t>
The interpretation of a field does not change between minor The interpretation of a field does not change between minor
versions of the same major HTTP version, though the default behavior of a versions of the same major HTTP version, though the default behavior of a
recipient in the absence of such a field can change. Unless specified recipient in the absence of such a field can change. Unless specified
otherwise, fields are defined for all versions of HTTP. otherwise, fields are defined for all versions of HTTP.
skipping to change at line 1544 skipping to change at line 1524
Other recipients <bcp14>SHOULD</bcp14> ignore unrecognized header and trailer fields. Other recipients <bcp14>SHOULD</bcp14> ignore unrecognized header and trailer fields.
Adhering to these requirements allows HTTP's functionality to be extended Adhering to these requirements allows HTTP's functionality to be extended
without updating or removing deployed intermediaries. without updating or removing deployed intermediaries.
</t> </t>
</section> </section>
<section anchor="field.lines" title="Field Lines and Combined Field Val ue"> <section anchor="field.lines" title="Field Lines and Combined Field Val ue">
<t> <t>
<iref item="field line"/> <iref item="field line"/>
<iref item="field name"/> <iref item="field name"/>
<iref item="field line value"/> <iref item="field line value"/>
Field sections are composed of any number of <em>field lines</em>, Field sections are composed of any number of "field lines",
each with a <em>field name</em> (see <xref target="fields.names"/>) each with a "field name" (see <xref target="fields.names"/>)
identifying the field, and a <em>field line value</em> that conveys identifying the field, and a "field line value" that conveys
data for that instance of the field. data for that instance of the field.
</t> </t>
<t> <t>
<iref item="field value"/> <iref item="field value"/>
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
<em>field value</em> for that field consists of the corresponding "field value" for that field consists of the corresponding
field line value. field line value.
When a field name is repeated within a section, its combined field value When a field name is repeated within a section, its combined field value
consists of the list of corresponding field line values within that section, consists of the list of corresponding field line values within that section,
concatenated in order, with each field line value separated by a comma. concatenated in order, with each field line value separated by a comma.
</t> </t>
<t> <t>
For example, this section: For example, this section:
</t> </t>
<sourcecode type="http-message"><![CDATA[Example-Field: Foo, Bar <sourcecode type="http-message"><![CDATA[Example-Field: Foo, Bar
Example-Field: Baz Example-Field: Baz
skipping to change at line 1590 skipping to change at line 1570
</t> </t>
<t> <t>
The order in which field lines with the The order in which field lines with the
same name are received is therefore significant to the interpretation of same name are received is therefore significant to the interpretation of
the field value; a proxy <bcp14>MUST NOT</bcp14> change the order of these fi eld line the field value; a proxy <bcp14>MUST NOT</bcp14> change the order of these fi eld line
values when forwarding a message. values when forwarding a message.
</t> </t>
<t> <t>
This means that, aside from the well-known exception noted below, a sender This means that, aside from the well-known exception noted below, a sender
<bcp14>MUST NOT</bcp14> generate multiple field lines with the same name in a message <bcp14>MUST NOT</bcp14> generate multiple field lines with the same name in a message
(whether in the headers or trailers), or append a field line when a field (whether in the headers or trailers) or append a field line when a field
line of the same name already exists in the message, unless that field's line of the same name already exists in the message, unless that field's
definition allows multiple field line values to be recombined as a definition allows multiple field line values to be recombined as a
comma-separated list [i.e., at least one alternative of the field's comma-separated list (i.e., at least one alternative of the field's
definition allows a comma-separated list, such as an ABNF rule of definition allows a comma-separated list, such as an ABNF rule of
#(values) defined in <xref target="abnf.extension"/>]. #(values) defined in <xref target="abnf.extension"/>).
</t> </t>
<aside> <aside>
<t> <t>
<strong>Note:</strong> In practice, the "Set-Cookie" header fi eld (<xref target="COOKIE"/>) <strong>Note:</strong> In practice, the "Set-Cookie" header fi eld (<xref target="COOKIE"/>)
often appears in a response message across multiple field lines and does not often appears in a response message across multiple field lines and does not
use the list syntax, violating the above requirements on multiple field lines use the list syntax, violating the above requirements on multiple field lines
with the same field name. Since it cannot be combined into a single field with the same field name. Since it cannot be combined into a single field
value, recipients ought to handle "Set-Cookie" as a special case while value, recipients ought to handle "Set-Cookie" as a special case while
processing fields. (See Appendix A.2.3 of <xref target="Kri2001"/> for processing fields. (See Appendix A.2.3 of <xref target="Kri2001"/> for
details.) details.)
skipping to change at line 1655 skipping to change at line 1635
<section anchor="fields.values" title="Field Values"> <section anchor="fields.values" title="Field Values">
<t> <t>
HTTP field values consist of a sequence of characters in a format defined 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 using by the field's grammar. Each field's grammar is usually defined using
ABNF (<xref target="RFC5234"/>). ABNF (<xref target="RFC5234"/>).
</t> </t>
<iref primary="true" item="Grammar" subitem="field-value"/> <iref primary="true" item="Grammar" subitem="field-value"/>
<iref primary="true" item="Grammar" subitem="field-vchar"/> <iref primary="true" item="Grammar" subitem="field-vchar"/>
<iref primary="true" item="Grammar" subitem="field-content"/> <iref primary="true" item="Grammar" subitem="field-content"/>
<iref primary="true" item="Grammar" subitem="obs-text"/> <iref primary="true" item="Grammar" subitem="obs-text"/>
<sourcecode type="abnf7230"><![CDATA[ field-value = *field-conte nt <sourcecode type="abnf9110"><![CDATA[ field-value = *field-conte nt
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
]]></sourcecode> ]]></sourcecode>
<t> <t>
A field value does not include leading or trailing whitespace. When a A field value does not include leading or trailing whitespace. When a
specific version of HTTP allows such whitespace to appear in a message, specific version of HTTP allows such whitespace to appear in a message,
a field parsing implementation <bcp14>MUST</bcp14> exclude such whitespace pr ior to a field parsing implementation <bcp14>MUST</bcp14> exclude such whitespace pr ior to
evaluating the field value. evaluating the field value.
skipping to change at line 1694 skipping to change at line 1674
either reject the message or replace each of those characters with SP either reject the message or replace each of those characters with SP
before further processing or forwarding of that message. Field values before further processing or forwarding of that message. Field values
containing other CTL characters are also invalid; however, containing other CTL characters are also invalid; however,
recipients <bcp14>MAY</bcp14> retain such characters for the sake of robustne ss when recipients <bcp14>MAY</bcp14> retain such characters for the sake of robustne ss when
they appear within a safe context (e.g., an application-specific quoted they appear within a safe context (e.g., an application-specific quoted
string that will not be processed by any downstream HTTP parser). string that will not be processed by any downstream HTTP parser).
</t> </t>
<t> <t>
<iref item="singleton field"/> <iref item="singleton field"/>
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 <em>singleton fields</em>. referred to as "singleton fields".
</t> </t>
<t> <t>
<iref item="list-based field"/> <iref item="list-based field"/>
Fields that allow multiple members as the field value are referred to as Fields that allow multiple members as the field value are referred to as
<em>list-based fields</em>. The list operator extension of "list-based fields". The list operator extension of
<xref target="abnf.extension"/> is used as a common notation for defining <xref target="abnf.extension"/> is used as a common notation for defining
field values that can contain multiple members. field values that can contain multiple members.
</t> </t>
<t> <t>
Because commas (",") are used as the delimiter between members, they need Because commas (",") are used as the delimiter between members, they need
to be treated with care if they are allowed as data within a member. This 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 a singleton field is true for both list-based and singleton fields, since a singleton field
might be erroneously sent with multiple members and detecting such errors might be erroneously sent with multiple members and detecting such errors
improves interoperability. Fields that expect to contain a improves interoperability. Fields that expect to contain a
comma within a member, such as within an <xref target="http.date" format="non e">HTTP-date</xref> or comma within a member, such as within an <xref target="http.date" format="non e">HTTP-date</xref> or
skipping to change at line 1765 skipping to change at line 1745
at least &lt;n&gt; and at most &lt;m&gt; elements, each separated by a single at least &lt;n&gt; and at most &lt;m&gt; elements, each separated by a single
comma (",") and optional whitespace (<xref target="whitespace" format="none"> OWS</xref>, comma (",") and optional whitespace (<xref target="whitespace" format="none"> OWS</xref>,
defined in <xref target="whitespace"/>). defined in <xref target="whitespace"/>).
</t> </t>
<section anchor="abnf.extension.sender" title="Sender Requirement s"> <section anchor="abnf.extension.sender" title="Sender Requirement s">
<t> <t>
In any production that uses the list construct, a sender <bcp14>MUST NOT</bcp 14> In any production that uses the list construct, a sender <bcp14>MUST NOT</bcp 14>
generate empty list elements. In other words, a sender has to generate generate empty list elements. In other words, a sender has to generate
lists that satisfy the following syntax: lists that satisfy the following syntax:
</t> </t>
<artwork type="example"><![CDATA[ <artwork><![CDATA[
1#element => element *( OWS "," OWS element ) 1#element => element *( OWS "," OWS element )
]]></artwork> ]]></artwork>
<t> <t>
and: and:
</t> </t>
<artwork type="example"><![CDATA[ <artwork><![CDATA[
#element => [ 1#element ] #element => [ 1#element ]
]]></artwork> ]]></artwork>
<t> <t>
and for n &gt;= 1 and m &gt; 1: and for n &gt;= 1 and m &gt; 1:
</t> </t>
<artwork type="example"><![CDATA[ <artwork><![CDATA[
<n>#<m>element => element <n-1>*<m-1>( OWS "," OWS element ) <n>#<m>element => element <n-1>*<m-1>( OWS "," OWS element )
]]></artwork> ]]></artwork>
<t> <t>
<xref target="collected.abnf"/> shows the collected ABNF fo r senders <xref target="collected.abnf"/> shows the collected ABNF fo r senders
after the list constructs have been expanded. after the list constructs have been expanded.
</t> </t>
</section> </section>
<section anchor="abnf.extension.recipient" title="Recipient Requi rements"> <section anchor="abnf.extension.recipient" title="Recipient Requi rements">
<t> <t>
Empty elements do not contribute to the count of elements present. Empty elements do not contribute to the count of elements present.
A recipient <bcp14>MUST</bcp14> parse and ignore A recipient <bcp14>MUST</bcp14> parse and ignore
a reasonable number of empty list elements: enough to handle common mistakes a reasonable number of empty list elements: enough to handle common mistakes
by senders that merge values, but not so much that they could be used as a by senders that merge values, but not so much that they could be used as a
denial-of-service mechanism. In other words, a recipient <bcp14>MUST</bcp14> accept lists denial-of-service mechanism. In other words, a recipient <bcp14>MUST</bcp14> accept lists
that satisfy the following syntax: that satisfy the following syntax:
</t> </t>
<artwork type="example"><![CDATA[ <artwork><![CDATA[
#element => [ element ] *( OWS "," OWS [ element ] ) #element => [ element ] *( OWS "," OWS [ element ] )
]]></artwork> ]]></artwork>
<t> <t>
Note that because of the potential presence of empty list elements, the Note that because of the potential presence of empty list elements, the
RFC 5234 ABNF cannot enforce the cardinality of list elements, and RFC 5234 ABNF cannot enforce the cardinality of list elements, and
consequently all cases are mapped as if there was no cardinality specified. consequently all cases are mapped as if there was no cardinality specified.
</t> </t>
<t> <t>
For example, given these ABNF productions: For example, given these ABNF productions:
</t> </t>
<artwork type="example"><![CDATA[ <artwork><![CDATA[
example-list = 1#example-list-elmt example-list = 1#example-list-elmt
example-list-elmt = token ; see Section 5.6.2 example-list-elmt = token ; see Section 5.6.2
]]></artwork> ]]></artwork>
<t> <t>
Then the following are valid values for example-list (not including the Then the following are valid values for example-list (not including the
double quotes, which are present for delimitation only): double quotes, which are present for delimitation only):
</t> </t>
<artwork type="example"><![CDATA[ <artwork><![CDATA[
"foo,bar" "foo,bar"
"foo ,bar," "foo ,bar,"
"foo , ,bar,charlie" "foo , ,bar,charlie"
]]></artwork> ]]></artwork>
<t> <t>
In contrast, the following values would be invalid, since at least one In contrast, the following values would be invalid, since at least one
non-empty element is required by the example-list production: non-empty element is required by the example-list production:
</t> </t>
<artwork type="example"><![CDATA[ <artwork><![CDATA[
"" ""
"," ","
", ," ", ,"
]]></artwork> ]]></artwork>
</section> </section>
</section> </section>
<section anchor="tokens" title="Tokens"> <section anchor="tokens" title="Tokens">
<t anchor="rule.token.separators"> <t anchor="rule.token.separators">
Tokens are short textual identifiers that do not include whitespace or Tokens are short textual identifiers that do not include whitespace or
delimiters. delimiters.
</t> </t>
<iref primary="true" item="Grammar" subitem="token"/> <iref primary="true" item="Grammar" subitem="token"/>
<iref primary="true" item="Grammar" subitem="tchar"/> <iref primary="true" item="Grammar" subitem="tchar"/>
<sourcecode type="abnf7230"><![CDATA[ token = 1*tchar <sourcecode type="abnf9110"><![CDATA[ token = 1*tchar
tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*"
/ "+" / "-" / "." / "^" / "_" / "`" / "|" / "~" / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~"
/ DIGIT / ALPHA / DIGIT / ALPHA
; any VCHAR, except delimiters ; any VCHAR, except delimiters
]]></sourcecode> ]]></sourcecode>
<t anchor="delimiters"> <t anchor="delimiters">
<iref item="Delimiters"/> <iref item="Delimiters"/>
Many HTTP field values are defined using common syntax Many HTTP field values are defined using common syntax
components, separated by whitespace or specific delimiting characters. components, separated by whitespace or specific delimiting characters.
skipping to change at line 1889 skipping to change at line 1869
interpreting the protocol element. interpreting the protocol element.
</t> </t>
<t> <t>
BWS has no semantics. Any content known to be BWS has no semantics. Any content known to be
defined as BWS <bcp14>MAY</bcp14> be removed before interpreting it or forwar ding the defined as BWS <bcp14>MAY</bcp14> be removed before interpreting it or forwar ding the
message downstream. message downstream.
</t> </t>
<iref primary="true" item="Grammar" subitem="OWS"/> <iref primary="true" item="Grammar" subitem="OWS"/>
<iref primary="true" item="Grammar" subitem="RWS"/> <iref primary="true" item="Grammar" subitem="RWS"/>
<iref primary="true" item="Grammar" subitem="BWS"/> <iref primary="true" item="Grammar" subitem="BWS"/>
<sourcecode type="abnf7230"><![CDATA[ OWS = *( SP / H TAB ) <sourcecode type="abnf9110"><![CDATA[ OWS = *( SP / H TAB )
; optional whitespace ; optional whitespace
RWS = 1*( SP / HTAB ) RWS = 1*( SP / HTAB )
; required whitespace ; required whitespace
BWS = OWS BWS = OWS
; "bad" whitespace ; "bad" whitespace
]]></sourcecode> ]]></sourcecode>
</section> </section>
<section anchor="quoted.strings" title="Quoted Strings"> <section anchor="quoted.strings" title="Quoted Strings">
<t anchor="rule.quoted-string"> <t anchor="rule.quoted-string">
A string of text is parsed as a single value if it is quoted using A string of text is parsed as a single value if it is quoted using
double-quote marks. double-quote marks.
</t> </t>
<iref primary="true" item="Grammar" subitem="quoted-string"/> <iref primary="true" item="Grammar" subitem="quoted-string"/>
<iref primary="true" item="Grammar" subitem="qdtext"/> <iref primary="true" item="Grammar" subitem="qdtext"/>
<sourcecode type="abnf7230"><![CDATA[ quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE <sourcecode type="abnf9110"><![CDATA[ quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE
qdtext = HTAB / SP / %x21 / %x23-5B / %x5D-7E / obs-text qdtext = HTAB / SP / %x21 / %x23-5B / %x5D-7E / obs-text
]]></sourcecode> ]]></sourcecode>
<t anchor="rule.quoted-pair"> <t anchor="rule.quoted-pair">
The backslash octet ("\") can be used as a single-octet The backslash octet ("\") can be used as a single-octet
quoting mechanism within quoted-string and comment constructs. quoting mechanism within quoted-string and comment constructs.
Recipients that process the value of a quoted-string <bcp14>MUST</bcp14> hand le a Recipients that process the value of a quoted-string <bcp14>MUST</bcp14> hand le a
quoted-pair as if it were replaced by the octet following the backslash. quoted-pair as if it were replaced by the octet following the backslash.
</t> </t>
<iref primary="true" item="Grammar" subitem="quoted-pair"/> <iref primary="true" item="Grammar" subitem="quoted-pair"/>
<sourcecode type="abnf7230"><![CDATA[ quoted-pair = "\" ( HTA B / SP / VCHAR / obs-text ) <sourcecode type="abnf9110"><![CDATA[ quoted-pair = "\" ( HTA B / SP / VCHAR / obs-text )
]]></sourcecode> ]]></sourcecode>
<t> <t>
A sender <bcp14>SHOULD NOT</bcp14> generate a quoted-pair in a quoted-string except A sender <bcp14>SHOULD NOT</bcp14> generate a quoted-pair in a quoted-string except
where necessary to quote DQUOTE and backslash octets occurring within that where necessary to quote DQUOTE and backslash octets occurring within that
string. string.
A sender <bcp14>SHOULD NOT</bcp14> generate a quoted-pair in a comment except A sender <bcp14>SHOULD NOT</bcp14> generate a quoted-pair in a comment except
where necessary to quote parentheses ["(" and ")"] and backslash octets where necessary to quote parentheses ["(" and ")"] and backslash octets
occurring within that comment. occurring within that comment.
</t> </t>
</section> </section>
<section anchor="comments" title="Comments"> <section anchor="comments" title="Comments">
<t anchor="rule.comment"> <t anchor="rule.comment">
Comments can be included in some HTTP fields by surrounding Comments can be included in some HTTP fields by surrounding
the comment text with parentheses. Comments are only allowed in the comment text with parentheses. Comments are only allowed in
fields containing "comment" as part of their field value definition. fields containing "comment" as part of their field value definition.
</t> </t>
<iref primary="true" item="Grammar" subitem="comment"/> <iref primary="true" item="Grammar" subitem="comment"/>
<iref primary="true" item="Grammar" subitem="ctext"/> <iref primary="true" item="Grammar" subitem="ctext"/>
<sourcecode type="abnf7230"><![CDATA[ comment = "(" *( ct ext / quoted-pair / comment ) ")" <sourcecode type="abnf9110"><![CDATA[ comment = "(" *( ct ext / quoted-pair / comment ) ")"
ctext = HTAB / SP / %x21-27 / %x2A-5B / %x5D-7E / obs-text ctext = HTAB / SP / %x21-27 / %x2A-5B / %x5D-7E / obs-text
]]></sourcecode> ]]></sourcecode>
</section> </section>
<section anchor="parameter" title="Parameters"> <section anchor="parameter" title="Parameters">
<t anchor="rule.parameter"> <t anchor="rule.parameter">
Parameters are instances of name=value pairs; they are often used in field Parameters are instances of name/value pairs; they are often used in field
values as a common syntax for appending auxiliary information to an item. values as a common syntax for appending auxiliary information to an item.
Each parameter is usually delimited by an immediately preceding semicolon. Each parameter is usually delimited by an immediately preceding semicolon.
</t> </t>
<iref primary="true" item="Grammar" subitem="parameters"/> <iref primary="true" item="Grammar" subitem="parameters"/>
<iref primary="true" item="Grammar" subitem="parameter"/> <iref primary="true" item="Grammar" subitem="parameter"/>
<iref primary="true" item="Grammar" subitem="parameter-name"/> <iref primary="true" item="Grammar" subitem="parameter-name"/>
<iref primary="true" item="Grammar" subitem="parameter-value"/> <iref primary="true" item="Grammar" subitem="parameter-value"/>
<sourcecode type="abnf7230"><![CDATA[ parameters = *( OWS " ;" OWS [ parameter ] ) <sourcecode type="abnf9110"><![CDATA[ parameters = *( OWS " ;" OWS [ parameter ] )
parameter = parameter-name "=" parameter-value parameter = parameter-name "=" parameter-value
parameter-name = token parameter-name = token
parameter-value = ( token / quoted-string ) parameter-value = ( token / quoted-string )
]]></sourcecode> ]]></sourcecode>
<t> <t>
Parameter names are case-insensitive. Parameter values might or might Parameter names are case-insensitive. Parameter values might or might
not be case-sensitive, depending on the semantics of the parameter not be case-sensitive, depending on the semantics of the parameter
name. Examples of parameters and some equivalent forms can be seen in name. Examples of parameters and some equivalent forms can be seen in
media types (<xref target="media.type"/>) and the Accept header field media types (<xref target="media.type"/>) and the Accept header field
(<xref target="field.accept"/>). (<xref target="field.accept"/>).
skipping to change at line 1985 skipping to change at line 1965
<section anchor="http.date" title="Date/Time Formats"> <section anchor="http.date" title="Date/Time Formats">
<iref primary="true" item="clock"/> <iref primary="true" item="clock"/>
<t> <t>
Prior to 1995, there were three different formats commonly used by servers Prior to 1995, there were three different formats commonly used by servers
to communicate timestamps. For compatibility with old implementations, all to communicate timestamps. For compatibility with old implementations, all
three are defined here. The preferred format is a fixed-length and three are defined here. The preferred format is a fixed-length and
single-zone subset of the date and time specification used by the single-zone subset of the date and time specification used by the
Internet Message Format <xref target="RFC5322"/>. Internet Message Format <xref target="RFC5322"/>.
</t> </t>
<iref primary="true" item="Grammar" subitem="HTTP-date"/> <iref primary="true" item="Grammar" subitem="HTTP-date"/>
<sourcecode type="abnf7230"><![CDATA[ HTTP-date = IMF-fixdate / obs-date <sourcecode type="abnf9110"><![CDATA[ HTTP-date = IMF-fixdate / obs-date
]]></sourcecode> ]]></sourcecode>
<t> <t>
An example of the preferred format is An example of the preferred format is
</t> </t>
<artwork type="example"><![CDATA[ <artwork><![CDATA[
Sun, 06 Nov 1994 08:49:37 GMT ; IMF-fixdate Sun, 06 Nov 1994 08:49:37 GMT ; IMF-fixdate
]]></artwork> ]]></artwork>
<t> <t>
Examples of the two obsolete formats are Examples of the two obsolete formats are
</t> </t>
<artwork type="example"><![CDATA[ <artwork><![CDATA[
Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format
Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format
]]></artwork> ]]></artwork>
<t> <t>
A recipient that parses a timestamp value in an HTTP field <bcp14>MUST</bcp14 > A recipient that parses a timestamp value in an HTTP field <bcp14>MUST</bcp14 >
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, that contains one or more timestamps defined as HTTP-date,
the sender <bcp14>MUST</bcp14> generate those timestamps in the IMF-fixdate f ormat. the sender <bcp14>MUST</bcp14> generate those timestamps in the IMF-fixdate f ormat.
</t> </t>
<t> <t>
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 predecessor three-letter abbreviation for Greenwich Mean Time, "GMT", a predecessor
of the UTC name; values in the asctime format are assumed to be in UTC. of the UTC name; values in the asctime format are assumed to be in UTC.
</t> </t>
<t> <t>
A <em>clock</em> is an implementation capable of providing a A "clock" is an implementation capable of providing a
reasonable approximation of the current instant in UTC. reasonable approximation of the current instant in UTC.
A clock implementation ought to use NTP (<xref target="RFC5905"/>), A clock implementation ought to use NTP (<xref target="RFC5905"/>),
or some similar protocol, to synchronize with UTC. or some similar protocol, to synchronize with UTC.
</t> </t>
<t anchor="preferred.date.format"> <t anchor="preferred.date.format">
Preferred format: Preferred format:
</t> </t>
<iref primary="true" item="Grammar" subitem="IMF-fixdate"/> <iref primary="true" item="Grammar" subitem="IMF-fixdate"/>
<iref primary="true" item="Grammar" subitem="date1"/> <iref primary="true" item="Grammar" subitem="date1"/>
<iref primary="true" item="Grammar" subitem="time-of-day"/> <iref primary="true" item="Grammar" subitem="time-of-day"/>
<iref primary="true" item="Grammar" subitem="hour"/> <iref primary="true" item="Grammar" subitem="hour"/>
<iref primary="true" item="Grammar" subitem="minute"/> <iref primary="true" item="Grammar" subitem="minute"/>
<iref primary="true" item="Grammar" subitem="second"/> <iref primary="true" item="Grammar" subitem="second"/>
<iref primary="true" item="Grammar" subitem="day-name"/> <iref primary="true" item="Grammar" subitem="day-name"/>
<iref primary="true" item="Grammar" subitem="day-name-l"/> <iref primary="true" item="Grammar" subitem="day-name-l"/>
<iref primary="true" item="Grammar" subitem="day"/> <iref primary="true" item="Grammar" subitem="day"/>
<iref primary="true" item="Grammar" subitem="month"/> <iref primary="true" item="Grammar" subitem="month"/>
<iref primary="true" item="Grammar" subitem="year"/> <iref primary="true" item="Grammar" subitem="year"/>
<iref primary="true" item="Grammar" subitem="GMT"/> <iref primary="true" item="Grammar" subitem="GMT"/>
<sourcecode type="abnf7230"><![CDATA[ IMF-fixdate = day-name ", " SP date1 SP time-of-day SP GMT <sourcecode type="abnf9110"><![CDATA[ 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"
date1 = day SP month SP year date1 = day SP month SP year
; e.g., 02 Jun 1982 ; e.g., 02 Jun 1982
day = 2DIGIT day = 2DIGIT
skipping to change at line 2064 skipping to change at line 2044
hour = 2DIGIT hour = 2DIGIT
minute = 2DIGIT minute = 2DIGIT
second = 2DIGIT second = 2DIGIT
]]></sourcecode> ]]></sourcecode>
<t anchor="obsolete.date.formats"> <t anchor="obsolete.date.formats">
Obsolete formats: Obsolete formats:
</t> </t>
<iref primary="true" item="Grammar" subitem="obs-date"/> <iref primary="true" item="Grammar" subitem="obs-date"/>
<sourcecode type="abnf7230"><![CDATA[ obs-date = rfc850-date / asctime-date <sourcecode type="abnf9110"><![CDATA[ obs-date = rfc850-date / asctime-date
]]></sourcecode> ]]></sourcecode>
<iref primary="true" item="Grammar" subitem="rfc850-date"/> <iref primary="true" item="Grammar" subitem="rfc850-date"/>
<sourcecode type="abnf7230"><![CDATA[ rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT <sourcecode type="abnf9110"><![CDATA[ rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT
date2 = day "-" month "-" 2DIGIT date2 = day "-" month "-" 2DIGIT
; e.g., 02-Jun-82 ; e.g., 02-Jun-82
day-name-l = %s"Monday" / %s"Tuesday" / %s"Wednesday" day-name-l = %s"Monday" / %s"Tuesday" / %s"Wednesday"
/ %s"Thursday" / %s"Friday" / %s"Saturday" / %s"Thursday" / %s"Friday" / %s"Saturday"
/ %s"Sunday" / %s"Sunday"
]]></sourcecode> ]]></sourcecode>
<iref primary="true" item="Grammar" subitem="asctime-date"/> <iref primary="true" item="Grammar" subitem="asctime-date"/>
<sourcecode type="abnf7230"><![CDATA[ asctime-date = day-name SP date3 SP time-of-day SP year <sourcecode type="abnf9110"><![CDATA[ asctime-date = day-name SP date3 SP time-of-day SP year
date3 = month SP ( 2DIGIT / ( SP 1DIGIT )) date3 = month SP ( 2DIGIT / ( SP 1DIGIT ))
; e.g., Jun 2 ; e.g., Jun 2
]]></sourcecode> ]]></sourcecode>
<t> <t>
HTTP-date is case sensitive. Note that <xref target="CACHING" section="4.2"/> relaxes this for cache recipients. HTTP-date is case sensitive. Note that <xref target="CACHING" section="4.2"/> relaxes this for cache recipients.
</t> </t>
<t> <t>
A sender <bcp14>MUST NOT</bcp14> generate additional whitespace in an HTTP-da te beyond A sender <bcp14>MUST NOT</bcp14> generate additional whitespace in an HTTP-da te beyond
that specifically included as SP in the grammar. that specifically included as SP in the grammar.
The semantics of <xref target="preferred.date.format" format="none">day-name< /xref>, <xref target="preferred.date.format" format="none">day</xref>, The semantics of <xref target="preferred.date.format" format="none">day-name< /xref>, <xref target="preferred.date.format" format="none">day</xref>,
skipping to change at line 2106 skipping to change at line 2086
</t> </t>
<t> <t>
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. timestamps unless otherwise restricted by the field definition.
For example, messages are occasionally forwarded over HTTP from a non-HTTP For example, messages are occasionally forwarded over HTTP from a non-HTTP
source that might generate any of the date and time specifications defined source that might generate any of the date and time specifications defined
by the Internet Message Format. by the Internet Message Format.
</t> </t>
<aside> <aside>
<t> <t>
<strong>Note:</strong> HTTP requirements for the date/time stamp format apply only <strong>Note:</strong> HTTP requirements for timestamp form ats apply only
to their usage within the protocol stream. Implementations are to their usage within the protocol stream. Implementations are
not required to use these formats for user presentation, request not required to use these formats for user presentation, request
logging, etc. logging, etc.
</t> </t>
</aside> </aside>
</section> </section>
</section> </section>
</section> </section>
<section anchor="message.abstraction" title="Message Abstraction"> <section anchor="message.abstraction" title="Message Abstraction">
<iref primary="true" item="message abstraction"/> <iref primary="true" item="message abstraction"/>
skipping to change at line 2129 skipping to change at line 2109
<t> <t>
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 messages. This section defines an abstract data type for HTTP messages
based on a generalization of those message characteristics, common structure, based on a generalization of those message characteristics, common structure,
and capacity for conveying semantics. This abstraction is used to define and capacity for conveying semantics. This abstraction is used to define
requirements on senders and recipients that are independent of the HTTP requirements on senders and recipients that are independent of the HTTP
version, such that a message in one version can be relayed through other version, such that a message in one version can be relayed through other
versions without changing its meaning. versions without changing its meaning.
</t> </t>
<t> <t>
A <em>message</em> consists of control data to describe and route the A "message" consists of the following:
message, a headers lookup table of key/value pairs for extending that
control data and conveying additional information about the sender, message,
content, or context, a potentially unbounded stream of content, and a
trailers lookup table of key/value pairs for communicating information
obtained while sending the content.
</t> </t>
<ul>
<li>control data to describe and route the message,</li>
<li>a headers lookup table of name/value pairs for extending that co
ntrol
data and conveying additional information about the sender, message,
content, or context,</li>
<li>a potentially unbounded stream of content, and</li>
<li>a trailers lookup table of name/value pairs for communicating in
formation
obtained while sending the content.</li>
</ul>
<t> <t>
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 content, containing fields for the headers table. When a message includes content,
the content is sent after the header section, potentially followed by a the content is sent after the header section, potentially followed by a
trailer section that might contain fields for the trailers table. trailer section that might contain fields for the trailers table.
</t> </t>
<t> <t>
Messages are expected to be processed as a stream, wherein the purpose of Messages are expected to be processed as a stream, wherein the purpose of
that stream and its continued processing is revealed while being read. that stream and its continued processing is revealed while being read.
Hence, control data describes what the recipient needs to know immediately, Hence, control data describes what the recipient needs to know immediately,
header fields describe what needs to be known before receiving content, header fields describe what needs to be known before receiving content,
the content (when present) presumably contains what the recipient wants or the content (when present) presumably contains what the recipient wants or
needs to fulfill the message semantics, and trailer fields provide needs to fulfill the message semantics, and trailer fields provide
optional metadata that was unknown prior to sending the content. optional metadata that was unknown prior to sending the content.
</t> </t>
<t> <t>
Messages are intended to be <em>self-descriptive</em>: Messages are intended to be "self-descriptive":
everything a recipient needs to know about the message can be determined by everything a recipient needs to know about the message can be determined by
looking at the message itself, after decoding or reconstituting parts that looking at the message itself, after decoding or reconstituting parts that
have been compressed or elided in transit, without requiring an have been compressed or elided in transit, without requiring an
understanding of the sender's current application state (established via understanding of the sender's current application state (established via
prior messages). However, a client <bcp14>MUST</bcp14> retain knowledge of th e request when prior messages). However, a client <bcp14>MUST</bcp14> retain knowledge of th e request when
parsing, interpreting, or caching a corresponding response. For example, parsing, interpreting, or caching a corresponding response. For example,
responses to the <xref target="HEAD" format="none">HEAD</xref> method look ju st like the beginning of a responses to the <xref target="HEAD" format="none">HEAD</xref> method look ju st like the beginning of a
response to <xref target="GET" format="none">GET</xref>, but cannot be parsed in the same manner. response to <xref target="GET" format="none">GET</xref> but cannot be parsed in the same manner.
</t> </t>
<t> <t>
Note that this message abstraction is a generalization across many versions Note that this message abstraction is a generalization across many versions
of HTTP, including features that might not be found in some versions. For of HTTP, including features that might not be found in some versions. For
example, trailers were introduced within the HTTP/1.1 chunked transfer example, trailers were introduced within the HTTP/1.1 chunked transfer
coding as a trailer section after the content. An equivalent feature is coding as a trailer section after the content. An equivalent feature is
present in HTTP/2 and HTTP/3 within the header block that terminates each present in HTTP/2 and HTTP/3 within the header block that terminates each
stream. stream.
</t> </t>
<section anchor="message.framing" title="Framing and Completeness"> <section anchor="message.framing" title="Framing and Completeness">
skipping to change at line 2187 skipping to change at line 2171
</t> </t>
<t> <t>
HTTP/0.9 and early deployments of HTTP/1.0 used closure of the underlying HTTP/0.9 and early deployments of HTTP/1.0 used closure of the underlying
connection to end a response. For backwards compatibility, this implicit connection to end a response. For backwards compatibility, this implicit
framing is also allowed in HTTP/1.1. However, implicit framing can fail to framing is also allowed in HTTP/1.1. However, implicit framing can fail to
distinguish an incomplete response if the connection closes early. For distinguish an incomplete response if the connection closes early. For
that reason, almost all modern implementations use explicit framing in that reason, almost all modern implementations use explicit framing in
the form of length-delimited sequences of message data. the form of length-delimited sequences of message data.
</t> </t>
<t> <t>
A message is considered <em>complete</em> when all of the octets A message is considered "complete" when all of the octets
indicated by its framing are available. Note that, indicated by its framing are available. Note that,
when no explicit framing is used, a response message that is ended when no explicit framing is used, a response message that is ended
by the underlying connection's close is considered complete even though it by the underlying connection's close is considered complete even though it
might be indistinguishable from an incomplete response, unless a might be indistinguishable from an incomplete response, unless a
transport-level error indicates that it is not complete. transport-level error indicates that it is not complete.
</t> </t>
</section> </section>
<section anchor="message.control.data" title="Control Data"> <section anchor="message.control.data" title="Control Data">
<iref primary="true" item="control data"/> <iref primary="true" item="control data"/>
<t> <t>
skipping to change at line 2262 skipping to change at line 2246
recipient is conformant. A recipient can assume that a message with a recipient is conformant. A recipient can assume that a message with a
higher minor version, when sent to a recipient that has not yet indicated higher minor version, when sent to a recipient that has not yet indicated
support for that higher version, is sufficiently backwards-compatible to be support for that higher version, is sufficiently backwards-compatible to be
safely processed by any implementation of the same major version. safely processed by any implementation of the same major version.
</t> </t>
</section> </section>
<section anchor="header.fields" title="Header Fields"> <section anchor="header.fields" title="Header Fields">
<iref primary="true" item="header section"/> <iref primary="true" item="header section"/>
<iref item="field"/> <iref item="field"/>
<t> <t>
Fields (<xref target="fields"/>) that are sent/received before the content Fields (<xref target="fields"/>) that are sent or received before the content
are referred to as "header fields" (or just "headers", colloquially). are referred to as "header fields" (or just "headers", colloquially).
</t> </t>
<t> <t>
The <em>header section</em> of a message consists of a sequence of The "header section" of a message consists of a sequence of
header field lines. Each header field might modify or extend message header field lines. Each header field might modify or extend message
semantics, describe the sender, define the content, or provide additional semantics, describe the sender, define the content, or provide additional
context. context.
</t> </t>
<aside> <aside>
<t> <t>
<strong>Note:</strong> We refer to named fields specifically a s a "header field" when they <strong>Note:</strong> We refer to named fields specifically a s a "header field" when they
are only allowed to be sent in the header section. are only allowed to be sent in the header section.
</t> </t>
</aside> </aside>
</section> </section>
<section anchor="content" title="Content"> <section anchor="content" title="Content">
<iref item="content"/> <iref item="content"/>
<t> <t>
HTTP messages often transfer a complete or partial representation as the HTTP messages often transfer a complete or partial representation as the
message <em>content</em>: a stream of octets sent after the header message "content": a stream of octets sent after the header
section, as delineated by the message framing. section, as delineated by the message framing.
</t> </t>
<t> <t>
This abstract definition of content reflects the data after it has been This abstract definition of content reflects the data after it has been
extracted from the message framing. For example, an HTTP/1.1 message body extracted from the message framing. For example, an HTTP/1.1 message body
(<xref target="HTTP11" section="6"/>) might consist of a stream of data encod ed (<xref target="HTTP11" section="6"/>) might consist of a stream of data encod ed
with the chunked transfer coding — a sequence of data chunks, one with the chunked transfer coding -- a sequence of data chunks, one
zero-length chunk, and a trailer section — whereas zero-length chunk, and a trailer section -- whereas
the content of that same message the content of that same message
includes only the data stream after the transfer coding has been decoded; includes only the data stream after the transfer coding has been decoded;
it does not include the chunk lengths, chunked framing syntax, nor the it does not include the chunk lengths, chunked framing syntax, nor the
trailer fields (<xref target="trailer.fields"/>). trailer fields (<xref target="trailer.fields"/>).
</t> </t>
<aside> <aside>
<t> <t>
<strong>Note:</strong> Some field names have a "Content-" pref ix. This is an informal <strong>Note:</strong> Some field names have a "Content-" pref ix. This is an informal
convention; while some of these fields refer to the content of the convention; while some of these fields refer to the content of the
message, as defined above, others are scoped to the selected representatio n message, as defined above, others are scoped to the selected representatio n
skipping to change at line 2420 skipping to change at line 2404
representation of the resource identified by the Content-Location representation of the resource identified by the Content-Location
field value. However, such an assertion cannot be trusted unless field value. However, such an assertion cannot be trusted unless
it can be verified by other means (not defined by this specification).</l i> it can be verified by other means (not defined by this specification).</l i>
<li>Otherwise, the content is unidentified by HTTP, but a more specific <li>Otherwise, the content is unidentified by HTTP, but a more specific
identifier might be supplied within the content itself.</li> identifier might be supplied within the content itself.</li>
</ol> </ol>
</section> </section>
</section> </section>
<section anchor="trailer.fields" title="Trailer Fields"> <section anchor="trailer.fields" title="Trailer Fields">
<iref primary="true" item="trailer section"/> <iref primary="true" item="trailer section"/>
<iref primary="true" item="trailer fields"/> <iref primary="true" item="Trailer Fields"/>
<iref primary="true" item="trailers"/> <iref primary="true" item="trailers"/>
<t> <t>
Fields (<xref target="fields"/>) that are located within a Fields (<xref target="fields"/>) that are located within a
<em>trailer section</em> are referred to as "trailer fields" "trailer section" are referred to as "trailer fields"
(or just "trailers", colloquially). (or just "trailers", colloquially).
Trailer fields can be useful for supplying message integrity checks, digital Trailer fields can be useful for supplying message integrity checks, digital
signatures, delivery metrics, or post-processing status information. signatures, delivery metrics, or post-processing status information.
</t> </t>
<t> <t>
Trailer fields ought to be processed and stored separately from the fields Trailer fields ought to be processed and stored separately from the fields
in the header section to avoid contradicting message semantics known at in the header section to avoid contradicting message semantics known at
the time the header section was complete. The presence or absence of the time the header section was complete. The presence or absence of
certain header fields might impact choices made for the routing or certain header fields might impact choices made for the routing or
processing of the message as a whole before the trailers are received; processing of the message as a whole before the trailers are received;
those choices cannot be unmade by the later discovery of trailer fields. those choices cannot be unmade by the later discovery of trailer fields.
</t> </t>
<section anchor="trailers.limitations" title="Limitations on use of Trailers"> <section anchor="trailers.limitations" title="Limitations on Use of Trailers">
<t> <t>
A trailer section is only possible when supported by the version A trailer section is only possible when supported by the version
of HTTP in use and enabled by an explicit framing mechanism. of HTTP in use and enabled by an explicit framing mechanism.
For example, the chunked coding in HTTP/1.1 allows a trailer section to be For example, the chunked transfer coding in HTTP/1.1 allows a trailer section to be
sent after the content (<xref target="HTTP11" section="7.1.2"/>). sent after the content (<xref target="HTTP11" section="7.1.2"/>).
</t> </t>
<t> <t>
Many fields cannot be processed outside the header section because Many fields cannot be processed outside the header section because
their evaluation is necessary prior to receiving the content, such as their evaluation is necessary prior to receiving the content, such as
those that describe message framing, routing, authentication, those that describe message framing, routing, authentication,
request modifiers, response controls, or content format. request modifiers, response controls, or content format.
A sender <bcp14>MUST NOT</bcp14> generate a trailer field unless the sender k nows the A sender <bcp14>MUST NOT</bcp14> generate a trailer field unless the sender k nows the
corresponding header field name's definition permits the field to be sent corresponding header field name's definition permits the field to be sent
in trailers. in trailers.
skipping to change at line 2498 skipping to change at line 2482
<t> <t>
Like header fields, trailer fields with the same name are processed in the Like header fields, trailer fields with the same name are processed in the
order received; multiple trailer field lines with the same name have the order received; multiple trailer field lines with the same name have the
equivalent semantics as appending the multiple values as a list of members. equivalent semantics as appending the multiple values as a list of members.
Trailer fields that might be generated more than once during a message Trailer fields that might be generated more than once during a message
<bcp14>MUST</bcp14> be defined as a list-based field even if each member valu e is only <bcp14>MUST</bcp14> be defined as a list-based field even if each member valu e is only
processed once per field line received. processed once per field line received.
</t> </t>
<t> <t>
At the end of a message, a recipient <bcp14>MAY</bcp14> treat the set of rece ived At the end of a message, a recipient <bcp14>MAY</bcp14> treat the set of rece ived
trailer fields as a data structure of key/value pairs, similar to (but trailer fields as a data structure of name/value pairs, similar to (but
separate from) the header fields. Additional processing expectations, if separate from) the header fields. Additional processing expectations, if
any, can be defined within the field specification for a field intended any, can be defined within the field specification for a field intended
for use in trailers. for use in trailers.
</t> </t>
</section> </section>
</section> </section>
<section anchor="message.metadata" title="Message Metadata"> <section anchor="message.metadata" title="Message Metadata">
<t> <t>
Fields that describe the message itself, such as when and how the Fields that describe the message itself, such as when and how the
message has been generated, can appear in both requests and responses. message has been generated, can appear in both requests and responses.
skipping to change at line 2521 skipping to change at line 2505
<iref primary="true" item="Fields" subitem="Date"/> <iref primary="true" item="Fields" subitem="Date"/>
<iref primary="true" item="Header Fields" subitem="Date"/> <iref primary="true" item="Header Fields" subitem="Date"/>
<iref primary="true" item="Date header field"/> <iref primary="true" item="Date header field"/>
<t> <t>
The "Date" header field represents the date and time at which The "Date" header field represents the date and time at which
the message was originated, having the same semantics as the Origination the message was originated, having the same semantics as the Origination
Date Field (orig-date) defined in <xref target="RFC5322" section="3.6.1"/>. Date Field (orig-date) defined in <xref target="RFC5322" section="3.6.1"/>.
The field value is an HTTP-date, as defined in <xref target="http.date"/>. The field value is an HTTP-date, as defined in <xref target="http.date"/>.
</t> </t>
<iref primary="true" item="Grammar" subitem="Date"/> <iref primary="true" item="Grammar" subitem="Date"/>
<sourcecode type="abnf7230"><![CDATA[ Date = HTTP-date <sourcecode type="abnf9110"><![CDATA[ Date = HTTP-date
]]></sourcecode> ]]></sourcecode>
<t> <t>
An example is An example is
</t> </t>
<sourcecode type="http-message"><![CDATA[Date: Tue, 15 Nov 1994 0 8:12:31 GMT <sourcecode type="http-message"><![CDATA[Date: Tue, 15 Nov 1994 0 8:12:31 GMT
]]></sourcecode> ]]></sourcecode>
<t> <t>
A sender that generates a Date header field <bcp14>SHOULD</bcp14> generate it s A sender that generates a Date header field <bcp14>SHOULD</bcp14> generate it s
field value as the best available approximation of the date and time of field value as the best available approximation of the date and time of
message generation. In theory, the date ought to represent the moment just message generation. In theory, the date ought to represent the moment just
skipping to change at line 2578 skipping to change at line 2562
<iref primary="true" item="Header Fields" subitem="Trailer"/> <iref primary="true" item="Header Fields" subitem="Trailer"/>
<iref primary="true" item="Trailer header field"/> <iref primary="true" item="Trailer header field"/>
<t> <t>
The "Trailer" header field provides a list of field names that the sender The "Trailer" header field provides a list of field names that the sender
anticipates sending as trailer fields within that message. This allows a anticipates sending as trailer fields within that message. This allows a
recipient to prepare for receipt of the indicated metadata before it starts recipient to prepare for receipt of the indicated metadata before it starts
processing the content. processing the content.
</t> </t>
<iref primary="true" item="Grammar" subitem="Trailer"/> <iref primary="true" item="Grammar" subitem="Trailer"/>
<iref primary="false" item="Grammar" subitem="field-name"/> <iref primary="false" item="Grammar" subitem="field-name"/>
<sourcecode type="abnf7230"><![CDATA[ Trailer = #field-name <sourcecode type="abnf9110"><![CDATA[ Trailer = #field-name
]]></sourcecode> ]]></sourcecode>
<t> <t>
For example, a sender might indicate that a signature will For example, a sender might indicate that a signature will
be computed as the content is being streamed and provide the final be computed as the content is being streamed and provide the final
signature as a trailer field. This allows a recipient to perform the same signature as a trailer field. This allows a recipient to perform the same
check on the fly as it receives the content. check on the fly as it receives the content.
</t> </t>
<t> <t>
A sender that intends to generate one or more trailer fields in a message A sender that intends to generate one or more trailer fields in a message
<bcp14>SHOULD</bcp14> generate a <xref target="field.trailer" format="none">T railer</xref> header field in the header <bcp14>SHOULD</bcp14> generate a <xref target="field.trailer" format="none">T railer</xref> header field in the header
skipping to change at line 2621 skipping to change at line 2605
<iref primary="true" item="request target"/> <iref primary="true" item="request target"/>
<t> <t>
Although HTTP is used in a wide variety of applications, most clients rely Although HTTP is used in a wide variety of applications, most clients rely
on the same resource identification mechanism and configuration techniques on the same resource identification mechanism and configuration techniques
as general-purpose Web browsers. Even when communication options are as general-purpose Web browsers. Even when communication options are
hard-coded in a client's configuration, we can think of their combined hard-coded in a client's configuration, we can think of their combined
effect as a URI reference (<xref target="uri.references"/>). effect as a URI reference (<xref target="uri.references"/>).
</t> </t>
<t> <t>
A URI reference is resolved to its absolute form in order to obtain the A URI reference is resolved to its absolute form in order to obtain the
<em>target URI</em>. The target URI excludes the reference's "target URI". The target URI excludes the reference's
fragment component, if any, since fragment identifiers are reserved for fragment component, if any, since fragment identifiers are reserved for
client-side processing (<xref target="URI" sectionFormat="comma" section="3.5 "/>). client-side processing (<xref target="URI" sectionFormat="comma" section="3.5 "/>).
</t> </t>
<t> <t>
To perform an action on a <em>target resource</em>, the client sends To perform an action on a "target resource", the client sends
a request message containing enough components of its parsed target URI to a request message containing enough components of its parsed target URI to
enable recipients to identify that same resource. For historical reasons, enable recipients to identify that same resource. For historical reasons,
the parsed target URI components, collectively referred to as the the parsed target URI components, collectively referred to as the
<em>request target</em>, are sent within the message control data "request target", are sent within the message control data
and the <xref target="field.host" format="none">Host</xref> header field (<xr ef target="field.host"/>). and the <xref target="field.host" format="none">Host</xref> header field (<xr ef target="field.host"/>).
</t> </t>
<t> <t>
There are two unusual cases for which the request target components are in There are two unusual cases for which the request target components are in
a method-specific form: a method-specific form:
</t> </t>
<ul> <ul>
<li> <li>
For CONNECT (<xref target="CONNECT"/>), the request target is the host For CONNECT (<xref target="CONNECT"/>), the request target is the host
name and port number of the tunnel destination, separated by a colon. name and port number of the tunnel destination, separated by a colon.
skipping to change at line 2663 skipping to change at line 2647
from the received components in accordance with their local configuration from the received components in accordance with their local configuration
and incoming connection context. This reconstruction is specific to each and incoming connection context. This reconstruction is specific to each
major protocol version. For example, major protocol version. For example,
<xref target="HTTP11" section="3.3"/> defines how a server <xref target="HTTP11" section="3.3"/> defines how a server
determines the target URI of an HTTP/1.1 request. determines the target URI of an HTTP/1.1 request.
</t> </t>
<aside anchor="effective.request.uri"> <aside anchor="effective.request.uri">
<t> <t>
<iref primary="true" item="effective request URI"/> <iref primary="true" item="effective request URI"/>
<strong>Note:</strong> Previous specifications defined the rec omposed target URI as a <strong>Note:</strong> Previous specifications defined the rec omposed target URI as a
distinct concept, the <em>effective request URI</em>. distinct concept, the "effective request URI".
</t> </t>
</aside> </aside>
</section> </section>
<section anchor="field.host" title="Host and :authority"> <section anchor="field.host" title="Host and :authority">
<iref primary="true" item="Fields" subitem="Host"/> <iref primary="true" item="Fields" subitem="Host"/>
<iref primary="true" item="Header Fields" subitem="Host"/> <iref primary="true" item="Header Fields" subitem="Host"/>
<iref primary="true" item="Host header field"/> <iref primary="true" item="Host header field"/>
<t> <t>
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 information from the target URI, enabling the origin
server to distinguish among resources while servicing requests server to distinguish among resources while servicing requests
for multiple host names. for multiple host names.
</t> </t>
<t> <t>
In HTTP/2 <xref target="HTTP2"/> and HTTP/3 <xref target="HTTP3"/>, the In HTTP/2 <xref target="HTTP2"/> and HTTP/3 <xref target="HTTP3"/>, the
Host header field is, in some cases, supplanted by the ":authority" Host header field is, in some cases, supplanted by the ":authority"
pseudo-header field of a request's control data. pseudo-header field of a request's control data.
</t> </t>
<iref primary="true" item="Grammar" subitem="Host"/> <iref primary="true" item="Grammar" subitem="Host"/>
<sourcecode type="abnf7230"><![CDATA[ Host = uri-host [ ":" port ] ; Section 4 <sourcecode type="abnf9110"><![CDATA[ Host = uri-host [ ":" port ] ; Section 4
]]></sourcecode> ]]></sourcecode>
<t> <t>
The target URI's authority information is critical for handling a The target URI's authority information is critical for handling a
request. A user agent <bcp14>MUST</bcp14> generate a Host header field in a r equest request. A user agent <bcp14>MUST</bcp14> generate a Host header field in a r equest
unless it sends that information as an ":authority" pseudo-header field. unless it sends that information as an ":authority" pseudo-header field.
A user agent that sends Host <bcp14>SHOULD</bcp14> send it as the first field in the A user agent that sends Host <bcp14>SHOULD</bcp14> send it as the first field in the
header section of a request. header section of a request.
</t> </t>
<t> <t>
For example, a GET request to the origin server for For example, a GET request to the origin server for
skipping to change at line 2810 skipping to change at line 2794
version dependent; some versions of HTTP use implicit ordering of version dependent; some versions of HTTP use implicit ordering of
messages, while others use an explicit identifier. messages, while others use an explicit identifier.
</t> </t>
<t> <t>
All responses, regardless of the status code (including <xref target="final.i nterim" format="none">interim</xref> All responses, regardless of the status code (including <xref target="final.i nterim" format="none">interim</xref>
responses) can be sent at any time after a request is received, even if the responses) can be sent at any time after a request is received, even if the
request is not yet complete. A response can complete before its request is not yet complete. A response can complete before its
corresponding request is complete (<xref target="message.framing"/>). Likewis e, clients are not expected corresponding request is complete (<xref target="message.framing"/>). Likewis e, clients are not expected
to wait any specific amount of time for a response. Clients to wait any specific amount of time for a response. Clients
(including intermediaries) might abandon a request if the response is not (including intermediaries) might abandon a request if the response is not
forthcoming within a reasonable period of time. received within a reasonable period of time.
</t> </t>
<t> <t>
A client that receives a response while it is still sending the associated A client that receives a response while it is still sending the associated
request <bcp14>SHOULD</bcp14> continue sending that request, unless it receiv es request <bcp14>SHOULD</bcp14> continue sending that request unless it receive s
an explicit indication to the contrary (see, e.g., <xref target="HTTP11" sect ion="9.5"/> and <xref target="HTTP2" section="6.4"/>). an explicit indication to the contrary (see, e.g., <xref target="HTTP11" sect ion="9.5"/> and <xref target="HTTP2" section="6.4"/>).
</t> </t>
</section> </section>
<section anchor="message.forwarding" title="Message Forwarding"> <section anchor="message.forwarding" title="Message Forwarding">
<t> <t>
As described in <xref target="intermediaries"/>, intermediaries can serve As described in <xref target="intermediaries"/>, intermediaries can serve
a variety of roles in the processing of HTTP requests and responses. a variety of roles in the processing of HTTP requests and responses.
Some intermediaries are used to improve performance or availability. Some intermediaries are used to improve performance or availability.
Others are used for access control or to filter content. Others are used for access control or to filter content.
Since an HTTP stream has characteristics similar to a pipe-and-filter Since an HTTP stream has characteristics similar to a pipe-and-filter
architecture, there are no inherent limits to the extent an intermediary architecture, there are no inherent limits to the extent an intermediary
can enhance (or interfere) with either direction of the stream. can enhance (or interfere) with either direction of the stream.
</t> </t>
<t> <t>
Intermediaries are expected to forward messages even when protocol elements Intermediaries are expected to forward messages even when protocol elements
are not recognized (e.g., new methods, status codes, or field names), since t hat are not recognized (e.g., new methods, status codes, or field names) since th at
preserves extensibility for downstream recipients. preserves extensibility for downstream recipients.
</t> </t>
<t> <t>
An intermediary not acting as a tunnel <bcp14>MUST</bcp14> implement the An intermediary not acting as a tunnel <bcp14>MUST</bcp14> implement the
<xref target="field.connection" format="none">Connection</xref> header field, as specified in <xref target="field.connection" format="none">Connection</xref> header field, as specified in
<xref target="field.connection"/>, and exclude fields from being forwarded <xref target="field.connection"/>, and exclude fields from being forwarded
that are only intended for the incoming connection. that are only intended for the incoming connection.
</t> </t>
<t> <t>
An intermediary <bcp14>MUST NOT</bcp14> forward a message to itself unless it is An intermediary <bcp14>MUST NOT</bcp14> forward a message to itself unless it is
skipping to change at line 2857 skipping to change at line 2841
forwarding downstream. forwarding downstream.
However, senders and recipients cannot rely on incremental However, senders and recipients cannot rely on incremental
delivery of partial messages, since some implementations will buffer or delivery of partial messages, since some implementations will buffer or
delay message forwarding for the sake of network efficiency, security delay message forwarding for the sake of network efficiency, security
checks, or content transformations. checks, or content transformations.
</t> </t>
<section anchor="field.connection" title="Connection"> <section anchor="field.connection" title="Connection">
<iref primary="true" item="Fields" subitem="Connection"/> <iref primary="true" item="Fields" subitem="Connection"/>
<iref primary="true" item="Header Fields" subitem="Connection"/> <iref primary="true" item="Header Fields" subitem="Connection"/>
<iref primary="true" item="Connection header field"/> <iref primary="true" item="Connection header field"/>
<iref primary="true" item="Grammar" subitem="Connection"/>
<iref primary="true" item="Grammar" subitem="connection-option"/>
<t> <t>
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.
</t> </t>
<sourcecode type="abnf9110"><![CDATA[ Connection = #conne
ction-option
connection-option = token
]]></sourcecode>
<t>
Connection options are case-insensitive.
</t>
<t> <t>
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 <bcp14>MUST</bcp1 4> list information for or about the current connection, the sender <bcp14>MUST</bcp1 4> 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.
</t> </t>
<t> <t>
Intermediaries <bcp14>MUST</bcp14> parse a received Connection Intermediaries <bcp14>MUST</bcp14> parse a received Connection
header field before a message is forwarded and, for each header field before a message is forwarded and, for each
connection-option in this field, remove any header or trailer field(s) from connection-option in this field, remove any header or trailer field(s) from
the message with the same name as the connection-option, and then the message with the same name as the connection-option, and then
remove the Connection header field itself (or replace it with the remove the Connection header field itself (or replace it with the
intermediary's own connection options for the forwarded message). intermediary's own control options for the forwarded message).
</t> </t>
<t> <t>
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 distinguishing fields that are only intended for the
immediate recipient ("hop-by-hop") from those fields that are immediate recipient ("hop-by-hop") from those fields that are
intended for all recipients on the chain ("end-to-end"), enabling the intended for all recipients on the chain ("end-to-end"), enabling the
message to be self-descriptive and allowing future connection-specific message to be self-descriptive and allowing future connection-specific
extensions to be deployed without fear that they will be blindly extensions to be deployed without fear that they will be blindly
forwarded by older intermediaries. forwarded by older intermediaries.
</t> </t>
<t> <t>
Furthermore, intermediaries <bcp14>SHOULD</bcp14> remove or replace field(s) Furthermore, intermediaries <bcp14>SHOULD</bcp14> remove or replace fields
whose that are known to require removal before forwarding, whether or not they appe
semantics are known to require removal before forwarding, whether or not they ar as a
appear as a Connection connection-option, after applying those fields' semantics. This includes but
option, after applying those fields' semantics. This includes but is not limi is not limited to:
ted to:
</t> </t>
<ul> <ul>
<li>Proxy-Connection (<xref target="HTTP11" section="C.2.2"/>) </li> <li>Proxy-Connection (<xref target="HTTP11" section="C.2.2"/>) </li>
<li>Keep-Alive (<xref target="RFC2068" section="19.7.1"/>)</li > <li>Keep-Alive (<xref target="RFC2068" section="19.7.1"/>)</li >
<li>TE (<xref target="field.te"/>)</li> <li>TE (<xref target="field.te"/>)</li>
<li>Transfer-Encoding (<xref target="HTTP11" section="6.1"/>)< /li> <li>Transfer-Encoding (<xref target="HTTP11" section="6.1"/>)< /li>
<li>Upgrade (<xref target="field.upgrade"/>)</li> <li>Upgrade (<xref target="field.upgrade"/>)</li>
</ul> </ul>
<t> <t>
The Connection header field's value has the following grammar:
</t>
<iref primary="true" item="Grammar" subitem="Connection"/>
<iref primary="true" item="Grammar" subitem="connection-option"/>
<sourcecode type="abnf7230"><![CDATA[ Connection = #conne
ction-option
connection-option = token
]]></sourcecode>
<t>
Connection options are case-insensitive.
</t>
<t>
A sender <bcp14>MUST NOT</bcp14> send a connection option corresponding to a A sender <bcp14>MUST NOT</bcp14> send a connection option corresponding to a
field that is intended for all recipients of the content. field that is intended for all recipients of the content.
For example, Cache-Control is never appropriate as a For example, Cache-Control is never appropriate as a
connection option (<xref target="CACHING" section="5.2"/>). connection option (<xref target="CACHING" section="5.2"/>).
</t> </t>
<t> <t>
Connection options do not always correspond to a field Connection options do not always correspond to a field
present in the message, since a connection-specific field present in the message, since a connection-specific field
might not be needed if there are no parameters associated with a might not be needed if there are no parameters associated with a
connection option. In contrast, a connection-specific field connection option. In contrast, a connection-specific field
received without a corresponding connection option usually indicates received without a corresponding connection option usually indicates
that the field has been improperly forwarded by an intermediary and that the field has been improperly forwarded by an intermediary and
ought to be ignored by the recipient. ought to be ignored by the recipient.
</t> </t>
<t> <t>
When defining a new connection option that does not correspond to a field, When defining a new connection option that does not correspond to a field,
specification authors ought to reserve the corresponding field name specification authors ought to reserve the corresponding field name
anyway in order to avoid later collisions. Such reserved field names are anyway in order to avoid later collisions. Such reserved field names are
registered in the Hypertext Transfer Protocol (HTTP) Field Name Registry registered in the "Hypertext Transfer Protocol (HTTP) Field Name Registry"
(<xref target="fields.registry"/>). (<xref target="fields.registry"/>).
</t> </t>
</section> </section>
<section anchor="field.max-forwards" title="Max-Forwards"> <section anchor="field.max-forwards" title="Max-Forwards">
<iref primary="true" item="Fields" subitem="Max-Forwards"/> <iref primary="true" item="Fields" subitem="Max-Forwards"/>
<iref primary="true" item="Header Fields" subitem="Max-Forwards"/ > <iref primary="true" item="Header Fields" subitem="Max-Forwards"/ >
<iref primary="true" item="Max-Forwards header field"/> <iref primary="true" item="Max-Forwards header field"/>
<t> <t>
The "Max-Forwards" header field provides a mechanism with the The "Max-Forwards" header field provides a mechanism with the
TRACE (<xref target="TRACE"/>) and OPTIONS (<xref target="OPTIONS"/>) TRACE (<xref target="TRACE"/>) and OPTIONS (<xref target="OPTIONS"/>)
request methods to limit the number of times that the request is forwarded by request methods to limit the number of times that the request is forwarded by
proxies. This can be useful when the client is attempting to proxies. This can be useful when the client is attempting to
trace a request that appears to be failing or looping mid-chain. trace a request that appears to be failing or looping mid-chain.
</t> </t>
<iref primary="true" item="Grammar" subitem="Max-Forwards"/> <iref primary="true" item="Grammar" subitem="Max-Forwards"/>
<sourcecode type="abnf7230"><![CDATA[ Max-Forwards = 1*DIGIT <sourcecode type="abnf9110"><![CDATA[ Max-Forwards = 1*DIGIT
]]></sourcecode> ]]></sourcecode>
<t> <t>
The Max-Forwards value is a decimal integer indicating the remaining The Max-Forwards value is a decimal integer indicating the remaining
number of times this request message can be forwarded. number of times this request message can be forwarded.
</t> </t>
<t> <t>
Each intermediary that receives a TRACE or OPTIONS request containing a Each intermediary that receives a TRACE or OPTIONS request containing a
Max-Forwards header field <bcp14>MUST</bcp14> check and update its value prio r to Max-Forwards header field <bcp14>MUST</bcp14> check and update its value prio r to
forwarding the request. If the received value is zero (0), the intermediary forwarding the request. If the received value is zero (0), the intermediary
<bcp14>MUST NOT</bcp14> forward the request; instead, the intermediary <bcp14 >MUST</bcp14> respond as <bcp14>MUST NOT</bcp14> forward the request; instead, the intermediary <bcp14 >MUST</bcp14> respond as
skipping to change at line 2985 skipping to change at line 2966
Via can be used for tracking message forwards, Via can be used for tracking message forwards,
avoiding request loops, and identifying the protocol capabilities of avoiding request loops, and identifying the protocol capabilities of
senders along the request/response chain. senders along the request/response chain.
</t> </t>
<iref primary="true" item="Grammar" subitem="Via"/> <iref primary="true" item="Grammar" subitem="Via"/>
<iref primary="true" item="Grammar" subitem="received-protocol"/> <iref primary="true" item="Grammar" subitem="received-protocol"/>
<iref primary="true" item="Grammar" subitem="protocol-name"/> <iref primary="true" item="Grammar" subitem="protocol-name"/>
<iref primary="true" item="Grammar" subitem="protocol-version"/> <iref primary="true" item="Grammar" subitem="protocol-version"/>
<iref primary="true" item="Grammar" subitem="received-by"/> <iref primary="true" item="Grammar" subitem="received-by"/>
<iref primary="true" item="Grammar" subitem="pseudonym"/> <iref primary="true" item="Grammar" subitem="pseudonym"/>
<sourcecode type="abnf7230"><![CDATA[ Via = #( received-protocol RWS received-by [ RWS comment ] ) <sourcecode type="abnf9110"><![CDATA[ Via = #( received-protocol RWS received-by [ RWS comment ] )
received-protocol = [ protocol-name "/" ] protocol-version received-protocol = [ protocol-name "/" ] protocol-version
; see Section 7.8 ; see Section 7.8
received-by = pseudonym [ ":" port ] received-by = pseudonym [ ":" port ]
pseudonym = token pseudonym = token
]]></sourcecode> ]]></sourcecode>
<t> <t>
Each member of the Via field value represents a proxy or gateway that has Each member of the Via field value represents a proxy or gateway that has
forwarded the message. Each intermediary appends its own information forwarded the message. Each intermediary appends its own information
about how the message was received, such that the end result is ordered about how the message was received, such that the end result is ordered
skipping to change at line 3082 skipping to change at line 3063
Some intermediaries include features for transforming messages and their Some intermediaries include features for transforming messages and their
content. A proxy might, for example, convert between image formats in content. A proxy might, for example, convert between image formats in
order to save cache space or to reduce the amount of traffic on a slow order to save cache space or to reduce the amount of traffic on a slow
link. However, operational problems might occur when these transformations link. However, operational problems might occur when these transformations
are applied to content intended for critical applications, such as medical are applied to content intended for critical applications, such as medical
imaging or scientific data analysis, particularly when integrity checks or imaging or scientific data analysis, particularly when integrity checks or
digital signatures are used to ensure that the content received is digital signatures are used to ensure that the content received is
identical to the original. identical to the original.
</t> </t>
<t> <t>
An HTTP-to-HTTP proxy is called a <em>transforming proxy</em> An HTTP-to-HTTP proxy is called a "transforming proxy"
if it is designed or configured to modify messages in a semantically if it is 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 presumed format transcoder, or a privacy filter. Such transformations are presumed
to be desired by whichever client (or client organization) chose the to be desired by whichever client (or client organization) chose the
proxy. proxy.
skipping to change at line 3109 skipping to change at line 3090
</t> </t>
<t> <t>
A proxy <bcp14>MUST NOT</bcp14> modify the "absolute-path" and "query" parts of the A proxy <bcp14>MUST NOT</bcp14> modify the "absolute-path" and "query" parts of the
received target URI when forwarding it to the next inbound server except received target URI when forwarding it to the next inbound server except
as required by that forwarding protocol. For example, a proxy forwarding as required by that forwarding protocol. For example, a proxy forwarding
a request to an origin server via HTTP/1.1 will replace an empty path with a request to an origin server via HTTP/1.1 will replace an empty path with
"/" (<xref target="HTTP11" section="3.2.1"/>) or "*" (<xref target="HTTP11" s ection="3.2.4"/>), "/" (<xref target="HTTP11" section="3.2.1"/>) or "*" (<xref target="HTTP11" s ection="3.2.4"/>),
depending on the request method. depending on the request method.
</t> </t>
<t> <t>
A proxy <bcp14>MUST NOT</bcp14> transform the content (<xref target="content" A proxy <bcp14>MUST NOT</bcp14> transform the content (<xref target="content"
/>) of a message that />) of a
contains a no-transform cache-control response directive (<xref target="CACHI response message that contains a no-transform cache directive
NG" section="5.2"/>). (<xref target="CACHING" section="5.2.2.6"/>). Note that this
Note that this does not include changes to the message body that do not affec does not apply to message transformations that do not change the content,
t such as the addition or removal of transfer codings
the content, such as transfer codings (<xref target="HTTP11" section="7"/>). (<xref target="HTTP11" section="7"/>).
</t> </t>
<t> <t>
A proxy <bcp14>MAY</bcp14> transform the content of a message A proxy <bcp14>MAY</bcp14> transform the content of a message
that does not contain a no-transform cache-control directive. that does not contain a no-transform cache directive.
A proxy that transforms the content of a <xref target="status.200" format="no ne">200 (OK)</xref> response A proxy that transforms the content of a <xref target="status.200" format="no ne">200 (OK)</xref> response
can inform downstream recipients that a transformation has been can inform downstream recipients that a transformation has been
applied by changing the response status code to applied by changing the response status code to
<xref target="status.203" format="none">203 (Non-Authoritative Information)</ xref> (<xref target="status.203"/>). <xref target="status.203" format="none">203 (Non-Authoritative Information)</ xref> (<xref target="status.203"/>).
</t> </t>
<t> <t>
A proxy <bcp14>SHOULD NOT</bcp14> modify header fields that provide informati on about A proxy <bcp14>SHOULD NOT</bcp14> modify header fields that provide informati on about
the endpoints of the communication chain, the resource state, or the the endpoints of the communication chain, the resource state, or the
<xref target="selected.representation" format="none">selected representation< /xref> (other than the content) unless the field's <xref target="selected.representation" format="none">selected representation< /xref> (other than the content) unless the field's
definition specifically allows such modification or the modification is definition specifically allows such modification or the modification is
skipping to change at line 3148 skipping to change at line 3131
</t> </t>
<t> <t>
A client <bcp14>MAY</bcp14> send a list of protocol names in the Upgrade head er field A client <bcp14>MAY</bcp14> send a list of protocol names in the Upgrade head er field
of a request to invite the server to switch to one or more of the named of a request to invite the server to switch to one or more of the named
protocols, in order of descending preference, before sending protocols, in order of descending preference, before sending
the final response. A server <bcp14>MAY</bcp14> ignore a received Upgrade hea der field the final response. A server <bcp14>MAY</bcp14> ignore a received Upgrade hea der field
if it wishes to continue using the current protocol on that connection. if it wishes to continue using the current protocol on that connection.
Upgrade cannot be used to insist on a protocol change. Upgrade cannot be used to insist on a protocol change.
</t> </t>
<iref primary="true" item="Grammar" subitem="Upgrade"/> <iref primary="true" item="Grammar" subitem="Upgrade"/>
<sourcecode type="abnf7230"><![CDATA[ Upgrade = #protocol <sourcecode type="abnf9110"><![CDATA[ Upgrade = #protocol
protocol = protocol-name ["/" protocol-version] protocol = protocol-name ["/" protocol-version]
protocol-name = token protocol-name = token
protocol-version = token protocol-version = token
]]></sourcecode> ]]></sourcecode>
<t> <t>
Although protocol names are registered with a preferred case, Although protocol names are registered with a preferred case,
recipients <bcp14>SHOULD</bcp14> use case-insensitive comparison when matchin g each recipients <bcp14>SHOULD</bcp14> use case-insensitive comparison when matchin g each
protocol-name to supported protocols. protocol-name to supported protocols.
</t> </t>
skipping to change at line 3267 skipping to change at line 3250
either provided as the content of the message or either provided as the content of the message or
referred to by the message semantics and the target referred to by the message semantics and the target
URI. The representation data is in a format and encoding defined by URI. The representation data is in a format and encoding defined by
the representation metadata header fields. the representation metadata header fields.
</t> </t>
<t> <t>
The data type of the representation data is determined via the header fields The data type of the representation data is determined via the header fields
<xref target="field.content-type" format="none">Content-Type</xref> and <xref target="field.content-encoding" format="none">Content-Encoding</xref>. <xref target="field.content-type" format="none">Content-Type</xref> and <xref target="field.content-encoding" format="none">Content-Encoding</xref>.
These define a two-layer, ordered encoding model: These define a two-layer, ordered encoding model:
</t> </t>
<artwork type="example"><![CDATA[ <artwork><![CDATA[
representation-data := Content-Encoding( Content-Type( data ) ) representation-data := Content-Encoding( Content-Type( data ) )
]]></artwork> ]]></artwork>
</section> </section>
<section anchor="representation.metadata" title="Representation Metadat a"> <section anchor="representation.metadata" title="Representation Metadat a">
<t> <t>
Representation header fields provide metadata about the representation. Representation header fields provide metadata about the representation.
When a message includes content, the representation header fields When a message includes content, the representation header fields
describe how to interpret that data. In a response to a HEAD request, the describe how to interpret that data. In a response to a HEAD request, the
representation header fields describe the representation data that would representation header fields describe the representation data that would
have been enclosed in the content if the same request had been a GET. have been enclosed in the content if the same request had been a GET.
skipping to change at line 3294 skipping to change at line 3277
<t> <t>
The "Content-Type" header field indicates the media type of the The "Content-Type" header field indicates the media type of the
associated representation: either the representation enclosed in associated representation: either the representation enclosed in
the message content or the <xref target="selected.representation" format="non e">selected representation</xref>, as determined by the the message content or the <xref target="selected.representation" format="non e">selected representation</xref>, as determined by the
message semantics. The indicated media type defines both the data format message semantics. The indicated media type defines both the data format
and how that data is intended to be processed by a recipient, within the and how that data is intended to be processed by a recipient, within the
scope of the received message semantics, after any content codings scope of the received message semantics, after any content codings
indicated by <xref target="field.content-encoding" format="none">Content-Enco ding</xref> are decoded. indicated by <xref target="field.content-encoding" format="none">Content-Enco ding</xref> are decoded.
</t> </t>
<iref primary="true" item="Grammar" subitem="Content-Type"/> <iref primary="true" item="Grammar" subitem="Content-Type"/>
<sourcecode type="abnf7230"><![CDATA[ Content-Type = media-type <sourcecode type="abnf9110"><![CDATA[ Content-Type = media-type
]]></sourcecode> ]]></sourcecode>
<t> <t>
Media types are defined in <xref target="media.type"/>. An example of the Media types are defined in <xref target="media.type"/>. An example of the
field is field is
</t> </t>
<sourcecode type="http-message"><![CDATA[Content-Type: text/html; ch arset=ISO-8859-4 <sourcecode type="http-message"><![CDATA[Content-Type: text/html; ch arset=ISO-8859-4
]]></sourcecode> ]]></sourcecode>
<t> <t>
A sender that generates a message containing content <bcp14>SHOULD</bcp14> A sender that generates a message containing content <bcp14>SHOULD</bcp14>
generate a Content-Type header field in that message unless the intended generate a Content-Type header field in that message unless the intended
skipping to change at line 3346 skipping to change at line 3329
HTTP uses media types <xref target="RFC2046"/> in the HTTP uses media types <xref target="RFC2046"/> in the
<xref target="field.content-type" format="none">Content-Type</xref> (<xref ta rget="field.content-type"/>) <xref target="field.content-type" format="none">Content-Type</xref> (<xref ta rget="field.content-type"/>)
and <xref target="field.accept" format="none">Accept</xref> (<xref target="fi eld.accept"/>) header fields in and <xref target="field.accept" format="none">Accept</xref> (<xref target="fi eld.accept"/>) header fields in
order to provide open and extensible data typing and type negotiation. order to provide open and extensible data typing and type negotiation.
Media types define both a data format and various processing models: Media types define both a data format and various processing models:
how to process that data in accordance with the message context. how to process that data in accordance with the message context.
</t> </t>
<iref primary="true" item="Grammar" subitem="media-type"/> <iref primary="true" item="Grammar" subitem="media-type"/>
<iref primary="true" item="Grammar" subitem="type"/> <iref primary="true" item="Grammar" subitem="type"/>
<iref primary="true" item="Grammar" subitem="subtype"/> <iref primary="true" item="Grammar" subitem="subtype"/>
<sourcecode type="abnf7230"><![CDATA[ media-type = type "/" subt ype parameters <sourcecode type="abnf9110"><![CDATA[ media-type = type "/" subt ype parameters
type = token type = token
subtype = token subtype = token
]]></sourcecode> ]]></sourcecode>
<t> <t>
The type and subtype tokens are case-insensitive. The type and subtype tokens are case-insensitive.
</t> </t>
<t> <t>
The type/subtype <bcp14>MAY</bcp14> be followed by semicolon-delimited parame ters The type/subtype <bcp14>MAY</bcp14> be followed by semicolon-delimited parame ters
(<xref target="parameter"/>) in the form of name=value pairs. (<xref target="parameter"/>) in the form of name/value pairs.
The presence or absence of a parameter might be significant to the The presence or absence of a parameter might be significant to the
processing of a media type, depending on its definition within the media processing of a media type, depending on its definition within the media
type registry. type registry.
Parameter values might or might not be case-sensitive, depending on the Parameter values might or might not be case-sensitive, depending on the
semantics of the parameter name. semantics of the parameter name.
</t> </t>
<t> <t>
For example, the following media types are equivalent in describing HTML For example, the following media types are equivalent in describing HTML
text data encoded in the UTF-8 character encoding scheme, but the first is text data encoded in the UTF-8 character encoding scheme, but the first is
preferred for consistency (the "charset" parameter value is defined as preferred for consistency (the "charset" parameter value is defined as
being case-insensitive in <xref target="RFC2046" sectionFormat="comma" sectio n="4.1.2"/>): being case-insensitive in <xref target="RFC2046" sectionFormat="comma" sectio n="4.1.2"/>):
</t> </t>
<artwork type="example"><![CDATA[ <artwork><![CDATA[
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
]]></artwork> ]]></artwork>
<t> <t>
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 <xref target="BCP13"/>. procedures defined in <xref target="BCP13"/>.
</t> </t>
</section> </section>
<section anchor="charset" title="Charset"> <section anchor="charset" title="Charset">
<t> <t>
HTTP uses <em>charset</em> names to indicate or negotiate the HTTP uses "charset" names to indicate or negotiate the
character encoding scheme (<xref target="RFC6365" sectionFormat="comma" secti character encoding scheme (<xref target="RFC6365" sectionFormat="comma" secti
on="1.3"/>) on="2"/>)
of a textual representation. In the fields defined by this document, of a textual representation. In the fields defined by this document,
charset names appear either in parameters (<xref target="field.content-type" format="none">Content-Type</xref>), charset names appear either in parameters (<xref target="field.content-type" format="none">Content-Type</xref>),
or, for <xref target="field.accept-encoding" format="none">Accept-Encoding</x ref>, in the form of a plain <xref target="rule.token.separators" format="none"> token</xref>. or, for <xref target="field.accept-encoding" format="none">Accept-Encoding</x ref>, in the form of a plain <xref target="rule.token.separators" format="none"> token</xref>.
In both cases, charset names are matched case-insensitively. In both cases, charset names are matched case-insensitively.
</t> </t>
<t> <t>
Charset names ought to be registered in the IANA "Character Sets" registry Charset names ought to be registered in the IANA "Character Sets" registry
(<eref target="https://www.iana.org/assignments/character-sets" (<eref target="https://www.iana.org/assignments/character-sets"
brackets="angle"/>) brackets="angle"/>)
according to the procedures defined in <xref target="RFC2978" section="2"/>. according to the procedures defined in <xref target="RFC2978" section="2"/>.
skipping to change at line 3407 skipping to change at line 3390
rule defined in <xref target="RFC2978" section="2.3"/> (as rule defined in <xref target="RFC2978" section="2.3"/> (as
corrected in <xref target="Err1912"/>). That rule allows two characters corrected in <xref target="Err1912"/>). That rule allows two characters
that are not included in "token" ("{" and "}"), but no charset name that are not included in "token" ("{" and "}"), but no charset name
registered at the time of this writing includes braces registered at the time of this writing includes braces
(see <xref target="Err5433"/>). (see <xref target="Err5433"/>).
</t> </t>
</aside> </aside>
</section> </section>
<section anchor="multipart.types" title="Multipart Types"> <section anchor="multipart.types" title="Multipart Types">
<t> <t>
MIME provides for a number of "multipart" types — encapsulations of MIME provides for a number of "multipart" types -- encapsulations of
one or more representations within a single message body. All multipart one or more representations within a single message body. All multipart
types share a common syntax, as defined in <xref target="RFC2046" section="5. 1.1"/>, types share a common syntax, as defined in <xref target="RFC2046" section="5. 1.1"/>,
and include a boundary parameter as part of the media type and include a boundary parameter as part of the media type
value. The message body is itself a protocol element; a sender <bcp14>MUST</b cp14> value. The message body is itself a protocol element; a sender <bcp14>MUST</b cp14>
generate only CRLF to represent line breaks between body parts. generate only CRLF to represent line breaks between body parts.
</t> </t>
<t> <t>
HTTP message framing does not use the multipart boundary as an indicator HTTP message framing does not use the multipart boundary as an indicator
of message body length, though it might be used by implementations that of message body length, though it might be used by implementations that
generate or process the content. For example, the "multipart/form-data" generate or process the content. For example, the "multipart/form-data"
skipping to change at line 3439 skipping to change at line 3422
<t> <t>
The "Content-Encoding" header field indicates what content codings The "Content-Encoding" header field indicates what content codings
have been applied to the representation, beyond those inherent in the media have been applied to the representation, beyond those inherent in the media
type, and thus what decoding mechanisms have to be applied in order to type, and thus what decoding mechanisms have to be applied in order to
obtain data in the media type referenced by the <xref target="field.content-t ype" format="none">Content-Type</xref> obtain data in the media type referenced by the <xref target="field.content-t ype" format="none">Content-Type</xref>
header field. header field.
Content-Encoding is primarily used to allow a representation's data to be Content-Encoding is primarily used to allow a representation's data to be
compressed without losing the identity of its underlying media type. compressed without losing the identity of its underlying media type.
</t> </t>
<iref primary="true" item="Grammar" subitem="Content-Encoding"/> <iref primary="true" item="Grammar" subitem="Content-Encoding"/>
<sourcecode type="abnf7230"><![CDATA[ Content-Encoding = #content-c oding <sourcecode type="abnf9110"><![CDATA[ Content-Encoding = #content-c oding
]]></sourcecode> ]]></sourcecode>
<t> <t>
An example of its use is An example of its use is
</t> </t>
<sourcecode type="http-message"><![CDATA[Content-Encoding: gzip <sourcecode type="http-message"><![CDATA[Content-Encoding: gzip
]]></sourcecode> ]]></sourcecode>
<t> <t>
If one or more encodings have been applied to a representation, the sender If one or more encodings have been applied to a representation, the sender
that applied the encodings <bcp14>MUST</bcp14> generate a Content-Encoding he ader field that applied the encodings <bcp14>MUST</bcp14> generate a Content-Encoding he ader field
that lists the content codings in the order in which they were applied. that lists the content codings in the order in which they were applied.
Note that the coding named "identity" is reserved for its special role Note that the coding named "identity" is reserved for its special role
in <xref target="field.accept-encoding" format="none">Accept-Encoding</xref>, and thus <bcp14>SHOULD NOT</bcp14> be included. in <xref target="field.accept-encoding" format="none">Accept-Encoding</xref> and thus <bcp14>SHOULD NOT</bcp14> be included.
</t> </t>
<t> <t>
Additional information about the encoding parameters can be provided Additional information about the encoding parameters can be provided
by other header fields not defined by this specification. by other header fields not defined by this specification.
</t> </t>
<t> <t>
Unlike Transfer-Encoding (<xref target="HTTP11" section="6.1"/>), the codings listed Unlike Transfer-Encoding (<xref target="HTTP11" section="6.1"/>), the codings listed
in Content-Encoding are a characteristic of the representation; the in Content-Encoding are a characteristic of the representation; the
representation is defined in terms of the coded form, and all other representation is defined in terms of the coded form, and all other
metadata about the representation is about the coded form unless otherwise metadata about the representation is about the coded form unless otherwise
skipping to change at line 3499 skipping to change at line 3482
<iref primary="true" item="x-gzip (content coding)"/> <iref primary="true" item="x-gzip (content coding)"/>
<t> <t>
Content coding values indicate an encoding transformation that has Content coding values indicate an encoding transformation that has
been or can be applied to a representation. Content codings are primarily been or can be applied to a representation. Content codings are primarily
used to allow a representation to be compressed or otherwise usefully used to allow a representation to be compressed or otherwise usefully
transformed without losing the identity of its underlying media type transformed without losing the identity of its underlying media type
and without loss of information. Frequently, the representation is stored and without loss of information. Frequently, the representation is stored
in coded form, transmitted directly, and only decoded by the final recipient. in coded form, transmitted directly, and only decoded by the final recipient.
</t> </t>
<iref primary="true" item="Grammar" subitem="content-coding"/> <iref primary="true" item="Grammar" subitem="content-coding"/>
<sourcecode type="abnf7230"><![CDATA[ content-coding = token <sourcecode type="abnf9110"><![CDATA[ content-coding = token
]]></sourcecode> ]]></sourcecode>
<t> <t>
All content codings are case-insensitive and ought to be registered All content codings are case-insensitive and ought to be registered
within the "HTTP Content Coding Registry", as described in within the "HTTP Content Coding Registry", as described in
<xref target="content.coding.extensibility"/> <xref target="content.coding.extensibility"/>
</t> </t>
<t> <t>
Content-coding values are used in the Content-coding values are used in the
<xref target="field.accept-encoding" format="none">Accept-Encoding</xref> (<x ref target="field.accept-encoding"/>) <xref target="field.accept-encoding" format="none">Accept-Encoding</xref> (<x ref target="field.accept-encoding"/>)
and <xref target="field.content-encoding" format="none">Content-Encoding</xre f> (<xref target="field.content-encoding"/>) and <xref target="field.content-encoding" format="none">Content-Encoding</xre f> (<xref target="field.content-encoding"/>)
skipping to change at line 3557 skipping to change at line 3540
<section anchor="field.content-language" title="Content-Language"> <section anchor="field.content-language" title="Content-Language">
<iref primary="true" item="Fields" subitem="Content-Language"/> <iref primary="true" item="Fields" subitem="Content-Language"/>
<iref primary="true" item="Header Fields" subitem="Content-Language" /> <iref primary="true" item="Header Fields" subitem="Content-Language" />
<iref primary="true" item="Content-Language header field"/> <iref primary="true" item="Content-Language header field"/>
<t> <t>
The "Content-Language" header field describes the natural The "Content-Language" header field describes the natural
language(s) of the intended audience for the representation. Note that this m ight language(s) of the intended audience for the representation. Note that this m ight
not be equivalent to all the languages used within the representation. not be equivalent to all the languages used within the representation.
</t> </t>
<iref primary="true" item="Grammar" subitem="Content-Language"/> <iref primary="true" item="Grammar" subitem="Content-Language"/>
<sourcecode type="abnf7230"><![CDATA[ Content-Language = #language- tag <sourcecode type="abnf9110"><![CDATA[ Content-Language = #language- tag
]]></sourcecode> ]]></sourcecode>
<t> <t>
Language tags are defined in <xref target="language.tags"/>. The primary purp ose of Language tags are defined in <xref target="language.tags"/>. The primary purp ose of
Content-Language is to allow a user to identify and differentiate Content-Language is to allow a user to identify and differentiate
representations according to the users' own preferred language. Thus, if the representations according to the users' own preferred language. Thus, if the
content is intended only for a Danish-literate audience, the content is intended only for a Danish-literate audience, the
appropriate field is appropriate field is
</t> </t>
<sourcecode type="http-message"><![CDATA[Content-Language: da <sourcecode type="http-message"><![CDATA[Content-Language: da
]]></sourcecode> ]]></sourcecode>
skipping to change at line 3591 skipping to change at line 3574
]]></sourcecode> ]]></sourcecode>
<t> <t>
However, just because multiple languages are present within a representation However, just because multiple languages are present within a representation
does not mean that it is intended for multiple linguistic audiences. does not mean that it is intended for multiple linguistic audiences.
An example would be a beginner's language primer, such as "A First An example would be a beginner's language primer, such as "A First
Lesson in Latin", which is clearly intended to be used by an Lesson in Latin", which is clearly intended to be used by an
English-literate audience. In this case, the Content-Language would English-literate audience. In this case, the Content-Language would
properly only include "en". properly only include "en".
</t> </t>
<t> <t>
Content-Language <bcp14>MAY</bcp14> be applied to any media type — it is not Content-Language <bcp14>MAY</bcp14> be applied to any media type -- it is not
limited to textual documents. limited to textual documents.
</t> </t>
<section anchor="language.tags" title="Language Tags"> <section anchor="language.tags" title="Language Tags">
<t> <t>
A language tag, as defined in <xref target="RFC5646"/>, identifies a A language tag, as defined in <xref target="RFC5646"/>, identifies a
natural language spoken, written, or otherwise conveyed by human beings for natural language spoken, written, or otherwise conveyed by human beings for
communication of information to other human beings. Computer languages are communication of information to other human beings. Computer languages are
explicitly excluded. explicitly excluded.
</t> </t>
<t> <t>
HTTP uses language tags within the <xref target="field.accept-language" forma t="none">Accept-Language</xref> and HTTP uses language tags within the <xref target="field.accept-language" forma t="none">Accept-Language</xref> and
<xref target="field.content-language" format="none">Content-Language</xref> h eader fields. <xref target="field.content-language" format="none">Content-Language</xref> h eader fields.
<xref target="field.accept-language" format="none">Accept-Language</xref> use s the broader language-range production <xref target="field.accept-language" format="none">Accept-Language</xref> use s the broader language-range production
defined in <xref target="field.accept-language"/>, whereas defined in <xref target="field.accept-language"/>, whereas
<xref target="field.content-language" format="none">Content-Language</xref> u ses the language-tag production defined <xref target="field.content-language" format="none">Content-Language</xref> u ses the language-tag production defined
below. below.
</t> </t>
<iref primary="true" item="Grammar" subitem="language-tag"/> <iref primary="true" item="Grammar" subitem="language-tag"/>
<sourcecode type="abnf7230"><![CDATA[ language-tag = <Language-T ag, see [RFC5646], Section 2.1> <sourcecode type="abnf9110"><![CDATA[ language-tag = <Language-T ag, see [RFC5646], Section 2.1>
]]></sourcecode> ]]></sourcecode>
<t> <t>
A language tag is a sequence of one or more case-insensitive subtags, each A language tag is a sequence of one or more case-insensitive subtags, each
separated by a hyphen character ("-", %x2D). In most cases, a language tag separated by a hyphen character ("-", %x2D). In most cases, a language tag
consists of a primary language subtag that identifies a broad family of consists of a primary language subtag that identifies a broad family of
related languages (e.g., "en" = English), which is optionally followed by a related languages (e.g., "en" = English), which is optionally followed by a
series of subtags that refine or narrow that language's range (e.g., series of subtags that refine or narrow that language's range (e.g.,
"en-CA" = the variety of English as communicated in Canada). "en-CA" = the variety of English as communicated in Canada).
Whitespace is not allowed within a language tag. Whitespace is not allowed within a language tag.
Example tags include: Example tags include:
</t> </t>
<artwork type="example"><![CDATA[ <artwork><![CDATA[
fr, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN fr, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN
]]></artwork> ]]></artwork>
<t> <t>
See <xref target="RFC5646"/> for further information. See <xref target="RFC5646"/> for further information.
</t> </t>
</section> </section>
</section> </section>
<section anchor="field.content-length" title="Content-Length"> <section anchor="field.content-length" title="Content-Length">
<iref primary="true" item="Fields" subitem="Content-Length"/> <iref primary="true" item="Fields" subitem="Content-Length"/>
<iref primary="true" item="Header Fields" subitem="Content-Length"/> <iref primary="true" item="Header Fields" subitem="Content-Length"/>
<iref primary="true" item="Content-Length header field"/> <iref primary="true" item="Content-Length header field"/>
<t> <t>
The "Content-Length" header field indicates the associated representation's The "Content-Length" header field indicates the associated representation's
data length as a decimal non-negative integer number of octets. data length as a decimal non-negative integer number of octets.
When transferring a representation as content, Content-Length refers When transferring a representation as content, Content-Length refers
specifically to the amount of data enclosed so that it can be used to specifically to the amount of data enclosed so that it can be used to
delimit framing (e.g., <xref target="HTTP11" section="6.2"/>). delimit framing (e.g., <xref target="HTTP11" section="6.2"/>).
In other cases, Content-Length indicates the selected representation's In other cases, Content-Length indicates the selected representation's
current length, which can be used by recipients to estimate transfer time current length, which can be used by recipients to estimate transfer time
or compare to previously stored representations. or to compare with previously stored representations.
</t> </t>
<iref primary="true" item="Grammar" subitem="Content-Length"/> <iref primary="true" item="Grammar" subitem="Content-Length"/>
<sourcecode type="abnf7230"><![CDATA[ Content-Length = 1*DIGIT <sourcecode type="abnf9110"><![CDATA[ Content-Length = 1*DIGIT
]]></sourcecode> ]]></sourcecode>
<t> <t>
An example is An example is
</t> </t>
<sourcecode type="http-message"><![CDATA[Content-Length: 3495 <sourcecode type="http-message"><![CDATA[Content-Length: 3495
]]></sourcecode> ]]></sourcecode>
<t> <t>
A user agent <bcp14>SHOULD</bcp14> send Content-Length in a request when the method A user agent <bcp14>SHOULD</bcp14> 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. Transfer-Encoding.
skipping to change at line 3715 skipping to change at line 3698
field value that is inconsistent with the received message framing might field value that is inconsistent with the received message framing might
cause a security failure due to request smuggling or response splitting. cause a security failure due to request smuggling or response splitting.
</t> </t>
<t> <t>
As a result, a sender <bcp14>MUST NOT</bcp14> forward a message with a As a result, a sender <bcp14>MUST NOT</bcp14> forward a message with a
Content-Length header field value that is known to be incorrect. Content-Length header field value that is known to be incorrect.
</t> </t>
<t> <t>
Likewise, a sender <bcp14>MUST NOT</bcp14> forward a message with a Content-L ength Likewise, a sender <bcp14>MUST NOT</bcp14> forward a message with a Content-L ength
header field value that does not match the ABNF above, with one exception: header field value that does not match the ABNF above, with one exception:
A recipient of a Content-Length header field value consisting of the same a recipient of a Content-Length header field value consisting of the same
decimal value repeated as a comma-separated list (e.g, decimal value repeated as a comma-separated list (e.g,
"Content-Length: 42, 42"), <bcp14>MAY</bcp14> either reject the message as in valid or "Content-Length: 42, 42") <bcp14>MAY</bcp14> either reject the message as inv alid or
replace that invalid field value with a single instance of the decimal replace that invalid field value with a single instance of the decimal
value, since this likely indicates that a duplicate was generated or value, since this likely indicates that a duplicate was generated or
combined by an upstream message processor. combined by an upstream message processor.
</t> </t>
</section> </section>
<section anchor="field.content-location" title="Content-Location"> <section anchor="field.content-location" title="Content-Location">
<iref primary="true" item="Fields" subitem="Content-Location"/> <iref primary="true" item="Fields" subitem="Content-Location"/>
<iref primary="true" item="Header Fields" subitem="Content-Location" /> <iref primary="true" item="Header Fields" subitem="Content-Location" />
<iref primary="true" item="Content-Location header field"/> <iref primary="true" item="Content-Location header field"/>
<t> <t>
The "Content-Location" header field references a URI that can be used The "Content-Location" header field references a URI that can be used
as an identifier for a specific resource corresponding to the as an identifier for a specific resource corresponding to the
representation in this message's content. representation in this message's content.
In other words, if one were to perform a GET request on this URI at the time In other words, if one were to perform a GET request on this URI at the time
of this message's generation, then a <xref target="status.200" format="none"> 200 (OK)</xref> response would of this message's generation, then a <xref target="status.200" format="none"> 200 (OK)</xref> response would
contain the same representation that is enclosed as content in this message. contain the same representation that is enclosed as content in this message.
</t> </t>
<iref primary="true" item="Grammar" subitem="Content-Location"/> <iref primary="true" item="Grammar" subitem="Content-Location"/>
<sourcecode type="abnf7230"><![CDATA[ Content-Location = absolute-U RI / partial-URI <sourcecode type="abnf9110"><![CDATA[ Content-Location = absolute-U RI / partial-URI
]]></sourcecode> ]]></sourcecode>
<t> <t>
The field value is either an <xref target="uri.references" format="none">abso lute-URI</xref> or a The field value is either an <xref target="uri.references" format="none">abso lute-URI</xref> or a
<xref target="uri.references" format="none">partial-URI</xref>. In the latter case (<xref target="uri"/>), <xref target="uri.references" format="none">partial-URI</xref>. In the latter case (<xref target="uri"/>),
the referenced URI is relative to the target URI the referenced URI is relative to the target URI
(<xref target="URI" sectionFormat="comma" section="5"/>). (<xref target="URI" sectionFormat="comma" section="5"/>).
</t> </t>
<t> <t>
The Content-Location value is not a replacement for the target URI The Content-Location value is not a replacement for the target URI
(<xref target="target.resource"/>). It is representation metadata. (<xref target="target.resource"/>). It is representation metadata.
skipping to change at line 3827 skipping to change at line 3810
negotiated representations. If the user agent had wanted the latter negotiated representations. If the user agent had wanted the latter
semantics, it would have applied the PUT directly to the Content-Location semantics, it would have applied the PUT directly to the Content-Location
URI. URI.
</t> </t>
</section> </section>
<section anchor="response.validator" title="Validator Fields"> <section anchor="response.validator" title="Validator Fields">
<iref primary="true" item="metadata"/> <iref primary="true" item="metadata"/>
<iref primary="true" item="validator"/> <iref primary="true" item="validator"/>
<iref item="selected representation"/> <iref item="selected representation"/>
<t> <t>
Resource metadata is referred to as a <em>validator</em> if it Resource metadata is referred to as a "validator" if it
can be used within a precondition (<xref target="preconditions"/>) to can be used within a precondition (<xref target="preconditions"/>) to
make a conditional request (<xref target="conditional.requests"/>). make a conditional request (<xref target="conditional.requests"/>).
Validator fields convey a current validator for the Validator fields convey a current validator for the
<xref target="selected.representation" format="none">selected representation< /xref> <xref target="selected.representation" format="none">selected representation< /xref>
(<xref target="representations"/>). (<xref target="representations"/>).
</t> </t>
<t> <t>
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 response. representation chosen by the origin server while handling the response.
Note that, depending on the method and status code semantics, the Note that, depending on the method and status code semantics, the
skipping to change at line 3849 skipping to change at line 3832
necessarily the same as the representation enclosed as response content. necessarily the same as the representation enclosed as response content.
</t> </t>
<t> <t>
In a successful response to a state-changing request, validator fields In a successful response to a state-changing request, validator fields
describe the new representation that has replaced the prior describe the new representation that has replaced the prior
<xref target="selected.representation" format="none">selected representation< /xref> as a result of processing the <xref target="selected.representation" format="none">selected representation< /xref> as a result of processing the
request. request.
</t> </t>
<t> <t>
For example, an ETag field in a <xref target="status.201" format="none">201 ( Created)</xref> response For example, an ETag field in a <xref target="status.201" format="none">201 ( Created)</xref> response
communicates the entity-tag of the newly created resource's communicates the entity tag of the newly created resource's
representation, so that the entity-tag can be used as a validator in representation, so that the entity tag can be used as a validator in
later conditional requests to prevent the "lost update" problem. later conditional requests to prevent the "lost update" problem.
</t> </t>
<t> <t>
This specification defines two forms of metadata that are commonly used This specification defines two forms of metadata that are commonly used
to observe resource state and test for preconditions: modification dates to observe resource state and test for preconditions: modification dates
(<xref target="field.last-modified"/>) and opaque entity tags (<xref target="field.last-modified"/>) and opaque entity tags
(<xref target="field.etag"/>). (<xref target="field.etag"/>).
Additional metadata that reflects resource state Additional metadata that reflects resource state
has been defined by various extensions of HTTP, such as Web Distributed has been defined by various extensions of HTTP, such as Web Distributed
Authoring and Versioning <xref target="WEBDAV"/>, that are beyond the Authoring and Versioning <xref target="WEBDAV"/>, that are beyond the
skipping to change at line 3876 skipping to change at line 3859
<t> <t>
Validators come in two flavors: strong or weak. Weak validators are easy Validators come in two flavors: strong or weak. Weak validators are easy
to generate but are far less useful for comparisons. Strong validators to generate but are far less useful for comparisons. Strong validators
are ideal for comparisons but can be very difficult (and occasionally are ideal for comparisons but can be very difficult (and occasionally
impossible) to generate efficiently. Rather than impose that all forms impossible) to generate efficiently. Rather than impose that all forms
of resource adhere to the same strength of validator, HTTP exposes the of resource adhere to the same strength of validator, HTTP exposes the
type of validator in use and imposes restrictions on when weak validators type of validator in use and imposes restrictions on when weak validators
can be used as preconditions. can be used as preconditions.
</t> </t>
<t> <t>
A <em>strong validator</em> is representation metadata that changes value whe never A "strong validator" is representation metadata that changes value whenever
a change occurs to the representation data that would be observable in the a change occurs to the representation data that would be observable in the
content of a <xref target="status.200" format="none">200 (OK)</xref> response to GET. content of a <xref target="status.200" format="none">200 (OK)</xref> response to GET.
</t> </t>
<t> <t>
A strong validator might change for reasons other than a change to the A strong validator might change for reasons other than a change to the
representation data, such as when a representation data, such as when a
semantically significant part of the representation metadata is changed semantically significant part of the representation metadata is changed
(e.g., <xref target="field.content-type" format="none">Content-Type</xref>), but it is in the best interests of the (e.g., <xref target="field.content-type" format="none">Content-Type</xref>), but it is in the best interests of the
origin server to only change the value when it is necessary to invalidate origin server to only change the value when it is necessary to invalidate
the stored responses held by remote caches and authoring tools. the stored responses held by remote caches and authoring tools.
skipping to change at line 3915 skipping to change at line 3898
function applied to the representation data is also sufficient if the data function applied to the representation data is also sufficient if the data
is available prior to the response header fields being sent and the digest is available prior to the response header fields being sent and the digest
does not need to be recalculated every time a validation request is does not need to be recalculated every time a validation request is
received. However, if a resource has distinct representations that differ received. However, if a resource has distinct representations that differ
only in their metadata, such as might occur with content negotiation over only in their metadata, such as might occur with content negotiation over
media types that happen to share the same data format, then the origin media types that happen to share the same data format, then the origin
server needs to incorporate additional information in the validator to server needs to incorporate additional information in the validator to
distinguish those representations. distinguish those representations.
</t> </t>
<t> <t>
In contrast, a <em>weak validator</em> is representation metadata In contrast, a "weak validator" is representation metadata
that might not change for every change to the representation data. This that might 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.
</t> </t>
<t> <t>
An origin server <bcp14>SHOULD</bcp14> change a weak entity-tag whenever it An origin server <bcp14>SHOULD</bcp14> change a weak entity tag whenever it
considers prior representations to be unacceptable as a substitute for considers prior representations to be unacceptable as a substitute for
the current representation. In other words, a weak entity-tag ought to the current representation. In other words, a weak entity tag ought to
change whenever the origin server wants caches to invalidate old change whenever the origin server wants caches to invalidate old
responses. responses.
</t> </t>
<t> <t>
For example, the representation of a weather report that changes in For example, the representation of a weather report that changes in
content every second, based on dynamic measurements, might be grouped content every second, based on dynamic measurements, might be grouped
into sets of equivalent representations (from the origin server's into sets of equivalent representations (from the origin server's
perspective) with the same weak validator in order to allow cached perspective) with the same weak validator in order to allow cached
representations to be valid for a reasonable period of time (perhaps representations to be valid for a reasonable period of time (perhaps
adjusted dynamically based on server load or weather quality). adjusted dynamically based on server load or weather quality).
skipping to change at line 3972 skipping to change at line 3955
<iref primary="true" item="Fields" subitem="Last-Modified"/> <iref primary="true" item="Fields" subitem="Last-Modified"/>
<iref primary="true" item="Header Fields" subitem="Last-Modified" /> <iref primary="true" item="Header Fields" subitem="Last-Modified" />
<iref primary="true" item="Last-Modified header field"/> <iref primary="true" item="Last-Modified header field"/>
<t> <t>
The "Last-Modified" header field in a response provides a timestamp The "Last-Modified" header field in a response provides a timestamp
indicating the date and time at which the origin server believes the indicating the date and time at which the origin server believes the
<xref target="selected.representation" format="none">selected representation< /xref> was last modified, as determined at the conclusion <xref target="selected.representation" format="none">selected representation< /xref> was last modified, as determined at the conclusion
of handling the request. of handling the request.
</t> </t>
<iref primary="true" item="Grammar" subitem="Last-Modified"/> <iref primary="true" item="Grammar" subitem="Last-Modified"/>
<sourcecode type="abnf7230"><![CDATA[ Last-Modified = HTTP-date <sourcecode type="abnf9110"><![CDATA[ Last-Modified = HTTP-date
]]></sourcecode> ]]></sourcecode>
<t> <t>
An example of its use is An example of its use is
</t> </t>
<sourcecode type="http-message"><![CDATA[Last-Modified: Tue, 15 N ov 1994 12:45:26 GMT <sourcecode type="http-message"><![CDATA[Last-Modified: Tue, 15 N ov 1994 12:45:26 GMT
]]></sourcecode> ]]></sourcecode>
<section anchor="lastmod.generation" title="Generation"> <section anchor="lastmod.generation" title="Generation">
<t> <t>
An origin server <bcp14>SHOULD</bcp14> send Last-Modified for any selected An origin server <bcp14>SHOULD</bcp14> 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
skipping to change at line 4074 skipping to change at line 4057
have a <xref target="field.date" format="none">Date</xref> value equal to its Last-Modified time. have a <xref target="field.date" format="none">Date</xref> value equal to its Last-Modified time.
</t> </t>
</section> </section>
</section> </section>
<section anchor="field.etag" title="ETag"> <section anchor="field.etag" title="ETag">
<iref primary="true" item="Fields" subitem="ETag"/> <iref primary="true" item="Fields" subitem="ETag"/>
<iref primary="true" item="Header Fields" subitem="ETag"/> <iref primary="true" item="Header Fields" subitem="ETag"/>
<iref primary="true" item="Trailer Fields" subitem="ETag"/> <iref primary="true" item="Trailer Fields" subitem="ETag"/>
<iref primary="true" item="ETag field"/> <iref primary="true" item="ETag field"/>
<t> <t>
The "ETag" field in a response provides the current entity-tag for The "ETag" field in a response provides the current entity tag for
the <xref target="selected.representation" format="none">selected representat ion</xref>, as determined at the conclusion of handling the <xref target="selected.representation" format="none">selected representat ion</xref>, as determined at the conclusion of handling
the request. the request.
An entity-tag is an opaque validator for differentiating between An entity tag is an opaque validator for differentiating between
multiple representations of the same resource, regardless of whether multiple representations of the same resource, regardless of whether
those multiple representations are due to resource state changes over those multiple representations are due to resource state changes over
time, content negotiation resulting in multiple representations being time, content negotiation resulting in multiple representations being
valid at the same time, or both. An entity-tag consists of an opaque valid at the same time, or both. An entity tag consists of an opaque
quoted string, possibly prefixed by a weakness indicator. quoted string, possibly prefixed by a weakness indicator.
</t> </t>
<iref primary="true" item="Grammar" subitem="ETag"/> <iref primary="true" item="Grammar" subitem="ETag"/>
<iref primary="true" item="Grammar" subitem="entity-tag"/> <iref primary="true" item="Grammar" subitem="entity-tag"/>
<iref primary="true" item="Grammar" subitem="weak"/> <iref primary="true" item="Grammar" subitem="weak"/>
<iref primary="true" item="Grammar" subitem="opaque-tag"/> <iref primary="true" item="Grammar" subitem="opaque-tag"/>
<iref primary="true" item="Grammar" subitem="etagc"/> <iref primary="true" item="Grammar" subitem="etagc"/>
<sourcecode type="abnf7230"><![CDATA[ ETag = entity-tag <sourcecode type="abnf9110"><![CDATA[ ETag = entity-tag
entity-tag = [ weak ] opaque-tag entity-tag = [ weak ] opaque-tag
weak = %s"W/" weak = %s"W/"
opaque-tag = DQUOTE *etagc DQUOTE opaque-tag = DQUOTE *etagc DQUOTE
etagc = %x21 / %x23-7E / obs-text etagc = %x21 / %x23-7E / obs-text
; VCHAR except double quotes, plus obs-text ; VCHAR except double quotes, plus obs-text
]]></sourcecode> ]]></sourcecode>
<aside> <aside>
<t> <t>
<strong>Note:</strong> Previously, opaque-tag was defined t o be a quoted-string <strong>Note:</strong> Previously, opaque-tag was defined t o be a quoted-string
(<xref target="RFC2616" sectionFormat="comma" section="3.11"/>); thus, some recipients (<xref target="RFC2616" sectionFormat="comma" section="3.11"/>); thus, some recipients
might perform backslash unescaping. Servers therefore ought to avoid might perform backslash unescaping. Servers therefore ought to avoid
backslash characters in entity tags. backslash characters in entity tags.
</t> </t>
</aside> </aside>
<t> <t>
An entity-tag can be more reliable for validation than a modification An entity tag can be more reliable for validation than a modification
date in situations where it is inconvenient to store modification date in situations where it is inconvenient to store modification
dates, where the one-second resolution of HTTP date values is not dates, where the one-second resolution of HTTP-date values is not
sufficient, or where modification dates are not consistently maintained. sufficient, or where modification dates are not consistently maintained.
</t> </t>
<t> <t>
Examples: Examples:
</t> </t>
<sourcecode type="http-message"><![CDATA[ETag: "xyzzy" <sourcecode type="http-message"><![CDATA[ETag: "xyzzy"
ETag: W/"xyzzy" ETag: W/"xyzzy"
ETag: "" ETag: ""
]]></sourcecode> ]]></sourcecode>
<t> <t>
An entity-tag can be either a weak or strong validator, with An entity tag can be either a weak or strong validator, with
strong being the default. If an origin server provides an entity-tag strong being the default. If an origin server provides an entity tag
for a representation and the generation of that entity-tag does not satisfy for a representation and the generation of that entity tag does not satisfy
all of the characteristics of a strong validator all of the characteristics of a strong validator
(<xref target="weak.and.strong.validators"/>), then the origin server (<xref target="weak.and.strong.validators"/>), then the origin server
<bcp14>MUST</bcp14> mark the entity-tag as weak by prefixing its opaque value <bcp14>MUST</bcp14> mark the entity tag as weak by prefixing its opaque value
with "W/" (case-sensitive). with "W/" (case-sensitive).
</t> </t>
<t> <t>
A sender <bcp14>MAY</bcp14> send the Etag field in a trailer section (see A sender <bcp14>MAY</bcp14> send the ETag field in a trailer section (see
<xref target="trailer.fields"/>). However, since trailers are often <xref target="trailer.fields"/>). However, since trailers are often
ignored, it is preferable to send Etag as a header field unless the ignored, it is preferable to send ETag as a header field unless the
entity-tag is generated while sending the content. entity tag is generated while sending the content.
</t> </t>
<section anchor="entity.tag.generation" title="Generation"> <section anchor="entity.tag.generation" title="Generation">
<t> <t>
The principle behind entity-tags is that only the service author The principle behind entity tags is that only the service author
knows the implementation of a resource well enough to select the knows the implementation of a resource well enough to select the
most accurate and efficient validation mechanism for that resource, most accurate and efficient validation mechanism for that resource,
and that any such mechanism can be mapped to a simple sequence of and that any such mechanism can be mapped to a simple sequence of
octets for easy comparison. Since the value is opaque, there is no octets for easy comparison. Since the value is opaque, there is no
need for the client to be aware of how each entity-tag is constructed. need for the client to be aware of how each entity tag is constructed.
</t> </t>
<t> <t>
For example, a resource that has implementation-specific versioning For example, a resource that has implementation-specific versioning
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. accurately differentiate between representations.
Other implementations might use a collision-resistant hash of Other 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.
</t> </t>
<t> <t>
An origin server <bcp14>SHOULD</bcp14> send an ETag for any selected represen tation An origin server <bcp14>SHOULD</bcp14> send an ETag for any selected represen tation
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 (<xref target="CACHING"/>) can evaluating cache freshness (<xref target="CACHING"/>) can
substantially reduce unnecessary transfers and significantly substantially reduce unnecessary transfers and significantly
improve service availability, scalability, and reliability. improve service availability, scalability, and reliability.
</t> </t>
</section> </section>
<section anchor="entity.tag.comparison" title="Comparison"> <section anchor="entity.tag.comparison" title="Comparison">
<t> <t>
There are two entity-tag comparison functions, depending on whether or not There are two entity tag comparison functions, depending on whether or not
the comparison context allows the use of weak validators: the comparison context allows the use of weak validators:
</t> </t>
<dl> <dl>
<dt> <dt>
<em>Strong comparison</em>: "Strong comparison":
</dt> </dt>
<dd> <dd>
two entity-tags are equivalent if both are not weak and their opaque-tags two entity tags are equivalent if both are not weak and their opaque-tags
match character-by-character. match character-by-character.
</dd> </dd>
<dt> <dt>
<em>Weak comparison</em>: "Weak comparison":
</dt> </dt>
<dd> <dd>
two entity-tags are equivalent if their opaque-tags match two entity tags are equivalent if their opaque-tags match
character-by-character, regardless of either or both being tagged as "weak". character-by-character, regardless of either or both being tagged as "weak".
</dd> </dd>
</dl> </dl>
<t> <t>
The example below shows the results for a set of entity-tag pairs and both The example below shows the results for a set of entity tag pairs and both
the weak and strong comparison function results: the weak and strong comparison function results:
</t> </t>
<table align="left"> <table align="left">
<thead> <thead>
<tr> <tr>
<th>ETag 1</th> <th>ETag 1</th>
<th>ETag 2</th> <th>ETag 2</th>
<th>Strong Comparison</th> <th>Strong Comparison</th>
<th>Weak Comparison</th> <th>Weak Comparison</th>
</tr> </tr>
skipping to change at line 4223 skipping to change at line 4206
<tr> <tr>
<td>"1"</td> <td>"1"</td>
<td>"1"</td> <td>"1"</td>
<td>match</td> <td>match</td>
<td>match</td> <td>match</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section anchor="example.entity.tag.vs.conneg" <section anchor="example.entity.tag.vs.conneg"
title="Example: Entity-Tags Varying on Content-Negotiate d Resources"> title="Example: Entity Tags Varying on Content-Negotiate d Resources">
<t> <t>
Consider a resource that is subject to content negotiation Consider a resource that is subject to content negotiation
(<xref target="content.negotiation"/>), and where the representations sent in response to (<xref target="content.negotiation"/>), and where the representations sent in response to
a GET request vary based on the <xref target="field.accept-encoding" format=" none">Accept-Encoding</xref> request a GET request vary based on the <xref target="field.accept-encoding" format=" none">Accept-Encoding</xref> request
header field (<xref target="field.accept-encoding"/>): header field (<xref target="field.accept-encoding"/>):
</t> </t>
<t> <t>
&gt;&gt; Request: &gt;&gt; Request:
</t> </t>
<sourcecode type="http-message"><![CDATA[GET /index HTTP/1.1 <sourcecode type="http-message"><![CDATA[GET /index HTTP/1.1
skipping to change at line 4276 skipping to change at line 4259
ETag: "123-b" ETag: "123-b"
Content-Length: 43 Content-Length: 43
Vary: Accept-Encoding Vary: Accept-Encoding
Content-Type: text/plain Content-Type: text/plain
Content-Encoding: gzip Content-Encoding: gzip
...binary data...]]></sourcecode> ...binary data...]]></sourcecode>
<aside> <aside>
<t> <t>
<strong>Note:</strong> Content codings are a property of the representation data, <strong>Note:</strong> Content codings are a property of the representation data,
so a strong entity-tag for a content-encoded representation has to be so a strong entity tag for a content-encoded representation has to be
distinct from the entity tag of an unencoded representation to prevent distinct from the entity tag of an unencoded representation to prevent
potential conflicts during cache updates and range requests. In contrast, potential conflicts during cache updates and range requests. In contrast,
transfer codings (<xref target="HTTP11" section="7"/>) apply only during mes sage transfer transfer codings (<xref target="HTTP11" section="7"/>) apply only during mes sage transfer
and do not result in distinct entity-tags. and do not result in distinct entity tags.
</t> </t>
</aside> </aside>
</section> </section>
</section> </section>
</section> </section>
</section> </section>
<section anchor="methods" title="Methods"> <section anchor="methods" title="Methods">
<section anchor="method.overview" title="Overview"> <section anchor="method.overview" title="Overview">
<t> <t>
The request method token is the primary source of request semantics; The request method token is the primary source of request semantics;
skipping to change at line 4309 skipping to change at line 4292
(<xref target="preconditions"/>) to make the requested (<xref target="preconditions"/>) to make the requested
action conditional on the current state of the target resource. action conditional on the current state of the target resource.
</t> </t>
<t> <t>
HTTP is designed to be usable as an interface to distributed HTTP is designed to be usable as an interface to distributed
object systems. The request method invokes an action to be applied to object systems. The request method invokes an action to be applied to
a <xref target="target.resource" format="none">target resource</xref> in much the same way that a remote a <xref target="target.resource" format="none">target resource</xref> in much the same way that a remote
method invocation can be sent to an identified object. method invocation can be sent to an identified object.
</t> </t>
<iref primary="true" item="Grammar" subitem="method"/> <iref primary="true" item="Grammar" subitem="method"/>
<sourcecode type="abnf7230"><![CDATA[ method = token <sourcecode type="abnf9110"><![CDATA[ method = token
]]></sourcecode> ]]></sourcecode>
<t> <t>
The method token is case-sensitive because it might be used as a gateway The method token is case-sensitive because it might be used as a gateway
to object-based systems with case-sensitive method names. By convention, to object-based systems with case-sensitive method names. By convention,
standardized methods are defined in all-uppercase US-ASCII letters. standardized methods are defined in all-uppercase US-ASCII letters.
</t> </t>
<t> <t>
Unlike distributed objects, the standardized request methods in HTTP are Unlike distributed objects, the standardized request methods in HTTP are
not resource-specific, since uniform interfaces provide for better not resource-specific, since uniform interfaces provide for better
visibility and reuse in network-based systems <xref target="REST"/>. visibility and reuse in network-based systems <xref target="REST"/>.
skipping to change at line 4331 skipping to change at line 4314
applied to any resource, though each resource determines for itself applied to any resource, though each resource determines for itself
whether those semantics are implemented or allowed. whether those semantics are implemented or allowed.
</t> </t>
<t> <t>
This specification defines a number of standardized methods that are This specification defines a number of standardized methods that are
commonly used in HTTP, as outlined by the following table. commonly used in HTTP, as outlined by the following table.
</t> </t>
<table align="left" anchor="table.of.methods"> <table align="left" anchor="table.of.methods">
<thead> <thead>
<tr> <tr>
<th>Method</th> <th>Method Name</th>
<th>Description</th> <th>Description</th>
<th>Ref.</th> <th>Section</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td>GET</td> <td>GET</td>
<td>Transfer a current representation of the target resourc e.</td> <td>Transfer a current representation of the target resourc e.</td>
<td> <td>
<xref target="GET" format="counter"/> <xref target="GET" format="counter"/>
</td> </td>
</tr> </tr>
skipping to change at line 4422 skipping to change at line 4405
Additional methods, outside the scope of this specification, have been Additional methods, outside the scope of this specification, have been
specified for use in HTTP. All such methods ought to be registered specified for use in HTTP. All such methods ought to be registered
within the "Hypertext Transfer Protocol (HTTP) Method Registry", within the "Hypertext Transfer Protocol (HTTP) Method Registry",
as described in <xref target="method.extensibility"/>. as described in <xref target="method.extensibility"/>.
</t> </t>
</section> </section>
<section anchor="method.properties" title="Common Method Properties"> <section anchor="method.properties" title="Common Method Properties">
<section anchor="safe.methods" title="Safe Methods"> <section anchor="safe.methods" title="Safe Methods">
<iref item="safe" primary="true"/> <iref item="safe" primary="true"/>
<t> <t>
Request methods are considered <em>safe</em> if Request methods are considered "safe" if
their defined semantics are essentially read-only; i.e., the client does their defined semantics are essentially read-only; i.e., the client does
not request, and does not expect, any state change on the origin server not request, and does not expect, any state change on the origin server
as a result of applying a safe method to a target resource. Likewise, as a result of applying a safe method to a target resource. Likewise,
reasonable use of a safe method is not expected to cause any harm, reasonable use of a safe method is not expected to cause any harm,
loss of property, or unusual burden on the origin server. loss of property, or unusual burden on the origin server.
</t> </t>
<t> <t>
This definition of safe methods does not prevent an implementation from This definition of safe methods does not prevent an implementation from
including behavior that is potentially harmful, that is not entirely read-onl y, including behavior that is potentially harmful, that is not entirely read-onl y,
or that causes side effects while invoking a safe method. What is or that causes side effects while invoking a safe method. What is
skipping to change at line 4478 skipping to change at line 4461
the resource owner <bcp14>MUST</bcp14> disable or disallow that action when i t is the resource owner <bcp14>MUST</bcp14> disable or disallow that action when i t is
accessed using a safe request method. Failure to do so will result in accessed using a safe request method. Failure to do so will result in
unfortunate side effects when automated processes perform a GET on unfortunate side effects when automated processes perform a GET on
every URI reference for the sake of link maintenance, pre-fetching, every URI reference for the sake of link maintenance, pre-fetching,
building a search index, etc. building a search index, etc.
</t> </t>
</section> </section>
<section anchor="idempotent.methods" title="Idempotent Methods"> <section anchor="idempotent.methods" title="Idempotent Methods">
<iref item="idempotent" primary="true"/> <iref item="idempotent" primary="true"/>
<t> <t>
A request method is considered A request method is considered "idempotent"
<em>idempotent</em>
if the intended effect on the server of multiple identical requests with if the intended effect on the server of multiple identical requests with
that method is the same as the effect for a single such request. that method is the same as the effect for a single such request.
Of the request methods defined by this Of the request methods defined by this
specification, <xref target="PUT" format="none">PUT</xref>, <xref target="DEL ETE" format="none">DELETE</xref>, and safe request specification, <xref target="PUT" format="none">PUT</xref>, <xref target="DEL ETE" format="none">DELETE</xref>, and safe request
methods are idempotent. methods are idempotent.
</t> </t>
<t> <t>
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 request what has been requested by the user; a server is free to log each request
separately, retain a revision control history, or implement other separately, retain a revision control history, or implement other
skipping to change at line 4532 skipping to change at line 4514
connection was used. connection was used.
</t> </t>
<t> <t>
A proxy <bcp14>MUST NOT</bcp14> automatically retry non-idempotent requests. A proxy <bcp14>MUST NOT</bcp14> automatically retry non-idempotent requests.
A client <bcp14>SHOULD NOT</bcp14> automatically retry a failed automatic ret ry. A client <bcp14>SHOULD NOT</bcp14> automatically retry a failed automatic ret ry.
</t> </t>
</section> </section>
<section anchor="cacheable.methods" title="Methods and Caching"> <section anchor="cacheable.methods" title="Methods and Caching">
<t> <t>
For a cache to store and use a response, the associated method needs to For a cache to store and use a response, the associated method needs to
explicitly allow caching, and detail under what conditions a response can explicitly allow caching and to detail under what conditions a response can
be used to satisfy subsequent requests; a method definition which does not be used to satisfy subsequent requests; a method definition that does not
do so cannot be cached. For additional requirements see <xref target="CACHING "/>. do so cannot be cached. For additional requirements see <xref target="CACHING "/>.
</t> </t>
<t> <t>
This specification defines caching semantics for GET, HEAD, and POST, This specification defines caching semantics for GET, HEAD, and POST,
although the overwhelming majority of cache implementations only support although the overwhelming majority of cache implementations only support
GET and HEAD. GET and HEAD.
</t> </t>
</section> </section>
</section> </section>
<section anchor="method.definitions" title="Method Definitions"> <section anchor="method.definitions" title="Method Definitions">
skipping to change at line 4704 skipping to change at line 4686
a <xref target="status.201" format="none">201 (Created)</xref> response conta ining a <xref target="field.location" format="none">Location</xref> a <xref target="status.201" format="none">201 (Created)</xref> response conta ining a <xref target="field.location" format="none">Location</xref>
header field that provides an identifier for the primary resource created header field that provides an identifier for the primary resource created
(<xref target="field.location"/>) and a representation that describes the (<xref target="field.location"/>) and a representation that describes the
status of the request while referring to the new resource(s). status of the request while referring to the new resource(s).
</t> </t>
<t> <t>
Responses to POST requests are only cacheable when they include explicit Responses to POST requests are only cacheable when they include explicit
freshness information (see <xref target="CACHING" section="4.2.1"/>) and a freshness information (see <xref target="CACHING" section="4.2.1"/>) and a
<xref target="field.content-location" format="none">Content-Location</xref> h eader field that has the same value as <xref target="field.content-location" format="none">Content-Location</xref> h eader field that has the same value as
the POST's target URI (<xref target="field.content-location"/>). A cached POS T response can be reused the POST's target URI (<xref target="field.content-location"/>). A cached POS T response can be reused
to satisfy a later GET or HEAD request, but not a POST request, since POST to satisfy a later GET or HEAD request. In contrast, a POST request cannot
is required to be written through to the origin server, because it is be satisfied by a cached POST response because POST is potentially unsafe;
unsafe; see <xref target="CACHING" section="4"/>. see <xref target="CACHING" section="4"/>.
</t> </t>
<t> <t>
If the result of processing a POST would be equivalent to a representation If the result of processing a POST would be equivalent to a representation
of an existing resource, an origin server <bcp14>MAY</bcp14> redirect the use r agent to of an existing resource, an origin server <bcp14>MAY</bcp14> redirect the use r agent to
that resource by sending a <xref target="status.303" format="none">303 (See O ther)</xref> response with the that resource by sending a <xref target="status.303" format="none">303 (See O ther)</xref> response with the
existing resource's identifier in the <xref target="field.location" format="n one">Location</xref> field. existing resource's identifier in the <xref target="field.location" format="n one">Location</xref> field.
This has the benefits of providing the user agent a resource identifier This has the benefits of providing the user agent a resource identifier
and transferring the representation via a method more amenable to shared and transferring the representation via a method more amenable to shared
caching, though at the cost of an extra request if the user agent does not caching, though at the cost of an extra request if the user agent does not
already have the representation cached. already have the representation cached.
skipping to change at line 4804 skipping to change at line 4786
</t> </t>
<t> <t>
An origin server <bcp14>MUST NOT</bcp14> send a validator field An origin server <bcp14>MUST NOT</bcp14> send a validator field
(<xref target="response.validator"/>), such as an <xref target="field.etag" f ormat="none">ETag</xref> or (<xref target="response.validator"/>), such as an <xref target="field.etag" f ormat="none">ETag</xref> or
<xref target="field.last-modified" format="none">Last-Modified</xref> field, in a successful response to PUT unless <xref target="field.last-modified" format="none">Last-Modified</xref> field, in a successful response to PUT unless
the request's representation data was saved without any transformation the request's representation data was saved without any transformation
applied to the content (i.e., the resource's new representation data is applied to the content (i.e., the resource's new representation data is
identical to the content received in the PUT request) and the identical to the content received in the PUT request) and the
validator field value reflects the new representation. validator field value reflects the new representation.
This requirement allows a user agent to know when the representation it This requirement allows a user agent to know when the representation it
sent (and retains in memory) is the result of the PUT, and thus doesn't sent (and retains in memory) is the result of the PUT, and thus it doesn't
need to be retrieved again from the origin server. The new validator(s) need to be retrieved again from the origin server. The new validator(s)
received in the response can be used for future conditional requests in received in the response can be used for future conditional requests in
order to prevent accidental overwrites (<xref target="preconditions"/>). order to prevent accidental overwrites (<xref target="preconditions"/>).
</t> </t>
<t> <t>
The fundamental difference between the POST and PUT methods is The fundamental difference between the POST and PUT methods is
highlighted by the different intent for the enclosed representation. highlighted by the different intent for the enclosed representation.
The target resource in a POST request is intended to handle the The target resource in a POST request is intended to handle the
enclosed representation according to the resource's own semantics, enclosed representation according to the resource's own semantics,
whereas the enclosed representation in a PUT request is defined as whereas the enclosed representation in a PUT request is defined as
skipping to change at line 4876 skipping to change at line 4858
or might not be destroyed by the origin server, and the associated storage or might not be destroyed by the origin server, and the associated storage
might or might not be reclaimed, depending entirely on the nature of the might or might not be reclaimed, depending entirely on the nature of the
resource and its implementation by the origin server (which are beyond the resource and its implementation by the origin server (which are beyond the
scope of this specification). Likewise, other implementation aspects of a scope of this specification). Likewise, other implementation aspects of a
resource might need to be deactivated or archived as a result of a DELETE, resource might need to be deactivated or archived as a result of a DELETE,
such as database or gateway connections. In general, it is assumed that the such as database or gateway connections. In general, it is assumed that the
origin server will only allow DELETE on resources for which it has a origin server will only allow DELETE on resources for which it has a
prescribed mechanism for accomplishing the deletion. prescribed mechanism for accomplishing the deletion.
</t> </t>
<t> <t>
Relatively few resources allow the DELETE method — its primary use Relatively few resources allow the DELETE method -- its primary use
is for remote authoring environments, where the user has some direction is for remote authoring environments, where the user has some direction
regarding its effect. For example, a resource that was previously created regarding its effect. For example, a resource that was previously created
using a PUT request, or identified via the Location header field after a using a PUT request, or identified via the Location header field after a
<xref target="status.201" format="none">201 (Created)</xref> response to a PO ST request, might allow a <xref target="status.201" format="none">201 (Created)</xref> response to a PO ST request, might allow a
corresponding DELETE request to undo those actions. Similarly, custom corresponding DELETE request to undo those actions. Similarly, custom
user agent implementations that implement an authoring function, such as user agent implementations that implement an authoring function, such as
revision control clients using HTTP for remote operations, might use revision control clients using HTTP for remote operations, might use
DELETE based on an assumption that the server's URI space has been crafted DELETE based on an assumption that the server's URI space has been crafted
to correspond to a version repository. to correspond to a version repository.
</t> </t>
skipping to change at line 5068 skipping to change at line 5050
</t> </t>
</section> </section>
<section anchor="TRACE" title="TRACE"> <section anchor="TRACE" title="TRACE">
<iref primary="true" item="TRACE method"/> <iref primary="true" item="TRACE method"/>
<iref primary="true" item="Method" subitem="TRACE"/> <iref primary="true" item="Method" subitem="TRACE"/>
<t> <t>
The TRACE method requests a remote, application-level loop-back of the The TRACE method requests a remote, application-level loop-back of the
request message. The final recipient of the request <bcp14>SHOULD</bcp14> ref lect the request message. The final recipient of the request <bcp14>SHOULD</bcp14> ref lect the
message received, excluding some fields described below, back to the client message received, excluding some fields described below, back to the client
as the content of a <xref target="status.200" format="none">200 (OK)</xref> r esponse. The "message/http" as the content of a <xref target="status.200" format="none">200 (OK)</xref> r esponse. The "message/http"
(<xref target="HTTP11" section="10.1"/>) format is one way to do so. format (<xref target="HTTP11" section="10.1"/>) is one way to do so.
The final recipient is either the origin server or the first server to The final recipient is either the origin server or the first server to
receive a <xref target="field.max-forwards" format="none">Max-Forwards</xref> value of zero (0) in the request receive a <xref target="field.max-forwards" format="none">Max-Forwards</xref> value of zero (0) in the request
(<xref target="field.max-forwards"/>). (<xref target="field.max-forwards"/>).
</t> </t>
<t> <t>
A client <bcp14>MUST NOT</bcp14> generate fields in a TRACE request containin g A client <bcp14>MUST NOT</bcp14> generate fields in a TRACE request containin g
sensitive data that might be disclosed by the response. For example, it sensitive data that might be disclosed by the response. For example, it
would be foolish for a user agent to send stored user credentials would be foolish for a user agent to send stored user credentials
(<xref target="authentication"/>) or cookies <xref target="COOKIE"/> in a TRA CE (<xref target="authentication"/>) or cookies <xref target="COOKIE"/> in a TRA CE
request. The final recipient of the request <bcp14>SHOULD</bcp14> exclude any request request. The final recipient of the request <bcp14>SHOULD</bcp14> exclude any request
skipping to change at line 5118 skipping to change at line 5100
<iref primary="true" item="Fields" subitem="Expect"/> <iref primary="true" item="Fields" subitem="Expect"/>
<iref primary="true" item="Header Fields" subitem="Expect"/> <iref primary="true" item="Header Fields" subitem="Expect"/>
<iref primary="true" item="Expect header field"/> <iref primary="true" item="Expect header field"/>
<iref primary="true" item="100-continue (expect value)"/> <iref primary="true" item="100-continue (expect value)"/>
<t> <t>
The "Expect" header field in a request indicates a certain set of The "Expect" header field in a request indicates a certain set of
behaviors (expectations) that need to be supported by the server in behaviors (expectations) that need to be supported by the server in
order to properly handle this request. order to properly handle this request.
</t> </t>
<iref primary="true" item="Grammar" subitem="Expect"/> <iref primary="true" item="Grammar" subitem="Expect"/>
<sourcecode type="abnf7230"><![CDATA[ Expect = #expectation <sourcecode type="abnf9110"><![CDATA[ Expect = #expectation
expectation = token [ "=" ( token / quoted-string ) parameters ] expectation = token [ "=" ( token / quoted-string ) parameters ]
]]></sourcecode> ]]></sourcecode>
<t> <t>
The Expect field value is case-insensitive. The Expect field value is case-insensitive.
</t> </t>
<t> <t>
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).
</t> </t>
<t> <t>
A server that receives an Expect field value containing a member other than A server that receives an Expect field value containing a member other than
<xref target="field.expect" format="none">100-continue</xref> <xref target="field.expect" format="none">100-continue</xref>
<bcp14>MAY</bcp14> respond with a <bcp14>MAY</bcp14> respond with a
<xref target="status.417" format="none">417 (Expectation Failed)</xref> statu s code to indicate that the <xref target="status.417" format="none">417 (Expectation Failed)</xref> statu s code to indicate that the
unexpected expectation cannot be met. unexpected expectation cannot be met.
</t> </t>
<t> <t>
A <em>100-continue</em> expectation informs recipients that the A "100-continue" expectation informs recipients that the
client is about to send (presumably large) content in this request client is about to send (presumably large) content in this request
and wishes to receive a <xref target="status.100" format="none">100 (Continue )</xref> interim response if and wishes to receive a <xref target="status.100" format="none">100 (Continue )</xref> interim response if
the method, target URI, and header fields are not sufficient to cause an imme diate the method, target URI, and header fields are not sufficient to cause an imme diate
success, redirect, or error response. This allows the client to wait for an success, redirect, or error response. This allows the client to wait for an
indication that it is worthwhile to send the content before actually indication that it is worthwhile to send the content before actually
doing so, which can improve efficiency when the data is huge or doing so, which can improve efficiency when the data is huge or
when the client anticipates that an error is likely (e.g., when sending a when the client anticipates that an error is likely (e.g., when sending a
state-changing method, for the first time, without previously verified state-changing method, for the first time, without previously verified
authentication credentials). authentication credentials).
</t> </t>
skipping to change at line 5219 skipping to change at line 5201
request content, unless the connection is closed prematurely. request content, unless the connection is closed prematurely.
</li> </li>
<li> <li>
A server that responds with a final status code before reading the A server that responds with a final status code before reading the
entire request content <bcp14>SHOULD</bcp14> indicate whether it intends to entire request content <bcp14>SHOULD</bcp14> indicate whether it intends to
close the connection (e.g., see <xref target="HTTP11" section="9.6"/>) or close the connection (e.g., see <xref target="HTTP11" section="9.6"/>) or
continue reading the request content. continue reading the request content.
</li> </li>
</ul> </ul>
<t> <t>
An origin server <bcp14>MUST</bcp14>, upon receiving an HTTP/1.1 (or later) r equest that has a method, target URI, Upon receiving an HTTP/1.1 (or later) request that has a method, target URI,
and complete header section that contains a 100-continue expectation and and complete header section that contains a 100-continue expectation and
an indication that request content will follow, either send an immediate an indication that request content will follow, an origin server <bcp14>MUST<
response with a final status code, if that status can be determined by /bcp14>
examining just the method, target URI, and header fields, or send an immediat send either:
e </t>
<xref target="status.100" format="none">100 (Continue)</xref> response to enc <ul>
ourage the client to send the <li>an immediate response with a final status code, if that st
request content. The origin server <bcp14>MUST NOT</bcp14> wait for the conte atus can be
nt determined by examining just the method, target URI, and header fields, or
</li>
<li>an immediate <xref target="status.100" format="none">100 (
Continue)</xref> response to encourage the client
to send the request content.</li>
</ul>
<t>
The origin server <bcp14>MUST NOT</bcp14> wait for the content
before sending the <xref target="status.100" format="none">100 (Continue)</xr ef> response. before sending the <xref target="status.100" format="none">100 (Continue)</xr ef> response.
</t> </t>
<t> <t>
A proxy <bcp14>MUST</bcp14>, upon receiving an HTTP/1.1 (or later) request th at has a method, target URI, Upon receiving an HTTP/1.1 (or later) request that has a method, target URI,
and complete header section that contains a 100-continue expectation and and complete header section that contains a 100-continue expectation and
indicates a request content will follow, either send an immediate indicates a request content will follow, a proxy <bcp14>MUST</bcp14> either:
</t>
<ul>
<li>send an immediate
response with a final status code, if that status can be determined by response with a final status code, if that status can be determined by
examining just the method, target URI, and header fields, or begin forwarding examining just the method, target URI, and header fields, or</li>
the <li>forward the request toward the origin server by sending a
request toward the origin server by sending a corresponding request-line corresponding
and header section to the next inbound server. If the proxy believes (from request-line and header section to the next inbound server.</li>
configuration or past interaction) that the next inbound server only </ul>
supports HTTP/1.0, the proxy <bcp14>MAY</bcp14> generate an immediate <t>
<xref target="status.100" format="none">100 (Continue)</xref> response to enc If the proxy believes (from configuration or past interaction) that the
ourage the client to begin next inbound server only supports HTTP/1.0, the proxy <bcp14>MAY</bcp14> gene
sending the content. rate an
immediate <xref target="status.100" format="none">100 (Continue)</xref> respo
nse to encourage the client to
begin sending the content.
</t> </t>
</section> </section>
<section anchor="field.from" title="From"> <section anchor="field.from" title="From">
<iref primary="true" item="Fields" subitem="From"/> <iref primary="true" item="Fields" subitem="From"/>
<iref primary="true" item="Header Fields" subitem="From"/> <iref primary="true" item="Header Fields" subitem="From"/>
<iref primary="true" item="From header field"/> <iref primary="true" item="From header field"/>
<t> <t>
The "From" header field contains an Internet email address for a human The "From" header field contains an Internet email address for a human
user who controls the requesting user agent. The address ought to be user who controls the requesting user agent. The address ought to be
machine-usable, as defined by "mailbox" machine-usable, as defined by "mailbox"
in <xref target="RFC5322" section="3.4"/>: in <xref target="RFC5322" section="3.4"/>:
</t> </t>
<iref primary="true" item="Grammar" subitem="From"/> <iref primary="true" item="Grammar" subitem="From"/>
<sourcecode type="abnf7230"><![CDATA[ From = mailbox <sourcecode type="abnf9110"><![CDATA[ From = mailbox
mailbox = <mailbox, see [RFC5322], Section 3.4> mailbox = <mailbox, see [RFC5322], Section 3.4>
]]></sourcecode> ]]></sourcecode>
<t> <t>
An example is: An example is:
</t> </t>
<sourcecode type="http-message"><![CDATA[From: webmaster@example. org <sourcecode type="http-message"><![CDATA[From: spider-admin@examp le.org
]]></sourcecode> ]]></sourcecode>
<t> <t>
The From header field is rarely sent by non-robotic user agents. The From header field is rarely sent by non-robotic user agents.
A user agent <bcp14>SHOULD NOT</bcp14> send a From header field without expli cit A user agent <bcp14>SHOULD NOT</bcp14> send a From header field without expli cit
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.
</t> </t>
<t> <t>
A robotic user agent <bcp14>SHOULD</bcp14> send a valid From header field so that the A robotic user agent <bcp14>SHOULD</bcp14> send a valid From header field so that the
person responsible for running the robot can be contacted if problems person responsible for running the robot can be contacted if problems
skipping to change at line 5294 skipping to change at line 5287
<iref primary="true" item="Referer header field"/> <iref primary="true" item="Referer header field"/>
<t> <t>
The "Referer" [sic] header field allows the user agent to specify a URI The "Referer" [sic] header field allows the user agent to specify a URI
reference for the resource from which the <xref target="target.resource" form at="none">target URI</xref> was reference for the resource from which the <xref target="target.resource" form at="none">target URI</xref> was
obtained (i.e., the "referrer", though the field name is misspelled). obtained (i.e., the "referrer", though the field name is misspelled).
A user agent <bcp14>MUST NOT</bcp14> include the fragment and userinfo compon ents A user agent <bcp14>MUST NOT</bcp14> include the fragment and userinfo compon ents
of the URI reference <xref target="URI"/>, if any, when generating the of the URI reference <xref target="URI"/>, if any, when generating the
Referer field value. Referer field value.
</t> </t>
<iref primary="true" item="Grammar" subitem="Referer"/> <iref primary="true" item="Grammar" subitem="Referer"/>
<sourcecode type="abnf7230"><![CDATA[ Referer = absolute-URI / p artial-URI <sourcecode type="abnf9110"><![CDATA[ Referer = absolute-URI / p artial-URI
]]></sourcecode> ]]></sourcecode>
<t> <t>
The field value is either an <xref target="uri.references" format="none">abso lute-URI</xref> or a The field value is either an <xref target="uri.references" format="none">abso lute-URI</xref> or a
<xref target="uri.references" format="none">partial-URI</xref>. In the latter case (<xref target="uri"/>), <xref target="uri.references" format="none">partial-URI</xref>. In the latter case (<xref target="uri"/>),
the referenced URI is relative to the target URI the referenced URI is relative to the target URI
(<xref target="URI" sectionFormat="comma" section="5"/>). (<xref target="URI" sectionFormat="comma" section="5"/>).
</t> </t>
<t> <t>
The Referer header field allows servers to generate back-links to other The Referer header field allows servers to generate back-links to other
resources for simple analytics, logging, optimized caching, etc. It also resources for simple analytics, logging, optimized caching, etc. It also
skipping to change at line 5360 skipping to change at line 5353
An intermediary <bcp14>SHOULD NOT</bcp14> modify or delete the Referer header field when An intermediary <bcp14>SHOULD NOT</bcp14> modify or delete the Referer header field when
the field value shares the same scheme and host as the target URI. the field value shares the same scheme and host as the target URI.
</t> </t>
</section> </section>
<section anchor="field.te" title="TE"> <section anchor="field.te" title="TE">
<iref primary="true" item="Fields" subitem="TE"/> <iref primary="true" item="Fields" subitem="TE"/>
<iref primary="true" item="Header Fields" subitem="TE"/> <iref primary="true" item="Header Fields" subitem="TE"/>
<iref primary="true" item="TE header field"/> <iref primary="true" item="TE header field"/>
<t> <t>
The "TE" header field describes capabilities of the client with regard to The "TE" header field describes capabilities of the client with regard to
transfer encodings and trailer sections. transfer codings and trailer sections.
</t> </t>
<t> <t>
A TE field with a "trailers" member sent in a request indicates that the As described in <xref target="trailer.fields"/>,
client will not discard trailer fields, as described in a TE field with a "trailers" member sent in a request indicates that the
<xref target="trailer.fields"/>. client will not discard trailer fields.
</t> </t>
<t> <t>
TE is also used within HTTP/1.1 to advise servers about what transfer TE is also used within HTTP/1.1 to advise servers about which transfer
codings the client is able to accept in a response. codings the client is able to accept in a response.
As of publication, only HTTP/1.1 uses transfer codings As of publication, only HTTP/1.1 uses transfer codings
(see <xref target="HTTP11" section="7"/>). (see <xref target="HTTP11" section="7"/>).
</t> </t>
<t> <t>
The TE field value is a list of members, with each member (aside from The TE field value is a list of members, with each member (aside from
"trailers") consisting of a transfer coding name token with an optional "trailers") consisting of a transfer coding name token with an optional
weight indicating the client's relative preference for that weight indicating the client's relative preference for that
transfer coding (<xref target="quality.values"/>) and transfer coding (<xref target="quality.values"/>) and
optional parameters for that transfer coding. optional parameters for that transfer coding.
</t> </t>
<iref primary="true" item="Grammar" subitem="TE"/> <iref primary="true" item="Grammar" subitem="TE"/>
<iref primary="true" item="Grammar" subitem="t-codings"/> <iref primary="true" item="Grammar" subitem="t-codings"/>
<iref primary="true" item="Grammar" subitem="transfer-coding"/> <iref primary="true" item="Grammar" subitem="transfer-coding"/>
<iref primary="true" item="Grammar" subitem="transfer-parameter"/ > <iref primary="true" item="Grammar" subitem="transfer-parameter"/ >
<sourcecode type="abnf7230"><![CDATA[ TE = #t-co dings <sourcecode type="abnf9110"><![CDATA[ TE = #t-co dings
t-codings = "trailers" / ( transfer-coding [ weight ] ) t-codings = "trailers" / ( transfer-coding [ weight ] )
transfer-coding = token *( OWS ";" OWS transfer-parameter ) transfer-coding = token *( OWS ";" OWS transfer-parameter )
transfer-parameter = token BWS "=" BWS ( token / quoted-string ) transfer-parameter = token BWS "=" BWS ( token / quoted-string )
]]></sourcecode> ]]></sourcecode>
<t> <t>
A sender of TE <bcp14>MUST</bcp14> also send a "TE" connection option within the A sender of TE <bcp14>MUST</bcp14> also send a "TE" connection option within the
<xref target="field.connection" format="none">Connection</xref> header field (<xref target="field.connection"/>) <xref target="field.connection" format="none">Connection</xref> header field (<xref target="field.connection"/>)
to inform intermediaries not to forward this field. to inform intermediaries not to forward this field.
</t> </t>
</section> </section>
skipping to change at line 5409 skipping to change at line 5402
<t> <t>
The "User-Agent" header field contains information about the user agent The "User-Agent" header field contains information about the user agent
originating the request, which is often used by servers to help identify originating the request, which is often used by servers to help identify
the scope of reported interoperability problems, to work around or tailor the scope of reported interoperability problems, to work around or tailor
responses to avoid particular user agent limitations, and for analytics responses to avoid particular user agent limitations, and for analytics
regarding browser or operating system use. A user agent <bcp14>SHOULD</bcp14> send regarding browser or operating system use. A user agent <bcp14>SHOULD</bcp14> send
a User-Agent header field in each request unless specifically configured not a User-Agent header field in each request unless specifically configured not
to do so. to do so.
</t> </t>
<iref primary="true" item="Grammar" subitem="User-Agent"/> <iref primary="true" item="Grammar" subitem="User-Agent"/>
<sourcecode type="abnf7230"><![CDATA[ User-Agent = product *( RW S ( product / comment ) ) <sourcecode type="abnf9110"><![CDATA[ User-Agent = product *( RW S ( product / comment ) )
]]></sourcecode> ]]></sourcecode>
<t> <t>
The User-Agent field value consists of one or more product identifiers, The User-Agent field value consists of one or more product identifiers,
each followed by zero or more comments (<xref target="comments"/>), which tog ether each followed by zero or more comments (<xref target="comments"/>), which tog ether
identify the user agent software and its significant subproducts. identify the user agent software and its significant subproducts.
By convention, the product identifiers are listed in decreasing order of By convention, the product identifiers are listed in decreasing order of
their significance for identifying the user agent software. Each product their significance for identifying the user agent software. Each product
identifier consists of a name and optional version. identifier consists of a name and optional version.
</t> </t>
<iref primary="true" item="Grammar" subitem="product"/> <iref primary="true" item="Grammar" subitem="product"/>
<iref primary="true" item="Grammar" subitem="product-version"/> <iref primary="true" item="Grammar" subitem="product-version"/>
<sourcecode type="abnf7230"><![CDATA[ product = token [" /" product-version] <sourcecode type="abnf9110"><![CDATA[ product = token [" /" product-version]
product-version = token product-version = token
]]></sourcecode> ]]></sourcecode>
<t> <t>
A sender <bcp14>SHOULD</bcp14> limit generated product identifiers to what is necessary A sender <bcp14>SHOULD</bcp14> limit generated product identifiers to what is necessary
to identify the product; a sender <bcp14>MUST NOT</bcp14> generate advertisin g or other to identify the product; a sender <bcp14>MUST NOT</bcp14> generate advertisin g or other
nonessential information within the product identifier. nonessential information within the product identifier.
A sender <bcp14>SHOULD NOT</bcp14> generate information in <xref target="fiel d.user-agent" format="none">product-version</xref> A sender <bcp14>SHOULD NOT</bcp14> generate information in <xref target="fiel d.user-agent" format="none">product-version</xref>
that is not a version identifier (i.e., successive versions of the same that is not a version identifier (i.e., successive versions of the same
product name ought to differ only in the product-version portion of the product name ought to differ only in the product-version portion of the
product identifier). product identifier).
skipping to change at line 5473 skipping to change at line 5466
<iref primary="true" item="Fields" subitem="Allow"/> <iref primary="true" item="Fields" subitem="Allow"/>
<iref primary="true" item="Header Fields" subitem="Allow"/> <iref primary="true" item="Header Fields" subitem="Allow"/>
<iref primary="true" item="Allow header field"/> <iref primary="true" item="Allow header field"/>
<t> <t>
The "Allow" header field lists the set of methods advertised as The "Allow" header field lists the set of methods advertised as
supported by the <xref target="target.resource" format="none">target resource </xref>. The purpose of this field supported by the <xref target="target.resource" format="none">target resource </xref>. The purpose of this field
is strictly to inform the recipient of valid request methods associated is strictly to inform the recipient of valid request methods associated
with the resource. with the resource.
</t> </t>
<iref primary="true" item="Grammar" subitem="Allow"/> <iref primary="true" item="Grammar" subitem="Allow"/>
<sourcecode type="abnf7230"><![CDATA[ Allow = #method <sourcecode type="abnf9110"><![CDATA[ Allow = #method
]]></sourcecode> ]]></sourcecode>
<t> <t>
Example of use: Example of use:
</t> </t>
<sourcecode type="http-message"><![CDATA[Allow: GET, HEAD, PUT <sourcecode type="http-message"><![CDATA[Allow: GET, HEAD, PUT
]]></sourcecode> ]]></sourcecode>
<t> <t>
The actual set of allowed methods is defined by the origin server at the The actual set of allowed methods is defined by the origin server at the
time of each request. An origin server <bcp14>MUST</bcp14> generate an Allow header field in a time of each request. An origin server <bcp14>MUST</bcp14> generate an Allow header field in a
<xref target="status.405" format="none">405 (Method Not Allowed)</xref> respo nse and <bcp14>MAY</bcp14> do so in any <xref target="status.405" format="none">405 (Method Not Allowed)</xref> respo nse and <bcp14>MAY</bcp14> do so in any
other response. An empty Allow field value indicates that the resource other response. An empty Allow field value indicates that the resource
allows no methods, which might occur in a 405 response if the resource has allows no methods, which might occur in a 405 response if the resource has
been temporarily disabled by configuration. been temporarily disabled by configuration.
</t> </t>
<t> <t>
A proxy <bcp14>MUST NOT</bcp14> modify the Allow header field — it does not n eed A proxy <bcp14>MUST NOT</bcp14> modify the Allow header field -- it does not need
to understand all of the indicated methods in order to handle them to understand all of the indicated methods in order to handle them
according to the generic message handling rules. according to the generic message handling rules.
</t> </t>
</section> </section>
<section anchor="field.location" title="Location"> <section anchor="field.location" title="Location">
<iref primary="true" item="Fields" subitem="Location"/> <iref primary="true" item="Fields" subitem="Location"/>
<iref primary="true" item="Header Fields" subitem="Location"/> <iref primary="true" item="Header Fields" subitem="Location"/>
<iref primary="true" item="Location header field"/> <iref primary="true" item="Location header field"/>
<t> <t>
The "Location" header field is used in some responses to refer to a The "Location" header field is used in some responses to refer to a
specific resource in relation to the response. The type of relationship is specific resource in relation to the response. The type of relationship is
defined by the combination of request method and status code semantics. defined by the combination of request method and status code semantics.
</t> </t>
<iref primary="true" item="Grammar" subitem="Location"/> <iref primary="true" item="Grammar" subitem="Location"/>
<sourcecode type="abnf7230"><![CDATA[ Location = URI-reference <sourcecode type="abnf9110"><![CDATA[ Location = URI-reference
]]></sourcecode> ]]></sourcecode>
<t> <t>
The field value consists of a single URI-reference. When it has the form The field value consists of a single URI-reference. When it has the form
of a relative reference (<xref target="URI" sectionFormat="comma" section="4. 2"/>), of a relative reference (<xref target="URI" sectionFormat="comma" section="4. 2"/>),
the final value is computed by resolving it against the target the final value is computed by resolving it against the target
URI (<xref target="URI" sectionFormat="comma" section="5"/>). URI (<xref target="URI" sectionFormat="comma" section="5"/>).
</t> </t>
<t> <t>
For <xref target="status.201" format="none">201 (Created)</xref> responses, t he Location value refers to For <xref target="status.201" format="none">201 (Created)</xref> responses, t he Location value refers to
the primary resource created by the request. the primary resource created by the request.
skipping to change at line 5595 skipping to change at line 5588
how long the service is expected to be unavailable to the client. how long the service is expected to be unavailable to the client.
When sent with any <xref target="status.3xx" format="none">3xx (Redirection)< /xref> response, Retry-After When sent with any <xref target="status.3xx" format="none">3xx (Redirection)< /xref> response, Retry-After
indicates the minimum time that the user agent is asked to wait before indicates the minimum time that the user agent is asked to wait before
issuing the redirected request. issuing the redirected request.
</t> </t>
<t> <t>
The Retry-After field value can be either an HTTP-date or a number The Retry-After field value can be either an HTTP-date or a number
of seconds to delay after receiving the response. of seconds to delay after receiving the response.
</t> </t>
<iref primary="true" item="Grammar" subitem="Retry-After"/> <iref primary="true" item="Grammar" subitem="Retry-After"/>
<sourcecode type="abnf7230"><![CDATA[ Retry-After = HTTP-date / delay-seconds <sourcecode type="abnf9110"><![CDATA[ Retry-After = HTTP-date / delay-seconds
]]></sourcecode> ]]></sourcecode>
<t anchor="rule.delay-seconds"> <t anchor="rule.delay-seconds">
A delay-seconds value is a non-negative decimal integer, representing time A delay-seconds value is a non-negative decimal integer, representing time
in seconds. in seconds.
</t> </t>
<iref primary="true" item="Grammar" subitem="delay-seconds"/> <iref primary="true" item="Grammar" subitem="delay-seconds"/>
<sourcecode type="abnf7230"><![CDATA[ delay-seconds = 1*DIGIT <sourcecode type="abnf9110"><![CDATA[ delay-seconds = 1*DIGIT
]]></sourcecode> ]]></sourcecode>
<t> <t>
Two examples of its use are Two examples of its use are
</t> </t>
<sourcecode type="http-message"><![CDATA[Retry-After: Fri, 31 Dec 1999 23:59:59 GMT <sourcecode type="http-message"><![CDATA[Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
Retry-After: 120 Retry-After: 120
]]></sourcecode> ]]></sourcecode>
<t> <t>
In the latter example, the delay is 2 minutes. In the latter example, the delay is 2 minutes.
</t> </t>
skipping to change at line 5628 skipping to change at line 5621
<iref primary="true" item="Server header field"/> <iref primary="true" item="Server header field"/>
<t> <t>
The "Server" header field contains information about the The "Server" header field contains information about the
software used by the origin server to handle the request, which is often software used by the origin server to handle the request, which is often
used by clients to help identify the scope of reported interoperability used by clients to help identify the scope of reported interoperability
problems, to work around or tailor requests to avoid particular server problems, to work around or tailor requests to avoid particular server
limitations, and for analytics regarding server or operating system use. limitations, and for analytics regarding server or operating system use.
An origin server <bcp14>MAY</bcp14> generate a Server header field in its res ponses. An origin server <bcp14>MAY</bcp14> generate a Server header field in its res ponses.
</t> </t>
<iref primary="true" item="Grammar" subitem="Server"/> <iref primary="true" item="Grammar" subitem="Server"/>
<sourcecode type="abnf7230"><![CDATA[ Server = product *( RWS ( product / comment ) ) <sourcecode type="abnf9110"><![CDATA[ Server = product *( RWS ( product / comment ) )
]]></sourcecode> ]]></sourcecode>
<t> <t>
The Server header field value consists of one or more product identifiers, ea ch The Server header field value consists of one or more product identifiers, ea ch
followed by zero or more comments (<xref target="comments"/>), which together followed by zero or more comments (<xref target="comments"/>), which together
identify the origin server software and its significant subproducts. identify the origin server software and its significant subproducts.
By convention, the product identifiers are listed in decreasing order of By convention, the product identifiers are listed in decreasing order of
their significance for identifying the origin server software. Each product their significance for identifying the origin server software. Each product
identifier consists of a name and optional version, as defined in identifier consists of a name and optional version, as defined in
<xref target="field.user-agent"/>. <xref target="field.user-agent"/>.
</t> </t>
skipping to change at line 5662 skipping to change at line 5655
</section> </section>
</section> </section>
</section> </section>
<section anchor="authentication" title="HTTP Authentication"> <section anchor="authentication" title="HTTP Authentication">
<section anchor="auth.scheme" title="Authentication Scheme"> <section anchor="auth.scheme" title="Authentication Scheme">
<t> <t>
HTTP provides a general framework for access control and authentication, HTTP provides a general framework for access control and authentication,
via an extensible set of challenge-response authentication schemes, which via an extensible set of challenge-response authentication schemes, which
can be used by a server to challenge a client request and by a client to can be used by a server to challenge a client request and by a client to
provide authentication information. It uses a case-insensitive provide authentication information. It uses a case-insensitive
token to identify the authentication scheme token to identify the authentication scheme:
</t> </t>
<iref primary="true" item="Grammar" subitem="auth-scheme"/> <iref primary="true" item="Grammar" subitem="auth-scheme"/>
<sourcecode type="abnf7230"><![CDATA[ auth-scheme = token <sourcecode type="abnf9110"><![CDATA[ auth-scheme = token
]]></sourcecode> ]]></sourcecode>
<t> <t>
Aside from the general framework, this document does not specify any Aside from the general framework, this document does not specify any
authentication schemes. New and existing authentication schemes are authentication schemes. New and existing authentication schemes are
specified independently and ought to be registered within the specified independently and ought to be registered within the
"Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry". "Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry".
For example, the "basic" and "digest" authentication schemes are defined by For example, the "basic" and "digest" authentication schemes are defined by
<xref target="RFC7617" format="none">RFC 7617</xref> and <xref target="RFC7617"/> and
<xref target="RFC7616" format="none">RFC 7616</xref>, respectively. <xref target="RFC7616"/>, respectively.
</t> </t>
</section> </section>
<section anchor="auth.params" title="Authentication Parameters"> <section anchor="auth.params" title="Authentication Parameters">
<t> <t>
The authentication scheme is followed by additional information necessary The authentication scheme is followed by additional information necessary
for achieving authentication via that scheme as either a 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.
</t> </t>
<iref primary="true" item="Grammar" subitem="token68"/> <iref primary="true" item="Grammar" subitem="token68"/>
<sourcecode type="abnf7230"><![CDATA[ token68 = 1*( ALPHA / DIGIT / <sourcecode type="abnf9110"><![CDATA[ token68 = 1*( ALPHA / DIGIT /
"-" / "." / "_" / "~" / "+" / "/" ) *"=" "-" / "." / "_" / "~" / "+" / "/" ) *"="
]]></sourcecode> ]]></sourcecode>
<t> <t>
The token68 syntax allows the 66 unreserved URI characters The token68 syntax allows the 66 unreserved URI characters
(<xref target="URI"/>), plus a few others, so that it can hold a (<xref target="URI"/>), plus a few others, so that it can hold a
base64, base64url (URL and filename safe alphabet), base32, or base16 (hex) base64, base64url (URL and filename safe alphabet), base32, or base16 (hex)
encoding, with or without padding, but excluding whitespace encoding, with or without padding, but excluding whitespace
(<xref target="RFC4648"/>). (<xref target="RFC4648"/>).
</t> </t>
<t> <t>
Authentication parameters are name=value pairs, where the name token is Authentication parameters are name/value pairs, where the name token is
matched case-insensitively matched case-insensitively
and each parameter name <bcp14>MUST</bcp14> only occur once per challenge. and each parameter name <bcp14>MUST</bcp14> only occur once per challenge.
</t> </t>
<iref primary="true" item="Grammar" subitem="auth-param"/> <iref primary="true" item="Grammar" subitem="auth-param"/>
<sourcecode type="abnf7230"><![CDATA[ auth-param = token BWS "= " BWS ( token / quoted-string ) <sourcecode type="abnf9110"><![CDATA[ auth-param = token BWS "= " BWS ( token / quoted-string )
]]></sourcecode> ]]></sourcecode>
<t> <t>
Parameter values can be expressed either as "token" or as "quoted-string" Parameter values can be expressed either as "token" or as "quoted-string"
(<xref target="fields.components"/>). (<xref target="fields.components"/>).
Authentication scheme definitions need to accept both notations, both for Authentication scheme definitions need to accept both notations, both for
senders and recipients, to allow recipients to use generic parsing senders and recipients, to allow recipients to use generic parsing
components regardless of the authentication scheme. components regardless of the authentication scheme.
</t> </t>
<t> <t>
For backwards compatibility, authentication scheme definitions can restrict For backwards compatibility, authentication scheme definitions can restrict
skipping to change at line 5731 skipping to change at line 5724
<xref target="field.www-authenticate" format="none">WWW-Authenticate</xref> h eader field containing at least one <xref target="field.www-authenticate" format="none">WWW-Authenticate</xref> h eader field containing at least one
challenge applicable to the requested resource. challenge applicable to the requested resource.
</t> </t>
<t> <t>
A <xref target="status.407" format="none">407 (Proxy Authentication Required) </xref> response message is A <xref target="status.407" format="none">407 (Proxy Authentication Required) </xref> response message is
used by a proxy to challenge the authorization of a client, including a used by a proxy to challenge the authorization of a client, including a
<xref target="field.proxy-authenticate" format="none">Proxy-Authenticate</xre f> header field containing at least one <xref target="field.proxy-authenticate" format="none">Proxy-Authenticate</xre f> header field containing at least one
challenge applicable to the proxy for the requested resource. challenge applicable to the proxy for the requested resource.
</t> </t>
<iref primary="true" item="Grammar" subitem="challenge"/> <iref primary="true" item="Grammar" subitem="challenge"/>
<sourcecode type="abnf7230"><![CDATA[ challenge = auth-scheme [ 1 *SP ( token68 / #auth-param ) ] <sourcecode type="abnf9110"><![CDATA[ challenge = auth-scheme [ 1 *SP ( token68 / #auth-param ) ]
]]></sourcecode> ]]></sourcecode>
<aside> <aside>
<t> <t>
<strong>Note:</strong> Many clients fail to parse a challenge that contains an unknown <strong>Note:</strong> Many clients fail to parse a challenge that contains an unknown
scheme. A workaround for this problem is to list well-supported schemes scheme. A workaround for this problem is to list well-supported schemes
(such as "basic") first.<!-- see https://greenbytes.de/tech/tc/httpauth/#mu ltibasicunknown2 --> (such as "basic") first.
</t> </t>
</aside> </aside>
<t> <t>
A user agent that wishes to authenticate itself with an origin server A user agent that wishes to authenticate itself with an origin server
— usually, but not necessarily, after receiving a -- usually, but not necessarily, after receiving a
<xref target="status.401" format="none">401 (Unauthorized)</xref> — can do so <xref target="status.401" format="none">401 (Unauthorized)</xref> -- can do s
by including an o by including an
<xref target="field.authorization" format="none">Authorization</xref> header field with the request. <xref target="field.authorization" format="none">Authorization</xref> header field with the request.
</t> </t>
<t> <t>
A client that wishes to authenticate itself with a proxy — usually, A client that wishes to authenticate itself with a proxy -- usually,
but not necessarily, after receiving a but not necessarily, after receiving a
<xref target="status.407" format="none">407 (Proxy Authentication Required)</ xref> — can do so by <xref target="status.407" format="none">407 (Proxy Authentication Required)</ xref> -- can do so by
including a <xref target="field.proxy-authorization" format="none">Proxy-Auth orization</xref> header field with the including a <xref target="field.proxy-authorization" format="none">Proxy-Auth orization</xref> header field with the
request. request.
</t> </t>
</section> </section>
<section anchor="credentials" title="Credentials"> <section anchor="credentials" title="Credentials">
<t> <t>
Both the <xref target="field.authorization" format="none">Authorization</xref > field value and the Both the <xref target="field.authorization" format="none">Authorization</xref > field value and the
<xref target="field.proxy-authorization" format="none">Proxy-Authorization</x ref> field value contain the client's <xref target="field.proxy-authorization" format="none">Proxy-Authorization</x ref> field value contain the client's
credentials for the realm of the resource being requested, based upon a credentials for the realm of the resource being requested, based upon a
challenge received in a response (possibly at some point in the past). challenge received in a response (possibly at some point in the past).
When creating their values, the user agent ought to do so by selecting the When creating their values, the user agent ought to do so by selecting the
challenge with what it considers to be the most secure auth-scheme that it challenge with what it considers to be the most secure auth-scheme that it
understands, obtaining credentials from the user as appropriate. understands, obtaining credentials from the user as appropriate.
Transmission of credentials within header field values implies significant Transmission of credentials within header field values implies significant
security considerations regarding the confidentiality of the underlying security considerations regarding the confidentiality of the underlying
connection, as described in connection, as described in
<xref target="confidentiality.of.credentials"/>. <xref target="confidentiality.of.credentials"/>.
</t> </t>
<iref primary="true" item="Grammar" subitem="credentials"/> <iref primary="true" item="Grammar" subitem="credentials"/>
<sourcecode type="abnf7230"><![CDATA[ credentials = auth-scheme [ 1 *SP ( token68 / #auth-param ) ] <sourcecode type="abnf9110"><![CDATA[ credentials = auth-scheme [ 1 *SP ( token68 / #auth-param ) ]
]]></sourcecode> ]]></sourcecode>
<t> <t>
Upon receipt of a request for a protected resource that omits credentials, Upon receipt of a request for a protected resource that omits credentials,
contains invalid credentials (e.g., a bad password) or partial credentials contains invalid credentials (e.g., a bad password) or partial credentials
(e.g., when the authentication scheme requires more than one round trip), (e.g., when the authentication scheme requires more than one round trip),
an origin server <bcp14>SHOULD</bcp14> send a <xref target="status.401" forma t="none">401 (Unauthorized)</xref> response an origin server <bcp14>SHOULD</bcp14> send a <xref target="status.401" forma t="none">401 (Unauthorized)</xref> response
that contains a <xref target="field.www-authenticate" format="none">WWW-Authe nticate</xref> header field with at least that contains a <xref target="field.www-authenticate" format="none">WWW-Authe nticate</xref> header field with at least
one (possibly new) challenge applicable to the requested resource. one (possibly new) challenge applicable to the requested resource.
</t> </t>
<t> <t>
skipping to change at line 5809 skipping to change at line 5802
<t> <t>
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 <xref target="COOKIE"/>, Set-Cookie and Cookie header fields, defined in <xref target="COOKIE"/>,
for passing tokens related to authentication. for passing tokens related to authentication.
</t> </t>
</section> </section>
<section anchor="protection.space" <section anchor="protection.space"
title="Establishing a Protection Space (Realm)"> title="Establishing a Protection Space (Realm)">
<iref item="Protection Space"/> <iref item="Protection Space"/>
<iref item="Realm"/> <iref item="Realm"/>
<iref item="Origin"/> <iref item="origin"/>
<t> <t>
The <em>realm</em> 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.
</t> </t>
<t> <t>
A <em>protection space</em> is defined by the origin (see A "protection space" is defined by the origin (see
<xref target="origin"/>) of the <xref target="origin"/>) of the
server being accessed, in combination with the realm value if present. server being accessed, in combination with the realm value if present.
These realms allow the protected resources on a server to be These realms allow the protected resources on a server to be
partitioned into a set of protection spaces, each with its own 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 that a additional semantics specific to the authentication scheme. Note that a
response can have multiple challenges with the same auth-scheme but response can have multiple challenges with the same auth-scheme but
with different realms. with different realms.
</t> </t>
skipping to change at line 5860 skipping to change at line 5853
title="Authenticating Users to Origin Servers"> title="Authenticating Users to Origin Servers">
<section anchor="field.www-authenticate" title="WWW-Authenticate"> <section anchor="field.www-authenticate" title="WWW-Authenticate">
<iref primary="true" item="Fields" subitem="WWW-Authenticate"/> <iref primary="true" item="Fields" subitem="WWW-Authenticate"/>
<iref primary="true" item="Header Fields" subitem="WWW-Authentica te"/> <iref primary="true" item="Header Fields" subitem="WWW-Authentica te"/>
<iref primary="true" item="WWW-Authenticate header field"/> <iref primary="true" item="WWW-Authenticate header field"/>
<t> <t>
The "WWW-Authenticate" response header field indicates the authentication The "WWW-Authenticate" response header field indicates the authentication
scheme(s) and parameters applicable to the target resource. scheme(s) and parameters applicable to the target resource.
</t> </t>
<iref primary="true" item="Grammar" subitem="WWW-Authenticate"/> <iref primary="true" item="Grammar" subitem="WWW-Authenticate"/>
<sourcecode type="abnf7230"><![CDATA[ WWW-Authenticate = #challe nge <sourcecode type="abnf9110"><![CDATA[ WWW-Authenticate = #challe nge
]]></sourcecode> ]]></sourcecode>
<t> <t>
A server generating a <xref target="status.401" format="none">401 (Unauthoriz ed)</xref> response A server generating a <xref target="status.401" format="none">401 (Unauthoriz ed)</xref> response
<bcp14>MUST</bcp14> send a WWW-Authenticate header field containing at least one <bcp14>MUST</bcp14> send a WWW-Authenticate header field containing at least one
challenge. A server <bcp14>MAY</bcp14> generate a WWW-Authenticate header fi eld challenge. A server <bcp14>MAY</bcp14> generate a WWW-Authenticate header fi eld
in other response messages to indicate that supplying credentials in other response messages to indicate that supplying credentials
(or different credentials) might affect the response. (or different credentials) might affect the response.
</t> </t>
<t> <t>
A proxy forwarding a response <bcp14>MUST NOT</bcp14> modify any A proxy forwarding a response <bcp14>MUST NOT</bcp14> modify any
skipping to change at line 5886 skipping to change at line 5879
comma-separated list of authentication parameters. Furthermore, the header comma-separated list of authentication parameters. Furthermore, the header
field itself can occur multiple times. field itself can occur multiple times.
</t> </t>
<t> <t>
For instance: For instance:
</t> </t>
<sourcecode type="http-message"><![CDATA[WWW-Authenticate: Basic realm="simple", Newauth realm="apps", <sourcecode type="http-message"><![CDATA[WWW-Authenticate: Basic realm="simple", Newauth realm="apps",
type=1, title="Login to \"apps\"" type=1, title="Login to \"apps\""
]]></sourcecode> ]]></sourcecode>
<t> <t>
This header field contains two challenges; one for the "Basic" scheme with This header field contains two challenges, one for the "Basic" scheme with
a realm value of "simple", and another for the "Newauth" scheme with a a realm value of "simple" and another for the "Newauth" scheme with a
realm value of "apps", and two additional parameters "type" and "title". realm value of "apps". It also contains two additional parameters, "type" and
"title".
</t> </t>
<t> <t>
Some user agents do not recognise this form, however. As a result, sending Some user agents do not recognize this form, however. As a result, sending
a WWW-Authenticate field value with more than one member on the same field a WWW-Authenticate field value with more than one member on the same field
line might not be interoperable. line might not be interoperable.
</t> </t>
<aside> <aside>
<t> <t>
<strong>Note:</strong> The challenge grammar production use s the list syntax as <strong>Note:</strong> The challenge grammar production use s the list syntax as
well. Therefore, a sequence of comma, whitespace, and comma can be well. Therefore, a sequence of comma, whitespace, and comma can be
considered either as applying to the preceding challenge, or to be an considered either as applying to the preceding challenge, or to be an
empty entry in the list of challenges. In practice, this ambiguity empty entry in the list of challenges. In practice, this ambiguity
does not affect the semantics of the header field value and thus is does not affect the semantics of the header field value and thus is
harmless. harmless.
</t> </t>
</aside> </aside>
</section> </section>
<section anchor="field.authorization" title="Authorization"> <section anchor="field.authorization" title="Authorization">
<iref primary="true" item="Fields" subitem="Authorization"/> <iref primary="true" item="Fields" subitem="Authorization"/>
<iref primary="true" item="Header Fields" subitem="Authorization" /> <iref primary="true" item="Header Fields" subitem="Authorization" />
<iref primary="true" item="Authorization header field"/> <iref primary="true" item="Authorization header field"/>
<t> <t>
The "Authorization" header field allows a user agent to authenticate itself The "Authorization" header field allows a user agent to authenticate itself
with an origin server — usually, but not necessarily, after receiving with an origin server -- usually, but not necessarily, after receiving
a <xref target="status.401" format="none">401 (Unauthorized)</xref> response. Its value consists of a <xref target="status.401" format="none">401 (Unauthorized)</xref> response. Its value consists of
credentials containing the authentication information of the user agent for credentials containing the authentication information of the user agent for
the realm of the resource being requested. the realm of the resource being requested.
</t> </t>
<iref primary="true" item="Grammar" subitem="Authorization"/> <iref primary="true" item="Grammar" subitem="Authorization"/>
<sourcecode type="abnf7230"><![CDATA[ Authorization = credential s <sourcecode type="abnf9110"><![CDATA[ Authorization = credential s
]]></sourcecode> ]]></sourcecode>
<t> <t>
If a request is authenticated and a realm specified, the same credentials If a request is authenticated and a realm specified, the same credentials
are presumed to be valid for all other requests within this realm (assuming are presumed to be valid for all other requests within this realm (assuming
that the authentication scheme itself does not require otherwise, such as that the authentication scheme itself does not require otherwise, such as
credentials that vary according to a challenge value or using synchronized credentials that vary according to a challenge value or using synchronized
clocks). clocks).
</t> </t>
<t> <t>
A proxy forwarding a request <bcp14>MUST NOT</bcp14> modify any A proxy forwarding a request <bcp14>MUST NOT</bcp14> modify any
<xref target="field.authorization" format="none">Authorization</xref> header fields in that request. <xref target="field.authorization" format="none">Authorization</xref> header fields in that request.
See <xref target="CACHING" section="3.5"/> for details of and requirements See <xref target="CACHING" section="3.5"/> for details of and requirements
pertaining to handling of the Authorization header field by HTTP caches. pertaining to handling of the Authorization header field by HTTP caches.
</t> </t>
</section> </section>
<section anchor="field.authentication-info" title="Authentication-In fo"> <section anchor="field.authentication-info" title="Authentication-In fo">
<iref primary="true" item="Fields" subitem="Authentication-Info"/ > <iref primary="true" item="Fields" subitem="Authentication-Info"/ >
<iref primary="true" item="Header Fields" subitem="Authentication -Info"/> <iref primary="true" item="Header Fields" subitem="Authentication -Info"/>
<iref primary="true" item="Authentication-Info header field"/> <iref primary="true" item="Authentication-Info header field"/>
<t> <t>
HTTP authentication schemes can use the Authentication-Info response HTTP authentication schemes can use the "Authentication-Info" response
field to communicate information after the client's authentication credential s have been accepted. field to communicate information after the client's authentication credential s have been accepted.
This information can include a finalization message from the server (e.g., it can contain the This information can include a finalization message from the server (e.g., it can contain the
server authentication). server authentication).
</t> </t>
<t> <t>
The field value is a list of parameters (name/value pairs), using the "auth-p aram" The field value is a list of parameters (name/value pairs), using the "auth-p aram"
syntax defined in <xref target="challenge.and.response"/>. syntax defined in <xref target="challenge.and.response"/>.
This specification only describes the generic format; authentication schemes This specification only describes the generic format; authentication schemes
using Authentication-Info will define the individual parameters. The "Digest" using Authentication-Info will define the individual parameters. The "Digest"
Authentication Scheme, for instance, defines multiple parameters in Authentication Scheme, for instance, defines multiple parameters in
<xref target="RFC7616" section="3.5"/>. <xref target="RFC7616" section="3.5"/>.
</t> </t>
<iref primary="true" item="Grammar" subitem="Authentication-Info" /> <iref primary="true" item="Grammar" subitem="Authentication-Info" />
<sourcecode type="abnf7230"><![CDATA[ Authentication-Info = #aut h-param <sourcecode type="abnf9110"><![CDATA[ Authentication-Info = #aut h-param
]]></sourcecode> ]]></sourcecode>
<t> <t>
The Authentication-Info field can be used in any HTTP response, The Authentication-Info field can be used in any HTTP response,
independently of request method and status code. Its semantics are defined independently of request method and status code. Its semantics are defined
by the authentication scheme indicated by the <xref target="field.authorizati on" format="none">Authorization</xref> header field by the authentication scheme indicated by the <xref target="field.authorizati on" format="none">Authorization</xref> header field
(<xref target="field.authorization"/>) of the corresponding request. (<xref target="field.authorization"/>) of the corresponding request.
</t> </t>
<t> <t>
A proxy forwarding a response is not allowed to modify the field value in any A proxy forwarding a response is not allowed to modify the field value in any
way. way.
skipping to change at line 5986 skipping to change at line 5979
<iref primary="true" item="Proxy-Authenticate header field"/> <iref primary="true" item="Proxy-Authenticate header field"/>
<t> <t>
The "Proxy-Authenticate" header field consists of at least one The "Proxy-Authenticate" header field consists of at least one
challenge that indicates the authentication scheme(s) and parameters challenge that indicates the authentication scheme(s) and parameters
applicable to the proxy for this request. applicable to the proxy for this request.
A proxy <bcp14>MUST</bcp14> send at least one Proxy-Authenticate header field in A proxy <bcp14>MUST</bcp14> send at least one Proxy-Authenticate header field in
each <xref target="status.407" format="none">407 (Proxy Authentication Requir ed)</xref> response that it each <xref target="status.407" format="none">407 (Proxy Authentication Requir ed)</xref> response that it
generates. generates.
</t> </t>
<iref primary="true" item="Grammar" subitem="Proxy-Authenticate"/ > <iref primary="true" item="Grammar" subitem="Proxy-Authenticate"/ >
<sourcecode type="abnf7230"><![CDATA[ Proxy-Authenticate = #chal lenge <sourcecode type="abnf9110"><![CDATA[ Proxy-Authenticate = #chal lenge
]]></sourcecode> ]]></sourcecode>
<t> <t>
Unlike <xref target="field.www-authenticate" format="none">WWW-Authenticate</ xref>, the Proxy-Authenticate header field Unlike <xref target="field.www-authenticate" format="none">WWW-Authenticate</ xref>, the Proxy-Authenticate header field
applies only to the next outbound client on the response chain. applies only to the next outbound client on the response chain.
This is because only the client that chose a given proxy is likely to have This is because only the client that chose a given proxy is likely to have
the credentials necessary for authentication. However, when multiple the credentials necessary for authentication. However, when multiple
proxies are used within the same administrative domain, such as office and proxies are used within the same administrative domain, such as office and
regional caching proxies within a large corporate network, it is common regional caching proxies within a large corporate network, it is common
for credentials to be generated by the user agent and passed through the for credentials to be generated by the user agent and passed through the
hierarchy until consumed. Hence, in such a configuration, it will appear hierarchy until consumed. Hence, in such a configuration, it will appear
skipping to change at line 6018 skipping to change at line 6011
<iref primary="true" item="Header Fields" subitem="Proxy-Authoriz ation"/> <iref primary="true" item="Header Fields" subitem="Proxy-Authoriz ation"/>
<iref primary="true" item="Proxy-Authorization header field"/> <iref primary="true" item="Proxy-Authorization header field"/>
<t> <t>
The "Proxy-Authorization" header field allows the client to The "Proxy-Authorization" header field allows the client to
identify itself (or its user) to a proxy that requires identify itself (or its user) to a proxy that requires
authentication. Its value consists of credentials containing the authentication. Its value consists of credentials containing the
authentication information of the client for the proxy and/or realm of the authentication information of the client for the proxy and/or realm of the
resource being requested. resource being requested.
</t> </t>
<iref primary="true" item="Grammar" subitem="Proxy-Authorization" /> <iref primary="true" item="Grammar" subitem="Proxy-Authorization" />
<sourcecode type="abnf7230"><![CDATA[ Proxy-Authorization = cred entials <sourcecode type="abnf9110"><![CDATA[ Proxy-Authorization = cred entials
]]></sourcecode> ]]></sourcecode>
<t> <t>
Unlike <xref target="field.authorization" format="none">Authorization</xref>, the Proxy-Authorization header field Unlike <xref target="field.authorization" format="none">Authorization</xref>, the Proxy-Authorization header field
applies only to the next inbound proxy that demanded authentication using applies only to the next inbound proxy that demanded authentication using
the <xref target="field.proxy-authenticate" format="none">Proxy-Authenticate< /xref> header field. When multiple proxies are used the <xref target="field.proxy-authenticate" format="none">Proxy-Authenticate< /xref> header field. When multiple proxies are used
in a chain, the Proxy-Authorization header field is consumed by the first in a chain, the Proxy-Authorization header field is consumed by the first
inbound proxy that was expecting to receive credentials. A proxy <bcp14>MAY</ bcp14> inbound proxy that was expecting to receive credentials. A proxy <bcp14>MAY</ bcp14>
relay the credentials from the client request to the next proxy if that is relay the credentials from the client request to the next proxy if that is
the mechanism by which the proxies cooperatively authenticate a given the mechanism by which the proxies cooperatively authenticate a given
request. request.
</t> </t>
</section> </section>
<section anchor="field.proxy-authentication-info" <section anchor="field.proxy-authentication-info"
title="Proxy-Authentication-Info"> title="Proxy-Authentication-Info">
<iref primary="true" item="Fields" subitem="Proxy-Authentication- Info"/> <iref primary="true" item="Fields" subitem="Proxy-Authentication- Info"/>
<iref primary="true" <iref primary="true"
item="Header Fields" item="Header Fields"
subitem="Proxy-Authentication-Info"/> subitem="Proxy-Authentication-Info"/>
<iref primary="true" item="Proxy-Authentication-Info header field "/> <iref primary="true" item="Proxy-Authentication-Info header field "/>
<t> <t>
The Proxy-Authentication-Info response header field is equivalent to The "Proxy-Authentication-Info" response header field is equivalent to
<xref target="field.authentication-info" format="none">Authentication-Info</x ref>, except that it applies to proxy authentication (<xref target="challenge.an d.response"/>) <xref target="field.authentication-info" format="none">Authentication-Info</x ref>, except that it applies to proxy authentication (<xref target="challenge.an d.response"/>)
and its semantics are defined by the and its semantics are defined by the
authentication scheme indicated by the Proxy-Authorization header field authentication scheme indicated by the Proxy-Authorization header field
(<xref target="field.proxy-authorization"/>) (<xref target="field.proxy-authorization"/>)
of the corresponding request: of the corresponding request:
</t> </t>
<iref primary="true" item="Grammar" subitem="Proxy-Authentication -Info"/> <iref primary="true" item="Grammar" subitem="Proxy-Authentication -Info"/>
<sourcecode type="abnf7230"><![CDATA[ Proxy-Authentication-Info = #auth-param <sourcecode type="abnf9110"><![CDATA[ Proxy-Authentication-Info = #auth-param
]]></sourcecode> ]]></sourcecode>
<t> <t>
However, unlike <xref target="field.authentication-info" format="none">Authen tication-Info</xref>, the Proxy-Authentication-Info header However, unlike <xref target="field.authentication-info" format="none">Authen tication-Info</xref>, the Proxy-Authentication-Info header
field applies only to the next outbound client on the response chain. This is field applies only to the next outbound client on the response chain. This is
because only the client that chose a given proxy is likely to have the because only the client that chose a given proxy is likely to have the
credentials necessary for authentication. However, when multiple proxies are credentials necessary for authentication. However, when multiple proxies are
used within the same administrative domain, such as office and regional used within the same administrative domain, such as office and regional
caching proxies within a large corporate network, it is common for caching proxies within a large corporate network, it is common for
credentials to be generated by the user agent and passed through the credentials to be generated by the user agent and passed through the
hierarchy until consumed. Hence, in such a configuration, it will appear as hierarchy until consumed. Hence, in such a configuration, it will appear as
skipping to change at line 6083 skipping to change at line 6076
information; for example, in different formats, languages, or encodings. information; for example, in different formats, languages, or encodings.
Likewise, different users or user agents might have differing capabilities, Likewise, different users or user agents might have differing capabilities,
characteristics, or preferences that could influence which representation, characteristics, or preferences that could influence which representation,
among those available, would be best to deliver. For this reason, HTTP among those available, would be best to deliver. For this reason, HTTP
provides mechanisms for <xref target="content.negotiation" format="none">cont ent negotiation</xref>. provides mechanisms for <xref target="content.negotiation" format="none">cont ent negotiation</xref>.
</t> </t>
<t> <t>
This specification defines three patterns of content negotiation that can This specification defines three patterns of content negotiation that can
be made visible within the protocol: be made visible within the protocol:
"proactive" negotiation, where the server selects the representation based "proactive" negotiation, where the server selects the representation based
upon the user agent's stated preferences, "reactive" negotiation, upon the user agent's stated preferences; "reactive" negotiation,
where the server provides a list of representations for the user agent to where the server provides a list of representations for the user agent to
choose from, and "request content" negotiation, where the user agent choose from; and "request content" negotiation, where the user agent
selects the representation for a future request based upon the server's selects the representation for a future request based upon the server's
stated preferences in past responses. stated preferences in past responses.
</t> </t>
<t> <t>
Other patterns of content negotiation include Other patterns of content negotiation include
"conditional content", where the representation consists of multiple "conditional content", where the representation consists of multiple
parts that are selectively rendered based on user agent parameters, parts that are selectively rendered based on user agent parameters,
"active content", where the representation contains a script that "active content", where the representation contains a script that
makes additional (more specific) requests based on the user agent makes additional (more specific) requests based on the user agent
characteristics, and "Transparent Content Negotiation" characteristics, and "Transparent Content Negotiation"
skipping to change at line 6113 skipping to change at line 6106
and over the varying dimensions of content negotiation, and thus the and over the varying dimensions of content negotiation, and thus the
"sameness" of a resource's observed representations over time, is "sameness" of a resource's observed representations over time, is
determined entirely by whatever entity or algorithm selects or generates determined entirely by whatever entity or algorithm selects or generates
those responses. those responses.
</t> </t>
<section anchor="proactive.negotiation" title="Proactive Negotiation"> <section anchor="proactive.negotiation" title="Proactive Negotiation">
<t> <t>
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 request to encourage an algorithm located at the server to
select the preferred representation, it is called select the preferred representation, it is called
<em>proactive negotiation</em> "proactive negotiation"
(a.k.a., <em>server-driven negotiation</em>). Selection is based on (a.k.a., "server-driven negotiation"). Selection is based on
the available representations for a response (the dimensions over which it the available representations for a response (the dimensions over which it
might vary, such as language, content coding, etc.) compared to various might vary, such as language, content coding, etc.) compared to various
information supplied in the request, including both the explicit information supplied in the request, including both the explicit
negotiation header fields below and implicit 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
<xref target="field.user-agent" format="none">User-Agent</xref> field. <xref target="field.user-agent" format="none">User-Agent</xref> field.
</t> </t>
<t> <t>
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
"best guess" to the user agent along with the first response (when that "best guess" to the user agent along with the first response (when that
"best guess" is good enough for the user, this avoids the round trip "best guess" is good enough for the user, this avoids the round-trip
delay of a subsequent request). In order to improve the server's delay of a subsequent request). In order to improve the server's
guess, a user agent <bcp14>MAY</bcp14> send request header fields that descri be guess, a user agent <bcp14>MAY</bcp14> send request header fields that descri be
its preferences. its preferences.
</t> </t>
<t> <t>
Proactive negotiation has serious disadvantages: Proactive negotiation has serious disadvantages:
</t> </t>
<ul> <ul>
<li> <li>
It is impossible for the server to accurately determine what It is impossible for the server to accurately determine what
skipping to change at line 6183 skipping to change at line 6176
in <xref target="proactive.negotiation" format="none">proactive negotiation</ xref> of the response content. in <xref target="proactive.negotiation" format="none">proactive negotiation</ xref> of the response content.
The preferences sent in these The preferences sent in these
fields apply to any content in the response, including representations of fields apply to any content in the response, including representations of
the target resource, representations of error or processing status, and the target resource, representations of error or processing status, and
potentially even the miscellaneous text strings that might appear within potentially even the miscellaneous text strings that might appear within
the protocol. the protocol.
</t> </t>
</section> </section>
<section anchor="reactive.negotiation" title="Reactive Negotiation"> <section anchor="reactive.negotiation" title="Reactive Negotiation">
<t> <t>
With <em>reactive negotiation</em> With "reactive negotiation" (a.k.a., "agent-driven negotiation"), selection o
(a.k.a., <em>agent-driven negotiation</em>), selection of f
content (regardless of the status code) is performed by content (regardless of the status code) is performed by
the user agent after receiving an initial response. The mechanism for the user agent after receiving an initial response. The mechanism for
reactive negotiation might be as simple as a list of references to reactive negotiation might be as simple as a list of references to
alternative representations. alternative representations.
</t> </t>
<t> <t>
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 resources it can perform a GET request on one or more of the alternative resources
to obtain a different representation. Selection of such alternatives might to obtain a different representation. Selection of such alternatives might
be performed automatically (by the user agent) or manually (e.g., by the be performed automatically (by the user agent) or manually (e.g., by the
skipping to change at line 6226 skipping to change at line 6218
latency if transmitted in the header section, and needing a second request latency if transmitted in the header section, and needing a second request
to obtain an alternate representation. Furthermore, this specification to obtain an alternate representation. Furthermore, this specification
does not define a mechanism for supporting automatic selection, though it does not define a mechanism for supporting automatic selection, though it
does not prevent such a mechanism from being developed. does not prevent such a mechanism from being developed.
</t> </t>
</section> </section>
<section anchor="request.content.negotiation" <section anchor="request.content.negotiation"
title="Request Content Negotiation"> title="Request Content Negotiation">
<t> <t>
When content negotiation preferences are sent in a server's response, the When content negotiation preferences are sent in a server's response, the
listed preferences are called <em>request content negotiation</em> listed preferences are called "request content negotiation"
because they intend to influence selection of an appropriate content for because they intend to influence selection of an appropriate content for
subsequent requests to that resource. For example, subsequent requests to that resource. For example,
the <xref target="field.accept" format="none">Accept</xref> (<xref target="fi eld.accept"/>) and the <xref target="field.accept" format="none">Accept</xref> (<xref target="fi eld.accept"/>) and
<xref target="field.accept-encoding" format="none">Accept-Encoding</xref> (<x ref target="field.accept-encoding"/>) <xref target="field.accept-encoding" format="none">Accept-Encoding</xref> (<x ref target="field.accept-encoding"/>)
header fields can be sent in a response to indicate preferred media types header fields can be sent in a response to indicate preferred media types
and content codings for subsequent requests to that resource. and content codings for subsequent requests to that resource.
</t> </t>
<t> <t>
Similarly, <xref target="RFC5789" section="3.1"/> defines Similarly, <xref target="RFC5789" section="3.1"/> defines
the "Accept-Patch" response header field which allows discovery of the "Accept-Patch" response header field, which allows discovery of
which content types are accepted in PATCH requests. which content types are accepted in PATCH requests.
</t> </t>
</section> </section>
<section anchor="conneg.features" title="Content Negotiation Field Feat ures"> <section anchor="conneg.features" title="Content Negotiation Field Feat ures">
<section anchor="conneg.absent" title="Absence"> <section anchor="conneg.absent" title="Absence">
<t> <t>
For each of the content negotiation fields, a request that does not contain For each of the content negotiation fields, a request that does not contain
the field implies that the sender has no preference on that dimension of the field implies that the sender has no preference on that dimension of
negotiation. negotiation.
</t> </t>
skipping to change at line 6283 skipping to change at line 6275
that can be selected for a resource. that can be selected for a resource.
</t> </t>
<t> <t>
The weight is normalized to a real number in the range 0 through 1, The weight is normalized to a real number in the range 0 through 1,
where 0.001 is the least preferred and 1 is the most preferred; where 0.001 is the least preferred and 1 is the most preferred;
a value of 0 means "not acceptable". If no "q" parameter is present, a value of 0 means "not acceptable". If no "q" parameter is present,
the default weight is 1. the default weight is 1.
</t> </t>
<iref primary="true" item="Grammar" subitem="weight"/> <iref primary="true" item="Grammar" subitem="weight"/>
<iref primary="true" item="Grammar" subitem="qvalue"/> <iref primary="true" item="Grammar" subitem="qvalue"/>
<sourcecode type="abnf7230"><![CDATA[ weight = OWS ";" OWS "q=" qvalue <sourcecode type="abnf9110"><![CDATA[ weight = OWS ";" OWS "q=" qvalue
qvalue = ( "0" [ "." 0*3DIGIT ] ) qvalue = ( "0" [ "." 0*3DIGIT ] )
/ ( "1" [ "." 0*3("0") ] ) / ( "1" [ "." 0*3("0") ] )
]]></sourcecode> ]]></sourcecode>
<t> <t>
A sender of qvalue <bcp14>MUST NOT</bcp14> generate more than three digits af ter the A sender of qvalue <bcp14>MUST NOT</bcp14> generate more than three digits af ter the
decimal point. User configuration of these values ought to be limited in decimal point. User configuration of these values ought to be limited in
the same fashion. the same fashion.
</t> </t>
</section> </section>
<section anchor="wildcard.values" title="Wildcard Values"> <section anchor="wildcard.values" title="Wildcard Values">
<t> <t>
Most of these header fields, where indicated, define a wildcard value ("*") Most of these header fields, where indicated, define a wildcard value ("*")
to select unspecified values. If no wildcard is present, values that are to select unspecified values. If no wildcard is present, values that are
not explicitly mentioned in the field are considered unacceptable. not explicitly mentioned in the field are considered unacceptable.
Within <xref target="field.vary" format="none">Vary</xref>, the wildcard valu e means that the variance Within <xref target="field.vary" format="none">Vary</xref>, the wildcard valu e means that the variance
is unlimited. is unlimited.
</t> </t>
<aside> <aside>
<t> <t>
<strong>Note:</strong> In practice, using wildcards in cont ent negotiation has limited <strong>Note:</strong> In practice, using wildcards in cont ent negotiation has limited
practical value, because it is seldom useful to say, for example, "I practical value because it is seldom useful to say, for example, "I
prefer image/* more or less than (some other specific value)". Clients can prefer image/* more or less than (some other specific value)". By sending Acc
ept: */*;q=0, clients can
explicitly request a <xref target="status.406" format="none">406 (Not Accepta ble)</xref> response if a explicitly request a <xref target="status.406" format="none">406 (Not Accepta ble)</xref> response if a
more preferred format is not available by sending Accept: */*;q=0, but more preferred format is not available, but
they still need to be able to handle a different response, since the they still need to be able to handle a different response since the
server is allowed to ignore their preference. server is allowed to ignore their preference.
</t> </t>
</aside> </aside>
</section> </section>
</section> </section>
<section anchor="conneg.fields" title="Content Negotiation Fields"> <section anchor="conneg.fields" title="Content Negotiation Fields">
<section anchor="field.accept" title="Accept"> <section anchor="field.accept" title="Accept">
<iref primary="true" item="Fields" subitem="Accept"/> <iref primary="true" item="Fields" subitem="Accept"/>
<iref primary="true" item="Header Fields" subitem="Accept"/> <iref primary="true" item="Header Fields" subitem="Accept"/>
<iref primary="true" item="Accept header field"/> <iref primary="true" item="Accept header field"/>
<t> <t>
The "Accept" header field can be used by user agents to specify their The "Accept" header field can be used by user agents to specify their
preferences regarding response media types. For example, Accept header preferences regarding response media types. For example, Accept header
fields can be used to indicate that the request is specifically limited to fields can be used to indicate that the request is specifically limited to
a small set of desired types, as in the case of a request for an in-line a small set of desired types, as in the case of a request for an in-line
image. image.
</t> </t>
<t> <t>
When sent by a server in a response, Accept provides information When sent by a server in a response, Accept provides information
about what content types are preferred in the content of a subsequent about which content types are preferred in the content of a subsequent
request to the same resource. request to the same resource.
</t> </t>
<iref primary="true" item="Grammar" subitem="Accept"/> <iref primary="true" item="Grammar" subitem="Accept"/>
<iref primary="true" item="Grammar" subitem="media-range"/> <iref primary="true" item="Grammar" subitem="media-range"/>
<sourcecode type="abnf7230"><![CDATA[ Accept = #( media-range [ weight ] ) <sourcecode type="abnf9110"><![CDATA[ Accept = #( media-range [ weight ] )
media-range = ( "*/*" media-range = ( "*/*"
/ ( type "/" "*" ) / ( type "/" "*" )
/ ( type "/" subtype ) / ( type "/" subtype )
) parameters ) parameters
]]></sourcecode> ]]></sourcecode>
<t> <t>
The asterisk "*" character is used to group media types into ranges, The asterisk "*" character is used to group media types into ranges,
with "*/*" indicating all media types and "type/*" indicating all with "*/*" indicating all media types and "type/*" indicating all
subtypes of that type. The media-range can include media type subtypes of that type. The media-range can include media type
skipping to change at line 6470 skipping to change at line 6462
<iref primary="true" item="Header Fields" subitem="Accept-Charset "/> <iref primary="true" item="Header Fields" subitem="Accept-Charset "/>
<iref primary="true" item="Accept-Charset header field"/> <iref primary="true" item="Accept-Charset header field"/>
<t> <t>
The "Accept-Charset" header field can be sent by a user agent to indicate The "Accept-Charset" header field can be sent by a user agent to indicate
its preferences for charsets in textual response content. For example, its preferences for charsets in textual response content. For example,
this field allows user agents capable of understanding more comprehensive this field allows user agents capable of understanding more comprehensive
or special-purpose charsets to signal that capability to an origin server or special-purpose charsets to signal that capability to an origin server
that is capable of representing information in those charsets. that is capable of representing information in those charsets.
</t> </t>
<iref primary="true" item="Grammar" subitem="Accept-Charset"/> <iref primary="true" item="Grammar" subitem="Accept-Charset"/>
<sourcecode type="abnf7230"><![CDATA[ Accept-Charset = #( ( toke n / "*" ) [ weight ] ) <sourcecode type="abnf9110"><![CDATA[ Accept-Charset = #( ( toke n / "*" ) [ weight ] )
]]></sourcecode> ]]></sourcecode>
<t> <t>
Charset names are defined in <xref target="charset"/>. Charset names are defined in <xref target="charset"/>.
A user agent <bcp14>MAY</bcp14> associate a quality value with each charset t o indicate A user agent <bcp14>MAY</bcp14> associate a quality value with each charset t o indicate
the user's relative preference for that charset, as defined in <xref target=" quality.values"/>. the user's relative preference for that charset, as defined in <xref target=" quality.values"/>.
An example is An example is
</t> </t>
<sourcecode type="http-message"><![CDATA[Accept-Charset: iso-8859 -5, unicode-1-1;q=0.8 <sourcecode type="http-message"><![CDATA[Accept-Charset: iso-8859 -5, unicode-1-1;q=0.8
]]></sourcecode> ]]></sourcecode>
<t> <t>
The special value "*", if present in the Accept-Charset header field, The special value "*", if present in the Accept-Charset header field,
matches every charset that is not mentioned elsewhere in the matches every charset that is not mentioned elsewhere in the
field. field.
</t> </t>
<aside> <aside>
<t> <t>
<strong>Note:</strong> Accept-Charset is deprecated because UTF-8 has become nearly <strong>Note:</strong> Accept-Charset is deprecated because UTF-8 has become nearly
ubiquitous and sending a detailed list of user-preferred charsets wastes ubiquitous and sending a detailed list of user-preferred charsets wastes
bandwidth, increases latency, and makes passive fingerprinting far too bandwidth, increases latency, and makes passive fingerprinting far too
easy (<xref target="fingerprinting"/>). Most general-purpose user agents easy (<xref target="fingerprinting"/>). Most general-purpose user agents
do not send Accept-Charset, unless specifically configured to do so. do not send Accept-Charset unless specifically configured to do so.
</t> </t>
</aside> </aside>
</section> </section>
<section anchor="field.accept-encoding" title="Accept-Encoding"> <section anchor="field.accept-encoding" title="Accept-Encoding">
<iref primary="true" item="Fields" subitem="Accept-Encoding"/> <iref primary="true" item="Fields" subitem="Accept-Encoding"/>
<iref primary="true" item="Header Fields" subitem="Accept-Encodin g"/> <iref primary="true" item="Header Fields" subitem="Accept-Encodin g"/>
<iref primary="true" item="Accept-Encoding header field"/> <iref primary="true" item="Accept-Encoding header field"/>
<t> <t>
The "Accept-Encoding" header field can be used to indicate preferences The "Accept-Encoding" header field can be used to indicate preferences
regarding the use of content codings (<xref target="content.codings"/>). regarding the use of content codings (<xref target="content.codings"/>).
</t> </t>
<t> <t>
When sent by a user agent in a request, Accept-Encoding indicates the When sent by a user agent in a request, Accept-Encoding indicates the
content codings acceptable in a response. content codings acceptable in a response.
</t> </t>
<t> <t>
When sent by a server in a response, Accept-Encoding provides information When sent by a server in a response, Accept-Encoding provides information
about what content codings are preferred in the content of a subsequent about which content codings are preferred in the content of a subsequent
request to the same resource. request to the same resource.
</t> </t>
<t> <t>
An "identity" token is used as a synonym for An "identity" token is used as a synonym for
"no encoding" in order to communicate when no encoding is preferred. "no encoding" in order to communicate when no encoding is preferred.
</t> </t>
<iref primary="true" item="Grammar" subitem="Accept-Encoding"/> <iref primary="true" item="Grammar" subitem="Accept-Encoding"/>
<iref primary="true" item="Grammar" subitem="codings"/> <iref primary="true" item="Grammar" subitem="codings"/>
<sourcecode type="abnf7230"><![CDATA[ Accept-Encoding = #( codi ngs [ weight ] ) <sourcecode type="abnf9110"><![CDATA[ Accept-Encoding = #( codi ngs [ weight ] )
codings = content-coding / "identity" / "*" codings = content-coding / "identity" / "*"
]]></sourcecode> ]]></sourcecode>
<t> <t>
Each codings value <bcp14>MAY</bcp14> be given an associated quality value (w eight) Each codings value <bcp14>MAY</bcp14> be given an associated quality value (w eight)
representing the preference for that encoding, as defined in <xref target="qu ality.values"/>. representing the preference for that encoding, as defined in <xref target="qu ality.values"/>.
The asterisk "*" symbol in an Accept-Encoding field matches any available The asterisk "*" symbol in an Accept-Encoding field matches any available
content coding not explicitly listed in the field. content coding not explicitly listed in the field.
</t> </t>
<t> <t>
Examples: Examples:
skipping to change at line 6562 skipping to change at line 6554
<t> <t>
A representation could be encoded with multiple content codings. However, mos t A representation could be encoded with multiple content codings. However, mos t
content codings are alternative ways to accomplish the same purpose content codings are alternative ways to accomplish the same purpose
(e.g., data compression). When selecting between multiple content codings tha t (e.g., data compression). When selecting between multiple content codings tha t
have the same purpose, the acceptable content coding with the highest have the same purpose, the acceptable content coding with the highest
non-zero qvalue is preferred. non-zero qvalue is preferred.
</t> </t>
<t> <t>
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 response. implies that the user agent does not want any content coding in response.
If an Accept-Encoding header field is present in a request and none of the If a non-empty Accept-Encoding header field is present in a request and none of the
available representations for the response have a content coding that available representations for the response have a content coding that
is listed as acceptable, the origin server <bcp14>SHOULD</bcp14> send a respo nse is listed as acceptable, the origin server <bcp14>SHOULD</bcp14> send a respo nse
without any content coding. without any content coding unless the identity coding is indicated as unaccep table.
</t> </t>
<t> <t>
When the Accept-Encoding header field is present in a response, it indicates When the Accept-Encoding header field is present in a response, it indicates
what content codings the resource was willing to accept in the associated what content codings the resource was willing to accept in the associated
request. The field value is evaluated the same way as in a request. request. The field value is evaluated the same way as in a request.
</t> </t>
<t> <t>
Note that this information is specific to the associated request; the set of Note that this information is specific to the associated request; the set of
supported encodings might be different for other resources on the same supported encodings might be different for other resources on the same
server and could change over time or depend on other aspects of the request server and could change over time or depend on other aspects of the request
skipping to change at line 6592 skipping to change at line 6584
clients to distinguish between issues related to content codings and media clients to distinguish between issues related to content codings and media
types. In order to avoid confusion with issues related to media types, types. In order to avoid confusion with issues related to media types,
servers that fail a request with a 415 status for reasons unrelated to servers that fail a request with a 415 status for reasons unrelated to
content codings <bcp14>MUST NOT</bcp14> include the Accept-Encoding header content codings <bcp14>MUST NOT</bcp14> include the Accept-Encoding header
field. field.
</t> </t>
<t> <t>
The most common use of Accept-Encoding is in responses with a The most common use of Accept-Encoding is in responses with a
<xref target="status.415" format="none">415 (Unsupported Media Type)</xref> s tatus code, in response to <xref target="status.415" format="none">415 (Unsupported Media Type)</xref> s tatus code, in response to
optimistic use of a content coding by clients. However, the header field optimistic use of a content coding by clients. However, the header field
can also be used to indicate to clients that content codings are supported, can also be used to indicate to clients that content codings are supported in order
to optimize future interactions. For example, a resource might include it to optimize future interactions. For example, a resource might include it
in a <xref target="status.2xx" format="none">2xx (Successful)</xref> response when the request content was in a <xref target="status.2xx" format="none">2xx (Successful)</xref> response when the request content was
big enough to justify use of a compression coding but the client failed do big enough to justify use of a compression coding but the client failed do
so. so.
</t> </t>
</section> </section>
<section anchor="field.accept-language" title="Accept-Language"> <section anchor="field.accept-language" title="Accept-Language">
<iref primary="true" item="Fields" subitem="Accept-Language"/> <iref primary="true" item="Fields" subitem="Accept-Language"/>
<iref primary="true" item="Header Fields" subitem="Accept-Languag e"/> <iref primary="true" item="Header Fields" subitem="Accept-Languag e"/>
<iref primary="true" item="Accept-Language header field"/> <iref primary="true" item="Accept-Language header field"/>
<t> <t>
The "Accept-Language" header field can be used by user agents to The "Accept-Language" header field can be used by user agents to
indicate the set of natural languages that are preferred in the response. indicate the set of natural languages that are preferred in the response.
Language tags are defined in <xref target="language.tags"/>. Language tags are defined in <xref target="language.tags"/>.
</t> </t>
<iref primary="true" item="Grammar" subitem="Accept-Language"/> <iref primary="true" item="Grammar" subitem="Accept-Language"/>
<iref primary="true" item="Grammar" subitem="language-range"/> <iref primary="true" item="Grammar" subitem="language-range"/>
<sourcecode type="abnf7230"><![CDATA[ Accept-Language = #( langu age-range [ weight ] ) <sourcecode type="abnf9110"><![CDATA[ Accept-Language = #( langu age-range [ weight ] )
language-range = language-range =
<language-range, see [RFC4647], Section 2.1> <language-range, see [RFC4647], Section 2.1>
]]></sourcecode> ]]></sourcecode>
<t> <t>
Each language-range can be given an associated quality value Each language-range can be given an associated quality value
representing an estimate of the user's preference for the languages representing an estimate of the user's preference for the languages
specified by that range, as defined in <xref target="quality.values"/>. For e xample, specified by that range, as defined in <xref target="quality.values"/>. For e xample,
</t> </t>
<sourcecode type="http-message"><![CDATA[Accept-Language: da, en- gb;q=0.8, en;q=0.7 <sourcecode type="http-message"><![CDATA[Accept-Language: da, en- gb;q=0.8, en;q=0.7
]]></sourcecode> ]]></sourcecode>
skipping to change at line 6677 skipping to change at line 6669
<section anchor="field.vary" title="Vary"> <section anchor="field.vary" title="Vary">
<iref primary="true" item="Fields" subitem="Vary"/> <iref primary="true" item="Fields" subitem="Vary"/>
<iref primary="true" item="Header Fields" subitem="Vary"/> <iref primary="true" item="Header Fields" subitem="Vary"/>
<iref item="Vary header field" primary="true"/> <iref item="Vary header field" primary="true"/>
<t> <t>
The "Vary" header field in a response describes what parts of a request The "Vary" header field in a response describes what parts of a request
message, aside from the method and target URI, might have influenced the message, aside from the method and target URI, might have influenced the
origin server's process for selecting the content of this response. origin server's process for selecting the content of this response.
</t> </t>
<iref primary="true" item="Grammar" subitem="Vary"/> <iref primary="true" item="Grammar" subitem="Vary"/>
<sourcecode type="abnf7230"><![CDATA[ Vary = #( "*" / field-name ) <sourcecode type="abnf9110"><![CDATA[ Vary = #( "*" / field-name )
]]></sourcecode> ]]></sourcecode>
<t> <t>
A Vary field value is either the wildcard member "*" or a list of A Vary field value is either the wildcard member "*" or a list of
request field names, known as the selecting header fields, that might request field names, known as the selecting header fields, that might
have had a role in selecting the representation for this response. have had a role in selecting the representation for this response.
Potential selecting header fields are not limited to fields defined by Potential selecting header fields are not limited to fields defined by
this specification. this specification.
</t> </t>
<t> <t>
A list containing the member "*" signals that other aspects of the A list containing the member "*" signals that other aspects of the
skipping to change at line 6743 skipping to change at line 6735
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
<xref target="field.accept-language" format="none">Accept-Language</xref> hea der field. <xref target="field.accept-language" format="none">Accept-Language</xref> hea der field.
</t> </t>
<t> <t>
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 impact content selection to be less significant than Vary's performance impact
on caching, particularly when reuse is already limited by Cache-Control on caching, particularly when reuse is already limited by cache
response directives (<xref target="CACHING" section="5.2"/>). response directives (<xref target="CACHING" section="5.2"/>).
</t> </t>
<t> <t>
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 field reuse of that response for a different user is prohibited by the field
definition (<xref target="field.authorization"/>). definition (<xref target="field.authorization"/>).
Likewise, if the response content has been selected or influenced by Likewise, if the response content has been selected or influenced by
network region but the origin server wants the cached response to be network region, but the origin server wants the cached response to be
reused even if recipients move from one region to another, then there reused even if recipients move from one region to another, then there
is no need for the origin server to indicate such variance in Vary. is no need for the origin server to indicate such variance in Vary.
</t> </t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="conditional.requests" title="Conditional Requests"> <section anchor="conditional.requests" title="Conditional Requests">
<iref item="conditional request" primary="true"/> <iref item="conditional request" primary="true"/>
<t> <t>
A conditional request is an HTTP request with one or more request header A conditional request is an HTTP request with one or more request header
skipping to change at line 6822 skipping to change at line 6814
</t> </t>
<section anchor="field.if-match" title="If-Match"> <section anchor="field.if-match" title="If-Match">
<iref primary="true" item="Fields" subitem="If-Match"/> <iref primary="true" item="Fields" subitem="If-Match"/>
<iref primary="true" item="Header Fields" subitem="If-Match"/> <iref primary="true" item="Header Fields" subitem="If-Match"/>
<iref primary="true" item="If-Match header field"/> <iref primary="true" item="If-Match header field"/>
<t> <t>
The "If-Match" header field makes the request method conditional on the The "If-Match" header field makes the request method conditional on the
recipient origin server either having at least one current recipient origin server either having at least one current
representation of the target resource, when the field value is "*", or representation of the target resource, when the field value is "*", or
having a current representation of the target resource that has an having a current representation of the target resource that has an
entity-tag matching a member of the list of entity-tags provided in the entity tag matching a member of the list of entity tags provided in the
field value. field value.
</t> </t>
<t> <t>
An origin server <bcp14>MUST</bcp14> use the strong comparison function when comparing An origin server <bcp14>MUST</bcp14> use the strong comparison function when comparing
entity-tags for If-Match (<xref target="entity.tag.comparison"/>), since entity tags for If-Match (<xref target="entity.tag.comparison"/>), since
the client intends this precondition to prevent the method from being the client intends this precondition to prevent the method from being
applied if there have been any changes to the representation data. applied if there have been any changes to the representation data.
</t> </t>
<iref primary="true" item="Grammar" subitem="If-Match"/> <iref primary="true" item="Grammar" subitem="If-Match"/>
<sourcecode type="abnf7230"><![CDATA[ If-Match = "*" / #entity-t ag <sourcecode type="abnf9110"><![CDATA[ If-Match = "*" / #entity-t ag
]]></sourcecode> ]]></sourcecode>
<t> <t>
Examples: Examples:
</t> </t>
<sourcecode type="http-message"><![CDATA[If-Match: "xyzzy" <sourcecode type="http-message"><![CDATA[If-Match: "xyzzy"
If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz" If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-Match: * If-Match: *
]]></sourcecode> ]]></sourcecode>
<t> <t>
If-Match is most often used with state-changing methods (e.g., POST, PUT, If-Match is most often used with state-changing methods (e.g., POST, PUT,
DELETE) to prevent accidental overwrites when multiple user agents might be DELETE) to prevent accidental overwrites when multiple user agents might be
acting in parallel on the same resource (i.e., to prevent the "lost update" acting in parallel on the same resource (i.e., to prevent the "lost update"
problem). In general, it can be used with any method that involves the problem). In general, it can be used with any method that involves the
selection or modification of a representation to abort the request if the selection or modification of a representation to abort the request if the
<xref target="selected.representation" format="none">selected representation< /xref>'s current entity-tag is not a <xref target="selected.representation" format="none">selected representation< /xref>'s current entity tag is not a
member within the If-Match field value. member within the If-Match field value.
</t> </t>
<t> <t>
When an origin server receives a request that selects a representation When an origin server receives a request that selects a representation
and that request includes an If-Match header field, and that request includes an If-Match header field,
the origin server <bcp14>MUST</bcp14> evaluate the If-Match condition as per the origin server <bcp14>MUST</bcp14> evaluate the If-Match condition per
<xref target="evaluation"/> prior to performing the method. <xref target="evaluation"/> prior to performing the method.
</t> </t>
<t> <t>
To evaluate a received If-Match header field: To evaluate a received If-Match header field:
</t> </t>
<ol> <ol>
<li> <li>
If the field value is "*", the condition is true if the origin server If the field value is "*", the condition is true if the origin server
has a current representation for the target resource. has a current representation for the target resource.
</li> </li>
<li> <li>
If the field value is a list of entity-tags, the condition is true if If the field value is a list of entity tags, the condition is true if
any of the listed tags match the entity-tag of the selected representation any of the listed tags match the entity tag of the selected representation
. .
</li> </li>
<li> <li>
Otherwise, the condition is false. Otherwise, the condition is false.
</li> </li>
</ol> </ol>
<t> <t>
An origin server that evaluates an If-Match condition <bcp14>MUST NOT</bcp14> perform An origin server that evaluates an If-Match condition <bcp14>MUST NOT</bcp14> perform
the requested method if the condition evaluates to false. Instead, the requested method if the condition evaluates to false. Instead,
the origin server <bcp14>MAY</bcp14> the origin server <bcp14>MAY</bcp14>
indicate that the conditional request failed by responding with a indicate that the conditional request failed by responding with a
skipping to change at line 6891 skipping to change at line 6883
(i.e., the change requested by the user agent has already succeeded, but (i.e., the change requested by the user agent has already succeeded, but
the user agent might not be aware of it, perhaps because the prior response the user agent might not be aware of it, perhaps because the prior response
was lost or an equivalent change was made by some other user agent). was lost or an equivalent change was made by some other user agent).
</t> </t>
<t> <t>
Allowing an origin server to send a success response when a change request Allowing an origin server to send a success response when a change request
appears to have already been applied is more efficient for many authoring appears to have already been applied is more efficient for many authoring
use cases, but comes with some risk if multiple user agents are making use cases, but comes with some risk if multiple user agents are making
change requests that are very similar but not cooperative. change requests that are very similar but not cooperative.
For example, multiple user agents writing to a common resource as a For example, multiple user agents writing to a common resource as a
semaphore (e.g., a non-atomic increment) are likely to collide and semaphore (e.g., a nonatomic increment) are likely to collide and
potentially lose important state transitions. For those kinds of resources, potentially lose important state transitions. For those kinds of resources,
an origin server is better off being stringent in sending 412 for every an origin server is better off being stringent in sending 412 for every
failed precondition on an unsafe method. failed precondition on an unsafe method.
In other cases, excluding the ETag field from a success response might In other cases, excluding the ETag field from a success response might
encourage the user agent to perform a GET as its next request to eliminate encourage the user agent to perform a GET as its next request to eliminate
confusion about the resource's current state. confusion about the resource's current state.
</t> </t>
<t> <t>
A client <bcp14>MAY</bcp14> send an If-Match header field in a A client <bcp14>MAY</bcp14> send an If-Match header field in a
<xref target="GET" format="none">GET</xref> request to indicate that it would prefer a <xref target="GET" format="none">GET</xref> request to indicate that it would prefer a
<xref target="status.412" format="none">412 (Precondition Failed)</xref> resp onse if the selected <xref target="status.412" format="none">412 (Precondition Failed)</xref> resp onse if the selected
representation does not match. However, this is only useful in range representation does not match. However, this is only useful in range
requests (<xref target="range.requests"/>), for completing a previously requests (<xref target="range.requests"/>) for completing a previously
received partial representation, when there is no desire for a new received partial representation when there is no desire for a new
representation. <xref target="field.if-range" format="none">If-Range</xref> ( <xref target="field.if-range"/>) representation. <xref target="field.if-range" format="none">If-Range</xref> ( <xref target="field.if-range"/>)
is better suited for range requests when the client prefers to receive a is better suited for range requests when the client prefers to receive a
new representation. new representation.
</t> </t>
<t> <t>
A cache or intermediary <bcp14>MAY</bcp14> ignore If-Match because its A cache or intermediary <bcp14>MAY</bcp14> ignore If-Match because its
interoperability features are only necessary for an origin server. interoperability features are only necessary for an origin server.
</t> </t>
<t> <t>
Note that an If-Match header field with a list value containing "*" and Note that an If-Match header field with a list value containing "*" and
skipping to change at line 6929 skipping to change at line 6921
</t> </t>
</section> </section>
<section anchor="field.if-none-match" title="If-None-Match"> <section anchor="field.if-none-match" title="If-None-Match">
<iref primary="true" item="Fields" subitem="If-None-Match"/> <iref primary="true" item="Fields" subitem="If-None-Match"/>
<iref primary="true" item="Header Fields" subitem="If-None-Match" /> <iref primary="true" item="Header Fields" subitem="If-None-Match" />
<iref primary="true" item="If-None-Match header field"/> <iref primary="true" item="If-None-Match header field"/>
<t> <t>
The "If-None-Match" header field makes the request method conditional on The "If-None-Match" header field makes the request method conditional on
a recipient cache or origin server either not having any current a recipient cache or origin server either not having any current
representation of the target resource, when the field value is "*", or representation of the target resource, when the field value is "*", or
having a <xref target="selected.representation" format="none">selected repres entation</xref> with an entity-tag that does not match any having a <xref target="selected.representation" format="none">selected repres entation</xref> with an entity tag that does not match any
of those listed in the field value. of those listed in the field value.
</t> </t>
<t> <t>
A recipient <bcp14>MUST</bcp14> use the weak comparison function when compari ng A recipient <bcp14>MUST</bcp14> use the weak comparison function when compari ng
entity-tags for If-None-Match (<xref target="entity.tag.comparison"/>), entity tags for If-None-Match (<xref target="entity.tag.comparison"/>),
since weak entity-tags can be used for cache validation even if there have since weak entity tags can be used for cache validation even if there have
been changes to the representation data. been changes to the representation data.
</t> </t>
<iref primary="true" item="Grammar" subitem="If-None-Match"/> <iref primary="true" item="Grammar" subitem="If-None-Match"/>
<sourcecode type="abnf7230"><![CDATA[ If-None-Match = "*" / #ent ity-tag <sourcecode type="abnf9110"><![CDATA[ If-None-Match = "*" / #ent ity-tag
]]></sourcecode> ]]></sourcecode>
<t> <t>
Examples: Examples:
</t> </t>
<sourcecode type="http-message"><![CDATA[If-None-Match: "xyzzy" <sourcecode type="http-message"><![CDATA[If-None-Match: "xyzzy"
If-None-Match: W/"xyzzy" If-None-Match: W/"xyzzy"
If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz" If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz" If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz"
If-None-Match: * If-None-Match: *
]]></sourcecode> ]]></sourcecode>
<t> <t>
If-None-Match is primarily used in conditional GET requests to enable If-None-Match is primarily used in conditional GET requests to enable
efficient updates of cached information with a minimum amount of efficient updates of cached information with a minimum amount of
transaction overhead. When a client desires to update one or more stored transaction overhead. When a client desires to update one or more stored
responses that have entity-tags, the client <bcp14>SHOULD</bcp14> generate an responses that have entity tags, the client <bcp14>SHOULD</bcp14> generate an
If-None-Match header field containing a list of those entity-tags when If-None-Match header field containing a list of those entity tags when
making a GET request; this allows recipient servers to send a making a GET request; this allows recipient servers to send a
<xref target="status.304" format="none">304 (Not Modified)</xref> response to indicate when one of those <xref target="status.304" format="none">304 (Not Modified)</xref> response to indicate when one of those
stored responses matches the selected representation. stored responses matches the selected representation.
</t> </t>
<t> <t>
If-None-Match can also be used with a value of "*" to prevent an unsafe If-None-Match can also be used with a value of "*" to prevent an unsafe
request method (e.g., PUT) from inadvertently modifying an existing request method (e.g., PUT) from inadvertently modifying an existing
representation of the target resource when the client believes that representation of the target resource when the client believes that
the resource does not have a current representation (<xref target="safe.metho ds"/>). the resource does not have a current representation (<xref target="safe.metho ds"/>).
This is a variation on the "lost update" problem that might arise if more This is a variation on the "lost update" problem that might arise if more
than one client attempts to create an initial representation for the target than one client attempts to create an initial representation for the target
resource. resource.
</t> </t>
<t> <t>
When an origin server receives a request that selects a representation When an origin server receives a request that selects a representation
and that request includes an If-None-Match header field, and that request includes an If-None-Match header field,
the origin server <bcp14>MUST</bcp14> evaluate the If-None-Match condition as per the origin server <bcp14>MUST</bcp14> evaluate the If-None-Match condition pe r
<xref target="evaluation"/> prior to performing the method. <xref target="evaluation"/> prior to performing the method.
</t> </t>
<t> <t>
To evaluate a received If-None-Match header field: To evaluate a received If-None-Match header field:
</t> </t>
<ol> <ol>
<li> <li>
If the field value is "*", the condition is false if the origin server If the field value is "*", the condition is false if the origin server
has a current representation for the target resource. has a current representation for the target resource.
</li> </li>
<li> <li>
If the field value is a list of entity-tags, the condition is false if If the field value is a list of entity tags, the condition is false if
one of the listed tags matches the entity-tag of the selected representati one of the listed tags matches the entity tag of the selected representati
on. on.
</li> </li>
<li> <li>
Otherwise, the condition is true. Otherwise, the condition is true.
</li> </li>
</ol> </ol>
<t> <t>
An origin server that evaluates an If-None-Match condition <bcp14>MUST NOT</b cp14> An origin server that evaluates an If-None-Match condition <bcp14>MUST NOT</b cp14>
perform the requested method if the condition evaluates to false; instead, perform the requested method if the condition evaluates to false; instead,
the origin server <bcp14>MUST</bcp14> respond with either the origin server <bcp14>MUST</bcp14> respond with either
a) the <xref target="status.304" format="none">304 (Not Modified)</xref> stat us code if the request method a) the <xref target="status.304" format="none">304 (Not Modified)</xref> stat us code if the request method
skipping to change at line 7022 skipping to change at line 7014
<iref primary="true" item="Header Fields" subitem="If-Modified-Si nce"/> <iref primary="true" item="Header Fields" subitem="If-Modified-Si nce"/>
<iref primary="true" item="If-Modified-Since header field"/> <iref primary="true" item="If-Modified-Since header field"/>
<t> <t>
The "If-Modified-Since" header field makes a GET or HEAD request method The "If-Modified-Since" header field makes a GET or HEAD request method
conditional on the <xref target="selected.representation" format="none">selec ted representation</xref>'s modification conditional on the <xref target="selected.representation" format="none">selec ted representation</xref>'s modification
date being more date being more
recent than the date provided in the field value. Transfer of the selected recent than the date provided in the field value. Transfer of the selected
representation's data is avoided if that data has not changed. representation's data is avoided if that data has not changed.
</t> </t>
<iref primary="true" item="Grammar" subitem="If-Modified-Since"/> <iref primary="true" item="Grammar" subitem="If-Modified-Since"/>
<sourcecode type="abnf7230"><![CDATA[ If-Modified-Since = HTTP-d ate <sourcecode type="abnf9110"><![CDATA[ If-Modified-Since = HTTP-d ate
]]></sourcecode> ]]></sourcecode>
<t> <t>
An example of the field is: An example of the field is:
</t> </t>
<sourcecode type="http-message"><![CDATA[If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT <sourcecode type="http-message"><![CDATA[If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
]]></sourcecode> ]]></sourcecode>
<t> <t>
A recipient <bcp14>MUST</bcp14> ignore If-Modified-Since if the request conta ins an A recipient <bcp14>MUST</bcp14> ignore If-Modified-Since if the request conta ins an
<xref target="field.if-none-match" format="none">If-None-Match</xref> header field; the condition in <xref target="field.if-none-match" format="none">If-None-Match</xref> header field; the condition in
<xref target="field.if-none-match" format="none">If-None-Match</xref> is cons idered to be a more accurate <xref target="field.if-none-match" format="none">If-None-Match</xref> is cons idered to be a more accurate
skipping to change at line 7053 skipping to change at line 7045
A recipient <bcp14>MUST</bcp14> ignore the If-Modified-Since header field if the A recipient <bcp14>MUST</bcp14> ignore the If-Modified-Since header field if the
resource does not have a modification date available. resource does not have a modification date available.
</t> </t>
<t> <t>
A recipient <bcp14>MUST</bcp14> interpret an If-Modified-Since field value's timestamp A recipient <bcp14>MUST</bcp14> interpret an If-Modified-Since field value's timestamp
in terms of the origin server's clock. in terms of the origin server's clock.
</t> </t>
<t> <t>
If-Modified-Since is typically used for two distinct purposes: If-Modified-Since is typically used for two distinct purposes:
1) to allow efficient updates of a cached representation that does not 1) to allow efficient updates of a cached representation that does not
have an entity-tag and 2) to limit the scope of a web traversal to resources have an entity tag and 2) to limit the scope of a web traversal to resources
that have recently changed. that have recently changed.
</t> </t>
<t> <t>
When used for cache updates, a cache will typically use the value of the When used for cache updates, a cache will typically use the value of the
cached message's <xref target="field.last-modified" format="none">Last-Modifi ed</xref> header field to generate the field cached message's <xref target="field.last-modified" format="none">Last-Modifi ed</xref> header field to generate the field
value of If-Modified-Since. This behavior is most interoperable for cases value of If-Modified-Since. This behavior is most interoperable for cases
where clocks are poorly synchronized or when the server has chosen to only where clocks are poorly synchronized or when the server has chosen to only
honor exact timestamp matches (due to a problem with Last-Modified dates honor exact timestamp matches (due to a problem with Last-Modified dates
that appear to go "back in time" when the origin server's clock is that appear to go "back in time" when the origin server's clock is
corrected or a representation is restored from an archived backup). corrected or a representation is restored from an archived backup).
skipping to change at line 7083 skipping to change at line 7075
server in a prior response. Origin servers that choose an exact server in a prior response. Origin servers that choose an exact
timestamp match based on the selected representation's timestamp match based on the selected representation's
<xref target="field.last-modified" format="none">Last-Modified</xref> <xref target="field.last-modified" format="none">Last-Modified</xref>
header field will not be able to help the user agent limit its data header field will not be able to help the user agent limit its data
transfers to only those changed during the specified window. transfers to only those changed during the specified window.
</t> </t>
<t> <t>
When an origin server receives a request that selects a representation When an origin server receives a request that selects a representation
and that request includes an If-Modified-Since header field without an and that request includes an If-Modified-Since header field without an
<xref target="field.if-none-match" format="none">If-None-Match</xref> header field, the origin server <bcp14>SHOULD</bcp14> <xref target="field.if-none-match" format="none">If-None-Match</xref> header field, the origin server <bcp14>SHOULD</bcp14>
evaluate the If-Modified-Since condition as per evaluate the If-Modified-Since condition per
<xref target="evaluation"/> prior to performing the method. <xref target="evaluation"/> prior to performing the method.
</t> </t>
<t> <t>
To evaluate a received If-Modified-Since header field: To evaluate a received If-Modified-Since header field:
</t> </t>
<ol> <ol>
<li> <li>
If the selected representation's last modification date is earlier or If the selected representation's last modification date is earlier or
equal to the date provided in the field value, the condition is false. equal to the date provided in the field value, the condition is false.
</li> </li>
skipping to change at line 7121 skipping to change at line 7113
<section anchor="field.if-unmodified-since" title="If-Unmodified-Sin ce"> <section anchor="field.if-unmodified-since" title="If-Unmodified-Sin ce">
<iref primary="true" item="Fields" subitem="If-Unmodified-Since"/ > <iref primary="true" item="Fields" subitem="If-Unmodified-Since"/ >
<iref primary="true" item="Header Fields" subitem="If-Unmodified- Since"/> <iref primary="true" item="Header Fields" subitem="If-Unmodified- Since"/>
<iref primary="true" item="If-Unmodified-Since header field"/> <iref primary="true" item="If-Unmodified-Since header field"/>
<t> <t>
The "If-Unmodified-Since" header field makes the request method conditional The "If-Unmodified-Since" header field makes the request method conditional
on the <xref target="selected.representation" format="none">selected represen tation</xref>'s last modification date being on the <xref target="selected.representation" format="none">selected represen tation</xref>'s last modification date being
earlier than or equal to the date provided in the field value. earlier than or equal to the date provided in the field value.
This field accomplishes the This field accomplishes the
same purpose as <xref target="field.if-match" format="none">If-Match</xref> f or cases where the user agent does same purpose as <xref target="field.if-match" format="none">If-Match</xref> f or cases where the user agent does
not have an entity-tag for the representation. not have an entity tag for the representation.
</t> </t>
<iref primary="true" item="Grammar" subitem="If-Unmodified-Since" /> <iref primary="true" item="Grammar" subitem="If-Unmodified-Since" />
<sourcecode type="abnf7230"><![CDATA[ If-Unmodified-Since = HTTP -date <sourcecode type="abnf9110"><![CDATA[ If-Unmodified-Since = HTTP -date
]]></sourcecode> ]]></sourcecode>
<t> <t>
An example of the field is: An example of the field is:
</t> </t>
<sourcecode type="http-message"><![CDATA[If-Unmodified-Since: Sat , 29 Oct 1994 19:43:31 GMT <sourcecode type="http-message"><![CDATA[If-Unmodified-Since: Sat , 29 Oct 1994 19:43:31 GMT
]]></sourcecode> ]]></sourcecode>
<t> <t>
A recipient <bcp14>MUST</bcp14> ignore If-Unmodified-Since if the request con tains an A recipient <bcp14>MUST</bcp14> ignore If-Unmodified-Since if the request con tains an
<xref target="field.if-match" format="none">If-Match</xref> header field; the condition in <xref target="field.if-match" format="none">If-Match</xref> header field; the condition in
<xref target="field.if-match" format="none">If-Match</xref> is considered to be a more accurate replacement for <xref target="field.if-match" format="none">If-Match</xref> is considered to be a more accurate replacement for
skipping to change at line 7156 skipping to change at line 7148
resource does not have a modification date available. resource does not have a modification date available.
</t> </t>
<t> <t>
A recipient <bcp14>MUST</bcp14> interpret an If-Unmodified-Since field value' s timestamp A recipient <bcp14>MUST</bcp14> interpret an If-Unmodified-Since field value' s timestamp
in terms of the origin server's clock. in terms of the origin server's clock.
</t> </t>
<t> <t>
If-Unmodified-Since is most often used with state-changing methods If-Unmodified-Since is most often used with state-changing methods
(e.g., POST, PUT, DELETE) to prevent accidental overwrites when multiple (e.g., POST, PUT, DELETE) to prevent accidental overwrites when multiple
user agents might be acting in parallel on a resource that does user agents might be acting in parallel on a resource that does
not supply entity-tags with its representations (i.e., to prevent the not supply entity tags with its representations (i.e., to prevent the
"lost update" problem). "lost update" problem).
In general, it can be used with any method that involves the selection In general, it can be used with any method that involves the selection
or modification of a representation to abort the request if the or modification of a representation to abort the request if the
<xref target="selected.representation" format="none">selected representation< /xref>'s last modification date has <xref target="selected.representation" format="none">selected representation< /xref>'s last modification date has
changed since the date provided in the If-Unmodified-Since field value. changed since the date provided in the If-Unmodified-Since field value.
</t> </t>
<t> <t>
When an origin server receives a request that selects a representation When an origin server receives a request that selects a representation
and that request includes an If-Unmodified-Since header field without and that request includes an If-Unmodified-Since header field without
an <xref target="field.if-match" format="none">If-Match</xref> header field, an <xref target="field.if-match" format="none">If-Match</xref> header field,
the origin server <bcp14>MUST</bcp14> evaluate the If-Unmodified-Since condit ion as per the origin server <bcp14>MUST</bcp14> evaluate the If-Unmodified-Since condit ion per
<xref target="evaluation"/> prior to performing the method. <xref target="evaluation"/> prior to performing the method.
</t> </t>
<t> <t>
To evaluate a received If-Unmodified-Since header field: To evaluate a received If-Unmodified-Since header field:
</t> </t>
<ol> <ol>
<li> <li>
If the selected representation's last modification date is earlier than or If the selected representation's last modification date is earlier than or
equal to the date provided in the field value, the condition is true. equal to the date provided in the field value, the condition is true.
</li> </li>
skipping to change at line 7208 skipping to change at line 7200
use cases, but comes with some risk if multiple user agents are making use cases, but comes with some risk if multiple user agents are making
change requests that are very similar but not cooperative. change requests that are very similar but not cooperative.
In those cases, an origin server is better off being stringent in sending In those cases, an origin server is better off being stringent in sending
412 for every failed precondition on an unsafe method. 412 for every failed precondition on an unsafe method.
</t> </t>
<t> <t>
A client <bcp14>MAY</bcp14> send an If-Unmodified-Since header field in a A client <bcp14>MAY</bcp14> send an If-Unmodified-Since header field in a
<xref target="GET" format="none">GET</xref> request to indicate that it would prefer a <xref target="GET" format="none">GET</xref> request to indicate that it would prefer a
<xref target="status.412" format="none">412 (Precondition Failed)</xref> resp onse if the selected <xref target="status.412" format="none">412 (Precondition Failed)</xref> resp onse if the selected
representation has been modified. However, this is only useful in range representation has been modified. However, this is only useful in range
requests (<xref target="range.requests"/>), for completing a previously requests (<xref target="range.requests"/>) for completing a previously
received partial representation, when there is no desire for a new received partial representation when there is no desire for a new
representation. <xref target="field.if-range" format="none">If-Range</xref> ( <xref target="field.if-range"/>) representation. <xref target="field.if-range" format="none">If-Range</xref> ( <xref target="field.if-range"/>)
is better suited for range requests when the client prefers to receive a is better suited for range requests when the client prefers to receive a
new representation. new representation.
</t> </t>
<t> <t>
A cache or intermediary <bcp14>MAY</bcp14> ignore If-Unmodified-Since because its A cache or intermediary <bcp14>MAY</bcp14> ignore If-Unmodified-Since because its
interoperability features are only necessary for an origin server. interoperability features are only necessary for an origin server.
</t> </t>
</section> </section>
<section anchor="field.if-range" title="If-Range"> <section anchor="field.if-range" title="If-Range">
skipping to change at line 7247 skipping to change at line 7239
representation has been modified, the client would then have to make a representation has been modified, the client would then have to make a
second request to obtain the entire current representation. second request to obtain the entire current representation.
</t> </t>
<t> <t>
The "If-Range" header field allows a client to "short-circuit" the second The "If-Range" header field allows a client to "short-circuit" the second
request. Informally, its meaning is as follows: if the representation is unch anged, request. Informally, its meaning is as follows: if the representation is unch anged,
send me the part(s) that I am requesting in Range; otherwise, send me the send me the part(s) that I am requesting in Range; otherwise, send me the
entire representation. entire representation.
</t> </t>
<iref primary="true" item="Grammar" subitem="If-Range"/> <iref primary="true" item="Grammar" subitem="If-Range"/>
<sourcecode type="abnf7230"><![CDATA[ If-Range = entity-tag / HT TP-date <sourcecode type="abnf9110"><![CDATA[ If-Range = entity-tag / HT TP-date
]]></sourcecode> ]]></sourcecode>
<t> <t>
A valid <xref target="field.etag" format="none">entity-tag</xref> can be dist inguished from a valid A valid <xref target="field.etag" format="none">entity-tag</xref> can be dist inguished from a valid
<xref target="http.date" format="none">HTTP-date</xref> by examining the firs t three characters for a <xref target="http.date" format="none">HTTP-date</xref> by examining the firs t three characters for a
DQUOTE. DQUOTE.
</t> </t>
<t> <t>
A client <bcp14>MUST NOT</bcp14> generate an If-Range header field in a reque st that A client <bcp14>MUST NOT</bcp14> generate an If-Range header field in a reque st that
does not contain a <xref target="field.range" format="none">Range</xref> head er field. does not contain a <xref target="field.range" format="none">Range</xref> head er field.
A server <bcp14>MUST</bcp14> ignore an If-Range header field received in a re quest that A server <bcp14>MUST</bcp14> ignore an If-Range header field received in a re quest that
does not contain a <xref target="field.range" format="none">Range</xref> head er field. does not contain a <xref target="field.range" format="none">Range</xref> head er field.
An origin server <bcp14>MUST</bcp14> ignore an If-Range header field received in a An origin server <bcp14>MUST</bcp14> ignore an If-Range header field received in a
request for a target resource that does not support Range requests. request for a target resource that does not support Range requests.
</t> </t>
<t> <t>
A client <bcp14>MUST NOT</bcp14> generate an If-Range header field containing an A client <bcp14>MUST NOT</bcp14> generate an If-Range header field containing an
entity-tag that is marked as weak. entity tag that is marked as weak.
A client <bcp14>MUST NOT</bcp14> generate an If-Range header field containing an A client <bcp14>MUST NOT</bcp14> generate an If-Range header field containing an
<xref target="http.date" format="none">HTTP-date</xref> unless the client has no entity-tag for <xref target="http.date" format="none">HTTP-date</xref> unless the client has no entity tag for
the corresponding representation and the date is a strong validator the corresponding representation and the date is a strong validator
in the sense defined by <xref target="lastmod.comparison"/>. in the sense defined by <xref target="lastmod.comparison"/>.
</t> </t>
<t> <t>
A server that receives an If-Range header field on a Range request <bcp14>MUS T</bcp14> A server that receives an If-Range header field on a Range request <bcp14>MUS T</bcp14>
evaluate the condition as per <xref target="evaluation"/> prior to evaluate the condition per <xref target="evaluation"/> prior to
performing the method. performing the method.
</t> </t>
<t> <t>
To evaluate a received If-Range header field containing an To evaluate a received If-Range header field containing an
<xref target="http.date" format="none">HTTP-date</xref>: <xref target="http.date" format="none">HTTP-date</xref>:
</t> </t>
<ol> <ol>
<li>If the <xref target="http.date" format="none">HTTP-date</x ref> validator provided is not a <li>If the <xref target="http.date" format="none">HTTP-date</x ref> validator provided is not a
strong validator in the sense defined by strong validator in the sense defined by
<xref target="lastmod.comparison"/>, the condition is false.</li> <xref target="lastmod.comparison"/>, the condition is false.</li>
skipping to change at line 7306 skipping to change at line 7298
(<xref target="entity.tag.comparison"/>), the condition is true.</li> (<xref target="entity.tag.comparison"/>), the condition is true.</li>
<li>Otherwise, the condition is false.</li> <li>Otherwise, the condition is false.</li>
</ol> </ol>
<t> <t>
A recipient of an If-Range header field <bcp14>MUST</bcp14> ignore the A recipient of an If-Range header field <bcp14>MUST</bcp14> ignore the
<xref target="field.range" format="none">Range</xref> header field if the If- Range condition <xref target="field.range" format="none">Range</xref> header field if the If- Range condition
evaluates to false. Otherwise, the recipient <bcp14>SHOULD</bcp14> process th e evaluates to false. Otherwise, the recipient <bcp14>SHOULD</bcp14> process th e
<xref target="field.range" format="none">Range</xref> header field as request ed. <xref target="field.range" format="none">Range</xref> header field as request ed.
</t> </t>
<t> <t>
Note that the If-Range comparison is by exact Note that the If-Range comparison is by exact match, including when the
match, including when the validator is an <xref target="http.date" format="no validator is an <xref target="http.date" format="none">HTTP-date</xref>, and
ne">HTTP-date</xref>, and so so it
differs from the "earlier than or equal to" comparison used when evaluating differs from the "earlier than or equal to" comparison used when evaluating
an <xref target="field.if-unmodified-since" format="none">If-Unmodified-Since </xref> conditional. an <xref target="field.if-unmodified-since" format="none">If-Unmodified-Since </xref> conditional.
</t> </t>
</section> </section>
</section> </section>
<section anchor="evaluation" title="Evaluation of Preconditions"> <section anchor="evaluation" title="Evaluation of Preconditions">
<section anchor="when.to.evaluate" title="When to Evaluate"> <section anchor="when.to.evaluate" title="When to Evaluate">
<t> <t>
Except when excluded below, a recipient cache or origin server <bcp14>MUST</b cp14> Except when excluded below, a recipient cache or origin server <bcp14>MUST</b cp14>
evaluate received request preconditions after it has successfully performed evaluate received request preconditions after it has successfully performed
skipping to change at line 7343 skipping to change at line 7335
client intends that they be evaluated by a server that can provide a client intends that they be evaluated by a server that can provide a
current representation. current representation.
Likewise, a server <bcp14>MUST</bcp14> ignore the conditional request header fields Likewise, a server <bcp14>MUST</bcp14> ignore the conditional request header fields
defined by this specification when received with a request method that does defined by this specification when received with a request method that does
not involve the selection or modification of a not involve the selection or modification of a
<xref target="selected.representation" format="none">selected representation< /xref>, such as CONNECT, OPTIONS, or TRACE. <xref target="selected.representation" format="none">selected representation< /xref>, such as CONNECT, OPTIONS, or TRACE.
</t> </t>
<t> <t>
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 For example, the immutable cache directive
(defined by <xref target="RFC8246"/>) instructs caches to forgo (defined by <xref target="RFC8246"/>) instructs caches to forgo
forwarding conditional requests when they hold a fresh response. forwarding conditional requests when they hold a fresh response.
</t> </t>
<t> <t>
Although conditional request header fields are defined as being usable with Although conditional request header fields are defined as being usable with
the HEAD method (to keep HEAD's semantics consistent with those of GET), the HEAD method (to keep HEAD's semantics consistent with those of GET),
there is no point in sending a conditional HEAD because a successful there is no point in sending a conditional HEAD because a successful
response is around the same size as a <xref target="status.304" format="none" >304 (Not Modified)</xref> response is around the same size as a <xref target="status.304" format="none" >304 (Not Modified)</xref>
response and more useful than a <xref target="status.412" format="none">412 ( Precondition Failed)</xref> response and more useful than a <xref target="status.412" format="none">412 ( Precondition Failed)</xref>
response. response.
skipping to change at line 7474 skipping to change at line 7466
of HTTP, designed so that recipients not implementing this feature (or not of HTTP, designed so that recipients not implementing this feature (or not
supporting it for the target resource) can respond as if it is a normal supporting it for the target resource) can respond as if it is a normal
GET request without impacting interoperability. Partial responses are GET request without impacting interoperability. Partial responses are
indicated by a distinct status code to not be mistaken for full responses indicated by a distinct status code to not be mistaken for full responses
by caches that might not implement the feature. by caches that might not implement the feature.
</t> </t>
<section anchor="range.units" title="Range Units"> <section anchor="range.units" title="Range Units">
<t> <t>
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 or addressable structural units inherent to that data's content coding or
media type. For example, octet (a.k.a., byte) boundaries are a structural media type. For example, octet (a.k.a. byte) boundaries are a structural
unit common to all representation data, allowing partitions of the data to unit common to all representation data, allowing partitions of the data to
be identified as a range of bytes at some offset from the start or end of be identified as a range of bytes at some offset from the start or end of
that data. that data.
</t> </t>
<t> <t>
This general notion of a <em>range unit</em> is used This general notion of a "range unit" is used
in the <xref target="field.accept-ranges" format="none">Accept-Ranges</xref> (<xref target="field.accept-ranges"/>) in the <xref target="field.accept-ranges" format="none">Accept-Ranges</xref> (<xref target="field.accept-ranges"/>)
response header field to advertise support for range requests, the response header field to advertise support for range requests, the
<xref target="field.range" format="none">Range</xref> (<xref target="field.ra nge"/>) request header field <xref target="field.range" format="none">Range</xref> (<xref target="field.ra nge"/>) request header field
to delineate the parts of a representation that are requested, and the to delineate the parts of a representation that are requested, and the
<xref target="field.content-range" format="none">Content-Range</xref> (<xref target="field.content-range"/>) <xref target="field.content-range" format="none">Content-Range</xref> (<xref target="field.content-range"/>)
header field to describe which part of a representation is being header field to describe which part of a representation is being
transferred. transferred.
</t> </t>
<iref primary="true" item="Grammar" subitem="range-unit"/> <iref primary="true" item="Grammar" subitem="range-unit"/>
<sourcecode type="abnf7230"><![CDATA[ range-unit = token <sourcecode type="abnf9110"><![CDATA[ range-unit = token
]]></sourcecode> ]]></sourcecode>
<t> <t>
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 within the "HTTP Range Unit Registry", as defined in
<xref target="range.unit.registry"/>. <xref target="range.unit.registry"/>.
</t> </t>
<t> <t>
Range units are intended to be extensible, as described in Range units are intended to be extensible, as described in
<xref target="range.unit.extensibility"/>. <xref target="range.unit.extensibility"/>.
</t> </t>
<section anchor="range.specifiers" title="Range Specifiers"> <section anchor="range.specifiers" title="Range Specifiers">
<iref primary="true" item="satisfiable range"/>
<iref primary="true" item="unsatisfiable range"/>
<t> <t>
Ranges are expressed in terms of a range unit paired with a set of range Ranges are expressed in terms of a range unit paired with a set of range
specifiers. The range unit name determines what kinds of range-spec specifiers. The range unit name determines what kinds of range-spec
are applicable to its own specifiers. Hence, the following grammar is are applicable to its own specifiers. Hence, the following grammar is
generic: each range unit is expected to specify requirements on when generic: each range unit is expected to specify requirements on when
<xref target="rule.int-range" format="none">int-range</xref>, <xref target="r ule.suffix-range" format="none">suffix-range</xref>, and <xref target="rule.int-range" format="none">int-range</xref>, <xref target="r ule.suffix-range" format="none">suffix-range</xref>, and
<xref target="rule.other-range" format="none">other-range</xref> are allowed. <xref target="rule.other-range" format="none">other-range</xref> are allowed.
</t> </t>
<t anchor="rule.ranges-specifier"> <t anchor="rule.ranges-specifier">
A range request can specify a single range or a set A range request can specify a single range or a set
of ranges within a single representation. of ranges within a single representation.
</t> </t>
<iref primary="true" item="Grammar" subitem="ranges-specifier"/> <iref primary="true" item="Grammar" subitem="ranges-specifier"/>
<iref primary="true" item="Grammar" subitem="range-set"/> <iref primary="true" item="Grammar" subitem="range-set"/>
<iref primary="true" item="Grammar" subitem="range-spec"/> <iref primary="true" item="Grammar" subitem="range-spec"/>
<sourcecode type="abnf7230"><![CDATA[ ranges-specifier = range-u nit "=" range-set <sourcecode type="abnf9110"><![CDATA[ ranges-specifier = range-u nit "=" range-set
range-set = 1#range-spec range-set = 1#range-spec
range-spec = int-range range-spec = int-range
/ suffix-range / suffix-range
/ other-range / other-range
]]></sourcecode> ]]></sourcecode>
<t anchor="rule.int-range"> <t anchor="rule.int-range">
An <xref target="rule.int-range" format="none">int-range</xref> is a range ex pressed as two non-negative An <xref target="rule.int-range" format="none">int-range</xref> is a range ex pressed as two non-negative
integers or as one non-negative integer through to the end of the integers or as one non-negative integer through to the end of the
representation data. representation data.
The range unit specifies what the integers mean (e.g., they might indicate The range unit specifies what the integers mean (e.g., they might indicate
unit offsets from the beginning, inclusive numbered parts, etc.). unit offsets from the beginning, inclusive numbered parts, etc.).
</t> </t>
<iref primary="true" item="Grammar" subitem="int-range"/> <iref primary="true" item="Grammar" subitem="int-range"/>
<iref primary="true" item="Grammar" subitem="first-pos"/> <iref primary="true" item="Grammar" subitem="first-pos"/>
<iref primary="true" item="Grammar" subitem="last-pos"/> <iref primary="true" item="Grammar" subitem="last-pos"/>
<sourcecode type="abnf7230"><![CDATA[ int-range = first-pos "-" [ last-pos ] <sourcecode type="abnf9110"><![CDATA[ int-range = first-pos "-" [ last-pos ]
first-pos = 1*DIGIT first-pos = 1*DIGIT
last-pos = 1*DIGIT last-pos = 1*DIGIT
]]></sourcecode> ]]></sourcecode>
<t> <t>
An <xref target="rule.int-range" format="none">int-range</xref> is invalid if the An <xref target="rule.int-range" format="none">int-range</xref> is invalid if the
<xref target="rule.int-range" format="none">last-pos</xref> value is present and less than the <xref target="rule.int-range" format="none">last-pos</xref> value is present and less than the
<xref target="rule.int-range" format="none">first-pos</xref>. <xref target="rule.int-range" format="none">first-pos</xref>.
</t> </t>
<t anchor="rule.suffix-range"> <t anchor="rule.suffix-range">
A <xref target="rule.suffix-range" format="none">suffix-range</xref> is a ran ge expressed as a suffix of the A <xref target="rule.suffix-range" format="none">suffix-range</xref> is a ran ge expressed as a suffix of the
representation data with the provided non-negative integer maximum length representation data with the provided non-negative integer maximum length
(in range units). In other words, the last N units of the representation (in range units). In other words, the last N units of the representation
data. data.
</t> </t>
<iref primary="true" item="Grammar" subitem="suffix-range"/> <iref primary="true" item="Grammar" subitem="suffix-range"/>
<iref primary="true" item="Grammar" subitem="suffix-length"/> <iref primary="true" item="Grammar" subitem="suffix-length"/>
<sourcecode type="abnf7230"><![CDATA[ suffix-range = "-" suffix -length <sourcecode type="abnf9110"><![CDATA[ suffix-range = "-" suffix -length
suffix-length = 1*DIGIT suffix-length = 1*DIGIT
]]></sourcecode> ]]></sourcecode>
<t anchor="rule.other-range"> <t anchor="rule.other-range">
To provide for extensibility, the <xref target="rule.other-range" format="non e">other-range</xref> rule is a To provide for extensibility, the <xref target="rule.other-range" format="non e">other-range</xref> rule is a
mostly unconstrained grammar that allows application-specific or future mostly unconstrained grammar that allows application-specific or future
range units to define additional range specifiers. range units to define additional range specifiers.
</t> </t>
<iref primary="true" item="Grammar" subitem="other-range"/> <iref primary="true" item="Grammar" subitem="other-range"/>
<sourcecode type="abnf7230"><![CDATA[ other-range = 1*( %x21-2 B / %x2D-7E ) <sourcecode type="abnf9110"><![CDATA[ other-range = 1*( %x21-2 B / %x2D-7E )
; 1*(VCHAR excluding comma) ; 1*(VCHAR excluding comma)
]]></sourcecode> ]]></sourcecode>
<t>
A <xref target="rule.ranges-specifier" format="none">ranges-specifier</xref>
is invalid if it contains any
<xref target="rule.ranges-specifier" format="none">range-spec</xref> that is
invalid or undefined for the indicated
<xref target="range.units" format="none">range-unit</xref>.
</t>
<t anchor="satisfiable">
A valid <xref target="rule.ranges-specifier" format="none">ranges-specifier</
xref> is "satisfiable"
if it contains at least one <xref target="rule.ranges-specifier" format="none
">range-spec</xref> that is
satisfiable, as defined by the indicated <xref target="range.units" format="n
one">range-unit</xref>.
Otherwise, the <xref target="rule.ranges-specifier" format="none">ranges-spec
ifier</xref> is
"unsatisfiable".
</t>
</section> </section>
<section anchor="byte.ranges" title="Byte Ranges"> <section anchor="byte.ranges" title="Byte Ranges">
<t> <t>
The "bytes" range unit is used to express subranges of a representation The "bytes" range unit is used to express subranges of a representation
data's octet sequence. data's octet sequence.
Each byte range is expressed as an integer range at some offset, relative Each byte range is expressed as an integer range at some offset, relative
to either the beginning (<xref target="rule.int-range" format="none">int-rang e</xref>) or end to either the beginning (<xref target="rule.int-range" format="none">int-rang e</xref>) or end
(<xref target="rule.suffix-range" format="none">suffix-range</xref>) of the r epresentation data. (<xref target="rule.suffix-range" format="none">suffix-range</xref>) of the r epresentation data.
Byte ranges do not use the <xref target="rule.other-range" format="none">othe r-range</xref> specifier. Byte ranges do not use the <xref target="rule.other-range" format="none">othe r-range</xref> specifier.
</t> </t>
skipping to change at line 7594 skipping to change at line 7600
If the representation data has a content coding applied, each byte range is If the representation data has a content coding applied, each byte range is
calculated with respect to the encoded sequence of bytes, not the sequence calculated with respect to the encoded sequence of bytes, not the sequence
of underlying bytes that would be obtained after decoding. of underlying bytes that would be obtained after decoding.
</t> </t>
<t> <t>
Examples of bytes range specifiers: Examples of bytes range specifiers:
</t> </t>
<ul> <ul>
<li> <li>
<t>The first 500 bytes (byte offsets 0-499, inclusive):</t> <t>The first 500 bytes (byte offsets 0-499, inclusive):</t>
<artwork type="example"><![CDATA[ <artwork><![CDATA[
bytes=0-499 bytes=0-499
]]></artwork> ]]></artwork>
</li> </li>
<li> <li>
<t>The second 500 bytes (byte offsets 500-999, inclusive):< /t> <t>The second 500 bytes (byte offsets 500-999, inclusive):< /t>
<artwork type="example"><![CDATA[ <artwork><![CDATA[
bytes=500-999 bytes=500-999
]]></artwork> ]]></artwork>
</li> </li>
</ul> </ul>
<t> <t>
A client can limit the number of bytes requested without knowing the size A client can limit the number of bytes requested without knowing the size
of the <xref target="selected.representation" format="none">selected represen tation</xref>. of the <xref target="selected.representation" format="none">selected represen tation</xref>.
If the <xref target="rule.int-range" format="none">last-pos</xref> value is a bsent, or if the value is If the <xref target="rule.int-range" format="none">last-pos</xref> value is a bsent, or if the value is
greater than or equal to the current length of the representation data, the greater than or equal to the current length of the representation data, the
byte range is interpreted as the remainder of the representation (i.e., the byte range is interpreted as the remainder of the representation (i.e., the
server replaces the value of <xref target="rule.int-range" format="none">last -pos</xref> with a value that server replaces the value of <xref target="rule.int-range" format="none">last -pos</xref> with a value that
is one less than the current length of the selected representation). is one less than the current length of the selected representation).
</t> </t>
<t> <t>
A client can request the last N bytes (N &gt; 0) of the selected A client can refer to the last N bytes (N &gt; 0) of the selected
representation using a <xref target="rule.suffix-range" format="none">suffix- range</xref>. representation using a <xref target="rule.suffix-range" format="none">suffix- range</xref>.
If the selected representation is shorter than the specified If the selected representation is shorter than the specified
<xref target="rule.suffix-range" format="none">suffix-length</xref>, the enti re representation is used. <xref target="rule.suffix-range" format="none">suffix-length</xref>, the enti re representation is used.
</t> </t>
<t> <t>
Additional examples, assuming a representation of length 10000: Additional examples, assuming a representation of length 10000:
</t> </t>
<ul> <ul>
<li> <li>
<t>The final 500 bytes (byte offsets 9500-9999, inclusive): </t> <t>The final 500 bytes (byte offsets 9500-9999, inclusive): </t>
<artwork type="example"><![CDATA[ <artwork><![CDATA[
bytes=-500 bytes=-500
]]></artwork> ]]></artwork>
<t>Or:</t> <t>Or:</t>
<artwork type="example"><![CDATA[ <artwork><![CDATA[
bytes=9500- bytes=9500-
]]></artwork> ]]></artwork>
</li> </li>
<li> <li>
<t>The first and last bytes only (bytes 0 and 9999):</t> <t>The first and last bytes only (bytes 0 and 9999):</t>
<artwork type="example"><![CDATA[ <artwork><![CDATA[
bytes=0-0,-1 bytes=0-0,-1
]]></artwork> ]]></artwork>
</li> </li>
<li> <li>
<t>The first, middle, and last 1000 bytes:</t> <t>The first, middle, and last 1000 bytes:</t>
<artwork type="example"><![CDATA[ <artwork><![CDATA[
bytes= 0-999, 4500-5499, -1000 bytes= 0-999, 4500-5499, -1000
]]></artwork> ]]></artwork>
</li> </li>
<li> <li>
<t>Other valid (but not canonical) specifications of the se cond 500 <t>Other valid (but not canonical) specifications of the se cond 500
bytes (byte offsets 500-999, inclusive):</t> bytes (byte offsets 500-999, inclusive):</t>
<artwork type="example"><![CDATA[ <artwork><![CDATA[
bytes=500-600,601-999 bytes=500-600,601-999
bytes=500-700,601-999 bytes=500-700,601-999
]]></artwork> ]]></artwork>
</li> </li>
</ul> </ul>
<t> <t>
If a valid bytes <xref target="rule.ranges-specifier" format="none">range-set For a <xref target="GET" format="none">GET</xref> request, a valid bytes <xre
</xref> includes at least one f target="rule.ranges-specifier" format="none">range-spec</xref>
<xref target="rule.ranges-specifier" format="none">range-spec</xref> with a < is <xref target="satisfiable" format="none">satisfiable</xref> if it is eithe
xref target="rule.int-range" format="none">first-pos</xref> that is r:
less than the current length of the representation, or at least one
<xref target="rule.suffix-range" format="none">suffix-range</xref> with a non
-zero <xref target="rule.suffix-range" format="none">suffix-length</xref>,
then the bytes <xref target="rule.ranges-specifier" format="none">range-set</
xref> is satisfiable. Otherwise,
the bytes <xref target="rule.ranges-specifier" format="none">range-set</xref>
is unsatisfiable.
</t> </t>
<ul>
<li>an <xref target="rule.int-range" format="none">int-range</
xref> with a <xref target="rule.int-range" format="none">first-pos</xref> that
is less than the current length of the selected representation
or</li>
<li>a <xref target="rule.suffix-range" format="none">suffix-ra
nge</xref> with a non-zero
<xref target="rule.suffix-range" format="none">suffix-length</xref>.</li>
</ul>
<t> <t>
If the selected representation has zero length, the only satisfiable form of When a selected representation has zero length, the only
<xref target="rule.ranges-specifier" format="none">range-spec</xref> is a <xr <xref target="satisfiable" format="none">satisfiable</xref> form of <xref tar
ef target="rule.suffix-range" format="none">suffix-range</xref> with a non-zero get="rule.ranges-specifier" format="none">range-spec</xref> in a
<xref target="rule.suffix-range" format="none">suffix-length</xref>. <xref target="GET" format="none">GET</xref> request is a <xref target="rule.s
uffix-range" format="none">suffix-range</xref> with a
non-zero <xref target="rule.suffix-range" format="none">suffix-length</xref>.
</t> </t>
<t> <t>
In the byte-range syntax, <xref target="rule.int-range" format="none">first-p os</xref>, In the byte-range syntax, <xref target="rule.int-range" format="none">first-p os</xref>,
<xref target="rule.int-range" format="none">last-pos</xref>, and <xref target ="rule.suffix-range" format="none">suffix-length</xref> are <xref target="rule.int-range" format="none">last-pos</xref>, and <xref target ="rule.suffix-range" format="none">suffix-length</xref> are
expressed as decimal number of octets. Since there is no predefined limit expressed as decimal number of octets. Since there is no predefined limit
to the length of content, recipients <bcp14>MUST</bcp14> anticipate potential ly to the length of content, recipients <bcp14>MUST</bcp14> anticipate potential ly
large decimal numerals and prevent parsing errors due to integer conversion large decimal numerals and prevent parsing errors due to integer conversion
overflows. overflows.
</t> </t>
</section> </section>
skipping to change at line 7689 skipping to change at line 7699
<iref primary="true" item="Fields" subitem="Range"/> <iref primary="true" item="Fields" subitem="Range"/>
<iref primary="true" item="Header Fields" subitem="Range"/> <iref primary="true" item="Header Fields" subitem="Range"/>
<iref primary="true" item="Range header field"/> <iref primary="true" item="Range header field"/>
<t> <t>
The "Range" header field on a GET request modifies the method semantics to The "Range" header field on a GET request modifies the method semantics to
request transfer of only one or more subranges of the request transfer of only one or more subranges of the
selected representation data (<xref target="representation.data"/>), selected representation data (<xref target="representation.data"/>),
rather than the entire <xref target="selected.representation" format="none">s elected representation</xref>. rather than the entire <xref target="selected.representation" format="none">s elected representation</xref>.
</t> </t>
<iref primary="true" item="Grammar" subitem="Range"/> <iref primary="true" item="Grammar" subitem="Range"/>
<sourcecode type="abnf7230"><![CDATA[ Range = ranges-specifier <sourcecode type="abnf9110"><![CDATA[ Range = ranges-specifier
]]></sourcecode> ]]></sourcecode>
<t> <t>
A server <bcp14>MAY</bcp14> ignore the Range header field. However, origin se rvers and A server <bcp14>MAY</bcp14> ignore the Range header field. However, origin se rvers and
intermediate caches ought to support byte ranges when possible, since they intermediate caches ought to support byte ranges when possible, since they
support efficient recovery from partially failed transfers and partial support efficient recovery from partially failed transfers and partial
retrieval of large representations. retrieval of large representations.
</t> </t>
<t> <t>
A server <bcp14>MUST</bcp14> ignore a Range header field received with a requ est method A server <bcp14>MUST</bcp14> ignore a Range header field received with a requ est method
which is unrecognized or for which range handling is not defined. For this that is unrecognized or for which range handling is not defined. For this
specification, <xref target="GET" format="none">GET</xref> is the only method for which range handling specification, <xref target="GET" format="none">GET</xref> is the only method for which range handling
is defined. is defined.
</t> </t>
<t> <t>
An origin server <bcp14>MUST</bcp14> ignore a Range header field that contain s a range An origin server <bcp14>MUST</bcp14> ignore a Range header field that contain s a range
unit it does not understand. A proxy <bcp14>MAY</bcp14> discard a Range heade r unit it does not understand. A proxy <bcp14>MAY</bcp14> discard a Range heade r
field that contains a range unit it does not understand. field that contains a range unit it does not understand.
</t> </t>
<t> <t>
A server that supports range requests <bcp14>MAY</bcp14> ignore or reject a A server that supports range requests <bcp14>MAY</bcp14> ignore or reject a
<xref target="field.range" format="none">Range</xref> header field that consi <xref target="field.range" format="none">Range</xref> header field that conta
sts of more than two ins an invalid
overlapping ranges, or a set of many small ranges that are not listed <xref target="rule.ranges-specifier" format="none">ranges-specifier</xref> (<
in ascending order, since both are indications of either a broken client or xref target="range.specifiers"/>),
a deliberate denial-of-service attack (<xref target="overlapping.ranges"/>). a <xref target="rule.ranges-specifier" format="none">ranges-specifier</xref>
with more than two overlapping ranges,
or a set of many small ranges that are not listed in ascending order,
since these are indications of either a broken client or a deliberate
denial-of-service attack (<xref target="overlapping.ranges"/>).
A client <bcp14>SHOULD NOT</bcp14> request multiple ranges that are inherentl y less A client <bcp14>SHOULD NOT</bcp14> request multiple ranges that are inherentl y less
efficient to process and transfer than a single range that encompasses the efficient to process and transfer than a single range that encompasses the
same data. same data.
</t> </t>
<t> <t>
A server that supports range requests <bcp14>MAY</bcp14> ignore a <xref targe t="field.range" format="none">Range</xref> A server that supports range requests <bcp14>MAY</bcp14> ignore a <xref targe t="field.range" format="none">Range</xref>
header field when the selected representation has no content header field when the selected representation has no content
(i.e., the selected representation's data is of zero length). (i.e., the selected representation's data is of zero length).
</t> </t>
<t> <t>
skipping to change at line 7745 skipping to change at line 7757
of the Range header field would be a <xref target="status.200" format="none"> 200 (OK)</xref> response. In of the Range header field would be a <xref target="status.200" format="none"> 200 (OK)</xref> response. In
other words, Range is ignored when a conditional GET would result in a other words, Range is ignored when a conditional GET would result in a
<xref target="status.304" format="none">304 (Not Modified)</xref> response. <xref target="status.304" format="none">304 (Not Modified)</xref> response.
</t> </t>
<t> <t>
The If-Range header field (<xref target="field.if-range"/>) can be used as The If-Range header field (<xref target="field.if-range"/>) can be used as
a precondition to applying the Range header field. a precondition to applying the Range header field.
</t> </t>
<t> <t>
If all of the preconditions are true, the server supports the Range header If all of the preconditions are true, the server supports the Range header
field for the target resource, and the specified range(s) are valid and field for the target resource, the received Range field-value contains a
satisfiable (as defined in <xref target="byte.ranges"/>), the valid <xref target="rule.ranges-specifier" format="none">ranges-specifier</xr
server <bcp14>SHOULD</bcp14> send a <xref target="status.206" format="none">2 ef> with a <xref target="range.units" format="none">range-unit</xref>
06 (Partial Content)</xref> response with a supported for that target resource, and that
content containing one or more partial representations that correspond to <xref target="rule.ranges-specifier" format="none">ranges-specifier</xref> is
the satisfiable ranges requested. <xref target="satisfiable" format="none">satisfiable</xref> with respect
to the selected representation,
the server <bcp14>SHOULD</bcp14> send a <xref target="status.206" format="non
e">206 (Partial Content)</xref> response
with content containing one or more partial representations
that correspond to the satisfiable <xref target="rule.ranges-specifier" forma
t="none">range-spec</xref>(s) requested.
</t> </t>
<t> <t>
The above does not imply that a server will send all requested ranges. The above does not imply that a server will send all requested ranges.
In some cases, it may only be possible (or efficient) to send a portion of In some cases, it may only be possible (or efficient) to send a portion of
the requested ranges first, while expecting the client to re-request the the requested ranges first, while expecting the client to re-request the
remaining portions later if they are still desired remaining portions later if they are still desired
(see <xref target="status.206"/>). (see <xref target="status.206"/>).
</t> </t>
<t> <t>
If all of the preconditions are true, the server supports the Range header If all of the preconditions are true, the server supports the Range header
field for the target resource, and the specified range(s) are invalid or field for the target resource, the received Range field-value contains a
unsatisfiable, the server <bcp14>SHOULD</bcp14> send a valid <xref target="rule.ranges-specifier" format="none">ranges-specifier</xr
ef>, and either the
<xref target="range.units" format="none">range-unit</xref> is not supported f
or that target resource or
the <xref target="rule.ranges-specifier" format="none">ranges-specifier</xref
> is unsatisfiable with respect to
the selected representation, the server <bcp14>SHOULD</bcp14> send a
<xref target="status.416" format="none">416 (Range Not Satisfiable)</xref> re sponse. <xref target="status.416" format="none">416 (Range Not Satisfiable)</xref> re sponse.
</t> </t>
</section> </section>
<section anchor="field.accept-ranges" title="Accept-Ranges"> <section anchor="field.accept-ranges" title="Accept-Ranges">
<iref primary="true" item="Fields" subitem="Accept-Ranges"/> <iref primary="true" item="Fields" subitem="Accept-Ranges"/>
<iref primary="true" item="Header Fields" subitem="Accept-Ranges"/> <iref primary="true" item="Header Fields" subitem="Accept-Ranges"/>
<iref primary="true" item="Accept-Ranges header field"/> <iref primary="true" item="Accept-Ranges header field"/>
<t> <t>
The "Accept-Ranges" field in a response indicates whether an upstream The "Accept-Ranges" field in a response indicates whether an upstream
server supports range requests for the target resource. server supports range requests for the target resource.
</t> </t>
<iref primary="true" item="Grammar" subitem="Accept-Ranges"/> <iref primary="true" item="Grammar" subitem="Accept-Ranges"/>
<iref primary="true" item="Grammar" subitem="acceptable-ranges"/> <iref primary="true" item="Grammar" subitem="acceptable-ranges"/>
<sourcecode type="abnf7230"><![CDATA[ Accept-Ranges = acceptabl e-ranges <sourcecode type="abnf9110"><![CDATA[ Accept-Ranges = acceptabl e-ranges
acceptable-ranges = 1#range-unit acceptable-ranges = 1#range-unit
]]></sourcecode> ]]></sourcecode>
<t> <t>
For example, a server that supports For example, a server that supports
<xref target="byte.ranges">byte-range requests</xref> can send the field <xref target="byte.ranges">byte-range requests</xref> can send the field
</t> </t>
<sourcecode type="http-message"><![CDATA[Accept-Ranges: bytes <sourcecode type="http-message"><![CDATA[Accept-Ranges: bytes
]]></sourcecode> ]]></sourcecode>
<t> <t>
to indicate that it supports byte range requests for that target resource, to indicate that it supports byte range requests for that target resource,
skipping to change at line 7827 skipping to change at line 7845
</section> </section>
<section anchor="field.content-range" title="Content-Range"> <section anchor="field.content-range" title="Content-Range">
<iref primary="true" item="Fields" subitem="Content-Range"/> <iref primary="true" item="Fields" subitem="Content-Range"/>
<iref primary="true" item="Header Fields" subitem="Content-Range"/> <iref primary="true" item="Header Fields" subitem="Content-Range"/>
<iref primary="true" item="Content-Range header field"/> <iref primary="true" item="Content-Range header field"/>
<t> <t>
The "Content-Range" header field is sent in a single part The "Content-Range" header field is sent in a single part
<xref target="status.206" format="none">206 (Partial Content)</xref> response to indicate the partial range <xref target="status.206" format="none">206 (Partial Content)</xref> response to indicate the partial range
of the <xref target="selected.representation" format="none">selected represen tation</xref> enclosed as the message content, sent in of the <xref target="selected.representation" format="none">selected represen tation</xref> enclosed as the message content, sent in
each part of a multipart 206 response to indicate the range enclosed within each part of a multipart 206 response to indicate the range enclosed within
each body part, and sent in <xref target="status.416" format="none">416 (Rang e Not Satisfiable)</xref> each body part (<xref target="multipart.byteranges"/>), and sent in <xref tar get="status.416" format="none">416 (Range Not Satisfiable)</xref>
responses to provide information about the selected representation. responses to provide information about the selected representation.
</t> </t>
<iref primary="true" item="Grammar" subitem="Content-Range"/> <iref primary="true" item="Grammar" subitem="Content-Range"/>
<iref primary="true" item="Grammar" subitem="range-resp"/> <iref primary="true" item="Grammar" subitem="range-resp"/>
<iref primary="true" item="Grammar" subitem="incl-range"/> <iref primary="true" item="Grammar" subitem="incl-range"/>
<iref primary="true" item="Grammar" subitem="unsatisfied-range"/> <iref primary="true" item="Grammar" subitem="unsatisfied-range"/>
<iref primary="true" item="Grammar" subitem="complete-length"/> <iref primary="true" item="Grammar" subitem="complete-length"/>
<iref primary="false" item="Grammar" subitem="first-pos"/> <iref primary="false" item="Grammar" subitem="first-pos"/>
<iref primary="false" item="Grammar" subitem="last-pos"/> <iref primary="false" item="Grammar" subitem="last-pos"/>
<sourcecode type="abnf7230"><![CDATA[ Content-Range = range-u nit SP <sourcecode type="abnf9110"><![CDATA[ Content-Range = range-u nit SP
( range-resp / unsatisfied-range ) ( range-resp / unsatisfied-range )
range-resp = incl-range "/" ( complete-length / "*" ) range-resp = incl-range "/" ( complete-length / "*" )
incl-range = first-pos "-" last-pos incl-range = first-pos "-" last-pos
unsatisfied-range = "*/" complete-length unsatisfied-range = "*/" complete-length
complete-length = 1*DIGIT complete-length = 1*DIGIT
]]></sourcecode> ]]></sourcecode>
<t> <t>
If a <xref target="status.206" format="none">206 (Partial Content)</xref> res ponse contains a If a <xref target="status.206" format="none">206 (Partial Content)</xref> res ponse contains a
skipping to change at line 7975 skipping to change at line 7993
<section anchor="multipart.byteranges" title="Media Type multipart/byte ranges"> <section anchor="multipart.byteranges" title="Media Type multipart/byte ranges">
<iref item="Media Type" subitem="multipart/byteranges" primary="true "/> <iref item="Media Type" subitem="multipart/byteranges" primary="true "/>
<iref item="multipart/byteranges Media Type" primary="true"/> <iref item="multipart/byteranges Media Type" primary="true"/>
<t> <t>
When a <xref target="status.206" format="none">206 (Partial Content)</xref> r esponse message includes the When a <xref target="status.206" format="none">206 (Partial Content)</xref> r esponse message includes the
content of multiple ranges, they are transmitted as body parts in a content of multiple ranges, they are transmitted as body parts in a
multipart message body (<xref target="RFC2046" sectionFormat="comma" section= "5.1"/>) multipart message body (<xref target="RFC2046" sectionFormat="comma" section= "5.1"/>)
with the media type of "multipart/byteranges". with the media type of "multipart/byteranges".
</t> </t>
<t> <t>
The multipart/byteranges media type includes one or more body parts, each The "multipart/byteranges" media type includes one or more body parts, each
with its own <xref target="field.content-type" format="none">Content-Type</xr ef> and <xref target="field.content-range" format="none">Content-Range</xref> with its own <xref target="field.content-type" format="none">Content-Type</xr ef> and <xref target="field.content-range" format="none">Content-Range</xref>
fields. The required boundary parameter specifies the boundary string used fields. The required boundary parameter specifies the boundary string used
to separate each body part. to separate each body part.
</t> </t>
<t> <t>
Implementation Notes: Implementation Notes:
</t> </t>
<ol> <ol>
<li>Additional CRLFs might precede the first boundary string in t he body.</li> <li>Additional CRLFs might precede the first boundary string in t he body.</li>
<li>Although <xref target="RFC2046"/> permits the boundary string to be <li>Although <xref target="RFC2046"/> permits the boundary string to be
quoted, some existing implementations handle a quoted boundary quoted, some existing implementations handle a quoted boundary
string incorrectly.</li> string incorrectly.</li>
<li>A number of clients and servers were coded to an early draft <li>A number of clients and servers were coded to an early draft
of the byteranges specification that used a media type of of the byteranges specification that used a media type of
multipart/x-byteranges<iref item="multipart/x-byteranges Media Type"/> "multipart/x-byteranges"<iref item="multipart/x-byteranges Media Type"/><i
<iref item="Media Type" subitem="multipart/x-byteranges"/>, ref item="Media Type" subitem="multipart/x-byteranges"/>,
which is almost (but not quite) compatible with this type.</li> which is almost (but not quite) compatible with this type.</li>
</ol> </ol>
<t> <t>
Despite the name, the "multipart/byteranges" media type is not limited to Despite the name, the "multipart/byteranges" media type is not limited to
byte ranges. The following example uses an "exampleunit" range unit: byte ranges. The following example uses an "exampleunit" range unit:
</t> </t>
<sourcecode type="http-message"><![CDATA[HTTP/1.1 206 Partial Conten t <sourcecode type="http-message"><![CDATA[HTTP/1.1 206 Partial Conten t
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
skipping to change at line 8018 skipping to change at line 8035
...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--
]]></sourcecode> ]]></sourcecode>
<t> <t>
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.
</t> </t>
<dl> <dl>
<dt>Type name:</dt> <dt>Type name:</dt>
<dd>multipart</dd> <dd>multipart</dd>
<dt>Subtype name:</dt> <dt>Subtype name:</dt>
<dd>byteranges</dd> <dd>byteranges</dd>
<dt>Required parameters:</dt> <dt>Required parameters:</dt>
<dd>boundary</dd> <dd>boundary</dd>
<dt>Optional parameters:</dt> <dt>Optional parameters:</dt>
<dd>N/A</dd> <dd>N/A</dd>
<dt>Encoding considerations:</dt> <dt>Encoding considerations:</dt>
<dd>only "7bit", "8bit", or "binary" are permitted</dd> <dd>only "7bit", "8bit", or "binary" are permitted</dd>
<dt>Security considerations:</dt> <dt>Security considerations:</dt>
<dd>see <xref target="security.considerations"/> <dd>see <xref target="security.considerations"/>
</dd> </dd>
<dt>Interoperability considerations:</dt> <dt>Interoperability considerations:</dt>
<dd>N/A</dd> <dd>N/A</dd>
<dt>Published specification:</dt> <dt>Published specification:</dt>
<dd>This specification (see <xref target="multipart.byteranges"/> ).</dd> <dd>RFC 9110 (see <xref target="multipart.byteranges"/>)</dd>
<dt>Applications that use this media type:</dt> <dt>Applications that use this media type:</dt>
<dd>HTTP components supporting multiple ranges in a single reques t.</dd> <dd>HTTP components supporting multiple ranges in a single reques t</dd>
<dt>Fragment identifier considerations:</dt> <dt>Fragment identifier considerations:</dt>
<dd>N/A</dd> <dd>N/A</dd>
<dt>Additional information:</dt> <dt>Additional information:</dt>
<dd> <dd>
<dl> <dl>
<dt>Deprecated alias names for this type:</dt> <dt>Deprecated alias names for this type:</dt>
<dd>N/A</dd> <dd>N/A</dd>
<dt>Magic number(s):</dt> <dt>Magic number(s):</dt>
<dd>N/A</dd> <dd>N/A</dd>
<dt>File extension(s):</dt> <dt>File extension(s):</dt>
skipping to change at line 8129 skipping to change at line 8146
three-digit integer values outside of that range (i.e., 600..999) for three-digit integer values outside of that range (i.e., 600..999) for
internal communication of non-HTTP status (e.g., library errors). A client internal communication of non-HTTP status (e.g., library errors). A client
that receives a response with an invalid status code <bcp14>SHOULD</bcp14> pr ocess the that receives a response with an invalid status code <bcp14>SHOULD</bcp14> pr ocess the
response as if it had a <xref target="status.5xx" format="none">5xx (Server E rror)</xref> status code. response as if it had a <xref target="status.5xx" format="none">5xx (Server E rror)</xref> status code.
</t> </t>
<t anchor="final.interim"> <t anchor="final.interim">
<iref item="Status Codes" subitem="Final"/> <iref item="Status Codes" subitem="Final"/>
<iref item="Status Codes" subitem="Interim"/> <iref item="Status Codes" subitem="Interim"/>
<iref item="Status Codes" subitem="Informational"/> <iref item="Status Codes" subitem="Informational"/>
A single request can have multiple associated responses: zero or more A single request can have multiple associated responses: zero or more
<em>interim</em> (non-final) responses with status codes in the "interim" (non-final) responses with status codes in the
"informational" (<xref target="status.1xx" format="none">1xx</xref>) range, fo llowed by exactly one "informational" (<xref target="status.1xx" format="none">1xx</xref>) range, fo llowed by exactly one
<em>final</em> response with a status code in one of the other ranges. "final" response with a status code in one of the other ranges.
</t> </t>
<section anchor="overview.of.status.codes" title="Overview of Status Co des"> <section anchor="overview.of.status.codes" title="Overview of Status Co des">
<t> <t>
The status codes listed below are defined in this specification. The status codes listed below are defined in this specification.
The reason phrases listed here are only recommendations — they can be The reason phrases listed here are only recommendations -- they can be
replaced by local equivalents or left out altogether without affecting the replaced by local equivalents or left out altogether without affecting the
protocol. protocol.
</t> </t>
<t> <t>
Responses with status codes that are defined as heuristically cacheable Responses with status codes that are defined as heuristically cacheable
(e.g., 200, 203, 204, 206, 300, 301, 308, 404, 405, 410, 414, and 501 in this (e.g., 200, 203, 204, 206, 300, 301, 308, 404, 405, 410, 414, and 501 in this
specification) can be reused by a cache with heuristic expiration unless specification) can be reused by a cache with heuristic expiration unless
otherwise indicated by the method definition or explicit cache controls otherwise indicated by the method definition or explicit cache controls
<xref target="CACHING"/>; all other status codes are not heuristically cachea ble. <xref target="CACHING"/>; all other status codes are not heuristically cachea ble.
</t> </t>
skipping to change at line 8160 skipping to change at line 8177
within the "Hypertext Transfer Protocol (HTTP) Status Code Registry", within the "Hypertext Transfer Protocol (HTTP) Status Code Registry",
as described in <xref target="status.code.extensibility"/>. as described in <xref target="status.code.extensibility"/>.
</t> </t>
</section> </section>
<section anchor="status.1xx" title="Informational 1xx"> <section anchor="status.1xx" title="Informational 1xx">
<iref primary="true" item="1xx Informational (status code class)"/> <iref primary="true" item="1xx Informational (status code class)"/>
<iref primary="true" <iref primary="true"
item="Status Codes Classes" item="Status Codes Classes"
subitem="1xx Informational"/> subitem="1xx Informational"/>
<t> <t>
The <em>1xx (Informational)</em> class of status code indicates an The 1xx (Informational) class of status code indicates an
interim response for communicating connection status or request progress interim response for communicating connection status or request progress
prior to completing the requested action and sending a final response. prior to completing the requested action and sending a final response.
Since HTTP/1.0 did not define any 1xx status codes, a server <bcp14>MUST NOT< /bcp14> send Since HTTP/1.0 did not define any 1xx status codes, a server <bcp14>MUST NOT< /bcp14> send
a 1xx response to an HTTP/1.0 client. a 1xx response to an HTTP/1.0 client.
</t> </t>
<t> <t>
A 1xx response is terminated by the end of the header section; A 1xx response is terminated by the end of the header section;
it cannot contain content or trailers. it cannot contain content or trailers.
</t> </t>
<t> <t>
skipping to change at line 8185 skipping to change at line 8202
<t> <t>
A proxy <bcp14>MUST</bcp14> forward 1xx responses unless the proxy itself A proxy <bcp14>MUST</bcp14> forward 1xx responses unless the proxy itself
requested the generation of the 1xx response. For example, if a requested the generation of the 1xx response. For example, if a
proxy adds an "Expect: 100-continue" header field when it forwards a request, proxy adds an "Expect: 100-continue" header field when it forwards a request,
then it need not forward the corresponding <xref target="status.100" format=" none">100 (Continue)</xref> then it need not forward the corresponding <xref target="status.100" format=" none">100 (Continue)</xref>
response(s). response(s).
</t> </t>
<section anchor="status.100" title="100 Continue"> <section anchor="status.100" title="100 Continue">
<iref primary="true" item="100 Continue (status code)"/> <iref primary="true" item="100 Continue (status code)"/>
<t> <t>
The <em>100 (Continue)</em> status code indicates that the initial The 100 (Continue) status code indicates that the initial
part of a request has been received and has not yet been rejected by the part of a request has been received and has not yet been rejected by the
server. The server intends to send a final response after the request has server. The server intends to send a final response after the request has
been fully received and acted upon. been fully received and acted upon.
</t> </t>
<t> <t>
When the request contains an <xref target="field.expect" format="none">Expect </xref> header field that When the request contains an <xref target="field.expect" format="none">Expect </xref> header field that
includes a <xref target="field.expect" format="none">100-continue</xref> expe ctation, the 100 response includes a <xref target="field.expect" format="none">100-continue</xref> expe ctation, the 100 response
indicates that the server wishes to receive the request content, indicates that the server wishes to receive the request content,
as described in <xref target="field.expect"/>. The client as described in <xref target="field.expect"/>. The client
ought to continue sending the request and discard the 100 response. ought to continue sending the request and discard the 100 response.
</t> </t>
<t> <t>
If the request did not contain an <xref target="field.expect" format="none">E xpect</xref> header field If the request did not contain an <xref target="field.expect" format="none">E xpect</xref> header field
containing the <xref target="field.expect" format="none">100-continue</xref> expectation, containing the <xref target="field.expect" format="none">100-continue</xref> expectation,
the client can simply discard this interim response. the client can simply discard this interim response.
</t> </t>
</section> </section>
<section anchor="status.101" title="101 Switching Protocols"> <section anchor="status.101" title="101 Switching Protocols">
<iref primary="true" item="101 Switching Protocols (status code)" /> <iref primary="true" item="101 Switching Protocols (status code)" />
<t> <t>
The <em>101 (Switching Protocols)</em> status code indicates that the The 101 (Switching Protocols) status code indicates that the
server understands and is willing to comply with the client's request, server understands and is willing to comply with the client's request,
via the <xref target="field.upgrade" format="none">Upgrade</xref> header fiel d (<xref target="field.upgrade"/>), for via the <xref target="field.upgrade" format="none">Upgrade</xref> header fiel d (<xref target="field.upgrade"/>), for
a change in the application protocol being used on this connection. a change in the application protocol being used on this connection.
The server <bcp14>MUST</bcp14> generate an Upgrade header field in the respon se that The server <bcp14>MUST</bcp14> generate an Upgrade header field in the respon se that
indicates which protocol(s) will be in effect after this response. indicates which protocol(s) will be in effect after this response.
</t> </t>
<t> <t>
It is assumed that the server will only agree to switch protocols when 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 version of it is advantageous to do so. For example, switching to a newer version of
HTTP might be advantageous over older versions, and switching to a HTTP might be advantageous over older versions, and switching to a
real-time, synchronous protocol might be advantageous when delivering real-time, synchronous protocol might be advantageous when delivering
resources that use such features. resources that use such features.
</t> </t>
</section> </section>
</section> </section>
<section anchor="status.2xx" title="Successful 2xx"> <section anchor="status.2xx" title="Successful 2xx">
<iref primary="true" item="2xx Successful (status code class)"/> <iref primary="true" item="2xx Successful (status code class)"/>
<iref primary="true" item="Status Codes Classes" subitem="2xx Succes sful"/> <iref primary="true" item="Status Codes Classes" subitem="2xx Succes sful"/>
<t> <t>
The <em>2xx (Successful)</em> class of status code indicates that The 2xx (Successful) class of status code indicates that
the client's request was successfully received, understood, and accepted. the client's request was successfully received, understood, and accepted.
</t> </t>
<section anchor="status.200" title="200 OK"> <section anchor="status.200" title="200 OK">
<iref primary="true" item="200 OK (status code)"/> <iref primary="true" item="200 OK (status code)"/>
<t> <t>
The <em>200 (OK)</em> status code indicates that the request has The 200 (OK) status code indicates that the request has
succeeded. The content sent in a 200 response depends on the request succeeded. The content sent in a 200 response depends on the request
method. For the methods defined by this specification, the intended meaning method. For the methods defined by this specification, the intended meaning
of the content can be summarized as: of the content can be summarized as:
</t> </t>
<table align="left"> <table align="left">
<thead> <thead>
<tr> <tr>
<th>request method</th> <th>Request Method</th>
<th>response content is a representation of</th> <th>Response content is a representation of:</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td>GET</td> <td>GET</td>
<td>the <xref target="target.resource" format="none">tar get resource</xref> <td>the <xref target="target.resource" format="none">tar get resource</xref>
</td> </td>
</tr> </tr>
<tr> <tr>
<td>HEAD</td> <td>HEAD</td>
skipping to change at line 8279 skipping to change at line 8296
<td>the request message as received by the server return ing the <td>the request message as received by the server return ing the
trace</td> trace</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t> <t>
Aside from responses to CONNECT, a 200 response is expected to contain Aside from responses to CONNECT, a 200 response is expected to contain
message content unless the message framing explicitly indicates that the message content unless the message framing explicitly indicates that the
content has zero length. If some aspect of the request indicates a content has zero length. If some aspect of the request indicates a
preference for no content upon success, the origin server ought to send a preference for no content upon success, the origin server ought to send a
<em>204 (No Content)</em> response instead. 204 (No Content) response instead.
For CONNECT, there is no content because the successful result is a For CONNECT, there is no content because the successful result is a
tunnel, which begins immediately after the 200 response header section. tunnel, which begins immediately after the 200 response header section.
</t> </t>
<t> <t>
A 200 response is heuristically cacheable; i.e., unless otherwise indicated b y A 200 response is heuristically cacheable; i.e., unless otherwise indicated b y
the method definition or explicit cache controls (see <xref target="CACHING" section="4.2.2"/>). the method definition or explicit cache controls (see <xref target="CACHING" section="4.2.2"/>).
</t> </t>
<t> <t>
In 200 responses to GET or HEAD, an origin server <bcp14>SHOULD</bcp14> send any In 200 responses to GET or HEAD, an origin server <bcp14>SHOULD</bcp14> send any
available validator fields (<xref target="response.validator"/>) for the available validator fields (<xref target="response.validator"/>) for the
<xref target="selected.representation" format="none">selected representation< /xref>, with both a strong entity-tag and <xref target="selected.representation" format="none">selected representation< /xref>, with both a strong entity tag and
a <xref target="field.last-modified" format="none">Last-Modified</xref> date being preferred. a <xref target="field.last-modified" format="none">Last-Modified</xref> date being preferred.
</t> </t>
<t> <t>
In 200 responses to state-changing methods, any validator fields In 200 responses to state-changing methods, any validator fields
(<xref target="response.validator"/>) sent in the response convey the (<xref target="response.validator"/>) sent in the response convey the
current validators for the new representation formed as a result of current validators for the new representation formed as a result of
successfully applying the request semantics. Note that the PUT method successfully applying the request semantics. Note that the PUT method
(<xref target="PUT"/>) has additional requirements that might preclude (<xref target="PUT"/>) has additional requirements that might preclude
sending such validators. sending such validators.
</t> </t>
</section> </section>
<section anchor="status.201" title="201 Created"> <section anchor="status.201" title="201 Created">
<iref primary="true" item="201 Created (status code)"/> <iref primary="true" item="201 Created (status code)"/>
<t> <t>
The <em>201 (Created)</em> status code indicates that the request has The 201 (Created) status code indicates that the request has
been fulfilled and has resulted in one or more new resources being created. been fulfilled and has resulted in one or more new resources being created.
The primary resource created by the request is identified by either a The primary resource created by the request is identified by either a
<xref target="field.location" format="none">Location</xref> header field in t he response or, if no <xref target="field.location" format="none">Location</xref> header field in t he response or, if no
<xref target="field.location" format="none">Location</xref> header field is r eceived, by the target URI. <xref target="field.location" format="none">Location</xref> header field is r eceived, by the target URI.
</t> </t>
<t> <t>
The 201 response content typically describes and links to the resource(s) The 201 response content typically describes and links to the resource(s)
created. Any validator fields (<xref target="response.validator"/>) created. Any validator fields (<xref target="response.validator"/>)
sent in the response convey the current validators for a new sent in the response convey the current validators for a new
representation created by the request. Note that the PUT method representation created by the request. Note that the PUT method
(<xref target="PUT"/>) has additional requirements that might preclude (<xref target="PUT"/>) has additional requirements that might preclude
sending such validators. sending such validators.
</t> </t>
</section> </section>
<section anchor="status.202" title="202 Accepted"> <section anchor="status.202" title="202 Accepted">
<iref primary="true" item="202 Accepted (status code)"/> <iref primary="true" item="202 Accepted (status code)"/>
<t> <t>
The <em>202 (Accepted)</em> status code indicates that the request The 202 (Accepted) status code indicates that the request
has been accepted for processing, but the processing has not been has been accepted for processing, but the processing has not been
completed. The request might or might not eventually be acted upon, as it completed. The request might or might not eventually be acted upon, as it
might be disallowed when processing actually takes place. There is no might 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.
</t> </t>
<t> <t>
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 estimate of (or embed) a status monitor that can provide the user with an estimate of
when the request will be fulfilled. when the request will be fulfilled.
</t> </t>
</section> </section>
<section anchor="status.203" title="203 Non-Authoritative Informatio n"> <section anchor="status.203" title="203 Non-Authoritative Informatio n">
<iref primary="true" item="203 Non-Authoritative Information (sta tus code)"/> <iref primary="true" item="203 Non-Authoritative Information (sta tus code)"/>
<t> <t>
The <em>203 (Non-Authoritative Information)</em> status code The 203 (Non-Authoritative Information) status code
indicates that the request was successful but the enclosed content has been indicates that the request was successful but the enclosed content has been
modified from that of the origin server's <xref target="status.200" format="n one">200 (OK)</xref> response modified from that of the origin server's <xref target="status.200" format="n one">200 (OK)</xref> response
by a transforming proxy (<xref target="message.transformations"/>). This stat us code allows the by a transforming proxy (<xref target="message.transformations"/>). This stat us code allows the
proxy to notify recipients when a transformation has been applied, since proxy to notify recipients when a transformation has been applied, since
that knowledge might impact later decisions regarding the content. For that knowledge might impact later decisions regarding the content. For
example, future cache validation requests for the content might only be example, future cache validation requests for the content might only be
applicable along the same request path (through the same proxies). applicable along the same request path (through the same proxies).
</t> </t>
<t> <t>
A 203 response is heuristically cacheable; i.e., unless otherwise indicated b y A 203 response is heuristically cacheable; i.e., unless otherwise indicated b y
the method definition or explicit cache controls (see <xref target="CACHING" section="4.2.2"/>). the method definition or explicit cache controls (see <xref target="CACHING" section="4.2.2"/>).
</t> </t>
</section> </section>
<section anchor="status.204" title="204 No Content"> <section anchor="status.204" title="204 No Content">
<iref primary="true" item="204 No Content (status code)"/> <iref primary="true" item="204 No Content (status code)"/>
<t> <t>
The <em>204 (No Content)</em> status code indicates that the server The 204 (No Content) status code indicates that the server
has successfully fulfilled the request and that there is no additional has 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 <xref target="target.resource" format="none">targe t resource</xref> and its header fields refer to the <xref target="target.resource" format="none">targe t resource</xref> and its
<xref target="selected.representation" format="none">selected representation< /xref> after the requested action was applied. <xref target="selected.representation" format="none">selected representation< /xref> after the requested action was applied.
</t> </t>
<t> <t>
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 <xref target="field.etag" format="none"> ETag</xref> field, then request and the response contains an <xref target="field.etag" format="none"> ETag</xref> field, then
the PUT was successful and the ETag field value contains the entity-tag for the PUT was successful and the ETag field value contains the entity tag for
the new representation of that target resource. the new representation of that target resource.
</t> </t>
<t> <t>
The 204 response allows a server to indicate that the action has been The 204 response allows a server to indicate that the action has been
successfully applied to the target resource, while implying that the successfully applied to the target resource, while implying that the
user agent does not need to traverse away from its current "document view" user agent does not need to traverse away from its current "document view"
(if any). The server assumes that the user agent will provide some (if any). The server assumes that the user agent will provide some
indication of the success to its user, in accord with its own interface, indication of the success to its user, in accord with its own interface,
and apply any new or updated metadata in the response to its active and apply any new or updated metadata in the response to its active
representation. representation.
skipping to change at line 8401 skipping to change at line 8418
it cannot contain content or trailers. it cannot contain content or trailers.
</t> </t>
<t> <t>
A 204 response is heuristically cacheable; i.e., unless otherwise indicated b y A 204 response is heuristically cacheable; i.e., unless otherwise indicated b y
the method definition or explicit cache controls (see <xref target="CACHING" section="4.2.2"/>). the method definition or explicit cache controls (see <xref target="CACHING" section="4.2.2"/>).
</t> </t>
</section> </section>
<section anchor="status.205" title="205 Reset Content"> <section anchor="status.205" title="205 Reset Content">
<iref primary="true" item="205 Reset Content (status code)"/> <iref primary="true" item="205 Reset Content (status code)"/>
<t> <t>
The <em>205 (Reset Content)</em> status code indicates that the The 205 (Reset Content) status code indicates that the
server has fulfilled the request and desires that the user agent reset the server has fulfilled the request and desires that the user agent reset the
"document view", which caused the request to be sent, to its original state "document view", which caused the request to be sent, to its original state
as received from the origin server. as received from the origin server.
</t> </t>
<t> <t>
This response is intended to support a common data entry use case where This response is intended to support a common data entry use case where
the user receives content that supports data entry (a form, notepad, the user receives content that supports data entry (a form, notepad,
canvas, etc.), enters or manipulates data in that space, causes the entered canvas, etc.), enters or manipulates data in that space, causes the entered
data to be submitted in a request, and then the data entry mechanism is data to be submitted in a request, and then the data entry mechanism is
reset for the next entry so that the user can easily initiate another reset for the next entry so that the user can easily initiate another
input action. input action.
</t> </t>
<t> <t>
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 <bcp14>MUST NOT</bcp14> generate content in a 205 response . provided, a server <bcp14>MUST NOT</bcp14> generate content in a 205 response .
</t> </t>
</section> </section>
<section anchor="status.206" title="206 Partial Content"> <section anchor="status.206" title="206 Partial Content">
<iref primary="true" item="206 Partial Content (status code)"/> <iref primary="true" item="206 Partial Content (status code)"/>
<t> <t>
The <em>206 (Partial Content)</em> status code indicates that the The 206 (Partial Content) status code indicates that the
server is successfully fulfilling a range request for the target resource server is successfully fulfilling a range request for the target resource
by transferring one or more parts of the by transferring one or more parts of the
<xref target="selected.representation" format="none">selected representation< /xref>. <xref target="selected.representation" format="none">selected representation< /xref>.
</t> </t>
<t> <t>
A server that supports range requests (<xref target="range.requests"/>) will A server that supports range requests (<xref target="range.requests"/>) will
usually attempt to satisfy all of the requested ranges, since sending usually attempt to satisfy all of the requested ranges, since sending
less data will likely result in another client request for the remainder. less data will likely result in another client request for the remainder.
However, a server might want to send only a subset of the data requested However, a server might want to send only a subset of the data requested
for reasons of its own, such as temporary unavailability, cache efficiency, for reasons of its own, such as temporary unavailability, cache efficiency,
skipping to change at line 8461 skipping to change at line 8478
<t> <t>
A <xref target="field.content-length" format="none">Content-Length</xref> hea der field present in a 206 response A <xref target="field.content-length" format="none">Content-Length</xref> hea der field present in a 206 response
indicates the number of octets in the content of this message, which is indicates the number of octets in the content of this message, which is
usually not the complete length of the selected representation. usually not the complete length of the selected representation.
Each <xref target="field.content-range" format="none">Content-Range</xref> he ader field includes information about the Each <xref target="field.content-range" format="none">Content-Range</xref> he ader field includes information about the
selected representation's complete length. selected representation's complete length.
</t> </t>
<t> <t>
A sender that generates a 206 response to a request with an <xref target="fie ld.if-range" format="none">If-Range</xref> A sender that generates a 206 response to a request with an <xref target="fie ld.if-range" format="none">If-Range</xref>
header field <bcp14>SHOULD NOT</bcp14> generate other representation header header field <bcp14>SHOULD NOT</bcp14> generate other representation header
fields beyond those required, because the client fields beyond those required because the client
already has a prior response containing those header fields. already has a prior response containing those header fields.
Otherwise, a sender <bcp14>MUST</bcp14> generate all of the representation he ader Otherwise, a sender <bcp14>MUST</bcp14> generate all of the representation he ader
fields that would have been sent in a <xref target="status.200" format="none" >200 (OK)</xref> response fields that would have been sent in a <xref target="status.200" format="none" >200 (OK)</xref> response
to the same request. to the same request.
</t> </t>
<t> <t>
A 206 response is heuristically cacheable; i.e., unless otherwise indicated b y A 206 response is heuristically cacheable; i.e., unless otherwise indicated b y
explicit cache controls (see <xref target="CACHING" section="4.2.2"/>). explicit cache controls (see <xref target="CACHING" section="4.2.2"/>).
</t> </t>
<section anchor="partial.single" title="Single Part"> <section anchor="partial.single" title="Single Part">
skipping to change at line 8494 skipping to change at line 8511
... 26012 bytes of partial image data ... ... 26012 bytes of partial image data ...
]]></sourcecode> ]]></sourcecode>
</section> </section>
<section anchor="partial.multipart" title="Multiple Parts"> <section anchor="partial.multipart" title="Multiple Parts">
<t> <t>
If multiple parts are being transferred, the server generating the 206 If multiple parts are being transferred, the server generating the 206
response <bcp14>MUST</bcp14> generate "multipart/byteranges" content, as defi ned response <bcp14>MUST</bcp14> generate "multipart/byteranges" content, as defi ned
in <xref target="multipart.byteranges"/>, and a in <xref target="multipart.byteranges"/>, and a
<xref target="field.content-type" format="none">Content-Type</xref> header fi eld containing the <xref target="field.content-type" format="none">Content-Type</xref> header fi eld containing the
multipart/byteranges media type and its required boundary parameter. "multipart/byteranges" media type and its required boundary parameter.
To avoid confusion with single-part responses, a server <bcp14>MUST NOT</bcp1 4> generate To avoid confusion with single-part responses, a server <bcp14>MUST NOT</bcp1 4> generate
a <xref target="field.content-range" format="none">Content-Range</xref> heade r field in the HTTP header section of a a <xref target="field.content-range" format="none">Content-Range</xref> heade r field in the HTTP header section of a
multiple part response (this field will be sent in each part instead). multiple part response (this field will be sent in each part instead).
</t> </t>
<t> <t>
Within the header area of each body part in the multipart content, the Within the header area of each body part in the multipart content, the
server <bcp14>MUST</bcp14> generate a <xref target="field.content-range" form at="none">Content-Range</xref> header field server <bcp14>MUST</bcp14> generate a <xref target="field.content-range" form at="none">Content-Range</xref> header field
corresponding to the range being enclosed in that body part. corresponding to the range being enclosed in that body part.
If the selected representation would have had a <xref target="field.content-t ype" format="none">Content-Type</xref> If the selected representation would have had a <xref target="field.content-t ype" format="none">Content-Type</xref>
header field in a <xref target="status.200" format="none">200 (OK)</xref> res ponse, the server <bcp14>SHOULD</bcp14> header field in a <xref target="status.200" format="none">200 (OK)</xref> res ponse, the server <bcp14>SHOULD</bcp14>
skipping to change at line 8532 skipping to change at line 8549
...the second range ...the second range
--THIS_STRING_SEPARATES-- --THIS_STRING_SEPARATES--
]]></sourcecode> ]]></sourcecode>
<t> <t>
When multiple ranges are requested, a server <bcp14>MAY</bcp14> coalesce any of the When multiple ranges are requested, a server <bcp14>MAY</bcp14> coalesce any of the
ranges that overlap, or that are separated by a gap that is smaller than the ranges that overlap, or that are separated by a gap that is smaller than the
overhead of sending multiple parts, regardless of the order in which the overhead of sending multiple parts, regardless of the order in which the
corresponding range-spec appeared in the received <xref target="field.range" format="none">Range</xref> corresponding range-spec appeared in the received <xref target="field.range" format="none">Range</xref>
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, it representation's media type and the chosen boundary parameter length, it
can be less efficient to transfer many small disjoint parts than it is to can be less efficient to transfer many small disjoint parts than it is to
transfer the entire selected representation. transfer the entire selected representation.
</t> </t>
<t> <t>
A server <bcp14>MUST NOT</bcp14> generate a multipart response to a request f or a single A server <bcp14>MUST NOT</bcp14> generate a multipart response to a request f or a single
range, since a client that does not request multiple parts might not range, since a client that does not request multiple parts might not
support multipart responses. However, a server <bcp14>MAY</bcp14> generate a support multipart responses. However, a server <bcp14>MAY</bcp14> generate a
multipart/byteranges response with only a single body part if multiple "multipart/byteranges" response with only a single body part if multiple
ranges were requested and only one range was found to be satisfiable or ranges were requested and only one range was found to be satisfiable or
only one range remained after coalescing. only one range remained after coalescing.
A client that cannot process a multipart/byteranges response <bcp14>MUST NOT< /bcp14> A client that cannot process a "multipart/byteranges" response <bcp14>MUST NO T</bcp14>
generate a request that asks for multiple ranges. generate a request that asks for multiple ranges.
</t> </t>
<t> <t>
A server that generates a multipart response <bcp14>SHOULD</bcp14> send A server that generates a multipart response <bcp14>SHOULD</bcp14> send
the parts in the same order that the corresponding range-spec appeared the parts in the same order that the corresponding range-spec appeared
in the received <xref target="field.range" format="none">Range</xref> header field, excluding those ranges in the received <xref target="field.range" format="none">Range</xref> header field, excluding those ranges
that were deemed unsatisfiable or that were coalesced into other ranges. that were deemed unsatisfiable or that were coalesced into other ranges.
A client that receives a multipart response <bcp14>MUST</bcp14> inspect the A client that receives a multipart response <bcp14>MUST</bcp14> inspect the
<xref target="field.content-range" format="none">Content-Range</xref> header field present in each body part in <xref target="field.content-range" format="none">Content-Range</xref> header field present in each body part in
order to determine which range is contained in that body part; a client order to determine which range is contained in that body part; a client
skipping to change at line 8602 skipping to change at line 8619
ranges within the new response and all of the matching stored responses. ranges within the new response and all of the matching stored responses.
If the union consists of the entire range of the representation, then the If the union consists of the entire range of the representation, then the
client <bcp14>MUST</bcp14> process the combined response as if it were a comp lete client <bcp14>MUST</bcp14> process the combined response as if it were a comp lete
<xref target="status.200" format="none">200 (OK)</xref> response, including a <xref target="field.content-length" format="none">Content-Length</xref> <xref target="status.200" format="none">200 (OK)</xref> response, including a <xref target="field.content-length" format="none">Content-Length</xref>
header field that reflects the complete length. header field that reflects the complete length.
Otherwise, the client <bcp14>MUST</bcp14> process the set of continuous range s as one of Otherwise, the client <bcp14>MUST</bcp14> process the set of continuous range s as one of
the following: the following:
an incomplete <xref target="status.200" format="none">200 (OK)</xref> respons e if the combined response is an incomplete <xref target="status.200" format="none">200 (OK)</xref> respons e if the combined response is
a prefix of the representation, a prefix of the representation,
a single <xref target="status.206" format="none">206 (Partial Content)</xref> response containing a single <xref target="status.206" format="none">206 (Partial Content)</xref> response containing
multipart/byteranges content, or "multipart/byteranges" content, or
multiple <xref target="status.206" format="none">206 (Partial Content)</xref> responses, each with one multiple <xref target="status.206" format="none">206 (Partial Content)</xref> responses, each with one
continuous range that is indicated by a <xref target="field.content-range" fo rmat="none">Content-Range</xref> header continuous range that is indicated by a <xref target="field.content-range" fo rmat="none">Content-Range</xref> header
field. field.
</t> </t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="status.3xx" title="Redirection 3xx"> <section anchor="status.3xx" title="Redirection 3xx">
<iref primary="true" item="3xx Redirection (status code class)"/> <iref primary="true" item="3xx Redirection (status code class)"/>
<iref primary="true" <iref primary="true"
item="Status Codes Classes" item="Status Codes Classes"
subitem="3xx Redirection"/> subitem="3xx Redirection"/>
<t> <t>
The <em>3xx (Redirection)</em> class of status code indicates that The 3xx (Redirection) class of status code indicates that
further action needs to be taken by the user agent in order to fulfill the further 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:
</t> </t>
<ol> <ol>
<li> <li>
Redirects that indicate this resource might be available at a Redirects that indicate this resource might be available at a
different URI, as provided by the <xref target="field.location" format="none ">Location</xref> header field, different URI, as provided by the <xref target="field.location" format="none ">Location</xref> header field,
as in the status codes <xref target="status.301" format="none">301 (Moved Pe rmanently)</xref>, as in the status codes <xref target="status.301" format="none">301 (Moved Pe rmanently)</xref>,
<xref target="status.302" format="none">302 (Found)</xref>, <xref target="st atus.307" format="none">307 (Temporary Redirect)</xref>, and <xref target="status.302" format="none">302 (Found)</xref>, <xref target="st atus.307" format="none">307 (Temporary Redirect)</xref>, and
<xref target="status.308" format="none">308 (Permanent Redirect)</xref>. <xref target="status.308" format="none">308 (Permanent Redirect)</xref>.
skipping to change at line 8657 skipping to change at line 8674
and <xref target="status.302" format="none">302 (Found)</xref> were original ly defined as method-preserving and <xref target="status.302" format="none">302 (Found)</xref> were original ly defined as method-preserving
(<xref target="HTTP10" sectionFormat="comma" section="9.3"/>) to match their implementation (<xref target="HTTP10" sectionFormat="comma" section="9.3"/>) to match their implementation
at CERN; <xref target="status.303" format="none">303 (See Other)</xref> was defined for a redirection that at CERN; <xref target="status.303" format="none">303 (See Other)</xref> was defined for a redirection that
changed its method to GET. However, early user agents split on whether to changed its method to GET. However, early user agents split on whether to
redirect POST requests as POST (according to then-current specification) redirect POST requests as POST (according to then-current specification)
or as GET (the safer alternative when redirected to a different site). or as GET (the safer alternative when redirected to a different site).
Prevailing practice eventually converged on changing the method to GET. Prevailing practice eventually converged on changing the method to GET.
<xref target="status.307" format="none">307 (Temporary Redirect)</xref> and <xref target="status.307" format="none">307 (Temporary Redirect)</xref> and
<xref target="status.308" format="none">308 (Permanent Redirect)</xref> <xref target="status.308" format="none">308 (Permanent Redirect)</xref>
<xref target="RFC7538"/> were <xref target="RFC7538"/> were
later added to unambiguously indicate method-preserving redirects, and later added to unambiguously indicate method-preserving redirects, and statu
<xref target="status.301" format="none">301</xref>/<xref target="status.302" s codes
format="none">302</xref> have been adjusted to allow a POST <xref target="status.301" format="none">301</xref> and <xref target="status.
302" format="none">302</xref> have been adjusted to allow a POST
request to be redirected as GET. request to be redirected as GET.
</t> </t>
</aside> </aside>
<t> <t>
If a <xref target="field.location" format="none">Location</xref> header field If a <xref target="field.location" format="none">Location</xref> header field
(<xref target="field.location"/>) is provided, the user agent <bcp14>MAY</bcp 14> (<xref target="field.location"/>) is provided, the user agent <bcp14>MAY</bcp 14>
automatically redirect its request to the URI referenced by the Location automatically redirect its request to the URI referenced by the Location
field value, even if the specific status code is not understood. field value, even if the specific status code is not understood.
Automatic redirection needs to be done with care for methods not known to be Automatic redirection needs to be done with care for methods not known to be
<xref target="safe.methods" format="none">safe</xref>, as defined in <xref ta rget="safe.methods"/>, since <xref target="safe.methods" format="none">safe</xref>, as defined in <xref ta rget="safe.methods"/>, since
skipping to change at line 8697 skipping to change at line 8714
includes: includes:
</t> </t>
<ol> <ol>
<li>Connection-specific header fields (see <xref target="fi eld.connection"/>),</li> <li>Connection-specific header fields (see <xref target="fi eld.connection"/>),</li>
<li>Header fields specific to the client's proxy configurat ion, <li>Header fields specific to the client's proxy configurat ion,
including (but not limited to) <xref target="field.proxy-authorization" f ormat="none">Proxy-Authorization</xref>,</li> including (but not limited to) <xref target="field.proxy-authorization" f ormat="none">Proxy-Authorization</xref>,</li>
<li>Origin-specific header fields (if any), including (but not <li>Origin-specific header fields (if any), including (but not
limited to) <xref target="field.host" format="none">Host</xref>,</li> limited to) <xref target="field.host" format="none">Host</xref>,</li>
<li>Validating header fields that were added by the impleme ntation's <li>Validating header fields that were added by the impleme ntation's
cache (e.g., <xref target="field.if-none-match" format="none">If-None-Mat ch</xref>, cache (e.g., <xref target="field.if-none-match" format="none">If-None-Mat ch</xref>,
<xref target="field.if-modified-since" format="none">If-Modified-Since</x ref>),</li> <xref target="field.if-modified-since" format="none">If-Modified-Since</x ref>), and</li>
<li>Resource-specific header fields, including (but not lim ited to) <li>Resource-specific header fields, including (but not lim ited to)
<xref target="field.referer" format="none">Referer</xref>, Origin, <xref target="field.referer" format="none">Referer</xref>, Origin,
<xref target="field.authorization" format="none">Authorization</xref>, an d Cookie.</li> <xref target="field.authorization" format="none">Authorization</xref>, an d Cookie.</li>
</ol> </ol>
</li> </li>
<li> <li>
<t> <t>
Consider removing header fields that were not automatically generated by t he Consider removing header fields that were not automatically generated by t he
implementation (i.e., those present in the request because they were added implementation (i.e., those present in the request because they were added
by the calling context) where there are security implications; this by the calling context) where there are security implications; this
skipping to change at line 8743 skipping to change at line 8760
<t> <t>
<strong>Note:</strong> An earlier version of this specificatio n recommended a <strong>Note:</strong> An earlier version of this specificatio n recommended a
maximum of five redirections (<xref target="RFC2068" sectionFormat="comma" s ection="10.3"/>). maximum of five redirections (<xref target="RFC2068" sectionFormat="comma" s ection="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.
</t> </t>
</aside> </aside>
<section anchor="status.300" title="300 Multiple Choices"> <section anchor="status.300" title="300 Multiple Choices">
<iref primary="true" item="300 Multiple Choices (status code)"/> <iref primary="true" item="300 Multiple Choices (status code)"/>
<t> <t>
The <em>300 (Multiple Choices)</em> status code indicates that the The 300 (Multiple Choices) status code indicates that the
<xref target="target.resource" format="none">target resource</xref> has more than one representation, each with <xref target="target.resource" format="none">target resource</xref> has more than one representation, each with
its own more specific identifier, and information about the alternatives is its own more specific identifier, and information about the alternatives is
being provided so that the user (or user agent) can select a preferred being 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 engage identifiers. In other words, the server desires that the user agent engage
in reactive negotiation to select the most appropriate representation(s) in reactive negotiation to select the most appropriate representation(s)
for its needs (<xref target="content.negotiation"/>). for its needs (<xref target="content.negotiation"/>).
</t> </t>
<t> <t>
If the server has a preferred choice, the server <bcp14>SHOULD</bcp14> genera te a If the server has a preferred choice, the server <bcp14>SHOULD</bcp14> genera te a
skipping to change at line 8790 skipping to change at line 8807
led to both URI and Alternates (a subsequent proposal) being dropped from led to both URI and Alternates (a subsequent proposal) being dropped from
this specification. It is possible to communicate the list as a this specification. It is possible to communicate the list as a
Link header field value <xref target="RFC8288"/> whose members have a relatio nship of Link header field value <xref target="RFC8288"/> whose members have a relatio nship of
"alternate", though deployment is a chicken-and-egg problem. "alternate", though deployment is a chicken-and-egg problem.
</t> </t>
</aside> </aside>
</section> </section>
<section anchor="status.301" title="301 Moved Permanently"> <section anchor="status.301" title="301 Moved Permanently">
<iref primary="true" item="301 Moved Permanently (status code)"/> <iref primary="true" item="301 Moved Permanently (status code)"/>
<t> <t>
The <em>301 (Moved Permanently)</em> status code indicates that the The 301 (Moved Permanently) status code indicates that the
<xref target="target.resource" format="none">target resource</xref> has been assigned a new permanent URI and <xref target="target.resource" format="none">target resource</xref> has been assigned a new permanent URI and
any future references to this resource ought to use one of the enclosed any future references to this resource ought to use one of the enclosed
URIs. The server is suggesting that a user agent with link-editing capability URIs. The server is suggesting that a user agent with link-editing capability
can permanently replace references to the target URI with one of the can permanently replace references to the target URI with one of the
new references sent by the server. However, this suggestion is usually new references sent by the server. However, this suggestion is usually
ignored unless the user agent is actively editing references ignored unless the user agent is actively editing references
(e.g., engaged in authoring content), the connection is secured, and (e.g., engaged in authoring content), the connection is secured, and
the origin server is a trusted authority for the content being edited. the origin server is a trusted authority for the content being edited.
</t> </t>
<t> <t>
skipping to change at line 8823 skipping to change at line 8840
</t> </t>
</aside> </aside>
<t> <t>
A 301 response is heuristically cacheable; i.e., unless otherwise indicated b y A 301 response is heuristically cacheable; i.e., unless otherwise indicated b y
the method definition or explicit cache controls (see <xref target="CACHING" section="4.2.2"/>). the method definition or explicit cache controls (see <xref target="CACHING" section="4.2.2"/>).
</t> </t>
</section> </section>
<section anchor="status.302" title="302 Found"> <section anchor="status.302" title="302 Found">
<iref primary="true" item="302 Found (status code)"/> <iref primary="true" item="302 Found (status code)"/>
<t> <t>
The <em>302 (Found)</em> status code indicates that the target The 302 (Found) status code indicates that the target
resource resides temporarily under a different URI. Since the redirection resource 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.
</t> </t>
<t> <t>
The server <bcp14>SHOULD</bcp14> generate a <xref target="field.location" for mat="none">Location</xref> header field in the The server <bcp14>SHOULD</bcp14> generate a <xref target="field.location" for mat="none">Location</xref> header field in the
response containing a URI reference for the different URI. response containing a URI reference for the different URI.
The user agent <bcp14>MAY</bcp14> use the Location field value for automatic redirection. The user agent <bcp14>MAY</bcp14> use the Location field value for automatic redirection.
The server's response content usually contains a short hypertext note with The server's response content usually contains a short hypertext note with
a hyperlink to the different URI(s). a hyperlink to the different URI(s).
skipping to change at line 8847 skipping to change at line 8864
<strong>Note:</strong> For historical reasons, a user agent <bcp14>MAY</bcp14> change the <strong>Note:</strong> For historical reasons, a user agent <bcp14>MAY</bcp14> change the
request method from POST to GET for the subsequent request. If this request method from POST to GET for the subsequent request. If this
behavior is undesired, the <xref target="status.307" format="none">307 (Temp orary Redirect)</xref> behavior is undesired, the <xref target="status.307" format="none">307 (Temp orary Redirect)</xref>
status code can be used instead. status code can be used instead.
</t> </t>
</aside> </aside>
</section> </section>
<section anchor="status.303" title="303 See Other"> <section anchor="status.303" title="303 See Other">
<iref primary="true" item="303 See Other (status code)"/> <iref primary="true" item="303 See Other (status code)"/>
<t> <t>
The <em>303 (See Other)</em> 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 URI redirecting the user agent to a different resource, as indicated by a URI
in the <xref target="field.location" format="none">Location</xref> header fie ld, which is intended to provide in the <xref target="field.location" format="none">Location</xref> header fie ld, which is intended to provide
an indirect response to the original request. A user agent can perform a an indirect response to the original request. A user agent can perform a
retrieval request targeting that URI (a GET or HEAD request if using HTTP), retrieval request targeting that URI (a GET or HEAD request if using HTTP),
which might also be redirected, and present the eventual result as an which might also be redirected, and present the eventual result as an
answer to the original request. Note that the new URI in the Location answer to the original request. Note that the new URI in the Location
header field is not considered equivalent to the target URI. header field is not considered equivalent to the target URI.
</t> </t>
<t> <t>
This status code is applicable to any HTTP method. It is This status code is applicable to any HTTP method. It is
skipping to change at line 8884 skipping to change at line 8901
</t> </t>
<t> <t>
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 the response ought to contain a short hypertext note with a hyperlink to the
same URI reference provided in the <xref target="field.location" format="none ">Location</xref> header field. same URI reference provided in the <xref target="field.location" format="none ">Location</xref> header field.
</t> </t>
</section> </section>
<section anchor="status.304" title="304 Not Modified"> <section anchor="status.304" title="304 Not Modified">
<iref primary="true" item="304 Not Modified (status code)"/> <iref primary="true" item="304 Not Modified (status code)"/>
<t> <t>
The <em>304 (Not Modified)</em> status code indicates that a The 304 (Not Modified) status code indicates that a
conditional GET or HEAD request has been conditional GET or HEAD request has been
received and would have resulted in a <xref target="status.200" format="none" >200 (OK)</xref> response received and would have resulted in a <xref target="status.200" format="none" >200 (OK)</xref> response
if it were not for the fact that the condition evaluated to false. if it were not for the fact that the condition evaluated to false.
In other words, there is no need for the server to transfer a In other words, there is no need for the server to transfer a
representation of the target resource because the request indicates that representation of the target resource because the request indicates that
the client, which made the request conditional, already has a valid the client, which made the request conditional, already has a valid
representation; the server is therefore redirecting the client to make representation; the server is therefore redirecting the client to make
use of that stored representation as if it were the content of a use of that stored representation as if it were the content of a
<xref target="status.200" format="none">200 (OK)</xref> response. <xref target="status.200" format="none">200 (OK)</xref> response.
</t> </t>
<t> <t>
The server generating a 304 response <bcp14>MUST</bcp14> generate any of the following The server generating a 304 response <bcp14>MUST</bcp14> generate any of the following
header fields that would have been sent in a <xref target="status.200" format ="none">200 (OK)</xref> header fields that would have been sent in a <xref target="status.200" format ="none">200 (OK)</xref>
response to the same request: response to the same request:
Cache-Control,
<xref target="field.content-location" format="none">Content-Location</xref>,
<xref target="field.date" format="none">Date</xref>,
<xref target="field.etag" format="none">ETag</xref>,
Expires, and
<xref target="field.vary" format="none">Vary</xref>.
</t> </t>
<ul>
<li>
<xref target="field.content-location" format="none">Content
-Location</xref>, <xref target="field.date" format="none">Date</xref>, <xref tar
get="field.etag" format="none">ETag</xref>,
and <xref target="field.vary" format="none">Vary</xref>
</li>
<li>
Cache-Control and Expires (see
<xref target="CACHING"/>)
</li>
</ul>
<t> <t>
Since the goal of a 304 response is to minimize information transfer Since the goal of a 304 response is to minimize information transfer
when the recipient already has one or more cached representations, when the recipient already has one or more cached representations,
a sender <bcp14>SHOULD NOT</bcp14> generate representation metadata other a sender <bcp14>SHOULD NOT</bcp14> generate representation metadata other
than the above listed fields unless said metadata exists for the than the above listed fields unless said metadata exists for the
purpose of guiding cache updates (e.g., <xref target="field.last-modified" fo rmat="none">Last-Modified</xref> might purpose of guiding cache updates (e.g., <xref target="field.last-modified" fo rmat="none">Last-Modified</xref> might
be useful if the response does not have an <xref target="field.etag" format=" none">ETag</xref> field). be useful if the response does not have an <xref target="field.etag" format=" none">ETag</xref> field).
</t> </t>
<t> <t>
Requirements on a cache that receives a 304 response are defined in Requirements on a cache that receives a 304 response are defined in
skipping to change at line 8929 skipping to change at line 8950
304 response to that client. 304 response to that client.
</t> </t>
<t> <t>
A 304 response is terminated by the end of the header section; A 304 response is terminated by the end of the header section;
it cannot contain content or trailers. it cannot contain content or trailers.
</t> </t>
</section> </section>
<section anchor="status.305" title="305 Use Proxy"> <section anchor="status.305" title="305 Use Proxy">
<iref primary="true" item="305 Use Proxy (status code)"/> <iref primary="true" item="305 Use Proxy (status code)"/>
<t> <t>
The <em>305 (Use Proxy)</em> status code was defined in a previous The 305 (Use Proxy) status code was defined in a previous
version of this specification and is now deprecated (<xref target="RFC7231" s ection="B"/>). version of this specification and is now deprecated (<xref target="RFC7231" s ection="B"/>).
</t> </t>
</section> </section>
<section anchor="status.306" title="306 (Unused)"> <section anchor="status.306" title="306 (Unused)">
<iref primary="true" item="306 (Unused) (status code)"/> <iref primary="true" item="306 (Unused) (status code)"/>
<t> <t>
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.
</t> </t>
</section> </section>
<section anchor="status.307" title="307 Temporary Redirect"> <section anchor="status.307" title="307 Temporary Redirect">
<iref primary="true" item="307 Temporary Redirect (status code)"/ > <iref primary="true" item="307 Temporary Redirect (status code)"/ >
<t> <t>
The <em>307 (Temporary Redirect)</em> status code indicates that the The 307 (Temporary Redirect) status code indicates that the
<xref target="target.resource" format="none">target resource</xref> resides t emporarily under a different URI <xref target="target.resource" format="none">target resource</xref> resides t emporarily under a different URI
and the user agent <bcp14>MUST NOT</bcp14> change the request method if it pe rforms an and the user agent <bcp14>MUST NOT</bcp14> change the request method if it pe rforms an
automatic redirection to that URI. automatic redirection to that URI.
Since the redirection can change over time, the client ought to continue Since the redirection can change over time, the client ought to continue
using the original target URI for future requests. using the original target URI for future requests.
</t> </t>
<t> <t>
The server <bcp14>SHOULD</bcp14> generate a <xref target="field.location" for mat="none">Location</xref> header field in the The server <bcp14>SHOULD</bcp14> generate a <xref target="field.location" for mat="none">Location</xref> header field in the
response containing a URI reference for the different URI. response containing a URI reference for the different URI.
The user agent <bcp14>MAY</bcp14> use the Location field value for automatic redirection. The user agent <bcp14>MAY</bcp14> use the Location field value for automatic redirection.
The server's response content usually contains a short hypertext note with The server's response content usually contains a short hypertext note with
a hyperlink to the different URI(s). a hyperlink to the different URI(s).
</t> </t>
</section> </section>
<section anchor="status.308" title="308 Permanent Redirect"> <section anchor="status.308" title="308 Permanent Redirect">
<iref primary="true" item="308 Permanent Redirect (status code)"/ > <iref primary="true" item="308 Permanent Redirect (status code)"/ >
<t> <t>
The <em>308 (Permanent Redirect)</em> status code indicates that the The 308 (Permanent Redirect) status code indicates that the
<xref target="target.resource" format="none">target resource</xref> has been assigned a new permanent URI and <xref target="target.resource" format="none">target resource</xref> has been assigned a new permanent URI and
any future references to this resource ought to use one of the enclosed any future references to this resource ought to use one of the enclosed
URIs. The server is suggesting that a user agent with link-editing capability URIs. The server is suggesting that a user agent with link-editing capability
can permanently replace references to the target URI with one of the can permanently replace references to the target URI with one of the
new references sent by the server. However, this suggestion is usually new references sent by the server. However, this suggestion is usually
ignored unless the user agent is actively editing references ignored unless the user agent is actively editing references
(e.g., engaged in authoring content), the connection is secured, and (e.g., engaged in authoring content), the connection is secured, and
the origin server is a trusted authority for the content being edited. the origin server is a trusted authority for the content being edited.
</t> </t>
<t> <t>
skipping to change at line 8984 skipping to change at line 9005
The user agent <bcp14>MAY</bcp14> use the Location field value for automatic redirection. The user agent <bcp14>MAY</bcp14> use the Location field value for automatic redirection.
The server's response content usually contains a short hypertext note with The server's response content usually contains a short hypertext note with
a hyperlink to the new URI(s). a hyperlink to the new URI(s).
</t> </t>
<t> <t>
A 308 response is heuristically cacheable; i.e., unless otherwise indicated b y A 308 response is heuristically cacheable; i.e., unless otherwise indicated b y
the method definition or explicit cache controls (see <xref target="CACHING" section="4.2.2"/>). the method definition or explicit cache controls (see <xref target="CACHING" section="4.2.2"/>).
</t> </t>
<aside> <aside>
<t> <t>
<strong>Note:</strong> This status code is much younger (Ju ne 2014) than its sibling codes, and thus <strong>Note:</strong> This status code is much younger (Ju ne 2014) than its sibling codes and thus
might not be recognized everywhere. See <xref target="RFC7538" section="4"/> might not be recognized everywhere. See <xref target="RFC7538" section="4"/>
for deployment considerations. for deployment considerations.
</t> </t>
</aside> </aside>
</section> </section>
</section> </section>
<section anchor="status.4xx" title="Client Error 4xx"> <section anchor="status.4xx" title="Client Error 4xx">
<iref primary="true" item="4xx Client Error (status code class)"/> <iref primary="true" item="4xx Client Error (status code class)"/>
<iref primary="true" <iref primary="true"
item="Status Codes Classes" item="Status Codes Classes"
subitem="4xx Client Error"/> subitem="4xx Client Error"/>
<t> <t>
The <em>4xx (Client Error)</em> class of status code indicates that The 4xx (Client Error) class of status code indicates that
the client seems to have erred. Except when responding to a HEAD request, the client seems to have erred. Except when responding to a HEAD request,
the server <bcp14>SHOULD</bcp14> send a representation containing an explanat ion of the server <bcp14>SHOULD</bcp14> send a representation containing an explanat ion of
the error situation, and whether it is a temporary or permanent condition. the error situation, and whether it is a temporary or permanent condition.
These status codes are applicable to any request method. User agents These status codes are applicable to any request method. User agents
<bcp14>SHOULD</bcp14> display any included representation to the user. <bcp14>SHOULD</bcp14> display any included representation to the user.
</t> </t>
<section anchor="status.400" title="400 Bad Request"> <section anchor="status.400" title="400 Bad Request">
<iref primary="true" item="400 Bad Request (status code)"/> <iref primary="true" item="400 Bad Request (status code)"/>
<t> <t>
The <em>400 (Bad Request)</em> status code indicates that the server The 400 (Bad Request) status code indicates that the server
cannot or will not process the request due to something that is perceived cannot or will not process the request due to something that is perceived
to be a client error (e.g., malformed request syntax, invalid request to be a client error (e.g., malformed request syntax, invalid request
message framing, or deceptive request routing). message framing, or deceptive request routing).
</t> </t>
</section> </section>
<section anchor="status.401" title="401 Unauthorized"> <section anchor="status.401" title="401 Unauthorized">
<iref primary="true" item="401 Unauthorized (status code)"/> <iref primary="true" item="401 Unauthorized (status code)"/>
<t> <t>
The <em>401 (Unauthorized)</em> status code indicates that the The 401 (Unauthorized) status code indicates that the
request has not been applied because it lacks valid authentication request has not been applied because it lacks valid authentication
credentials for the target resource. credentials for the target resource.
The server generating a 401 response <bcp14>MUST</bcp14> send a The server generating a 401 response <bcp14>MUST</bcp14> send a
<xref target="field.www-authenticate" format="none">WWW-Authenticate</xref> h eader field <xref target="field.www-authenticate" format="none">WWW-Authenticate</xref> h eader field
(<xref target="field.www-authenticate"/>) (<xref target="field.www-authenticate"/>)
containing at least one challenge applicable to the target resource. containing at least one challenge applicable to the target resource.
</t> </t>
<t> <t>
If the request included authentication credentials, then the 401 response If the request included authentication credentials, then the 401 response
indicates that authorization has been refused for those credentials. indicates that authorization has been refused for those credentials.
skipping to change at line 9038 skipping to change at line 9059
<xref target="field.authorization" format="none">Authorization</xref> header field (<xref target="field.authorization"/>). <xref target="field.authorization" format="none">Authorization</xref> header field (<xref target="field.authorization"/>).
If the 401 response contains the same challenge as the prior response, and If the 401 response contains the same challenge as the prior response, and
the user agent has already attempted authentication at least once, then the the user agent has already attempted authentication at least once, then the
user agent <bcp14>SHOULD</bcp14> present the enclosed representation to the u ser, since user agent <bcp14>SHOULD</bcp14> present the enclosed representation to the u ser, since
it usually contains relevant diagnostic information. it usually contains relevant diagnostic information.
</t> </t>
</section> </section>
<section anchor="status.402" title="402 Payment Required"> <section anchor="status.402" title="402 Payment Required">
<iref primary="true" item="402 Payment Required (status code)"/> <iref primary="true" item="402 Payment Required (status code)"/>
<t> <t>
The <em>402 (Payment Required)</em> status code is reserved for The 402 (Payment Required) status code is reserved for
future use. future use.
</t> </t>
</section> </section>
<section anchor="status.403" title="403 Forbidden"> <section anchor="status.403" title="403 Forbidden">
<iref primary="true" item="403 Forbidden (status code)"/> <iref primary="true" item="403 Forbidden (status code)"/>
<t> <t>
The <em>403 (Forbidden)</em> status code indicates that the The 403 (Forbidden) status code indicates that the
server understood the request but refuses to fulfill it. server understood the request but refuses to fulfill it.
A server that wishes to make public why the request has been forbidden A server that wishes to make public why the request has been forbidden
can describe that reason in the response content (if any). can describe that reason in the response content (if any).
</t> </t>
<t> <t>
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. server considers them insufficient to grant access.
The client <bcp14>SHOULD NOT</bcp14> automatically repeat the request with th e same The client <bcp14>SHOULD NOT</bcp14> automatically repeat the request with th e same
credentials. credentials.
The client <bcp14>MAY</bcp14> repeat the request with new or different creden tials. The client <bcp14>MAY</bcp14> repeat the request with new or different creden tials.
skipping to change at line 9069 skipping to change at line 9090
<t> <t>
An origin server that wishes to "hide" the current existence of a forbidden An origin server that wishes to "hide" the current existence of a forbidden
<xref target="target.resource" format="none">target resource</xref> <xref target="target.resource" format="none">target resource</xref>
<bcp14>MAY</bcp14> instead respond with a status <bcp14>MAY</bcp14> instead respond with a status
code of <xref target="status.404" format="none">404 (Not Found)</xref>. code of <xref target="status.404" format="none">404 (Not Found)</xref>.
</t> </t>
</section> </section>
<section anchor="status.404" title="404 Not Found"> <section anchor="status.404" title="404 Not Found">
<iref primary="true" item="404 Not Found (status code)"/> <iref primary="true" item="404 Not Found (status code)"/>
<t> <t>
The <em>404 (Not Found)</em> status code indicates that the origin The 404 (Not Found) status code indicates that the origin
server did not find a current representation for the server did not find a current representation for the
<xref target="target.resource" format="none">target resource</xref> or is not willing to disclose that one <xref target="target.resource" format="none">target resource</xref> or is not willing to disclose that one
exists. A 404 status code does not indicate whether this lack of representati on exists. A 404 status code does not indicate whether this lack of representati on
is temporary or permanent; the <xref target="status.410" format="none">410 (G one)</xref> status code is is temporary or permanent; the <xref target="status.410" format="none">410 (G one)</xref> status code is
preferred over 404 if the origin server knows, presumably through some preferred over 404 if the origin server knows, presumably through some
configurable means, that the condition is likely to be permanent. configurable means, that the condition is likely to be permanent.
</t> </t>
<t> <t>
A 404 response is heuristically cacheable; i.e., unless otherwise indicated b y A 404 response is heuristically cacheable; i.e., unless otherwise indicated b y
the method definition or explicit cache controls (see <xref target="CACHING" section="4.2.2"/>). the method definition or explicit cache controls (see <xref target="CACHING" section="4.2.2"/>).
</t> </t>
</section> </section>
<section anchor="status.405" title="405 Method Not Allowed"> <section anchor="status.405" title="405 Method Not Allowed">
<iref primary="true" item="405 Method Not Allowed (status code)"/ > <iref primary="true" item="405 Method Not Allowed (status code)"/ >
<t> <t>
The <em>405 (Method Not Allowed)</em> status code indicates that the The 405 (Method Not Allowed) status code indicates that the
method received in the request-line is known by the origin server but method received in the request-line is known by the origin server but
not supported by the <xref target="target.resource" format="none">target reso urce</xref>. not supported by the <xref target="target.resource" format="none">target reso urce</xref>.
The origin server <bcp14>MUST</bcp14> generate an <xref target="field.allow" format="none">Allow</xref> header field in The origin server <bcp14>MUST</bcp14> generate an <xref target="field.allow" format="none">Allow</xref> header field in
a 405 response containing a list of the target resource's currently a 405 response containing a list of the target resource's currently
supported methods. supported methods.
</t> </t>
<t> <t>
A 405 response is heuristically cacheable; i.e., unless otherwise indicated b y A 405 response is heuristically cacheable; i.e., unless otherwise indicated b y
the method definition or explicit cache controls (see <xref target="CACHING" section="4.2.2"/>). the method definition or explicit cache controls (see <xref target="CACHING" section="4.2.2"/>).
</t> </t>
</section> </section>
<section anchor="status.406" title="406 Not Acceptable"> <section anchor="status.406" title="406 Not Acceptable">
<iref primary="true" item="406 Not Acceptable (status code)"/> <iref primary="true" item="406 Not Acceptable (status code)"/>
<t> <t>
The <em>406 (Not Acceptable)</em> status code indicates that the The 406 (Not Acceptable) status code indicates that the
<xref target="target.resource" format="none">target resource</xref> does not have a current representation that <xref target="target.resource" format="none">target resource</xref> does not have a current representation that
would be acceptable to the user agent, according to the would be acceptable to the user agent, according to the
<xref target="proactive.negotiation" format="none">proactive negotiation</xre f> header fields received in the request <xref target="proactive.negotiation" format="none">proactive negotiation</xre f> header fields received in the request
(<xref target="proactive.negotiation"/>), and the server is unwilling to supp ly a (<xref target="proactive.negotiation"/>), and the server is unwilling to supp ly a
default representation. default representation.
</t> </t>
<t> <t>
The server <bcp14>SHOULD</bcp14> generate content containing a list of availa ble The server <bcp14>SHOULD</bcp14> generate content containing a list of availa ble
representation characteristics and corresponding resource identifiers from representation characteristics and corresponding resource identifiers from
which the user or user agent can choose the one most appropriate. which the user or user agent can choose the one most appropriate.
A user agent <bcp14>MAY</bcp14> automatically select the most appropriate cho ice from A user agent <bcp14>MAY</bcp14> automatically select the most appropriate cho ice from
that list. However, this specification does not define any standard for that list. However, this specification does not define any standard for
such automatic selection, as described in <xref target="status.300"/>. such automatic selection, as described in <xref target="status.300"/>.
</t> </t>
</section> </section>
<section anchor="status.407" title="407 Proxy Authentication Require d"> <section anchor="status.407" title="407 Proxy Authentication Require d">
<iref primary="true" item="407 Proxy Authentication Required (sta tus code)"/> <iref primary="true" item="407 Proxy Authentication Required (sta tus code)"/>
<t> <t>
The <em>407 (Proxy Authentication Required)</em> status code is The 407 (Proxy Authentication Required) status code is
similar to <xref target="status.401" format="none">401 (Unauthorized)</xref>, but it indicates that the client similar to <xref target="status.401" format="none">401 (Unauthorized)</xref>, but it indicates that the client
needs to authenticate itself in order to use a proxy for this request. needs to authenticate itself in order to use a proxy for this request.
The proxy <bcp14>MUST</bcp14> send a <xref target="field.proxy-authenticate" format="none">Proxy-Authenticate</xref> header field The proxy <bcp14>MUST</bcp14> send a <xref target="field.proxy-authenticate" format="none">Proxy-Authenticate</xref> header field
(<xref target="field.proxy-authenticate"/>) containing a challenge (<xref target="field.proxy-authenticate"/>) containing a challenge
applicable to that proxy for the request. The client <bcp14>MAY</bcp14> repea t applicable to that proxy for the request. The client <bcp14>MAY</bcp14> repea t
the request with a new or replaced <xref target="field.proxy-authorization" f ormat="none">Proxy-Authorization</xref> the request with a new or replaced <xref target="field.proxy-authorization" f ormat="none">Proxy-Authorization</xref>
header field (<xref target="field.proxy-authorization"/>). header field (<xref target="field.proxy-authorization"/>).
</t> </t>
</section> </section>
<section anchor="status.408" title="408 Request Timeout"> <section anchor="status.408" title="408 Request Timeout">
<iref primary="true" item="408 Request Timeout (status code)"/> <iref primary="true" item="408 Request Timeout (status code)"/>
<t> <t>
The <em>408 (Request Timeout)</em> status code indicates The 408 (Request Timeout) status code indicates
that the server did not receive a complete request message within the time that the server did not receive a complete request message within the time
that it was prepared to wait. that it was prepared to wait.
</t> </t>
<t> <t>
If the client has an outstanding request in transit, it <bcp14>MAY</bcp14> re peat that If the client has an outstanding request in transit, it <bcp14>MAY</bcp14> re peat that
request. If the current connection is not usable (e.g., as it would be in 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 connection will be HTTP/1.1 because request delimitation is lost), a new connection will be
used. used.
</t> </t>
</section> </section>
<section anchor="status.409" title="409 Conflict"> <section anchor="status.409" title="409 Conflict">
<iref primary="true" item="409 Conflict (status code)"/> <iref primary="true" item="409 Conflict (status code)"/>
<t> <t>
The <em>409 (Conflict)</em> status code indicates that the request The 409 (Conflict) status code indicates that the request
could not be completed due to a conflict with the current state of the target could not 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 able to resource. This code is used in situations where the user might be able to
resolve the conflict and resubmit the request. The server <bcp14>SHOULD</bcp1 4> generate resolve the conflict and resubmit the request. The server <bcp14>SHOULD</bcp1 4> generate
content that includes enough information for a user to recognize the content that includes enough information for a user to recognize the
source of the conflict. source of the conflict.
</t> </t>
<t> <t>
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 PUT example, if versioning were being used and the representation being PUT
included changes to a resource that conflict with those made by an included changes to a resource that conflict with those made by an
earlier (third-party) request, the origin server might use a 409 response earlier (third-party) request, the origin server might use a 409 response
to indicate that it can't complete the request. In this case, the response to indicate that it can't complete the request. In this case, the response
representation would likely contain information useful for merging the representation would likely contain information useful for merging the
differences based on the revision history. differences based on the revision history.
</t> </t>
</section> </section>
<section anchor="status.410" title="410 Gone"> <section anchor="status.410" title="410 Gone">
<iref primary="true" item="410 Gone (status code)"/> <iref primary="true" item="410 Gone (status code)"/>
<t> <t>
The <em>410 (Gone)</em> status code indicates that access to the The 410 (Gone) status code indicates that access to the
<xref target="target.resource" format="none">target resource</xref> is no lon ger available at the origin <xref target="target.resource" format="none">target resource</xref> is no lon ger available at the origin
server and that this condition is likely to be permanent. If the origin server and that this condition is likely to be permanent. If the origin
server does not know, or has no facility to determine, whether or not the server does not know, or has no facility to determine, whether or not the
condition is permanent, the status code <xref target="status.404" format="non e">404 (Not Found)</xref> condition is permanent, the status code <xref target="status.404" format="non e">404 (Not Found)</xref>
ought to be used instead. ought to be used instead.
</t> </t>
<t> <t>
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 for remote links to that resource be removed. Such an event is common for
limited-time, promotional services and for resources belonging to limited-time, promotional services and for resources belonging to
individuals no longer associated with the origin server's site. It is not individuals no longer associated with the origin server's site. It is not
necessary to mark all permanently unavailable resources as "gone" or necessary to mark all permanently unavailable resources as "gone" or
to keep the mark for any length of time — that is left to the to keep the mark for any length of time -- that is left to the
discretion of the server owner. discretion of the server owner.
</t> </t>
<t> <t>
A 410 response is heuristically cacheable; i.e., unless otherwise indicated b y A 410 response is heuristically cacheable; i.e., unless otherwise indicated b y
the method definition or explicit cache controls (see <xref target="CACHING" section="4.2.2"/>). the method definition or explicit cache controls (see <xref target="CACHING" section="4.2.2"/>).
</t> </t>
</section> </section>
<section anchor="status.411" title="411 Length Required"> <section anchor="status.411" title="411 Length Required">
<iref primary="true" item="411 Length Required (status code)"/> <iref primary="true" item="411 Length Required (status code)"/>
<t> <t>
The <em>411 (Length Required)</em> status code indicates that the The 411 (Length Required) status code indicates that the
server refuses to accept the request without a defined server refuses to accept the request without a defined
<xref target="field.content-length" format="none">Content-Length</xref> (<xre f target="field.content-length"/>). <xref target="field.content-length" format="none">Content-Length</xref> (<xre f target="field.content-length"/>).
The client <bcp14>MAY</bcp14> repeat the request if it adds a valid Content-L ength The client <bcp14>MAY</bcp14> repeat the request if it adds a valid Content-L ength
header field containing the length of the request content. header field containing the length of the request content.
</t> </t>
</section> </section>
<section anchor="status.412" title="412 Precondition Failed"> <section anchor="status.412" title="412 Precondition Failed">
<iref primary="true" item="412 Precondition Failed (status code)" /> <iref primary="true" item="412 Precondition Failed (status code)" />
<t> <t>
The <em>412 (Precondition Failed)</em> status code indicates that one The 412 (Precondition Failed) status code indicates that one
or more conditions given in the request header fields evaluated to false or more conditions given in the request header fields evaluated to false
when tested on the server (<xref target="conditional.requests"/>). This when tested on the server (<xref target="conditional.requests"/>). This
response status code allows the client to place preconditions on the response status code allows the client to place preconditions on the
current resource state (its current representations and metadata) and, current resource state (its current representations and metadata) and,
thus, prevent the request method from being applied if the target resource thus, prevent the request method from being applied if the target resource
is in an unexpected state. is in an unexpected state.
</t> </t>
</section> </section>
<section anchor="status.413" title="413 Content Too Large"> <section anchor="status.413" title="413 Content Too Large">
<iref primary="true" item="413 Content Too Large (status code)"/> <iref primary="true" item="413 Content Too Large (status code)"/>
<t> <t>
The <em>413 (Content Too Large)</em> status code indicates The 413 (Content Too Large) status code indicates
that the server is refusing to process a request because the request that the server is refusing to process a request because the request
content is larger than the server is willing or able to process. content is larger than the server is willing or able to process.
The server <bcp14>MAY</bcp14> terminate the request, if the protocol version in use The server <bcp14>MAY</bcp14> terminate the request, if the protocol version in use
allows it; otherwise, the server <bcp14>MAY</bcp14> close the connection. allows it; otherwise, the server <bcp14>MAY</bcp14> close the connection.
</t> </t>
<t> <t>
If the condition is temporary, the server <bcp14>SHOULD</bcp14> generate a If the condition is temporary, the server <bcp14>SHOULD</bcp14> generate a
<xref target="field.retry-after" format="none">Retry-After</xref> header fiel d to indicate that it is temporary <xref target="field.retry-after" format="none">Retry-After</xref> header fiel d to indicate that it is temporary
and after what time the client <bcp14>MAY</bcp14> try again. and after what time the client <bcp14>MAY</bcp14> try again.
</t> </t>
</section> </section>
<section anchor="status.414" title="414 URI Too Long"> <section anchor="status.414" title="414 URI Too Long">
<iref primary="true" item="414 URI Too Long (status code)"/> <iref primary="true" item="414 URI Too Long (status code)"/>
<t> <t>
The <em>414 (URI Too Long)</em> status code indicates that the server The 414 (URI Too Long) status code indicates that the server
is refusing to service the request because the is refusing to service the request because the
target URI is longer than the server is willing to target URI is longer than the server is willing to
interpret. This rare condition is only likely to occur when a client has interpret. This rare condition is only likely to occur when a client has
improperly converted a POST request to a GET request with long query improperly converted a POST request to a GET request with long query
information, when the client has descended into a "black hole" of information, when the client has descended into an infinite loop of
redirection (e.g., a redirected URI prefix that points to a suffix of redirection (e.g., a redirected URI prefix that points to a suffix of
itself) or when the server is under attack by a client attempting to itself) or when the server is under attack by a client attempting to
exploit potential security holes. exploit potential security holes.
</t> </t>
<t> <t>
A 414 response is heuristically cacheable; i.e., unless otherwise indicated b y A 414 response is heuristically cacheable; i.e., unless otherwise indicated b y
the method definition or explicit cache controls (see <xref target="CACHING" section="4.2.2"/>). the method definition or explicit cache controls (see <xref target="CACHING" section="4.2.2"/>).
</t> </t>
</section> </section>
<section anchor="status.415" title="415 Unsupported Media Type"> <section anchor="status.415" title="415 Unsupported Media Type">
<iref primary="true" item="415 Unsupported Media Type (status cod e)"/> <iref primary="true" item="415 Unsupported Media Type (status cod e)"/>
<t> <t>
The <em>415 (Unsupported Media Type)</em> status code indicates that The 415 (Unsupported Media Type) status code indicates that
the origin server is refusing to service the request because the content is the origin server is refusing to service the request because the content is
in a format not supported by this method on the <xref target="target.resource " format="none">target resource</xref>. in a format not supported by this method on the <xref target="target.resource " format="none">target resource</xref>.
</t> </t>
<t> <t>
The format problem might be due to the request's indicated The format problem might be due to the request's indicated
<xref target="field.content-type" format="none">Content-Type</xref> or <xref target="field.content-encoding" format="none">Content-Encoding</xref>, or as a <xref target="field.content-type" format="none">Content-Type</xref> or <xref target="field.content-encoding" format="none">Content-Encoding</xref>, or as a
result of inspecting the data directly. result of inspecting the data directly.
</t> </t>
<t> <t>
If the problem was caused by an unsupported content coding, the If the problem was caused by an unsupported content coding, the
<xref target="field.accept-encoding" format="none">Accept-Encoding</xref> res ponse header field <xref target="field.accept-encoding" format="none">Accept-Encoding</xref> res ponse header field
(<xref target="field.accept-encoding"/>) ought to be (<xref target="field.accept-encoding"/>) ought to be
used to indicate what (if any) content codings would have been accepted used to indicate which (if any) content codings would have been accepted
in the request. in the request.
</t> </t>
<t> <t>
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
<xref target="field.accept" format="none">Accept</xref> response header field (<xref target="field.accept"/>) <xref target="field.accept" format="none">Accept</xref> response header field (<xref target="field.accept"/>)
can be used to indicate what media types would have been accepted can be used to indicate which media types would have been accepted
in the request. in the request.
</t> </t>
</section> </section>
<section anchor="status.416" title="416 Range Not Satisfiable"> <section anchor="status.416" title="416 Range Not Satisfiable">
<iref primary="true" item="416 Range Not Satisfiable (status code )"/> <iref primary="true" item="416 Range Not Satisfiable (status code )"/>
<t> <t>
The <em>416 (Range Not Satisfiable)</em> status code indicates that The 416 (Range Not Satisfiable) status code indicates that
the set of ranges in the request's <xref target="field.range" format="none">R ange</xref> header field the set of ranges in the request's <xref target="field.range" format="none">R ange</xref> header field
(<xref target="field.range"/>) has been rejected either because none of (<xref target="field.range"/>) has been rejected either because none of
the requested ranges are satisfiable or because the client has requested the requested ranges are satisfiable or because the client has requested
an excessive number of small or overlapping ranges (a potential denial of an excessive number of small or overlapping ranges (a potential denial of
service attack). service attack).
</t> </t>
<t> <t>
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, <xref target="byte.ranges"/> defines what makes satisfiable. For example, <xref target="byte.ranges"/> defines what makes
a bytes range set satisfiable. a bytes range set satisfiable.
skipping to change at line 9315 skipping to change at line 9336
might not stop making an invalid range request until they have received might not stop making an invalid range request until they have received
a complete representation. Thus, clients cannot depend on receiving a a complete representation. Thus, clients cannot depend on receiving a
<xref target="status.416" format="none">416 (Range Not Satisfiable)</xref> r esponse even when it is most <xref target="status.416" format="none">416 (Range Not Satisfiable)</xref> r esponse even when it is most
appropriate. appropriate.
</t> </t>
</aside> </aside>
</section> </section>
<section anchor="status.417" title="417 Expectation Failed"> <section anchor="status.417" title="417 Expectation Failed">
<iref primary="true" item="417 Expectation Failed (status code)"/ > <iref primary="true" item="417 Expectation Failed (status code)"/ >
<t> <t>
The <em>417 (Expectation Failed)</em> status code indicates that the The 417 (Expectation Failed) status code indicates that the
expectation given in the request's <xref target="field.expect" format="none"> Expect</xref> header field expectation given in the request's <xref target="field.expect" format="none"> Expect</xref> header field
(<xref target="field.expect"/>) could not be met by at least one of the (<xref target="field.expect"/>) could not be met by at least one of the
inbound servers. inbound servers.
</t> </t>
</section> </section>
<section anchor="status.418" title="418 (Unused)"> <section anchor="status.418" title="418 (Unused)">
<iref primary="true" item="418 (Unused) (status code)"/> <iref primary="true" item="418 (Unused) (status code)"/>
<t> <t>
<xref target="RFC2324"/> was an April 1 RFC that lampooned the <xref target="RFC2324"/> was an April 1 RFC that lampooned the
various various ways
ways HTTP was abused; one such abuse was the definition of an HTTP was abused; one such abuse was the definition of an
application-specific 418 status code. In the intervening years, this application-specific 418 status code, which has been deployed as a joke
status code has been widely implemented as an "Easter Egg", and therefore often enough for the code to be unusable for any future use.
is effectively consumed by this use.
</t> </t>
<t> <t>
Therefore, the 418 status code is reserved in the IANA HTTP Status Code Therefore, the 418 status code is reserved in the IANA HTTP Status Code
Registry. This indicates that the status code cannot be assigned to other Registry. This indicates that the status code cannot be assigned to other
applications currently. If future circumstances require its use (e.g., applications currently. If future circumstances require its use (e.g.,
exhaustion of 4NN status codes), it can be re-assigned to another use. exhaustion of 4NN status codes), it can be re-assigned to another use.
</t> </t>
</section> </section>
<section anchor="status.421" title="421 Misdirected Request"> <section anchor="status.421" title="421 Misdirected Request">
<iref primary="true" item="421 Misdirected Request (status code)" /> <iref primary="true" item="421 Misdirected Request (status code)" />
skipping to change at line 9365 skipping to change at line 9385
<t> <t>
A proxy <bcp14>MUST NOT</bcp14> generate a 421 response. A proxy <bcp14>MUST NOT</bcp14> generate a 421 response.
</t> </t>
</section> </section>
<section anchor="status.422" title="422 Unprocessable Content"> <section anchor="status.422" title="422 Unprocessable Content">
<iref primary="true" item="422 Unprocessable Content (status code )"/> <iref primary="true" item="422 Unprocessable Content (status code )"/>
<t> <t>
The 422 (Unprocessable Content) status code indicates that the server The 422 (Unprocessable Content) status code indicates that the server
understands the content type of the request content (hence a understands the content type of the request content (hence a
<xref target="status.415" format="none">415 (Unsupported Media Type)</xref> s tatus code is inappropriate), <xref target="status.415" format="none">415 (Unsupported Media Type)</xref> s tatus code is inappropriate),
and the syntax of the request content is correct, but was unable to process and the syntax of the request content is correct, but it was unable to proces s
the contained instructions. For example, this status code can be sent if the contained instructions. For example, this status code can be sent if
an XML request content contains well-formed (i.e., syntactically correct), bu t an XML request content contains well-formed (i.e., syntactically correct), bu t
semantically erroneous XML instructions. semantically erroneous XML instructions.
</t> </t>
</section> </section>
<section anchor="status.426" title="426 Upgrade Required"> <section anchor="status.426" title="426 Upgrade Required">
<iref primary="true" item="426 Upgrade Required (status code)"/> <iref primary="true" item="426 Upgrade Required (status code)"/>
<t> <t>
The <em>426 (Upgrade Required)</em> status code indicates that the The 426 (Upgrade Required) status code indicates that the
server refuses to perform the request using the current protocol but might server refuses to perform the request using the current protocol but might
be willing to do so after the client upgrades to a different protocol. be willing to do so after the client upgrades to a different protocol.
The server <bcp14>MUST</bcp14> send an <xref target="field.upgrade" format="n one">Upgrade</xref> header field in a 426 The server <bcp14>MUST</bcp14> send an <xref target="field.upgrade" format="n one">Upgrade</xref> header field in a 426
response to indicate the required protocol(s) (<xref target="field.upgrade"/> ). response to indicate the required protocol(s) (<xref target="field.upgrade"/> ).
</t> </t>
<t> <t>
Example: Example:
</t> </t>
<sourcecode type="http-message"><![CDATA[HTTP/1.1 426 Upgrade Req uired <sourcecode type="http-message"><![CDATA[HTTP/1.1 426 Upgrade Req uired
Upgrade: HTTP/3.0 Upgrade: HTTP/3.0
skipping to change at line 9399 skipping to change at line 9419
This service requires use of the HTTP/3.0 protocol. This service requires use of the HTTP/3.0 protocol.
]]></sourcecode> ]]></sourcecode>
</section> </section>
</section> </section>
<section anchor="status.5xx" title="Server Error 5xx"> <section anchor="status.5xx" title="Server Error 5xx">
<iref primary="true" item="5xx Server Error (status code class)"/> <iref primary="true" item="5xx Server Error (status code class)"/>
<iref primary="true" <iref primary="true"
item="Status Codes Classes" item="Status Codes Classes"
subitem="5xx Server Error"/> subitem="5xx Server Error"/>
<t> <t>
The <em>5xx (Server Error)</em> class of status code indicates that The 5xx (Server Error) class of status code indicates that
the server is aware that it has erred or is incapable of performing the the server is aware that it has erred or is incapable of performing the
requested method. requested method.
Except when responding to a HEAD request, the server <bcp14>SHOULD</bcp14> se nd a Except when responding to a HEAD request, the server <bcp14>SHOULD</bcp14> se nd a
representation containing an explanation of the error situation, and representation containing an explanation of the error situation, and
whether it is a temporary or permanent condition. whether it is a temporary or permanent condition.
A user agent <bcp14>SHOULD</bcp14> display any included representation to the user. A user agent <bcp14>SHOULD</bcp14> display any included representation to the user.
These response codes are applicable to any request method. These status codes are applicable to any request method.
</t> </t>
<section anchor="status.500" title="500 Internal Server Error"> <section anchor="status.500" title="500 Internal Server Error">
<iref primary="true" item="500 Internal Server Error (status code )"/> <iref primary="true" item="500 Internal Server Error (status code )"/>
<t> <t>
The <em>500 (Internal Server Error)</em> status code indicates that The 500 (Internal Server Error) status code indicates that
the server encountered an unexpected condition that prevented it from the server encountered an unexpected condition that prevented it from
fulfilling the request. fulfilling the request.
</t> </t>
</section> </section>
<section anchor="status.501" title="501 Not Implemented"> <section anchor="status.501" title="501 Not Implemented">
<iref primary="true" item="501 Not Implemented (status code)"/> <iref primary="true" item="501 Not Implemented (status code)"/>
<t> <t>
The <em>501 (Not Implemented)</em> status code indicates that the The 501 (Not Implemented) status code indicates that the
server does not support the functionality required to fulfill the request. server does not support the functionality required to fulfill the request.
This is the appropriate response when the server does not recognize the This is the appropriate response when the server does not recognize the
request method and is not capable of supporting it for any resource. request method and is not capable of supporting it for any resource.
</t> </t>
<t> <t>
A 501 response is heuristically cacheable; i.e., unless otherwise indicated b y A 501 response is heuristically cacheable; i.e., unless otherwise indicated b y
the method definition or explicit cache controls (see <xref target="CACHING" section="4.2.2"/>). the method definition or explicit cache controls (see <xref target="CACHING" section="4.2.2"/>).
</t> </t>
</section> </section>
<section anchor="status.502" title="502 Bad Gateway"> <section anchor="status.502" title="502 Bad Gateway">
<iref primary="true" item="502 Bad Gateway (status code)"/> <iref primary="true" item="502 Bad Gateway (status code)"/>
<t> <t>
The <em>502 (Bad Gateway)</em> status code indicates that the server, The 502 (Bad Gateway) status code indicates that the server,
while acting as a gateway or proxy, received an invalid response from an while 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.
</t> </t>
</section> </section>
<section anchor="status.503" title="503 Service Unavailable"> <section anchor="status.503" title="503 Service Unavailable">
<iref primary="true" item="503 Service Unavailable (status code)" /> <iref primary="true" item="503 Service Unavailable (status code)" />
<t> <t>
The <em>503 (Service Unavailable)</em> status code indicates that the The 503 (Service Unavailable) status code indicates that the
server is currently unable to handle the request due to a temporary overload server is currently unable to handle the request due to a temporary overload
or scheduled maintenance, which will likely be alleviated after some delay. or scheduled maintenance, which will likely be alleviated after some delay.
The server <bcp14>MAY</bcp14> send a <xref target="field.retry-after" format= "none">Retry-After</xref> header field The server <bcp14>MAY</bcp14> send a <xref target="field.retry-after" format= "none">Retry-After</xref> header field
(<xref target="field.retry-after"/>) to suggest an appropriate (<xref target="field.retry-after"/>) to suggest an appropriate
amount of time for the client to wait before retrying the request. amount of time for the client to wait before retrying the request.
</t> </t>
<aside> <aside>
<t> <t>
<strong>Note:</strong> The existence of the 503 status code does not imply that a <strong>Note:</strong> The existence of the 503 status code does not imply that a
server has to use it when becoming overloaded. Some servers might server has to use it when becoming overloaded. Some servers might
simply refuse the connection. simply refuse the connection.
</t> </t>
</aside> </aside>
</section> </section>
<section anchor="status.504" title="504 Gateway Timeout"> <section anchor="status.504" title="504 Gateway Timeout">
<iref primary="true" item="504 Gateway Timeout (status code)"/> <iref primary="true" item="504 Gateway Timeout (status code)"/>
<t> <t>
The <em>504 (Gateway Timeout)</em> status code indicates that the The 504 (Gateway Timeout) status code indicates that the
server, while acting as a gateway or proxy, did not receive a timely server, while acting as a gateway or proxy, did not receive a timely
response from an upstream server it needed to access in order to response from an upstream server it needed to access in order to
complete the request. complete the request.
</t> </t>
</section> </section>
<section anchor="status.505" title="505 HTTP Version Not Supported"> <section anchor="status.505" title="505 HTTP Version Not Supported">
<iref primary="true" item="505 HTTP Version Not Supported (status code)"/> <iref primary="true" item="505 HTTP Version Not Supported (status code)"/>
<t> <t>
The <em>505 (HTTP Version Not Supported)</em> status code indicates The 505 (HTTP Version Not Supported) status code indicates
that the server does not support, or refuses to support, the major version that the server does not support, or refuses to support, the major version
of HTTP that was used in the request message. The server is indicating that of 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 major it is unable or unwilling to complete the request using the same major
version as the client, as described in <xref target="protocol.version"/>, oth er than with this version as the client, as described in <xref target="protocol.version"/>, oth er than with this
error message. The server <bcp14>SHOULD</bcp14> generate a representation for the 505 error message. The server <bcp14>SHOULD</bcp14> generate a representation for the 505
response that describes why that version is not supported and what other response that describes why that version is not supported and what other
protocols are supported by that server. protocols are supported by that server.
</t> </t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="extending" title="Extending HTTP"> <section anchor="extending" title="Extending HTTP">
<t> <t>
HTTP defines a number of generic extension points that can be used to HTTP defines a number of generic extension points that can be used to
introduce capabilities to the protocol without introducing a new version, introduce capabilities to the protocol without introducing a new version,
including methods, status codes, field names, and further extensibility including methods, status codes, field names, and further extensibility
points within defined fields, such as authentication schemes and points within defined fields, such as authentication schemes and
cache-directives (see Cache-Control extensions in <xref target="CACHING" sect ion="5.2.3"/>). Because the semantics of HTTP are cache directives (see Cache-Control extensions in <xref target="CACHING" sect ion="5.2.3"/>). Because the semantics of HTTP are
not versioned, these extension points are persistent; the version of the not versioned, these extension points are persistent; the version of the
protocol in use does not affect their semantics. protocol in use does not affect their semantics.
</t> </t>
<t> <t>
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 this is interacting with the specific version of the protocol in use. When this is
unavoidable, careful consideration needs to be given to how the extension unavoidable, careful consideration needs to be given to how the extension
can interoperate across versions. can interoperate across versions.
</t> </t>
<t> <t>
Additionally, specific versions of HTTP might have their own extensibility Additionally, specific versions of HTTP might have their own extensibility
points, such as transfer-codings in HTTP/1.1 (<xref target="HTTP11" section=" points, such as transfer codings in HTTP/1.1 (<xref target="HTTP11" section="
6.1"/>) and HTTP/2 (<xref target="HTTP2"/>) 6.1"/>) and HTTP/2 SETTINGS or frame types
SETTINGS or frame types. These extension points are specific to the (<xref target="HTTP2"/>). These extension points are specific to the
version of the protocol they occur within. version of the protocol they occur within.
</t> </t>
<t> <t>
Version-specific extensions cannot override or modify the semantics of Version-specific extensions cannot override or modify the semantics of
a version-independent mechanism or extension point (like a method or a version-independent mechanism or extension point (like a method or
header field) without explicitly being allowed by that protocol element. For header field) without explicitly being allowed by that protocol element. For
example, the CONNECT method (<xref target="CONNECT"/>) allows this. example, the CONNECT method (<xref target="CONNECT"/>) allows this.
</t> </t>
<t> <t>
These guidelines assure that the protocol operates correctly and These guidelines assure that the protocol operates correctly and
skipping to change at line 9638 skipping to change at line 9658
The definition of a new status code ought to explain the request The definition of a new status code ought to explain the request
conditions that would cause a response containing that status code (e.g., conditions that would cause a response containing that status code (e.g.,
combinations of request header fields and/or method(s)) along with any combinations of request header fields and/or method(s)) along with any
dependencies on response header fields (e.g., what fields are required, dependencies on response header fields (e.g., what fields are required,
what fields can modify the semantics, and what field semantics are what fields can modify the semantics, and what field semantics are
further refined when used with the new status code). further refined when used with the new status code).
</t> </t>
<t> <t>
By default, a status code applies only to the request corresponding to the By default, a status code applies only to the request corresponding to the
response it occurs within. If a status code applies to a larger scope of response it occurs within. If a status code applies to a larger scope of
applicability — for example, all requests to the resource in question, or applicability -- for example, all requests to the resource in question or
all requests to a server — this must be explicitly specified. When doing all requests to a server -- this must be explicitly specified. When doing
so, it should be noted that not all clients can be expected to so, it should be noted that not all clients can be expected to
consistently apply a larger scope, because they might not understand the consistently apply a larger scope because they might not understand the
new status code. new status code.
</t> </t>
<t> <t>
The definition of a new final status code ought to specify whether or not it The definition of a new final status code ought to specify whether or not it
is is heuristically cacheable. Note that any response with a final status code
heuristically cacheable. Note that all final status codes can be cached if th can be cached if the response has explicit freshness information. A status
e response they code defined as heuristically cacheable is allowed to be cached without
occur in has explicit freshness information; however, those status codes that explicit freshness information.
are Likewise, the definition of a status code can place
defined as being heuristically cacheable are allowed to be cached without exp constraints upon cache behavior if the must-understand cache
licit directive is used. See <xref target="CACHING"/> for more information.
freshness information. Likewise, the definition of a status code can place
constraints upon cache behavior, if the 'must-understand' cache directive is
used. See <xref target="CACHING"/> for more information.
</t> </t>
<t> <t>
Finally, the definition of a new status code ought to indicate whether the Finally, the definition of a new status code ought to indicate whether the
content has any implied association with an identified resource (<xref target ="identifying.content"/>). content has any implied association with an identified resource (<xref target ="identifying.content"/>).
</t> </t>
</section> </section>
</section> </section>
<section anchor="fields.extensibility" title="Field Extensibility"> <section anchor="fields.extensibility" title="Field Extensibility">
<t> <t>
HTTP's most widely used extensibility point is the definition of new header an d HTTP's most widely used extensibility point is the definition of new header an d
skipping to change at line 9697 skipping to change at line 9719
Any party can request registration of an HTTP field. See <xref target="consid erations.for.new.fields"/> for considerations to take Any party can request registration of an HTTP field. See <xref target="consid erations.for.new.fields"/> for considerations to take
into account when creating a new HTTP field. into account when creating a new HTTP field.
</t> </t>
<t> <t>
The "Hypertext Transfer Protocol (HTTP) Field Name Registry" is located at The "Hypertext Transfer Protocol (HTTP) Field Name Registry" is located at
<eref target="https://www.iana.org/assignments/http-fields/" brackets="angle" />. <eref target="https://www.iana.org/assignments/http-fields/" brackets="angle" />.
Registration requests can be made by following the instructions located Registration requests can be made by following the instructions located
there or by sending an email to the "ietf-http-wg@w3.org" mailing list. there or by sending an email to the "ietf-http-wg@w3.org" mailing list.
</t> </t>
<t> <t>
Field names are registered on the advice of a Designated Expert Field names are registered on the advice of a designated expert
(appointed by the IESG or their delegate). Fields with the status (appointed by the IESG or their delegate). Fields with the status
'permanent' are Specification Required 'permanent' are Specification Required
(<xref target="RFC8126" sectionFormat="comma" section="4.6"/>). (<xref target="RFC8126" sectionFormat="comma" section="4.6"/>).
</t> </t>
<t> <t>
Registration requests consist of the following information: Registration requests consist of the following information:
</t> </t>
<dl newline="true"> <dl newline="true">
<dt>Field name:</dt> <dt>Field name:</dt>
<dd> <dd>
The requested field name. It <bcp14>MUST</bcp14> conform to the The requested field name. It <bcp14>MUST</bcp14> conform to the
field-name syntax defined in <xref target="fields.names"/>, and <bcp14>SHOUL D</bcp14> be field-name syntax defined in <xref target="fields.names"/>, and it <bcp14>SH OULD</bcp14> be
restricted to just letters, digits, and hyphen ('-') restricted to just letters, digits, and hyphen ('-')
characters, with the first character being a letter. characters, with the first character being a letter.
</dd> </dd>
<dt>Status:</dt> <dt>Status:</dt>
<dd> <dd>
"permanent" or "provisional". "permanent", "provisional", "deprecated", or "obsoleted".
</dd> </dd>
<dt>Specification document(s):</dt> <dt>Specification document(s):</dt>
<dd> <dd>
Reference to the document that specifies Reference to the document that specifies
the field, preferably including a URI that can be used to retrieve the field, preferably including a URI that can be used to retrieve
a copy of the document. Optional but encouraged for provisional registration s. a copy of the document. Optional but encouraged for provisional registration s.
An indication of the relevant section(s) can also be included, but is not re quired. An indication of the relevant section(s) can also be included, but is not re quired.
</dd> </dd>
</dl> </dl>
<t> <t>
And, optionally: And optionally:
</t> </t>
<dl> <dl>
<dt>Comments:</dt> <dt>Comments:</dt>
<dd> <dd>
Additional information, such as about reserved entries. Additional information, such as about reserved entries.
</dd> </dd>
</dl> </dl>
<t> <t>
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.
</t> </t>
<t> <t>
Standards-defined names have a status of "permanent". Other names can also Standards-defined names have a status of "permanent". Other names can also
be registered as permanent, if the Expert(s) find that they are in use, in be registered as permanent if the expert(s) finds that they are in use, in
consultation with the community. Other names should be registered as consultation with the community. Other names should be registered as
"provisional". "provisional".
</t> </t>
<t> <t>
Provisional entries can be removed by the Expert(s) if — in consultation Provisional entries can be removed by the expert(s) if -- in consultation
with the community — the Expert(s) find that they are not in use. The with the community -- the expert(s) find that they are not in use. The
Experts can change a provisional entry's status to permanent at any time. expert(s) can change a provisional entry's status to permanent at any time.
</t> </t>
<t> <t>
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 widely expert(s)) if the expert(s) determines that an unregistered name is widely
deployed and not likely to be registered in a timely manner otherwise. deployed and not likely to be registered in a timely manner otherwise.
</t> </t>
</section> </section>
<section anchor="considerations.for.new.fields" <section anchor="considerations.for.new.fields"
title="Considerations for New Fields"> title="Considerations for New Fields">
<t> <t>
HTTP header and trailer fields are a widely-used extension point for the prot ocol. HTTP header and trailer fields are a widely used extension point for the prot ocol.
While they can be used in an ad hoc fashion, fields that are intended for While they can be used in an ad hoc fashion, fields that are intended for
wider use need to be carefully documented to ensure interoperability. wider use need to be carefully documented to ensure interoperability.
</t> </t>
<t> <t>
In particular, authors of specifications defining new fields are advised to c onsider In particular, authors of specifications defining new fields are advised to c onsider
and, where appropriate, document the following aspects: and, where appropriate, document the following aspects:
</t> </t>
<ul> <ul>
<li>Under what conditions the field can be used; e.g., only in <li>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 9792 skipping to change at line 9814
<li>If the field is allowable in trailers; by <li>If the field is allowable in trailers; by
default, it will not be (see <xref target="trailers.limitations"/>).</li> default, it will not be (see <xref target="trailers.limitations"/>).</li>
<li>Whether it is appropriate or even required to list the fie ld name in the <li>Whether it is appropriate or even required to list the fie ld name in the
<xref target="field.connection" format="none">Connection</xref> header fiel d (i.e., if the field is to <xref target="field.connection" format="none">Connection</xref> header fiel d (i.e., if the field is to
be hop-by-hop; see <xref target="field.connection"/>).</li> be hop-by-hop; see <xref target="field.connection"/>).</li>
<li>Whether the field introduces any additional security consi derations, such <li>Whether the field introduces any additional security consi derations, such
as disclosure of privacy-related data.</li> as disclosure of privacy-related data.</li>
</ul> </ul>
<t> <t>
Request header fields have additional considerations that need to be document ed Request header fields have additional considerations that need to be document ed
if the default behaviour is not appropriate: if the default behavior is not appropriate:
</t> </t>
<ul> <ul>
<li>If it is appropriate to list the field name in a <li>If it is appropriate to list the field name in a
<xref target="field.vary" format="none">Vary</xref> response header field ( e.g., when the request header <xref target="field.vary" format="none">Vary</xref> response header field ( e.g., when the request header
field is used by an origin server's content selection algorithm; see field is used by an origin server's content selection algorithm; see
<xref target="field.vary"/>).</li> <xref target="field.vary"/>).</li>
<li>If the field is intended to be stored when received in a P UT <li>If the field is intended to be stored when received in a P UT
request (see <xref target="PUT"/>).</li> request (see <xref target="PUT"/>).</li>
<li>If the field ought to be removed when automatically redire cting a <li>If the field ought to be removed when automatically redire cting a
request, due to security concerns (see <xref target="status.3xx"/>).</li> request due to security concerns (see <xref target="status.3xx"/>).</li>
</ul> </ul>
<section anchor="considerations.for.new.field.names" <section anchor="considerations.for.new.field.names"
title="Considerations for New Field Names"> title="Considerations for New Field Names">
<t> <t>
Authors of specifications defining new fields are advised to choose a short Authors of specifications defining new fields are advised to choose a short
but descriptive field name. Short names avoid needless data transmission; but descriptive field name. Short names avoid needless data transmission;
descriptive names avoid confusion and "squatting" on names that might have descriptive names avoid confusion and "squatting" on names that might have
broader uses. broader uses.
</t> </t>
<t> <t>
skipping to change at line 9836 skipping to change at line 9858
gateway interfaces (see <xref target="underscore.in.fields"/>). gateway interfaces (see <xref target="underscore.in.fields"/>).
</t> </t>
<t> <t>
Field names ought not be prefixed with "X-"; see Field names ought not be prefixed with "X-"; see
<xref target="BCP178"/> for further information. <xref target="BCP178"/> for further information.
</t> </t>
<t> <t>
Other prefixes are sometimes used in HTTP field names; for example, Other prefixes are sometimes used in HTTP field names; for example,
"Accept-" is used in many content negotiation headers, and "Content-" is used "Accept-" is used in many content negotiation headers, and "Content-" is used
as explained in <xref target="content"/>. These prefixes are as explained in <xref target="content"/>. These prefixes are
only an aid to recognizing the purpose of a field, and do not only an aid to recognizing the purpose of a field and do not
trigger automatic processing. trigger automatic processing.
</t> </t>
</section> </section>
<section anchor="considerations.for.new.field.values" <section anchor="considerations.for.new.field.values"
title="Considerations for New Field Values"> title="Considerations for New Field Values">
<t> <t>
A major task in the definition of a new HTTP field is the specification of A major task in the definition of a new HTTP field is the specification of
the field value syntax: what senders should generate, and how recipients the field value syntax: what senders should generate, and how recipients
should infer semantics from what is received. should infer semantics from what is received.
</t> </t>
<t> <t>
Authors are encouraged (but not required) to use either the ABNF rules in Authors are encouraged (but not required) to use either the ABNF rules in
this specification or those in <xref target="RFC8941"/> to define the syntax this specification or those in <xref target="RFC8941"/> to define the syntax
of new field values. of new field values.
</t> </t>
<t> <t>
Authors are advised to carefully consider how the combination of multiple Authors are advised to carefully consider how the combination of multiple
field lines will impact them (see <xref target="fields.order"/>). Because field lines will impact them (see <xref target="fields.order"/>). Because
senders might erroneously send multiple values, and both intermediaries senders might erroneously send multiple values, and both intermediaries
and HTTP libraries can perform combination automatically, this applies to and HTTP libraries can perform combination automatically, this applies to
all field values — even when only a single value is anticipated. all field values -- even when only a single value is anticipated.
</t> </t>
<t> <t>
Therefore, authors are advised to delimit or encode values that contain Therefore, authors are advised to delimit or encode values that contain
commas (e.g., with the <xref target="rule.quoted-string" format="none">quoted -string</xref> rule of commas (e.g., with the <xref target="rule.quoted-string" format="none">quoted -string</xref> rule of
<xref target="quoted.strings"/>, the String data type of <xref target="quoted.strings"/>, the String data type of
<xref target="RFC8941"/>, or a field-specific encoding). <xref target="RFC8941"/>, or a field-specific encoding).
This ensures that commas within field data are not confused This ensures that commas within field data are not confused
with the commas that delimit a list value. with the commas that delimit a list value.
</t> </t>
<t> <t>
skipping to change at line 9977 skipping to change at line 9999
<t> <t>
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 <xref target="field.www-authenti cate" format="none">WWW-Authenticate</xref>), origin-server authentication (i.e., using <xref target="field.www-authenti cate" format="none">WWW-Authenticate</xref>),
and/or proxy authentication (i.e., using <xref target="field.proxy-authent icate" format="none">Proxy-Authenticate</xref>). and/or proxy authentication (i.e., using <xref target="field.proxy-authent icate" format="none">Proxy-Authenticate</xref>).
</t> </t>
</li> </li>
<li> <li>
<t> <t>
The credentials carried in an <xref target="field.authorization" format="n one">Authorization</xref> header field are specific to The credentials carried in an <xref target="field.authorization" format="n one">Authorization</xref> header field are specific to
the user agent and, therefore, have the same effect on HTTP caches as the the user agent and, therefore, have the same effect on HTTP caches as the
"private" Cache-Control response directive (<xref target="CACHING" section ="5.2.2.7"/>), "private" cache response directive (<xref target="CACHING" section="5.2.2. 7"/>),
within the scope of the request in which they appear. within the scope of the request in which they appear.
</t> </t>
<t> <t>
Therefore, new authentication schemes that choose not to carry Therefore, new authentication schemes that choose not to carry
credentials in the <xref target="field.authorization" format="none">Author ization</xref> header field (e.g., using a newly defined credentials in the <xref target="field.authorization" format="none">Author ization</xref> header field (e.g., using a newly defined
header field) will need to explicitly disallow caching, by mandating the u se of header field) will need to explicitly disallow caching, by mandating the u se of
Cache-Control response directives (e.g., "private"). cache response directives (e.g., "private").
</t> </t>
</li> </li>
<li> <li>
<t> <t>
Schemes using <xref target="field.authentication-info" format="none">Authe ntication-Info</xref>, <xref target="field.proxy-authentication-info" format="no ne">Proxy-Authentication-Info</xref>, Schemes using <xref target="field.authentication-info" format="none">Authe ntication-Info</xref>, <xref target="field.proxy-authentication-info" format="no ne">Proxy-Authentication-Info</xref>,
or any other authentication related response header field need to or 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
<xref target="security.auth.add.resp"/>). <xref target="security.auth.add.resp"/>).
</t> </t>
</li> </li>
</ul> </ul>
</section> </section>
</section> </section>
<section anchor="range.unit.extensibility" title="Range Unit Extensibil ity"> <section anchor="range.unit.extensibility" title="Range Unit Extensibil ity">
<section anchor="range.unit.registry" title="Range Unit Registry"> <section anchor="range.unit.registry" title="Range Unit Registry">
<t> <t>
The "HTTP Range Unit Registry" defines the namespace for the range The "HTTP Range Unit Registry" defines the namespace for the range
unit names and refers to their corresponding specifications. unit names and refers to their corresponding specifications.
It is maintained at It is maintained at
<eref target="https://www.iana.org/assignments/http-parameters" <eref target="https://www.iana.org/assignments/http-parameters"
brackets="angle"/>. brackets="angle"/>.
</t> </t>
<t> <t>
skipping to change at line 10050 skipping to change at line 10072
<t> <t>
Content coding registrations <bcp14>MUST</bcp14> include the following fields : Content coding registrations <bcp14>MUST</bcp14> include the following fields :
</t> </t>
<ul> <ul>
<li>Name</li> <li>Name</li>
<li>Description</li> <li>Description</li>
<li>Pointer to specification text</li> <li>Pointer to specification text</li>
</ul> </ul>
<t> <t>
Names of content codings <bcp14>MUST NOT</bcp14> overlap with names of transf er codings Names of content codings <bcp14>MUST NOT</bcp14> overlap with names of transf er codings
(as per the "HTTP Transfer Coding registry", located at (per the "HTTP Transfer Coding Registry" located at
<eref target="https://www.iana.org/assignments/http-parameters/" <eref target="https://www.iana.org/assignments/http-parameters/"
brackets="angle"/>), unless brackets="angle"/>) unless
the encoding transformation is the encoding transformation is
identical (as is the case for the compression codings defined in identical (as is the case for the compression codings defined in
<xref target="content.codings"/>). <xref target="content.codings"/>).
</t> </t>
<t> <t>
Values to be added to this namespace require IETF Review Values to be added to this namespace require IETF Review
(see <xref target="RFC8126" section="4.8"/>) and <bcp14>MUST</bcp14> (see <xref target="RFC8126" section="4.8"/>) and <bcp14>MUST</bcp14>
conform to the purpose of content coding defined in conform to the purpose of content coding defined in
<xref target="content.codings"/>. <xref target="content.codings"/>.
</t> </t>
skipping to change at line 10116 skipping to change at line 10138
This will normally only be used in the case when a This will normally only be used in the case when a
responsible party cannot be contacted.</li> responsible party cannot be contacted.</li>
</ol> </ol>
</section> </section>
</section> </section>
<section anchor="security.considerations" title="Security Considerations"> <section anchor="security.considerations" title="Security Considerations">
<t> <t>
This section is meant to inform developers, information providers, and This section is meant to inform developers, information providers, and
users of known security concerns relevant to HTTP semantics and its users of known security concerns relevant to HTTP semantics and its
use for transferring information over the Internet. Considerations related use for transferring information over the Internet. Considerations related
to caching are discussed in <xref target="CACHING" section="7"/> to caching are discussed in <xref target="CACHING" section="7"/>,
and considerations related to HTTP/1.1 message syntax and parsing are and considerations related to HTTP/1.1 message syntax and parsing are
discussed in <xref target="HTTP11" section="11"/>. discussed in <xref target="HTTP11" section="11"/>.
</t> </t>
<t> <t>
The list of considerations below is not exhaustive. Most security concerns The list of considerations below is not exhaustive. Most security concerns
related to HTTP semantics are about securing server-side applications (code related to HTTP semantics are about securing server-side applications (code
behind the HTTP interface), securing user agent processing of content behind the HTTP interface), securing user agent processing of content
received via HTTP, or secure use of the Internet in general, rather than received via HTTP, or secure use of the Internet in general, rather than
security of the protocol. The security considerations for URIs, which security of the protocol. The security considerations for URIs, which
are fundamental to HTTP operation, are discussed in are fundamental to HTTP operation, are discussed in
<xref target="URI" section="7"/>. Various organizations maintain <xref target="URI" section="7"/>. Various organizations maintain
topical information and links to current research on Web application topical information and links to current research on Web application
security (e.g., <xref target="OWASP"/>). security (e.g., <xref target="OWASP"/>).
</t> </t>
<section anchor="establishing.authority" title="Establishing Authority" > <section anchor="establishing.authority" title="Establishing Authority" >
<iref item="authoritative response" primary="true"/> <iref item="authoritative response" primary="true"/>
<iref item="phishing" primary="true"/> <iref item="phishing" primary="true"/>
<t> <t>
HTTP relies on the notion of an <em>authoritative response</em>: a HTTP relies on the notion of an "authoritative response": a
response that has been determined by (or at the direction of) the origin response that has been determined by (or at the direction of) the origin
server identified within the target URI to be the most appropriate response server identified within the target URI to be the most appropriate response
for that request given the state of the target resource at the time of for that request given the state of the target resource at the time of
response message origination. response message origination.
</t> </t>
<t> <t>
When a registered name is used in the authority component, the "http" URI When a registered name is used in the authority component, the "http" URI
scheme (<xref target="http.uri"/>) relies on the user's local name scheme (<xref target="http.uri"/>) relies on the user's local name
resolution service to determine where it can find authoritative responses. resolution service to determine where it can find authoritative responses.
This means that any attack on a user's network host table, cached names, This means that any attack on a user's network host table, cached names,
skipping to change at line 10181 skipping to change at line 10203
with a protocol extension like <xref target="RFC8336"/>. with a protocol extension like <xref target="RFC8336"/>.
</t> </t>
<t> <t>
Providing a response from a non-authoritative source, such as a shared Providing a response from a non-authoritative source, such as a shared
proxy cache, is often useful to improve performance and availability, but proxy cache, is often useful to improve performance and availability, but
only to the extent that the source can be trusted or the distrusted only to the extent that the source can be trusted or the distrusted
response can be safely used. response can be safely used.
</t> </t>
<t> <t>
Unfortunately, communicating authority to users can be difficult. Unfortunately, communicating authority to users can be difficult.
For example, <em>phishing</em> is an attack on the user's perception For example, "phishing" is an attack on the user's perception
of authority, where that perception can be misled by presenting similar of authority, where that perception can be misled by presenting similar
branding in hypertext, possibly aided by userinfo obfuscating the authority branding in hypertext, possibly aided by userinfo obfuscating the authority
component (see <xref target="http.uri"/>). component (see <xref target="http.uri"/>).
User agents can reduce the impact of phishing attacks by enabling users to User agents can reduce the impact of phishing attacks by enabling users to
easily inspect a target URI prior to making an action, by prominently easily inspect a target URI prior to making an action, by prominently
distinguishing (or rejecting) userinfo when present, and by not sending distinguishing (or rejecting) userinfo when present, and by not sending
stored credentials and cookies when the referring document is from an stored credentials and cookies when the referring document is from an
unknown or untrusted source. unknown or untrusted source.
</t> </t>
</section> </section>
skipping to change at line 10312 skipping to change at line 10334
<t> <t>
Recipients ought to carefully limit the extent to which they process other Recipients ought to carefully limit the extent to which they process other
protocol elements, including (but not limited to) request methods, response protocol elements, including (but not limited to) request methods, response
status phrases, field names, numeric values, and chunk lengths. status phrases, field names, numeric values, and chunk lengths.
Failure to limit such processing can result in arbitrary code execution due t o Failure to limit such processing can result in arbitrary code execution due t o
buffer or arithmetic buffer or arithmetic
overflows, and increased vulnerability to denial-of-service attacks. overflows, and increased vulnerability to denial-of-service attacks.
</t> </t>
</section> </section>
<section anchor="compression.attacks" <section anchor="compression.attacks"
title="Attacks using Shared-dictionary Compression"> title="Attacks Using Shared-Dictionary Compression">
<t> <t>
Some attacks on encrypted protocols use the differences in size created by Some attacks on encrypted protocols use the differences in size created by
dynamic compression to reveal confidential information; for example, <xref ta rget="BREACH"/>. These attacks rely on creating a redundancy between dynamic compression to reveal confidential information; for example, <xref ta rget="BREACH"/>. These attacks rely on creating a redundancy between
attacker-controlled content and the confidential information, such that a attacker-controlled content and the confidential information, such that a
dynamic compression algorithm using the same dictionary for both content dynamic compression algorithm using the same dictionary for both content
will compress more efficiently when the attacker-controlled content matches will compress more efficiently when the attacker-controlled content matches
parts of the confidential content. parts of the confidential content.
</t> </t>
<t> <t>
HTTP messages can be compressed in a number of ways, including using TLS HTTP messages can be compressed in a number of ways, including using TLS
skipping to change at line 10392 skipping to change at line 10414
</t> </t>
<t> <t>
When an application uses client-side mechanisms to construct a target URI When an application uses client-side mechanisms to construct a target URI
out of user-provided information, such as the query fields of a form using out of user-provided information, such as the query fields of a form using
GET, potentially sensitive data might be provided that would not be GET, potentially sensitive data might be provided that would not be
appropriate for disclosure within a URI. POST is often preferred in such appropriate for disclosure within a URI. POST is often preferred in such
cases because it usually doesn't construct a URI; instead, POST of a form cases because it usually doesn't construct a URI; instead, POST of a form
transmits the potentially sensitive data in the request content. However, thi s transmits the potentially sensitive data in the request content. However, thi s
hinders caching and uses an unsafe method for what would otherwise be a safe hinders caching and uses an unsafe method for what would otherwise be a safe
request. Alternative workarounds include transforming the user-provided data request. Alternative workarounds include transforming the user-provided data
prior to constructing the URI, or filtering the data to only include common prior to constructing the URI or filtering the data to only include common
values that are not sensitive. Likewise, redirecting the result of a query values that are not sensitive. Likewise, redirecting the result of a query
to a different (server-generated) URI can remove potentially sensitive data to a different (server-generated) URI can remove potentially sensitive data
from later links and provide a cacheable response for later reuse. from later links and provide a cacheable response for later reuse.
</t> </t>
<t> <t>
Since the <xref target="field.referer" format="none">Referer</xref> header fi eld tells a target site about the Since the <xref target="field.referer" format="none">Referer</xref> header fi eld tells a target site about the
context that resulted in a request, it has the potential to reveal context that resulted in a request, it has the potential to reveal
information about the user's immediate browsing history and any personal information about the user's immediate browsing history and any personal
information that might be found in the referring resource's URI. information that might be found in the referring resource's URI.
Limitations on the Referer header field are described in <xref target="field. referer"/> to Limitations on the Referer header field are described in <xref target="field. referer"/> to
skipping to change at line 10552 skipping to change at line 10574
<t> <t>
The validators defined by this specification are not intended to ensure The validators defined by this specification are not intended to ensure
the validity of a representation, guard against malicious changes, or the validity of a representation, guard against malicious changes, or
detect on-path attacks. At best, they enable more efficient cache detect on-path attacks. At best, they enable more efficient cache
updates and optimistic concurrent writes when all participants are behaving updates and optimistic concurrent writes when all participants are behaving
nicely. At worst, the conditions will fail and the client will receive a nicely. At worst, the conditions will fail and the client will receive a
response that is no more harmful than an HTTP exchange without conditional response that is no more harmful than an HTTP exchange without conditional
requests. requests.
</t> </t>
<t> <t>
An entity-tag can be abused in ways that create privacy risks. For example, An entity tag can be abused in ways that create privacy risks. For example,
a site might deliberately construct a semantically invalid entity-tag that a site might deliberately construct a semantically invalid entity tag that
is unique to the user or user agent, send it in a cacheable response with a is unique to the user or user agent, send it in a cacheable response with a
long freshness time, and then read that entity-tag in later conditional long freshness time, and then read that entity tag in later conditional
requests as a means of re-identifying that user or user agent. Such an requests as a means of re-identifying that user or user agent. Such an
identifying tag would become a persistent identifier for as long as the identifying tag would become a persistent identifier for as long as the
user agent retained the original cache entry. User agents that cache user agent retained the original cache entry. User agents that cache
representations ought to ensure that the cache is cleared or replaced representations ought to ensure that the cache is cleared or replaced
whenever the user performs privacy-maintaining actions, such as clearing whenever the user performs privacy-maintaining actions, such as clearing
stored cookies or changing to a private browsing mode. stored cookies or changing to a private browsing mode.
</t> </t>
</section> </section>
<section anchor="overlapping.ranges" <section anchor="overlapping.ranges"
title="Denial-of-Service Attacks Using Range"> title="Denial-of-Service Attacks Using Range">
skipping to change at line 10679 skipping to change at line 10701
</section> </section>
</section> </section>
</section> </section>
<section anchor="IANA.considerations" title="IANA Considerations"> <section anchor="IANA.considerations" title="IANA Considerations">
<t> <t>
The change controller for the following registrations is: The change controller for the following registrations is:
"IETF (iesg@ietf.org) - Internet Engineering Task Force". "IETF (iesg@ietf.org) - Internet Engineering Task Force".
</t> </t>
<section anchor="uri.scheme.registration" title="URI Scheme Registratio n"> <section anchor="uri.scheme.registration" title="URI Scheme Registratio n">
<t> <t>
Please update the registry of URI Schemes <xref target="BCP35"/> at IANA has updated the "Uniform Resource Identifier (URI) Schemes" registry <xr ef target="BCP35"/> at
<eref target="https://www.iana.org/assignments/uri-schemes/" brackets="angle" /> with the <eref target="https://www.iana.org/assignments/uri-schemes/" brackets="angle" /> with the
permanent schemes listed in the table in <xref target="uri.schemes"/>. permanent schemes listed in <xref target="uri.scheme.table"/> in <xref target ="uri.schemes"/>.
</t> </t>
</section> </section>
<section anchor="method.registration" title="Method Registration"> <section anchor="method.registration" title="Method Registration">
<t> <t>
Please update the "Hypertext Transfer Protocol (HTTP) Method Registry" at IANA has updated the "Hypertext Transfer Protocol (HTTP) Method Registry" at
<eref target="https://www.iana.org/assignments/http-methods" brackets="angle"/ > with the <eref target="https://www.iana.org/assignments/http-methods" brackets="angle"/ > with the
registration procedure of <xref target="method.registry"/> and the method registration procedure of <xref target="method.registry"/> and the method
names summarized in the following table. names summarized in the following table.
</t> </t>
<!--AUTOGENERATED FROM extract-method-defs.xslt, do not edit manuall y-->
<table anchor="iana.method.registration.table"> <table anchor="iana.method.registration.table">
<thead> <thead>
<tr> <tr>
<th>Method</th> <th>Method</th>
<th>Safe</th> <th>Safe</th>
<th>Idempotent</th> <th>Idempotent</th>
<th>Ref.</th> <th>Section</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td>CONNECT</td> <td>CONNECT</td>
<td>no</td> <td>no</td>
<td>no</td> <td>no</td>
<td> <td>
<xref target="CONNECT" format="counter"/> <xref target="CONNECT" format="counter"/>
</td> </td>
skipping to change at line 10776 skipping to change at line 10798
<tr> <tr>
<td>*</td> <td>*</td>
<td>no</td> <td>no</td>
<td>no</td> <td>no</td>
<td> <td>
<xref target="method.registration" format="counter"/> <xref target="method.registration" format="counter"/>
</td> </td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<!--(END)-->
<t> <t>
<iref primary="true" item="Method" subitem="*"/> <iref primary="true" item="Method" subitem="*"/>
The method name "*" is reserved, since using "*" as a method name would The method name "*" is reserved because using "*" as a method name would
conflict with its usage as a wildcard in some fields (e.g., conflict with its usage as a wildcard in some fields (e.g.,
"Access-Control-Request-Method"). "Access-Control-Request-Method").
</t> </t>
</section> </section>
<section anchor="status.code.registration" title="Status Code Registrat ion"> <section anchor="status.code.registration" title="Status Code Registrat ion">
<t> <t>
Please update the "Hypertext Transfer Protocol (HTTP) Status Code Registry" IANA has updated the "Hypertext Transfer Protocol (HTTP) Status Code Registry "
at <eref target="https://www.iana.org/assignments/http-status-codes" at <eref target="https://www.iana.org/assignments/http-status-codes"
brackets="angle"/> with brackets="angle"/> with
the registration procedure of <xref target="status.code.registry"/> and the the registration procedure of <xref target="status.code.registry"/> and the
status code values summarized in the following table. status code values summarized in the following table.
</t> </t>
<!--AUTOGENERATED FROM extract-status-code-defs.xslt, do not edit ma nually-->
<table anchor="iana.status.code.registration.table"> <table anchor="iana.status.code.registration.table">
<thead> <thead>
<tr> <tr>
<th>Value</th> <th>Value</th>
<th>Description</th> <th>Description</th>
<th>Ref.</th> <th>Section</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td>100</td> <td>100</td>
<td>Continue</td> <td>Continue</td>
<td> <td>
<xref target="status.100" format="counter"/> <xref target="status.100" format="counter"/>
</td> </td>
</tr> </tr>
skipping to change at line 11126 skipping to change at line 11147
</tr> </tr>
<tr> <tr>
<td>505</td> <td>505</td>
<td>HTTP Version Not Supported</td> <td>HTTP Version Not Supported</td>
<td> <td>
<xref target="status.505" format="counter"/> <xref target="status.505" format="counter"/>
</td> </td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<!--(END)-->
</section> </section>
<section anchor="field.name.registration" title="Field Name Registratio n"> <section anchor="field.name.registration" title="Field Name Registratio n">
<t> <t>
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 <xref target="RF C3864"/>. registration procedures for message header fields defined in <xref target="RF C3864"/>.
It replaces the old procedures as they relate to HTTP, by defining a new It replaces the old procedures as they relate to HTTP by defining a new
registration procedure and moving HTTP field definitions into a separate registration procedure and moving HTTP field definitions into a separate
registry. registry.
</t> </t>
<t> <t>
Please create a new registry as outlined in <xref target="fields.registry"/>. IANA has created a new registry titled "Hypertext Transfer Protocol (HTTP)
</t> Field Name Registry" as outlined in <xref target="fields.registry"/>.
</t>
<t> <t>
After creating the registry, all entries in the Permanent and Provisional IANA has moved all entries in the "Permanent Message Header Field
Message Header Registries with the protocol 'http' are to be moved to it, Names" and "Provisional Message Header Field Names" registries (see
with the following changes applied: <eref target="https://www.iana.org/assignments/message-headers/"
brackets="angle"/>) with the
protocol 'http' to this registry and has applied the following changes:
</t> </t>
<ol> <ol>
<li>The 'Applicable Protocol' field is to be omitted.</li> <li>The 'Applicable Protocol' field has been omitted.</li>
<li>Entries with a status of 'standard', 'experimental', 'reserve <li>Entries that had a status of 'standard', 'experimental', 'res
d', or erved', or
'informational' are to have a status of 'permanent'.</li> 'informational' have been made to have a status of 'permanent'.</li>
<li>Provisional entries without a status are to have a status of <li>Provisional entries without a status have been made to have a
status of
'provisional'.</li> 'provisional'.</li>
<li>Permanent entries without a status (after confirmation that t he <li>Permanent entries without a status (after confirmation that t he
registration document did not define one) will have a status of registration document did not define one) have been made to have a status of
'provisional'. The Expert(s) can choose to update their status if there is 'provisional'. The expert(s) can choose to update the entries' status if ther
e is
evidence that another is more appropriate.</li> evidence that another is more appropriate.</li>
</ol> </ol>
<t> <t>
Please annotate the Permanent and Provisional Message Header registries to IANA has annotated the "Permanent Message Header Field
indicate that HTTP field name registrations have moved, with an Names" and "Provisional Message Header Field Names" registries with the
appropriate link. following note to indicate that HTTP field name registrations have moved:
</t>
<aside>
<t>
<strong>Note</strong>
</t>
<t>
HTTP field name registrations have been moved to
[<eref target="https://www.iana.org/assignments/http-fields" brackets="none"
/>] per
[RFC9110].
</t> </t>
</aside>
<t> <t>
After that is complete, please update the new registry with the IANA has updated the "Hypertext Transfer Protocol (HTTP) Field Name Registry"
field names listed in the following table. with the field names listed in the following table.
</t> </t>
<!--AUTOGENERATED FROM extract-header-defs.xslt, do not edit manuall y-->
<table align="left" anchor="iana.header.registration.table"> <table align="left" anchor="iana.header.registration.table">
<thead> <thead>
<tr> <tr>
<th>Field Name</th> <th>Field Name</th>
<th>Status</th> <th>Status</th>
<th>Ref.</th> <th>Section</th>
<th>Comments</th> <th>Comments</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td>Accept</td> <td>Accept</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.accept" format="counter"/> <xref target="field.accept" format="counter"/>
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>Accept-Charset</td> <td>Accept-Charset</td>
<td>deprecated</td> <td>deprecated</td>
<td> <td>
<xref target="field.accept-charset" format="counter"/> <xref target="field.accept-charset" format="counter"/>
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>Accept-Encoding</td> <td>Accept-Encoding</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.accept-encoding" format="counter"/> <xref target="field.accept-encoding" format="counter"/>
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>Accept-Language</td> <td>Accept-Language</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.accept-language" format="counter"/> <xref target="field.accept-language" format="counter"/>
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>Accept-Ranges</td> <td>Accept-Ranges</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.accept-ranges" format="counter"/> <xref target="field.accept-ranges" format="counter"/>
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>Allow</td> <td>Allow</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.allow" format="counter"/> <xref target="field.allow" format="counter"/>
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>Authentication-Info</td> <td>Authentication-Info</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.authentication-info" format="counter "/> <xref target="field.authentication-info" format="counter "/>
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>Authorization</td> <td>Authorization</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.authorization" format="counter"/> <xref target="field.authorization" format="counter"/>
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>Connection</td> <td>Connection</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.connection" format="counter"/> <xref target="field.connection" format="counter"/>
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>Content-Encoding</td> <td>Content-Encoding</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.content-encoding" format="counter"/> <xref target="field.content-encoding" format="counter"/>
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>Content-Language</td> <td>Content-Language</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.content-language" format="counter"/> <xref target="field.content-language" format="counter"/>
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>Content-Length</td> <td>Content-Length</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.content-length" format="counter"/> <xref target="field.content-length" format="counter"/>
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>Content-Location</td> <td>Content-Location</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.content-location" format="counter"/> <xref target="field.content-location" format="counter"/>
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>Content-Range</td> <td>Content-Range</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.content-range" format="counter"/> <xref target="field.content-range" format="counter"/>
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>Content-Type</td> <td>Content-Type</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.content-type" format="counter"/> <xref target="field.content-type" format="counter"/>
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>Date</td> <td>Date</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.date" format="counter"/> <xref target="field.date" format="counter"/>
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>ETag</td> <td>ETag</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.etag" format="counter"/> <xref target="field.etag" format="counter"/>
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>Expect</td> <td>Expect</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.expect" format="counter"/> <xref target="field.expect" format="counter"/>
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>From</td> <td>From</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.from" format="counter"/> <xref target="field.from" format="counter"/>
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>Host</td> <td>Host</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.host" format="counter"/> <xref target="field.host" format="counter"/>
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>If-Match</td> <td>If-Match</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.if-match" format="counter"/> <xref target="field.if-match" format="counter"/>
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>If-Modified-Since</td> <td>If-Modified-Since</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.if-modified-since" format="counter"/ > <xref target="field.if-modified-since" format="counter"/ >
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>If-None-Match</td> <td>If-None-Match</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.if-none-match" format="counter"/> <xref target="field.if-none-match" format="counter"/>
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>If-Range</td> <td>If-Range</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.if-range" format="counter"/> <xref target="field.if-range" format="counter"/>
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>If-Unmodified-Since</td> <td>If-Unmodified-Since</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.if-unmodified-since" format="counter "/> <xref target="field.if-unmodified-since" format="counter "/>
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>Last-Modified</td> <td>Last-Modified</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.last-modified" format="counter"/> <xref target="field.last-modified" format="counter"/>
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>Location</td> <td>Location</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.location" format="counter"/> <xref target="field.location" format="counter"/>
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>Max-Forwards</td> <td>Max-Forwards</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.max-forwards" format="counter"/> <xref target="field.max-forwards" format="counter"/>
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>Proxy-Authenticate</td> <td>Proxy-Authenticate</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.proxy-authenticate" format="counter" /> <xref target="field.proxy-authenticate" format="counter" />
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>Proxy-Authentication-Info</td> <td>Proxy-Authentication-Info</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.proxy-authentication-info" format="c ounter"/> <xref target="field.proxy-authentication-info" format="c ounter"/>
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>Proxy-Authorization</td> <td>Proxy-Authorization</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.proxy-authorization" format="counter "/> <xref target="field.proxy-authorization" format="counter "/>
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>Range</td> <td>Range</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.range" format="counter"/> <xref target="field.range" format="counter"/>
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>Referer</td> <td>Referer</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.referer" format="counter"/> <xref target="field.referer" format="counter"/>
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>Retry-After</td> <td>Retry-After</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.retry-after" format="counter"/> <xref target="field.retry-after" format="counter"/>
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>Server</td> <td>Server</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.server" format="counter"/> <xref target="field.server" format="counter"/>
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>TE</td> <td>TE</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.te" format="counter"/> <xref target="field.te" format="counter"/>
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>Trailer</td> <td>Trailer</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.trailer" format="counter"/> <xref target="field.trailer" format="counter"/>
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>Upgrade</td> <td>Upgrade</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.upgrade" format="counter"/> <xref target="field.upgrade" format="counter"/>
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>User-Agent</td> <td>User-Agent</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.user-agent" format="counter"/> <xref target="field.user-agent" format="counter"/>
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>Vary</td> <td>Vary</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.vary" format="counter"/> <xref target="field.vary" format="counter"/>
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>Via</td> <td>Via</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.via" format="counter"/> <xref target="field.via" format="counter"/>
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>WWW-Authenticate</td> <td>WWW-Authenticate</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.www-authenticate" format="counter"/> <xref target="field.www-authenticate" format="counter"/>
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>*</td> <td>*</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.vary" format="counter"/> <xref target="field.vary" format="counter"/>
</td> </td>
<td>(reserved)</td> <td>(reserved)</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<!--(END)-->
<t anchor="field.asterisk"> <t anchor="field.asterisk">
<iref primary="true" item="Fields" subitem="*"/> <iref primary="true" item="Fields" subitem="*"/>
The field name "*" is reserved, since using that name as The field name "*" is reserved because using that name as
an HTTP header field might conflict with its special semantics in the an HTTP header field might conflict with its special semantics in the
<xref target="field.vary" format="none">Vary</xref> header field (<xref targe t="field.vary"/>). <xref target="field.vary" format="none">Vary</xref> header field (<xref targe t="field.vary"/>).
</t> </t>
<t> <t>
<iref primary="true" item="Fields" subitem="Content-MD5"/> <iref primary="true" item="Fields" subitem="Content-MD5"/>
<iref primary="true" item="Header Fields" subitem="Content-MD5"/> <iref primary="true" item="Header Fields" subitem="Content-MD5"/>
<iref primary="true" item="Content-MD5 header field"/> <iref primary="true" item="Content-MD5 header field"/>
Finally, please update 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 a status of 'obsoleted' with references to
<xref target="RFC2616" section="14.15"/> (for the definition <xref target="RFC2616" section="14.15"/> (for the definition
of the header field) and of the header field) and
<xref target="RFC7231" section="B"/> (which removed the field <xref target="RFC7231" section="B"/> (which removed the field
definition from the updated specification). definition from the updated specification).
</t> </t>
</section> </section>
<section anchor="auth.scheme.registration" <section anchor="auth.scheme.registration"
title="Authentication Scheme Registration"> title="Authentication Scheme Registration">
<t> <t>
Please update the IANA has updated the
"Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry" "Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry"
at <eref target="https://www.iana.org/assignments/http-authschemes" at <eref target="https://www.iana.org/assignments/http-authschemes"
brackets="angle"/> with brackets="angle"/> with
the registration procedure of <xref target="auth.scheme.registry"/>. the registration procedure of <xref target="auth.scheme.registry"/>.
No authentication schemes are defined in this document. No authentication schemes are defined in this document.
</t> </t>
</section> </section>
<section anchor="content.coding.registration" <section anchor="content.coding.registration"
title="Content Coding Registration"> title="Content Coding Registration">
<t> <t>
Please update the "HTTP Content Coding Registry" at IANA has updated the "HTTP Content Coding Registry" at
<eref target="https://www.iana.org/assignments/http-parameters/" <eref target="https://www.iana.org/assignments/http-parameters/"
brackets="angle"/> brackets="angle"/>
with the registration procedure of <xref target="content.coding.registry"/> with the registration procedure of <xref target="content.coding.registry"/>
and the content coding names summarized in the table below. and the content coding names summarized in the table below.
</t> </t>
<table align="left" anchor="iana.content.coding.registration.table"> <table align="left" anchor="iana.content.coding.registration.table">
<thead> <thead>
<tr> <tr>
<th>Name</th> <th>Name</th>
<th>Description</th> <th>Description</th>
<th>Ref.</th> <th>Section</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td>compress</td> <td>compress</td>
<td>UNIX "compress" data format <xref target="Welch"/> <td>UNIX "compress" data format <xref target="Welch"/>
</td> </td>
<td> <td>
<xref target="compress.coding" format="counter"/> <xref target="compress.coding" format="counter"/>
</td> </td>
skipping to change at line 11621 skipping to change at line 11652
<td>Deprecated (alias for gzip)</td> <td>Deprecated (alias for gzip)</td>
<td> <td>
<xref target="gzip.coding" format="counter"/> <xref target="gzip.coding" format="counter"/>
</td> </td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section anchor="range.unit.registration" title="Range Unit Registratio n"> <section anchor="range.unit.registration" title="Range Unit Registratio n">
<t> <t>
Please update the "HTTP Range Unit Registry" at IANA has updated the "HTTP Range Unit Registry" at
<eref target="https://www.iana.org/assignments/http-parameters/" <eref target="https://www.iana.org/assignments/http-parameters/"
brackets="angle"/> brackets="angle"/>
with the registration procedure of <xref target="range.unit.registry"/> with the registration procedure of <xref target="range.unit.registry"/>
and the range unit names summarized in the table below. and the range unit names summarized in the table below.
</t> </t>
<table align="left" anchor="iana.range.units.table"> <table align="left" anchor="iana.range.units.table">
<thead> <thead>
<tr> <tr>
<th>Range Unit Name</th> <th>Range Unit Name</th>
<th>Description</th> <th>Description</th>
<th>Ref.</th> <th>Section</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td>bytes</td> <td>bytes</td>
<td>a range of octets</td> <td>a range of octets</td>
<td> <td>
<xref target="byte.ranges" format="counter"/> <xref target="byte.ranges" format="counter"/>
</td> </td>
</tr> </tr>
skipping to change at line 11655 skipping to change at line 11686
<td>reserved as keyword to indicate range requests are not supported</td> <td>reserved as keyword to indicate range requests are not supported</td>
<td> <td>
<xref target="field.accept-ranges" format="counter"/> <xref target="field.accept-ranges" format="counter"/>
</td> </td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section anchor="media.type.reg" title="Media Type Registration"> <section anchor="media.type.reg" title="Media Type Registration">
<t> <t>
Please update the "Media Types" registry at IANA has updated the "Media Types" registry at
<eref target="https://www.iana.org/assignments/media-types" brackets="angle"/ > <eref target="https://www.iana.org/assignments/media-types" brackets="angle"/ >
with the registration information in with the registration information in
<xref target="multipart.byteranges"/> <xref target="multipart.byteranges"/>
for the media type "multipart/byteranges". for the media type "multipart/byteranges".
</t> </t>
<t> <t>
Furthermore please update the registry note about "q" parameters with IANA has updated the registry note about "q" parameters with
a link to <xref target="field.accept"/> of this document. a link to <xref target="field.accept"/> of this document.
</t> </t>
</section> </section>
<section anchor="port.reg" title="Port Registration"> <section anchor="port.reg" title="Port Registration">
<t> <t>
Please update the "Service Name and Transport Protocol Port Number" IANA has updated the "Service Name and Transport Protocol Port Number
registry at <eref target="https://www.iana.org/assignments/service-names-port Registry" at <eref target="https://www.iana.org/assignments/service-names-por
-numbers/" t-numbers/"
brackets="angle"/> brackets="angle"/>
for the services on ports 80 and 443 that use UDP or TCP to: for the services on ports 80 and 443 that use UDP or TCP to:
</t> </t>
<ol> <ol>
<li>use this document as "Reference", and</li> <li>use this document as "Reference", and</li>
<li>when currently unspecified, set "Assignee" to "IESG" and "Con tact" to <li>when currently unspecified, set "Assignee" to "IESG" and "Con tact" to
"IETF_Chair".</li> "IETF_Chair".</li>
</ol> </ol>
</section> </section>
<section anchor="upgrade.token.registration" title="Upgrade Token Regis tration"> <section anchor="upgrade.token.registration" title="Upgrade Token Regis tration">
<t> <t>
Please update the IANA has updated the
"Hypertext Transfer Protocol (HTTP) Upgrade Token Registry" at "Hypertext Transfer Protocol (HTTP) Upgrade Token Registry" at
<eref target="https://www.iana.org/assignments/http-upgrade-tokens" <eref target="https://www.iana.org/assignments/http-upgrade-tokens"
brackets="angle"/> brackets="angle"/>
with the registration procedure of <xref target="upgrade.token.registry"/> with the registration procedure described in <xref target="upgrade.token.regi stry"/>
and the upgrade token names summarized in the following table. and the upgrade token names summarized in the following table.
</t> </t>
<table align="left"> <table align="left">
<thead> <thead>
<tr> <tr>
<th>Name</th> <th>Name</th>
<th>Description</th> <th>Description</th>
<th>Expected Version Tokens</th> <th>Expected Version Tokens</th>
<th>Ref.</th> <th>Section</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td>HTTP</td> <td>HTTP</td>
<td>Hypertext Transfer Protocol</td> <td>Hypertext Transfer Protocol</td>
<td>any DIGIT.DIGIT (e.g, "2.0")</td> <td>any DIGIT.DIGIT (e.g., "2.0")</td>
<td> <td>
<xref target="protocol.version" format="counter"/> <xref target="protocol.version" format="counter"/>
</td> </td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
</section> </section>
</middle> </middle>
<back> <back>
<displayreference xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" <displayreference target="HTTP10" to="HTTP/1.0"/>
xmlns:x="http://purl.org/net/xml2rfc/ext" <displayreference target="HTTP11" to="HTTP/1.1"/>
target="HTTP10" <displayreference target="HTTP2" to="HTTP/2"/>
to="HTTP/1.0"/> <displayreference target="HTTP3" to="HTTP/3"/>
<displayreference xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:x="http://purl.org/net/xml2rfc/ext"
target="HTTP11"
to="HTTP/1.1"/>
<displayreference xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:x="http://purl.org/net/xml2rfc/ext"
target="HTTP2"
to="HTTP/2"/>
<displayreference xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:x="http://purl.org/net/xml2rfc/ext"
target="HTTP3"
to="HTTP/3"/>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<reference anchor="CACHING"><!--included from draft-ietf-httpbis-cac
he-latest.xml--> <reference anchor='CACHING' target='https://www.rfc-editor.org/info/r
<front> fc9111'>
<title>HTTP Caching</title> <front>
<author fullname="Roy T. Fielding" <title>HTTP Caching</title>
initials="R." <author initials='R' surname='Fielding' fullname='Roy T. Fieldi
surname="Fielding" ng' role='editor'>
role="editor"> <organization />
<organization>Adobe</organization> </author>
<address> <author initials='M' surname='Nottingham' fullname='Mark Nottin
<postal> gham' role='editor'>
<postalLine>345 Park Ave</postalLine> <organization />
<postalLine>San Jose, CA 95110</postalLine> </author>
<postalLine>United States of America</postalLine> <author initials='J' surname='Reschke' fullname='Julian Reschke
</postal> ' role='editor'>
<email>fielding@gbiv.com</email> <organization />
<uri>https://roy.gbiv.com/</uri> </author>
</address> <date year='2022' month='June' />
</author> </front>
<author fullname="Mark Nottingham" <seriesInfo name="STD" value="98"/>
initials="M." <seriesInfo name="RFC" value="9111"/>
surname="Nottingham" <seriesInfo name="DOI" value="10.17487/RFC9111"/>
role="editor">
<organization>Fastly</organization>
<address>
<postal>
<postalLine>Prahran VIC</postalLine>
<postalLine>Australia</postalLine>
</postal>
<email>mnot@mnot.net</email>
<uri>https://www.mnot.net/</uri>
</address>
</author>
<author fullname="Julian Reschke"
initials="J."
surname="Reschke"
role="editor">
<organization abbrev="greenbytes">greenbytes GmbH</organiza
tion>
<address>
<postal>
<postalLine>Hafenweg 16</postalLine>
<postalLine>48155 Münster</postalLine>
<postalLine>Germany</postalLine>
</postal>
<email>julian.reschke@greenbytes.de</email>
<uri>https://greenbytes.de/tech/webdav/</uri>
</address>
</author>
<date year="2021" month="September" day="10"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-cache
-19"/>
</reference>
<reference anchor="RFC2046" target="https://www.rfc-editor.org/info/
rfc2046">
<front>
<title abbrev="Media Types">Multipurpose Internet Mail Extensi
ons (MIME) Part Two: Media Types</title>
<author initials="N." surname="Freed" fullname="Ned Freed"/>
<author initials="N."
surname="Borenstein"
fullname="Nathaniel S. Borenstein"/>
<date month="November" year="1996"/>
</front>
<seriesInfo name="RFC" value="2046"/>
<seriesInfo name="DOI" value="10.17487/RFC2046"/>
</reference>
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/
rfc2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Level
s</title>
<author initials="S." surname="Bradner" fullname="Scott Bradne
r"/>
<date month="March" year="1997"/>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/
rfc8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Wor
ds</title>
<author initials="B." surname="Leiba" fullname="Barry Leiba"/>
<date year="2017" month="May"/>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference> </reference>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2046.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.
xml"/>
<reference anchor="URI" target="https://www.rfc-editor.org/info/rfc3 986"> <reference anchor="URI" target="https://www.rfc-editor.org/info/rfc3 986">
<front> <front>
<title abbrev="URI Generic Syntax">Uniform Resource Identifier (URI): Generic Syntax</title> <title abbrev="URI Generic Syntax">Uniform Resource Identifier (URI): Generic Syntax</title>
<author initials="T." surname="Berners-Lee" fullname="Tim Bern ers-Lee"/> <author initials="T." surname="Berners-Lee" fullname="Tim Bern ers-Lee"/>
<author initials="R." surname="Fielding" fullname="Roy T. Fiel ding"/> <author initials="R." surname="Fielding" fullname="Roy T. Fiel ding"/>
<author initials="L." surname="Masinter" fullname="Larry Masin ter"/> <author initials="L." surname="Masinter" fullname="Larry Masin ter"/>
<date month="January" year="2005"/> <date month="January" year="2005"/>
</front> </front>
<seriesInfo name="STD" value="66"/> <seriesInfo name="STD" value="66"/>
<seriesInfo name="RFC" value="3986"/> <seriesInfo name="RFC" value="3986"/>
skipping to change at line 11837 skipping to change at line 11797
<reference anchor="TCP" target="https://www.rfc-editor.org/info/rfc7 93"> <reference anchor="TCP" target="https://www.rfc-editor.org/info/rfc7 93">
<front> <front>
<title>Transmission Control Protocol</title> <title>Transmission Control Protocol</title>
<author initials="J." surname="Postel" fullname="Jon Postel"/> <author initials="J." surname="Postel" fullname="Jon Postel"/>
<date year="1981" month="September"/> <date year="1981" month="September"/>
</front> </front>
<seriesInfo name="STD" value="7"/> <seriesInfo name="STD" value="7"/>
<seriesInfo name="RFC" value="793"/> <seriesInfo name="RFC" value="793"/>
<seriesInfo name="DOI" value="10.17487/RFC0793"/> <seriesInfo name="DOI" value="10.17487/RFC0793"/>
</reference> </reference>
<reference anchor="RFC4647" target="https://www.rfc-editor.org/info/ <reference anchor="RFC4647" target="https://www.rfc-editor.org/info/rfc4647">
rfc4647"> <front>
<front> <title>Matching of Language Tags</title>
<title>Matching of Language Tags</title>
<author initials="A."
surname="Phillips"
fullname="Addison Phillips"
role="editor"/>
<author initials="M."
surname="Davis"
fullname="Mark Davis"
role="editor"/>
<date year="2006" month="September"/>
</front>
<seriesInfo name="BCP" value="47"/>
<seriesInfo name="RFC" value="4647"/>
<seriesInfo name="DOI" value="10.17487/RFC4647"/>
</reference>
<reference anchor="RFC4648" target="https://www.rfc-editor.org/info/
rfc4648">
<front>
<title>The Base16, Base32, and Base64 Data Encodings</title>
<author fullname="S. Josefsson" initials="S." surname="Josefss
on"/>
<date year="2006" month="October"/>
</front>
<seriesInfo name="RFC" value="4648"/>
<seriesInfo name="DOI" value="10.17487/RFC4648"/>
</reference>
<reference anchor="RFC5234" target="https://www.rfc-editor.org/info/
rfc5234">
<front>
<title abbrev="ABNF for Syntax Specifications">Augmented BNF f
or Syntax Specifications: ABNF</title>
<author initials="D."
surname="Crocker"
fullname="Dave Crocker"
role="editor"/>
<author initials="P." surname="Overell" fullname="Paul Overell
"/>
<date month="January" year="2008"/>
</front>
<seriesInfo name="STD" value="68"/>
<seriesInfo name="RFC" value="5234"/>
<seriesInfo name="DOI" value="10.17487/RFC5234"/>
</reference>
<reference anchor="RFC5322" target="https://www.rfc-editor.org/info/
rfc5322">
<front>
<title>Internet Message Format</title>
<author initials="P." surname="Resnick" fullname="P. Resnick"/
>
<date year="2008" month="October"/>
</front>
<seriesInfo name="RFC" value="5322"/>
<seriesInfo name="DOI" value="10.17487/RFC5322"/>
</reference>
<reference anchor="RFC5646" target="https://www.rfc-editor.org/info/
rfc5646">
<front>
<title>Tags for Identifying Languages</title>
<author initials="A." <author initials="A."
surname="Phillips" surname="Phillips"
fullname="Addison Phillips" fullname="Addison Phillips"
role="editor"/> role="editor"/>
<author initials="M." <author initials="M."
surname="Davis" surname="Davis"
fullname="Mark Davis" fullname="Mark Davis"
role="editor"/> role="editor"/>
<date month="September" year="2009"/> <date year="2006" month="September"/>
</front> </front>
<seriesInfo name="BCP" value="47"/> <seriesInfo name="BCP" value="47"/>
<seriesInfo name="RFC" value="5646"/> <seriesInfo name="RFC" value="4647"/>
<seriesInfo name="DOI" value="10.17487/RFC5646"/> <seriesInfo name="DOI" value="10.17487/RFC4647"/>
</reference> </reference>
<reference anchor="RFC6125" target="https://www.rfc-editor.org/info/
rfc6125"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4648.
<front> xml"/>
<title>Representation and Verification of Domain-Based Applica <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5234.
tion Service Identity within Internet Public Key Infrastructure Using X.509 (PKI xml"/>
X) Certificates in the Context of Transport Layer Security (TLS)</title> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5322.
<author initials="P." surname="Saint-Andre" fullname="P. Saint xml"/>
-Andre"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5646.
<author initials="J." surname="Hodges" fullname="J. Hodges"/> xml"/>
<date year="2011" month="March"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6125.
</front> xml"/>
<seriesInfo name="RFC" value="6125"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6365.
<seriesInfo name="DOI" value="10.17487/RFC6125"/> xml"/>
</reference> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7405.
<reference anchor="RFC6365" target="https://www.rfc-editor.org/info/ xml"/>
rfc6365">
<front>
<title>Terminology Used in Internationalization in the IETF</t
itle>
<author initials="P." surname="Hoffman" fullname="P. Hoffman"/
>
<author initials="J." surname="Klensin" fullname="J. Klensin"/
>
<date year="2011" month="September"/>
</front>
<seriesInfo name="BCP" value="166"/>
<seriesInfo name="RFC" value="6365"/>
<seriesInfo name="DOI" value="10.17487/RFC6365"/>
</reference>
<reference anchor="RFC7405" target="https://www.rfc-editor.org/info/
rfc7405">
<front>
<title>Case-Sensitive String Support in ABNF</title>
<author initials="P." surname="Kyzivat" fullname="Dave Kyzivat
"/>
<date month="December" year="2014"/>
</front>
<seriesInfo name="RFC" value="7405"/>
<seriesInfo name="DOI" value="10.17487/RFC7405"/>
</reference>
<reference anchor="TLS13" target="https://www.rfc-editor.org/info/rf c8446"> <reference anchor="TLS13" target="https://www.rfc-editor.org/info/rf c8446">
<front> <front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3 </title> <title>The Transport Layer Security (TLS) Protocol Version 1.3 </title>
<author initials="E." surname="Rescorla" fullname="Eric Rescor la"/> <author initials="E." surname="Rescorla" fullname="Eric Rescor la"/>
<date year="2018" month="August"/> <date year="2018" month="August"/>
</front> </front>
<seriesInfo name="RFC" value="8446"/> <seriesInfo name="RFC" value="8446"/>
<seriesInfo name="DOI" value="10.17487/RFC8446"/> <seriesInfo name="DOI" value="10.17487/RFC8446"/>
</reference> </reference>
<reference anchor="USASCII"> <reference anchor="USASCII">
<front> <front>
<title>Coded Character Set -- 7-bit American Standard Code for Information Interchange</title> <title>Coded Character Set -- 7-bit American Standard Code for Information Interchange</title>
<author> <author>
<organization>American National Standards Institute</organi zation> <organization>American National Standards Institute</organi zation>
</author> </author>
<date year="1986"/> <date year="1986"/>
</front> </front>
<seriesInfo name="ANSI" value="X3.4"/> <seriesInfo name="ANSI" value="X3.4"/>
</reference> </reference>
<reference anchor="RFC1950" target="https://www.rfc-editor.org/info/
rfc1950"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1950.
<front> xml"/>
<title>ZLIB Compressed Data Format Specification version 3.3</ <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1951.
title> xml"/>
<author initials="L.P." surname="Deutsch" fullname="L. Peter D <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1952.
eutsch"/> xml"/>
<author initials="J-L." surname="Gailly" fullname="Jean-Loup G
ailly"/>
<date month="May" year="1996"/>
</front>
<seriesInfo name="RFC" value="1950"/>
<seriesInfo name="DOI" value="10.17487/RFC1950"/>
</reference>
<reference anchor="RFC1951" target="https://www.rfc-editor.org/info/
rfc1951">
<front>
<title>DEFLATE Compressed Data Format Specification version 1.
3</title>
<author initials="P." surname="Deutsch" fullname="L. Peter Deu
tsch"/>
<date month="May" year="1996"/>
</front>
<seriesInfo name="RFC" value="1951"/>
<seriesInfo name="DOI" value="10.17487/RFC1951"/>
</reference>
<reference anchor="RFC1952" target="https://www.rfc-editor.org/info/
rfc1952">
<front>
<title>GZIP file format specification version 4.3</title>
<author initials="P." surname="Deutsch" fullname="L. Peter Deu
tsch"/>
<author initials="J-L." surname="Gailly" fullname="Jean-Loup G
ailly"/>
<author initials="M." surname="Adler" fullname="Mark Adler"/>
<author initials="L.P." surname="Deutsch" fullname="L. Peter D
eutsch"/>
<author initials="G."
surname="Randers-Pehrson"
fullname="Glenn Randers-Pehrson"/>
<date month="May" year="1996"/>
</front>
<seriesInfo name="RFC" value="1952"/>
<seriesInfo name="DOI" value="10.17487/RFC1952"/>
</reference>
<reference anchor="Welch" target="https://ieeexplore.ieee.org/docume nt/1659158/"> <reference anchor="Welch" target="https://ieeexplore.ieee.org/docume nt/1659158/">
<front> <front>
<title>A Technique for High-Performance Data Compression</titl e> <title>A Technique for High-Performance Data Compression</titl e>
<author initials="T. A." surname="Welch" fullname="Terry A. We lch"/> <author initials="T." surname="Welch" fullname="Terry A. Welch "/>
<date month="June" year="1984"/> <date month="June" year="1984"/>
</front> </front>
<seriesInfo name="IEEE Computer" value="17(6)"/> <refcontent>IEEE Computer 17(6)</refcontent>
<seriesInfo name="DOI" value="10.1109/MC.1984.1659158"/> <seriesInfo name="DOI" value="10.1109/MC.1984.1659158"/>
</reference> </reference>
<reference anchor="RFC5280" target="https://www.rfc-editor.org/info/
rfc5280"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5280.
<front> xml"/>
<title>Internet X.509 Public Key Infrastructure Certificate an
d
Certificate Revocation List (CRL) Profile</title>
<author initials="D." surname="Cooper" fullname="D. Cooper"/>
<author initials="S." surname="Santesson" fullname="S. Santess
on"/>
<author initials="S." surname="Farrell" fullname="S. Farrell"/
>
<author initials="S." surname="Boeyen" fullname="S. Boeyen"/>
<author initials="R." surname="Housley" fullname="R. Housley"/
>
<author initials="W." surname="Polk" fullname="W. Polk"/>
<date year="2008" month="May"/>
</front>
<seriesInfo name="RFC" value="5280"/>
<seriesInfo name="DOI" value="10.17487/RFC5280"/>
</reference>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<reference anchor="HTTP11"><!--included from draft-ietf-httpbis-mess
aging-latest.xml--> <reference anchor="HTTP11" target='https://www.rfc-editor.org/info/r
fc9112'>
<front> <front>
<title>HTTP/1.1</title> <title>HTTP/1.1</title>
<author fullname="Roy T. Fielding" <author initials="R." surname="Fielding" fullname="Roy T. Fiel
initials="R." ding" role="editor">
surname="Fielding"
role="editor">
<organization>Adobe</organization> <organization>Adobe</organization>
<address>
<postal>
<postalLine>345 Park Ave</postalLine>
<postalLine>San Jose, CA 95110</postalLine>
<postalLine>United States of America</postalLine>
</postal>
<email>fielding@gbiv.com</email>
<uri>https://roy.gbiv.com/</uri>
</address>
</author> </author>
<author fullname="Mark Nottingham" <author initials="M." surname="Nottingham" fullname="Mark Nott
initials="M." ingham" role="editor">
surname="Nottingham"
role="editor">
<organization>Fastly</organization> <organization>Fastly</organization>
<address>
<postal>
<postalLine>Prahran VIC</postalLine>
<postalLine>Australia</postalLine>
</postal>
<email>mnot@mnot.net</email>
<uri>https://www.mnot.net/</uri>
</address>
</author> </author>
<author fullname="Julian Reschke" <author initials="J." surname="Reschke" fullname="Julian Resch
initials="J." ke" role="editor">
surname="Reschke" <organization>greenbytes GmbH</organization>
role="editor">
<organization abbrev="greenbytes">greenbytes GmbH</organiza
tion>
<address>
<postal>
<postalLine>Hafenweg 16</postalLine>
<postalLine>48155 Münster</postalLine>
<postalLine>Germany</postalLine>
</postal>
<email>julian.reschke@greenbytes.de</email>
<uri>https://greenbytes.de/tech/webdav/</uri>
</address>
</author> </author>
<date year="2021" month="September" day="10"/> <date month="June" year="2022"/>
</front> </front>
<seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-messa <seriesInfo name="STD" value="99"/>
ging-19"/> <seriesInfo name="RFC" value="9112"/>
<seriesInfo name="DOI" value="10.17487/RFC9112"/>
</reference> </reference>
<reference anchor="Err1912" <reference anchor="Err1912"
target="https://www.rfc-editor.org/errata/eid1912" target="https://www.rfc-editor.org/errata/eid1912"
quote-title="false"> quote-title="false">
<front> <front>
<title>Erratum ID 1912, RFC 2978</title> <title>Erratum ID 1912</title>
<author> <author>
<organization>RFC Errata</organization> <organization>RFC Errata</organization>
</author> </author>
<date/> <date/>
</front> </front>
<refcontent>RFC 2978</refcontent>
</reference> </reference>
<reference anchor="Err5433" <reference anchor="Err5433"
target="https://www.rfc-editor.org/errata/eid5433" target="https://www.rfc-editor.org/errata/eid5433"
quote-title="false"> quote-title="false">
<front> <front>
<title>Erratum ID 5433, RFC 2978</title> <title>Erratum ID 5433</title>
<author> <author>
<organization>RFC Errata</organization> <organization>RFC Errata</organization>
</author> </author>
<date/> <date/>
</front> </front>
<refcontent>RFC 2978</refcontent>
</reference> </reference>
<reference anchor="BREACH" <reference anchor="BREACH"
target="http://breachattack.com/resources/BREACH%20-%20SS L,%20gone%20in%2030%20seconds.pdf"> target="http://breachattack.com/resources/BREACH%20-%20SS L,%20gone%20in%2030%20seconds.pdf">
<front> <front>
<title>BREACH: Reviving the CRIME Attack</title> <title>BREACH: Reviving the CRIME Attack</title>
<author initials="Y." surname="Gluck" fullname="Yoel Gluck"/> <author initials="Y." surname="Gluck" fullname="Yoel Gluck"/>
<author initials="N." surname="Harris" fullname="Neal Harris"/ > <author initials="N." surname="Harris" fullname="Neal Harris"/ >
<author initials="A." surname="Prado" fullname="Angelo Prado"/ > <author initials="A." surname="Prado" fullname="Angelo Prado"/ >
<date year="2013" month="July"/> <date year="2013" month="July"/>
</front> </front>
</reference> </reference>
<reference anchor="Bujlow"> <reference anchor="Bujlow">
<front> <front>
<title>A Survey on Web Tracking: Mechanisms, Implications, and Defenses</title> <title>A Survey on Web Tracking: Mechanisms, Implications, and Defenses</title>
<author initials="T." surname="Bujlow" fullname="Tomasz Bujlow "/> <author initials="T." surname="Bujlow" fullname="Tomasz Bujlow "/>
<author initials="V." <author initials="V."
surname="Carela-Espanol" surname="Carela-Español"
fullname="Valentin Carela-Espanol"/> fullname="Valentin Carela-Español"/>
<author initials="J." surname="Sole-Pareta" fullname="Josep So <author initials="J." surname="Solé-Pareta" fullname="Josep So
le-Pareta"/> lé-Pareta"/>
<author initials="P." surname="Barlet-Ros" fullname="Pere Barl et-Ros"/> <author initials="P." surname="Barlet-Ros" fullname="Pere Barl et-Ros"/>
<date year="2017" month="August"/> <date year="2017" month="August"/>
</front> </front>
<seriesInfo name="DOI" value="10.1109/JPROC.2016.2637878"/> <seriesInfo name="DOI" value="10.1109/JPROC.2016.2637878"/>
<seriesInfo name="Proceedings of the IEEE" value="105(8)"/> <refcontent>In Proceedings of the IEEE 105(8)</refcontent>
</reference> </reference>
<reference anchor="Georgiev"> <reference anchor="Georgiev">
<front> <front>
<title>The Most Dangerous Code in the World: Validating SSL Ce rtificates in Non-browser Software</title> <title>The Most Dangerous Code in the World: Validating SSL Ce rtificates in Non-Browser Software</title>
<author initials="M." surname="Georgiev" fullname="Martin Geor giev"/> <author initials="M." surname="Georgiev" fullname="Martin Geor giev"/>
<author initials="S." surname="Iyengar" fullname="Subodh Iyeng ar"/> <author initials="S." surname="Iyengar" fullname="Subodh Iyeng ar"/>
<author initials="S." surname="Jana" fullname="Suman Jana"/> <author initials="S." surname="Jana" fullname="Suman Jana"/>
<author initials="R." surname="Anubhai" fullname="Rishita Anub hai"/> <author initials="R." surname="Anubhai" fullname="Rishita Anub hai"/>
<author initials="D." surname="Boneh" fullname="Dan Boneh"/> <author initials="D." surname="Boneh" fullname="Dan Boneh"/>
<author initials="V." surname="Shmatikov" fullname="Vitaly Shm atikov"/> <author initials="V." surname="Shmatikov" fullname="Vitaly Shm atikov"/>
<date year="2012" month="October"/> <date year="2012" month="October"/>
</front> </front>
<seriesInfo name="DOI" value="10.1145/2382196.2382204"/> <seriesInfo name="DOI" value="10.1145/2382196.2382204"/>
<refcontent>In Proceedings of the 2012 ACM Conference on Computer and Communications Security (CCS '12), pp. 38-49</refcontent> <refcontent>In Proceedings of the 2012 ACM Conference on Computer and Communications Security (CCS '12), pp. 38-49</refcontent>
skipping to change at line 12142 skipping to change at line 11961
<date year="1998"/> <date year="1998"/>
</front> </front>
<seriesInfo name="ISO/IEC" value="8859-1:1998"/> <seriesInfo name="ISO/IEC" value="8859-1:1998"/>
</reference> </reference>
<reference anchor="Kri2001" target="http://arxiv.org/abs/cs.SE/01050 18"> <reference anchor="Kri2001" target="http://arxiv.org/abs/cs.SE/01050 18">
<front> <front>
<title>HTTP Cookies: Standards, Privacy, and Politics</title> <title>HTTP Cookies: Standards, Privacy, and Politics</title>
<author initials="D." surname="Kristol" fullname="David M. Kri stol"/> <author initials="D." surname="Kristol" fullname="David M. Kri stol"/>
<date year="2001" month="November"/> <date year="2001" month="November"/>
</front> </front>
<seriesInfo name="ACM Transactions on Internet Technology" value= "1(2)"/> <refcontent>ACM Transactions on Internet Technology 1(2)</refcont ent>
</reference> </reference>
<reference anchor="Sniffing" target="https://mimesniff.spec.whatwg.o rg"> <reference anchor="Sniffing" target="https://mimesniff.spec.whatwg.o rg">
<front> <front>
<title>MIME Sniffing</title> <title>MIME Sniffing</title>
<author> <author>
<organization>WHATWG</organization> <organization>WHATWG</organization>
</author> </author>
<date/> <date/>
</front> </front>
</reference> </reference>
<reference anchor="REST" target="https://roy.gbiv.com/pubs/dissertat ion/top.htm"> <reference anchor="REST" target="https://roy.gbiv.com/pubs/dissertat ion/top.htm">
<front> <front>
<title>Architectural Styles and the Design of Network-based So ftware Architectures</title> <title>Architectural Styles and the Design of Network-based So ftware Architectures</title>
<author initials="R.T." surname="Fielding" fullname="Roy T. Fi elding"/> <author initials="R.T." surname="Fielding" fullname="Roy T. Fi elding"/>
<date month="September" year="2000"/> <date month="September" year="2000"/>
</front> </front>
<refcontent>Doctoral Dissertation, University of California, Irvi ne</refcontent> <refcontent>Doctoral Dissertation, University of California, Irvi ne</refcontent>
</reference> </reference>
<reference anchor="RFC1919" target="https://www.rfc-editor.org/info/
rfc1919"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1919.
<front> xml"/>
<title>Classical versus Transparent IP Proxies</title>
<author initials="M." surname="Chatel" fullname="Marc Chatel"/
>
<date year="1996" month="March"/>
</front>
<seriesInfo name="RFC" value="1919"/>
<seriesInfo name="DOI" value="10.17487/RFC1919"/>
</reference>
<reference anchor="HTTP10" target="https://www.rfc-editor.org/info/r fc1945"> <reference anchor="HTTP10" target="https://www.rfc-editor.org/info/r fc1945">
<front> <front>
<title abbrev="HTTP/1.0">Hypertext Transfer Protocol -- HTTP/1 .0</title> <title abbrev="HTTP/1.0">Hypertext Transfer Protocol -- HTTP/1 .0</title>
<author initials="T." surname="Berners-Lee" fullname="Tim Bern <author initials="T." surname="Berners-Lee" fullname="T. Berne
ers-Lee"/> rs-Lee"/>
<author initials="R.T." surname="Fielding" fullname="Roy T. Fi <author initials="R." surname="Fielding" fullname="R. Fielding
elding"/> "/>
<author initials="H.F." surname="Nielsen" fullname="Henrik Fry <author initials="H." surname="Frystyk" fullname="H. Frystyk"/
styk Nielsen"/> >
<date month="May" year="1996"/> <date month="May" year="1996"/>
</front> </front>
<seriesInfo name="RFC" value="1945"/> <seriesInfo name="RFC" value="1945"/>
<seriesInfo name="DOI" value="10.17487/RFC1945"/> <seriesInfo name="DOI" value="10.17487/RFC1945"/>
</reference> </reference>
<reference anchor="RFC2047" target="https://www.rfc-editor.org/info/ <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2047.
rfc2047"> xml"/>
<front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2068.
<title abbrev="Message Header Extensions">MIME (Multipurpose I xml"/>
nternet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Tex <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2145.
t</title> xml"/>
<author initials="K." surname="Moore" fullname="Keith Moore"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2295.
<date month="November" year="1996"/> xml"/>
</front>
<seriesInfo name="RFC" value="2047"/>
<seriesInfo name="DOI" value="10.17487/RFC2047"/>
</reference>
<reference anchor="RFC2068" target="https://www.rfc-editor.org/info/
rfc2068">
<front>
<title>Hypertext Transfer Protocol -- HTTP/1.1</title>
<author initials="R." surname="Fielding" fullname="Roy T. Fiel
ding"/>
<author initials="J." surname="Gettys" fullname="Jim Gettys"/>
<author initials="J." surname="Mogul" fullname="Jeffrey C. Mog
ul"/>
<author initials="H." surname="Nielsen" fullname="Henrik Fryst
yk Nielsen"/>
<author initials="T." surname="Berners-Lee" fullname="Tim Bern
ers-Lee"/>
<date month="January" year="1997"/>
</front>
<seriesInfo name="RFC" value="2068"/>
<seriesInfo name="DOI" value="10.17487/RFC2068"/>
</reference>
<reference anchor="RFC2145" target="https://www.rfc-editor.org/info/
rfc2145">
<front>
<title abbrev="HTTP Version Numbers">Use and Interpretation of
HTTP Version Numbers</title>
<author initials="J.C." surname="Mogul" fullname="Jeffrey C. M
ogul"/>
<author initials="R.T." surname="Fielding" fullname="Roy T. Fi
elding"/>
<author initials="J." surname="Gettys" fullname="Jim Gettys"/>
<author initials="H.F." surname="Nielsen" fullname="Henrik Fry
styk Nielsen"/>
<date month="May" year="1997"/>
</front>
<seriesInfo name="RFC" value="2145"/>
<seriesInfo name="DOI" value="10.17487/RFC2145"/>
</reference>
<reference anchor="RFC2295" target="https://www.rfc-editor.org/info/
rfc2295">
<front>
<title abbrev="HTTP Content Negotiation">Transparent Content N
egotiation in HTTP</title>
<author initials="K." surname="Holtman" fullname="Koen Holtman
"/>
<author initials="A.H." surname="Mutz" fullname="Andrew H. Mut
z"/>
<date year="1998" month="March"/>
</front>
<seriesInfo name="RFC" value="2295"/>
<seriesInfo name="DOI" value="10.17487/RFC2295"/>
</reference>
<reference anchor="RFC2324" target="https://www.rfc-editor.org/info/ rfc2324"> <reference anchor="RFC2324" target="https://www.rfc-editor.org/info/ rfc2324">
<front> <front>
<title>Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)</ti tle> <title>Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)</ti tle>
<author initials="L." surname="Masinter" fullname="L. Masinter "/> <author initials="L." surname="Masinter" fullname="L. Masinter "/>
<date year="1998" month="April" day="1"/> <date year="1998" month="April" day="1"/>
</front> </front>
<seriesInfo name="RFC" value="2324"/> <seriesInfo name="RFC" value="2324"/>
<seriesInfo name="DOI" value="10.17487/RFC2324"/> <seriesInfo name="DOI" value="10.17487/RFC2324"/>
</reference> </reference>
<reference anchor="RFC2557" target="https://www.rfc-editor.org/info/ <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2557.
rfc2557"> xml"/>
<front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2616.
<title abbrev="MIME Encapsulation of Aggregate Documents">MIME xml"/>
Encapsulation of Aggregate Documents, such as HTML (MHTML)</title> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2617.
<author initials="F." surname="Palme" fullname="Jacob Palme"/> xml"/>
<author initials="A." surname="Hopmann" fullname="Alex Hopmann <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2774.
"/> xml"/>
<author initials="N." surname="Shelness" fullname="Nick Shelne <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2818.
ss"/> xml"/>
<author initials="E." surname="Stefferud" fullname="Einar Stef <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2978.
ferud"/> xml"/>
<date year="1999" month="March"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3040.
</front> xml"/>
<seriesInfo name="RFC" value="2557"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4033.
<seriesInfo name="DOI" value="10.17487/RFC2557"/> xml"/>
</reference> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4559.
<reference anchor="RFC2616" target="https://www.rfc-editor.org/info/ xml"/>
rfc2616">
<front>
<title>Hypertext Transfer Protocol -- HTTP/1.1</title>
<author initials="R." surname="Fielding" fullname="R. Fielding
"/>
<author initials="J." surname="Gettys" fullname="J. Gettys"/>
<author initials="J." surname="Mogul" fullname="J. Mogul"/>
<author initials="H." surname="Frystyk" fullname="H. Frystyk"/
>
<author initials="L." surname="Masinter" fullname="L. Masinter
"/>
<author initials="P." surname="Leach" fullname="P. Leach"/>
<author initials="T." surname="Berners-Lee" fullname="T. Berne
rs-Lee"/>
<date month="June" year="1999"/>
</front>
<seriesInfo name="RFC" value="2616"/>
<seriesInfo name="DOI" value="10.17487/RFC2616"/>
</reference>
<reference anchor="RFC2617" target="https://www.rfc-editor.org/info/
rfc2617">
<front>
<title abbrev="HTTP Authentication">HTTP Authentication: Basic
and Digest Access Authentication</title>
<author initials="J." surname="Franks" fullname="John Franks"/
>
<author initials="P.M."
surname="Hallam-Baker"
fullname="Phillip M. Hallam-Baker"/>
<author initials="J.L." surname="Hostetler" fullname="Jeffery
L. Hostetler"/>
<author initials="S.D." surname="Lawrence" fullname="Scott D.
Lawrence"/>
<author initials="P.J." surname="Leach" fullname="Paul J. Leac
h"/>
<author initials="A." surname="Luotonen" fullname="Ari Luotone
n"/>
<author initials="L." surname="Stewart" fullname="Lawrence C.
Stewart"/>
<date month="June" year="1999"/>
</front>
<seriesInfo name="RFC" value="2617"/>
<seriesInfo name="DOI" value="10.17487/RFC2617"/>
</reference>
<reference anchor="RFC2774" target="https://www.rfc-editor.org/info/
rfc2774">
<front>
<title>An HTTP Extension Framework</title>
<author initials="H." surname="Frystyk" fullname="H. Frystyk"/
>
<author initials="P." surname="Leach" fullname="Paul J. Leach"
/>
<author initials="S." surname="Lawrence" fullname="Scott Lawre
nce"/>
<date year="2000" month="February"/>
</front>
<seriesInfo name="RFC" value="2774"/>
<seriesInfo name="DOI" value="10.17487/RFC2774"/>
</reference>
<reference anchor="RFC2818" target="https://www.rfc-editor.org/info/
rfc2818">
<front>
<title>HTTP Over TLS</title>
<author initials="E." surname="Rescorla" fullname="Eric Rescor
la"/>
<date year="2000" month="May"/>
</front>
<seriesInfo name="RFC" value="2818"/>
<seriesInfo name="DOI" value="10.17487/RFC2818"/>
</reference>
<reference anchor="RFC2978" target="https://www.rfc-editor.org/info/
rfc2978">
<front>
<title>IANA Charset Registration Procedures</title>
<author initials="N." surname="Freed" fullname="N. Freed"/>
<author initials="J." surname="Postel" fullname="J. Postel"/>
<date year="2000" month="October"/>
</front>
<seriesInfo name="BCP" value="19"/>
<seriesInfo name="RFC" value="2978"/>
<seriesInfo name="DOI" value="10.17487/RFC2978"/>
</reference>
<reference anchor="RFC3040" target="https://www.rfc-editor.org/info/
rfc3040">
<front>
<title>Internet Web Replication and Caching Taxonomy</title>
<author initials="I." surname="Cooper" fullname="I. Cooper"/>
<author initials="I." surname="Melve" fullname="I. Melve"/>
<author initials="G." surname="Tomlinson" fullname="G. Tomlins
on"/>
<date year="2001" month="January"/>
</front>
<seriesInfo name="RFC" value="3040"/>
<seriesInfo name="DOI" value="10.17487/RFC3040"/>
</reference>
<reference anchor="RFC4033" target="https://www.rfc-editor.org/info/
rfc4033">
<front>
<title>DNS Security Introduction and Requirements</title>
<author initials="R." surname="Arends" fullname="R. Arends"/>
<author initials="R." surname="Austein" fullname="R. Austein"/
>
<author initials="M." surname="Larson" fullname="M. Larson"/>
<author initials="D." surname="Massey" fullname="D. Massey"/>
<author initials="S." surname="Rose" fullname="S. Rose"/>
<date year="2005" month="March"/>
</front>
<seriesInfo name="RFC" value="4033"/>
<seriesInfo name="DOI" value="10.17487/RFC4033"/>
</reference>
<reference anchor="RFC4559" target="https://www.rfc-editor.org/info/
rfc4559">
<front>
<title>SPNEGO-based Kerberos and NTLM HTTP Authentication in M
icrosoft Windows</title>
<author initials="K." surname="Jaganathan" fullname="K. Jagana
than"/>
<author initials="L." surname="Zhu" fullname="L. Zhu"/>
<author initials="J." surname="Brezak" fullname="J. Brezak"/>
<date year="2006" month="June"/>
</front>
<seriesInfo name="RFC" value="4559"/>
<seriesInfo name="DOI" value="10.17487/RFC4559"/>
</reference>
<reference anchor="WEBDAV" target="https://www.rfc-editor.org/info/r fc4918"> <reference anchor="WEBDAV" target="https://www.rfc-editor.org/info/r fc4918">
<front> <front>
<title>HTTP Extensions for Web Distributed Authoring and Versi oning (WebDAV)</title> <title>HTTP Extensions for Web Distributed Authoring and Versi oning (WebDAV)</title>
<author initials="L.M." <author initials="L." surname="Dusseault" fullname="Lisa Dusse
surname="Dusseault" ault" role="editor"/>
fullname="Lisa Dusseault"
role="editor"/>
<date month="June" year="2007"/> <date month="June" year="2007"/>
</front> </front>
<seriesInfo name="RFC" value="4918"/> <seriesInfo name="RFC" value="4918"/>
<seriesInfo name="DOI" value="10.17487/RFC4918"/> <seriesInfo name="DOI" value="10.17487/RFC4918"/>
</reference> </reference>
<reference anchor="HTTP2" target="https://www.rfc-editor.org/info/rf c7540"> <reference anchor="HTTP2" target="https://www.rfc-editor.org/info/rf c9113">
<front> <front>
<title>Hypertext Transfer Protocol Version 2 (HTTP/2)</title> <title>HTTP/2</title>
<author initials="M." surname="Belshe" fullname="M. Belshe"/>
<author initials="R." surname="Peon" fullname="R. Peon"/>
<author initials="M." <author initials="M."
surname="Thomson" surname="Thomson"
fullname="M. Thomson" fullname="Martin Thomson"
role="editor"/> role="editor"/>
<date year="2015" month="May"/> <author initials="C."
surname="Benfield"
fullname="Cory Benfield"
role="editor"/>
<date year="2022" month="June"/>
</front> </front>
<seriesInfo name="RFC" value="7540"/> <seriesInfo name="RFC" value="9113"/>
<seriesInfo name="DOI" value="10.17487/RFC7540"/> <seriesInfo name="DOI" value="10.17487/RFC9113"/>
</reference> </reference>
<reference anchor="HPACK" target="https://www.rfc-editor.org/info/rf c7541"> <reference anchor="HPACK" target="https://www.rfc-editor.org/info/rf c7541">
<front> <front>
<title>HPACK: Header Compression for HTTP/2</title> <title>HPACK: Header Compression for HTTP/2</title>
<author initials="R." surname="Peon" fullname="R. Peon"/> <author initials="R." surname="Peon" fullname="R. Peon"/>
<author initials="H." surname="Ruellan" fullname="H. Ruellan"/ > <author initials="H." surname="Ruellan" fullname="H. Ruellan"/ >
<date year="2015" month="May"/> <date year="2015" month="May"/>
</front> </front>
<seriesInfo name="RFC" value="7541"/> <seriesInfo name="RFC" value="7541"/>
<seriesInfo name="DOI" value="10.17487/RFC7541"/> <seriesInfo name="DOI" value="10.17487/RFC7541"/>
</reference> </reference>
<reference anchor="RFC5905" target="https://www.rfc-editor.org/info/ <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5905.
rfc5905"> xml"/>
<front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6454.
<title>Network Time Protocol Version 4: Protocol and Algorithm xml"/>
s Specification</title> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7230.
<author initials="D." surname="Mills" fullname="David L. Mills xml"/>
"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7231.
<author initials="J." xml"/>
surname="Martin" <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7232.
fullname="Jim Martin" xml"/>
role="editor"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7233.
<author initials="J." surname="Burbank" fullname="Jack Burbank xml"/>
"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7234.
<author initials="W." surname="Kasch" fullname="William Kasch" xml"/>
/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7235.
<date year="2010" month="June"/> xml"/>
</front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7578.
<seriesInfo name="RFC" value="5905"/> xml"/>
<seriesInfo name="DOI" value="10.17487/RFC5905"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7615.
</reference> xml"/>
<reference anchor="RFC6454" target="https://www.rfc-editor.org/info/
rfc6454">
<front>
<title>The Web Origin Concept</title>
<author initials="A." surname="Barth" fullname="A. Barth"/>
<date year="2011" month="December"/>
</front>
<seriesInfo name="RFC" value="6454"/>
<seriesInfo name="DOI" value="10.17487/RFC6454"/>
</reference>
<reference anchor="RFC7230" target="https://www.rfc-editor.org/info/
rfc7230">
<front>
<title>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax
and Routing</title>
<author initials="R."
surname="Fielding"
fullname="Roy T. Fielding"
role="editor"/>
<author initials="J. F."
surname="Reschke"
fullname="Julian F. Reschke"
role="editor"/>
<date month="June" year="2014"/>
</front>
<seriesInfo name="RFC" value="7230"/>
<seriesInfo name="DOI" value="10.17487/RFC7230"/>
</reference>
<reference anchor="RFC7231" target="https://www.rfc-editor.org/info/
rfc7231">
<front>
<title>Hypertext Transfer Protocol (HTTP/1.1): Semantics and C
ontent</title>
<author initials="R."
surname="Fielding"
fullname="Roy T. Fielding"
role="editor"/>
<author initials="J. F."
surname="Reschke"
fullname="Julian F. Reschke"
role="editor"/>
<date month="June" year="2014"/>
</front>
<seriesInfo name="RFC" value="7231"/>
<seriesInfo name="DOI" value="10.17487/RFC7231"/>
</reference>
<reference anchor="RFC7232" target="https://www.rfc-editor.org/info/
rfc7232">
<front>
<title>Hypertext Transfer Protocol (HTTP/1.1): Conditional Req
uests</title>
<author fullname="Roy T. Fielding"
initials="R."
role="editor"
surname="Fielding"/>
<author fullname="Julian F. Reschke"
initials="J. F."
role="editor"
surname="Reschke"/>
<date month="June" year="2014"/>
</front>
<seriesInfo name="RFC" value="7232"/>
<seriesInfo name="DOI" value="10.17487/RFC7232"/>
</reference>
<reference anchor="RFC7233" target="https://www.rfc-editor.org/info/
rfc7233">
<front>
<title>Hypertext Transfer Protocol (HTTP/1.1): Range Requests<
/title>
<author initials="R."
surname="Fielding"
fullname="Roy T. Fielding"
role="editor"/>
<author initials="Y."
surname="Lafon"
fullname="Yves Lafon"
role="editor"/>
<author initials="J. F."
surname="Reschke"
fullname="Julian F. Reschke"
role="editor"/>
<date month="June" year="2014"/>
</front>
<seriesInfo name="RFC" value="7233"/>
<seriesInfo name="DOI" value="10.17487/RFC7233"/>
</reference>
<reference anchor="RFC7234" target="https://www.rfc-editor.org/info/
rfc7234">
<front>
<title>Hypertext Transfer Protocol (HTTP): Caching</title>
<author initials="R."
surname="Fielding"
fullname="Roy T. Fielding"
role="editor"/>
<author initials="M."
surname="Nottingham"
fullname="Mark Nottingham"
role="editor"/>
<author initials="J. F."
surname="Reschke"
fullname="Julian F. Reschke"
role="editor"/>
<date month="June" year="2014"/>
</front>
<seriesInfo name="RFC" value="7234"/>
<seriesInfo name="DOI" value="10.17487/RFC7234"/>
</reference>
<reference anchor="RFC7235" target="https://www.rfc-editor.org/info/
rfc7235">
<front>
<title>Hypertext Transfer Protocol (HTTP/1.1): Authentication<
/title>
<author initials="R."
surname="Fielding"
fullname="Roy T. Fielding"
role="editor"/>
<author initials="J. F."
surname="Reschke"
fullname="Julian F. Reschke"
role="editor"/>
<date month="June" year="2014"/>
</front>
<seriesInfo name="RFC" value="7235"/>
<seriesInfo name="DOI" value="10.17487/RFC7235"/>
</reference>
<reference anchor="RFC7578" target="https://www.rfc-editor.org/info/
rfc7578">
<front>
<title>Returning Values from Forms: multipart/form-data</title
>
<author initials="L." surname="Masinter" fullname="Larry Masin
ter"/>
<date year="2015" month="July"/>
</front>
<seriesInfo name="RFC" value="7578"/>
<seriesInfo name="DOI" value="10.17487/RFC7578"/>
</reference>
<reference anchor="RFC7615" target="https://www.rfc-editor.org/info/
rfc7615">
<front>
<title>HTTP Authentication-Info and Proxy-Authentication-Info
Response Header Fields</title>
<author initials="J. F." surname="Reschke" fullname="Julian F.
Reschke"/>
<date year="2015" month="September"/>
</front>
<seriesInfo name="RFC" value="7615"/>
<seriesInfo name="DOI" value="10.17487/RFC7615"/>
</reference>
<reference anchor="ALTSVC" target="https://www.rfc-editor.org/info/r fc7838"> <reference anchor="ALTSVC" target="https://www.rfc-editor.org/info/r fc7838">
<front> <front>
<title>HTTP Alternative Services</title> <title>HTTP Alternative Services</title>
<author initials="M." surname="Nottingham" fullname="M. Nottin gham"/> <author initials="M." surname="Nottingham" fullname="M. Nottin gham"/>
<author initials="P." surname="McManus" fullname="P. McManus"/ > <author initials="P." surname="McManus" fullname="P. McManus"/ >
<author initials="J." surname="Reschke" fullname="J. Reschke"/ > <author initials="J." surname="Reschke" fullname="J. Reschke"/ >
<date year="2016" month="April"/> <date year="2016" month="April"/>
</front> </front>
<seriesInfo name="RFC" value="7838"/> <seriesInfo name="RFC" value="7838"/>
<seriesInfo name="DOI" value="10.17487/RFC7838"/> <seriesInfo name="DOI" value="10.17487/RFC7838"/>
</reference> </reference>
<reference anchor="RFC8336" target="https://www.rfc-editor.org/info/ <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8336.
rfc8336"> xml"/>
<front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8615.
<title>The ORIGIN HTTP/2 Frame</title> xml"/>
<author initials="M." surname="Nottingham" fullname="M. Nottin
gham"/> <reference anchor='HTTP3' target='https://www.rfc-editor.org/info/rf
<author initials="E." surname="Nygren" fullname="E. Nygren"/> c9114'>
<date year="2018" month="March"/>
</front>
<seriesInfo name="RFC" value="8336"/>
<seriesInfo name="DOI" value="10.17487/RFC8336"/>
</reference>
<reference anchor="RFC8615" target="https://www.rfc-editor.org/info/
rfc8615">
<front>
<title>Well-Known Uniform Resource Identifiers (URIs)</title>
<author initials="M." surname="Nottingham" fullname="M. Nottin
gham"/>
<date year="2019" month="May"/>
</front>
<seriesInfo name="RFC" value="8615"/>
<seriesInfo name="DOI" value="10.17487/RFC8615"/>
</reference>
<reference anchor="HTTP3">
<front>
<title>Hypertext Transfer Protocol Version 3 (HTTP/3)</title>
<author initials="M." surname="Bishop" fullname="Mike Bishop"/
>
<date year="2021" month="February" day="2"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-quic-http-34"
/>
</reference>
<reference anchor="BCP13" target="https://www.rfc-editor.org/info/bc
p13">
<front>
<title>Media Type Specifications and Registration Procedures</
title>
<author initials="N." surname="Freed" fullname="Ned Freed"/>
<author initials="J." surname="Klensin" fullname="John C. Klen
sin"/>
<author initials="T." surname="Hansen" fullname="Tony Hansen"/
>
<date year="2013" month="January"/>
</front>
<seriesInfo name="BCP" value="13"/>
<seriesInfo name="RFC" value="6838"/>
</reference>
<reference anchor="BCP35" target="https://www.rfc-editor.org/info/bc
p35">
<front> <front>
<title>Guidelines and Registration Procedures for URI Schemes< <title>HTTP/3</title>
/title> <author initials="M."
<author initials="D." surname="Bishop"
surname="Thaler" fullname="Mike Bishop"
fullname="Dave Thaler"
role="editor"/> role="editor"/>
<author initials="T." surname="Hansen" fullname="Tony Hansen"/ <date year="2022" month="June"/>
>
<author initials="T." surname="Hardie" fullname="Ted Hardie"/>
<date year="2015" month="June"/>
</front>
<seriesInfo name="BCP" value="35"/>
<seriesInfo name="RFC" value="7595"/>
</reference>
<reference anchor="BCP178" target="https://www.rfc-editor.org/info/b
cp178">
<front>
<title>Deprecating the "X-" Prefix and Similar Constructs in A
pplication Protocols</title>
<author initials="P." surname="Saint-Andre" fullname="Peter Sa
int-Andre"/>
<author initials="D." surname="Crocker" fullname="Dave Crocker
"/>
<author initials="M." surname="Nottingham" fullname="Mark Nott
ingham"/>
<date year="2012" month="June"/>
</front> </front>
<seriesInfo name="BCP" value="178"/> <seriesInfo name="RFC" value="9114"/>
<seriesInfo name="RFC" value="6648"/> <seriesInfo name="DOI" value="10.17487/RFC9114"/>
</reference> </reference>
<referencegroup anchor="BCP13" target="https://www.rfc-editor.org/in
fo/bcp13">
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/refe
rence.RFC.4289.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/refe
rence.RFC.6838.xml"/>
</referencegroup>
<referencegroup anchor="BCP35" target="https://www.rfc-editor.org/in
fo/bcp35">
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/refe
rence.RFC.7595.xml"/>
</referencegroup>
<referencegroup anchor="BCP178" target="https://www.rfc-editor.org/i
nfo/bcp178">
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/refe
rence.RFC.6648.xml"/>
</referencegroup>
<reference anchor="RFC3864" target="https://www.rfc-editor.org/info/ rfc3864"> <reference anchor="RFC3864" target="https://www.rfc-editor.org/info/ rfc3864">
<front> <front>
<title>Registration Procedures for Message Header Fields</titl e> <title>Registration Procedures for Message Header Fields</titl e>
<author initials="G." surname="Klyne" fullname="G. Klyne"/> <author initials="G." surname="Klyne" fullname="G. Klyne"/>
<author initials="M." surname="Nottingham" fullname="M. Nottin gham"/> <author initials="M." surname="Nottingham" fullname="M. Nottin gham"/>
<author initials="J." surname="Mogul" fullname="J. Mogul"/> <author initials="J." surname="Mogul" fullname="J. Mogul"/>
<date year="2004" month="September"/> <date year="2004" month="September"/>
</front> </front>
<seriesInfo name="BCP" value="90"/> <seriesInfo name="BCP" value="90"/>
<seriesInfo name="RFC" value="3864"/> <seriesInfo name="RFC" value="3864"/>
skipping to change at line 12641 skipping to change at line 12141
</reference> </reference>
<reference anchor="COOKIE" target="https://www.rfc-editor.org/info/r fc6265"> <reference anchor="COOKIE" target="https://www.rfc-editor.org/info/r fc6265">
<front> <front>
<title>HTTP State Management Mechanism</title> <title>HTTP State Management Mechanism</title>
<author initials="A." surname="Barth" fullname="Adam Barth"/> <author initials="A." surname="Barth" fullname="Adam Barth"/>
<date year="2011" month="April"/> <date year="2011" month="April"/>
</front> </front>
<seriesInfo name="RFC" value="6265"/> <seriesInfo name="RFC" value="6265"/>
<seriesInfo name="DOI" value="10.17487/RFC6265"/> <seriesInfo name="DOI" value="10.17487/RFC6265"/>
</reference> </reference>
<reference anchor="RFC6585" target="https://www.rfc-editor.org/info/ <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6585.
rfc6585"> xml"/>
<front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7538.
<title>Additional HTTP Status Codes</title> xml"/>
<author initials="M." surname="Nottingham" fullname="M. Nottin <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7540.
gham"/> xml"/>
<author initials="R." surname="Fielding" fullname="R. Fielding <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7616.
"/> xml"/>
<date year="2012" month="April"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7617.
</front> xml"/>
<seriesInfo name="RFC" value="6585"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7694.
<seriesInfo name="DOI" value="10.17487/RFC6585"/> xml"/>
</reference> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126.
<reference anchor="RFC7538" target="https://www.rfc-editor.org/info/ xml"/>
rfc7538"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8187.
<front> xml"/>
<title>The Hypertext Transfer Protocol Status Code 308 (Perman <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8246.
ent Redirect)</title> xml"/>
<author initials="J. F." surname="Reschke" fullname="Julian F. <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8288.
Reschke"/> xml"/>
<date month="April" year="2015"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8941.
</front> xml"/>
<seriesInfo name="RFC" value="7538"/>
<seriesInfo name="DOI" value="10.17487/RFC7538"/> <reference anchor="OWASP" target="https://www.owasp.org/" quote-titl
</reference> e="false">
<reference anchor="RFC7616" target="https://www.rfc-editor.org/info/
rfc7616">
<front>
<title>HTTP Digest Access Authentication</title>
<author initials="R."
surname="Shekh-Yusef"
fullname="R. Shekh-Yusef"
role="editor"/>
<author initials="D." surname="Ahrens" fullname="D. Ahrens"/>
<author initials="S." surname="Bremer" fullname="S. Bremer"/>
<date year="2015" month="September"/>
</front>
<seriesInfo name="RFC" value="7616"/>
<seriesInfo name="DOI" value="10.17487/RFC7616"/>
</reference>
<reference anchor="RFC7617" target="https://www.rfc-editor.org/info/
rfc7617">
<front>
<title>The 'Basic' HTTP Authentication Scheme</title>
<author initials="J. F." surname="Reschke" fullname="Julian F.
Reschke"/>
<date year="2015" month="September"/>
</front>
<seriesInfo name="RFC" value="7617"/>
<seriesInfo name="DOI" value="10.17487/RFC7617"/>
</reference>
<reference anchor="RFC7694" target="https://www.rfc-editor.org/info/
rfc7694">
<front>
<title>Hypertext Transfer Protocol (HTTP) Client-Initiated Con
tent-Encoding</title>
<author initials="J. F." surname="Reschke" fullname="Julian F.
Reschke"/>
<date year="2015" month="November"/>
</front>
<seriesInfo name="RFC" value="7694"/>
<seriesInfo name="DOI" value="10.17487/RFC7694"/>
</reference>
<reference anchor="RFC8126" target="https://www.rfc-editor.org/info/
rfc8126">
<front>
<title>Guidelines for Writing an IANA Considerations Section i
n RFCs</title>
<author initials="M." surname="Cotton" fullname="M. Cotton"/>
<author initials="B." surname="Leiba" fullname="B. Leiba"/>
<author initials="T." surname="Narten" fullname="T. Narten"/>
<date year="2017" month="June"/>
</front>
<seriesInfo name="BCP" value="26"/>
<seriesInfo name="RFC" value="8126"/>
<seriesInfo name="DOI" value="10.17487/RFC8126"/>
</reference>
<reference anchor="RFC8187" target="https://www.rfc-editor.org/info/
rfc8187">
<front>
<title>Indicating Character Encoding and Language for HTTP Hea
der Field Parameters</title>
<author initials="J. F." surname="Reschke" fullname="Julian F.
Reschke"/>
<date month="September" year="2017"/>
</front>
<seriesInfo name="RFC" value="8187"/>
<seriesInfo name="DOI" value="10.17487/RFC8187"/>
</reference>
<reference anchor="RFC8246" target="https://www.rfc-editor.org/info/
rfc8246">
<front>
<title>HTTP Immutable Responses</title>
<author initials="P." surname="McManus" fullname="P. McManus"/
>
<date year="2017" month="September"/>
</front>
<seriesInfo name="RFC" value="8246"/>
<seriesInfo name="DOI" value="10.17487/RFC8246"/>
</reference>
<reference anchor="RFC8288" target="https://www.rfc-editor.org/info/
rfc8288">
<front>
<title>Web Linking</title>
<author initials="M." surname="Nottingham" fullname="M. Nottin
gham"/>
<date year="2017" month="October"/>
</front>
<seriesInfo name="RFC" value="8288"/>
<seriesInfo name="DOI" value="10.17487/RFC8288"/>
</reference>
<reference anchor="RFC8941" target="https://www.rfc-editor.org/info/
rfc8941">
<front>
<title>Structured Field Values for HTTP</title>
<author initials="M." surname="Nottingham" fullname="Mark Nott
ingham"/>
<author initials="P-H." surname="Kamp" fullname="Poul-Henning
Kamp"/>
<date month="February" year="2021"/>
</front>
<seriesInfo name="RFC" value="8941"/>
<seriesInfo name="DOI" value="10.17487/RFC8941"/>
</reference>
<reference anchor="OWASP" target="https://www.owasp.org/">
<front> <front>
<title abbrev="OWASP">A Guide to Building Secure Web Applicati <title>The Open Web Application Security Project</title>
ons and Web Services</title> <author>
<author role="editor" <organization/>
initials="A." </author>
surname="van der Stock" <date/>
fullname="Andrew van der Stock"/>
<date month="July" day="27" year="2005"/>
</front> </front>
<seriesInfo name="The Open Web Application Security Project (OWAS P)" value="2.0.1"/>
</reference> </reference>
</references> </references>
</references> </references>
<section anchor="collected.abnf" title="Collected ABNF"> <section anchor="collected.abnf" title="Collected ABNF">
<t>In the collected ABNF below, list rules are expanded as per <xref ta <t>In the collected ABNF below, list rules are expanded per <xref targe
rget="abnf.extension"/>.</t> t="abnf.extension"/>.</t>
<sourcecode type="abnf" name="draft-ietf-httpbis-semantics-latest.parse <sourcecode type="abnf" name="rfc9110.parsed-abnf"><![CDATA[Accept = [
d-abnf"><![CDATA[Accept = [ ( media-range [ weight ] ) *( OWS "," OWS ( media-ra ( media-range [ weight ] ) *( OWS "," OWS ( media-range [
nge [
weight ] ) ) ] weight ] ) ) ]
Accept-Charset = [ ( ( token / "*" ) [ weight ] ) *( OWS "," OWS ( ( Accept-Charset = [ ( ( token / "*" ) [ weight ] ) *( OWS "," OWS ( (
token / "*" ) [ weight ] ) ) ] token / "*" ) [ weight ] ) ) ]
Accept-Encoding = [ ( codings [ weight ] ) *( OWS "," OWS ( codings [ Accept-Encoding = [ ( codings [ weight ] ) *( OWS "," OWS ( codings [
weight ] ) ) ] weight ] ) ) ]
Accept-Language = [ ( language-range [ weight ] ) *( OWS "," OWS ( Accept-Language = [ ( language-range [ weight ] ) *( OWS "," OWS (
language-range [ weight ] ) ) ] language-range [ weight ] ) ) ]
Accept-Ranges = acceptable-ranges Accept-Ranges = acceptable-ranges
Allow = [ method *( OWS "," OWS method ) ] Allow = [ method *( OWS "," OWS method ) ]
Authentication-Info = [ auth-param *( OWS "," OWS auth-param ) ] Authentication-Info = [ auth-param *( OWS "," OWS auth-param ) ]
skipping to change at line 12982 skipping to change at line 12392
unsatisfied-range = "*/" complete-length unsatisfied-range = "*/" complete-length
uri-host = <host, see [URI], Section 3.2.2> uri-host = <host, see [URI], Section 3.2.2>
weak = %x57.2F ; W/ weak = %x57.2F ; W/
weight = OWS ";" OWS "q=" qvalue weight = OWS ";" OWS "q=" qvalue
year = 4DIGIT year = 4DIGIT
]]></sourcecode> ]]></sourcecode>
</section> </section>
<section anchor="changes.from.previous.rfcs" title="Changes from previous RFCs"> <section anchor="changes.from.previous.rfcs" title="Changes from Previous RFCs">
<section anchor="changes.from.rfc.2818" title="Changes from RFC 2818"> <section anchor="changes.from.rfc.2818" title="Changes from RFC 2818">
<t> <t>
None. None.
</t> </t>
</section> </section>
<section anchor="changes.from.rfc.7230" title="Changes from RFC 7230"> <section anchor="changes.from.rfc.7230" title="Changes from RFC 7230">
<t> <t>
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.
</t> </t>
<t> <t>
The requirement on semantic conformance has been replaced with permission to The requirement on semantic conformance has been replaced with permission to
ignore/workaround implementation-specific failures. ignore or work around implementation-specific failures.
(<xref target="requirements.notation"/>) (<xref target="requirements.notation"/>)
</t> </t>
<t> <t>
The description of an origin and authoritative access to origin servers has The description of an origin and authoritative access to origin servers has
been extended for both "http" and "https" URIs to account for alternative been extended for both "http" and "https" URIs to account for alternative
services and secured connections that are not necessarily based on TCP. services and secured connections that are not necessarily based on TCP.
(<xref target="http.uri"/>, <xref target="https.uri"/>, (Sections <xref target="http.uri" format="counter"/>, <xref target="https.uri
<xref target="origin"/>, <xref target="routing.origin"/>) " format="counter"/>,
<xref target="origin" format="counter"/>, and <xref target="routing.origin" f
ormat="counter"/>)
</t> </t>
<t> <t>
Explicit requirements have been added to check the target URI scheme's semant ics Explicit requirements have been added to check the target URI scheme's semant ics
and reject requests that don't meet any associated requirements. and reject requests that don't meet any associated requirements.
(<xref target="routing.reject"/>) (<xref target="routing.reject"/>)
</t> </t>
<t> <t>
Parameters in media type, media range, and expectation can be empty via Parameters in media type, media range, and expectation can be empty via
one or more trailing semicolons. one or more trailing semicolons.
(<xref target="parameter"/>) (<xref target="parameter"/>)
</t> </t>
<t> <t>
"Field value" now refers to the value after multiple field lines are combined "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 single header with commas -- by far the most common use. To refer to a single header
line's value, use "field line value". line's value, use "field line value".
(<xref target="header.fields"/>) (<xref target="header.fields"/>)
</t> </t>
<t> <t>
Trailer field semantics now transcend the specifics of chunked encoding. Trailer field semantics now transcend the specifics of chunked transfer codin
Use of trailer fields has been further limited to only allow generation g.
as a trailer field when the sender knows the field defines that usage and The use of trailer fields has been further limited to allow generation
to only allow merging into the header section if the recipient knows the as a trailer field only when the sender knows the field defines that usage an
d
to allow merging into the header section only if the recipient knows the
corresponding field definition permits and defines how to merge. In all corresponding field definition permits and defines how to merge. In all
other cases, implementations are encouraged to either store the trailer other cases, implementations are encouraged either to store the trailer
fields separately or discard them instead of merging. fields separately or to discard them instead of merging.
(<xref target="trailers.limitations"/>) (<xref target="trailers.limitations"/>)
</t> </t>
<t> <t>
Made 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 by origin servers explicit, to align with proxy handling. header field by origin servers has been made explicit to align with proxy han
dling.
(<xref target="field.host"/>) (<xref target="field.host"/>)
</t> </t>
<t> <t>
The grammar definition for the Via field's "received-by" was The grammar definition for the Via field's "received-by" was
expanded in 7230 due to changes in the URI grammar for host expanded in RFC 7230 due to changes in the URI grammar for host
<xref target="URI"/> that are not desirable for Via. For simplicity, <xref target="URI"/> that are not desirable for Via. For simplicity,
we have removed uri-host from the received-by production because it can we have removed uri-host from the received-by production because it can
be encompassed by the existing grammar for pseudonym. In particular, this be encompassed by the existing grammar for pseudonym. In particular, this
change removed comma from the allowed set of charaters for a host name in change removed comma from the allowed set of characters for a host name in
received-by. received-by.
(<xref target="field.via"/>) (<xref target="field.via"/>)
</t> </t>
</section> </section>
<section anchor="changes.from.rfc.7231" title="Changes from RFC 7231"> <section anchor="changes.from.rfc.7231" title="Changes from RFC 7231">
<t> <t>
Minimum URI lengths to be supported by implementations are now recommended. Minimum URI lengths to be supported by implementations are now recommended.
(<xref target="resources"/>) (<xref target="uri.references"/>)
</t> </t>
<t> <t>
Clarified that CR and NUL in field values are to be rejected or The following have been clarified: CR and NUL in field values are to be rejec
mapped to SP and that leading and trailing whitespace need to be ted or
mapped to SP, and leading and trailing whitespace needs to be
stripped from field values before they are consumed. stripped from field values before they are consumed.
(<xref target="fields.values"/>) (<xref target="fields.values"/>)
</t> </t>
<t> <t>
Parameters in media type, media range, and expectation can be empty via Parameters in media type, media range, and expectation can be empty via
one or more trailing semicolons. one or more trailing semicolons.
(<xref target="parameter"/>) (<xref target="parameter"/>)
</t> </t>
<t> <t>
An abstract data type for HTTP messages has been introduced to define the An abstract data type for HTTP messages has been introduced to define the
skipping to change at line 13085 skipping to change at line 12495
The terms "payload" and "payload body" have been replaced with "content", to better The terms "payload" and "payload body" have been replaced with "content", to better
align with its usage elsewhere (e.g., in field names) and to avoid confusion align with its usage elsewhere (e.g., in field names) and to avoid confusion
with frame payloads in HTTP/2 and HTTP/3. with frame payloads in HTTP/2 and HTTP/3.
(<xref target="content"/>) (<xref target="content"/>)
</t> </t>
<t> <t>
The term "effective request URI" has been replaced with "target URI". The term "effective request URI" has been replaced with "target URI".
(<xref target="target.resource"/>) (<xref target="target.resource"/>)
</t> </t>
<t> <t>
Restrictions on client retries have been loosened, to reflect implementation Restrictions on client retries have been loosened to reflect implementation
behavior. behavior.
(<xref target="idempotent.methods"/>) (<xref target="idempotent.methods"/>)
</t> </t>
<t> <t>
Clarified that request bodies on GET, HEAD, and DELETE are not interoperable. The fact that request bodies on GET, HEAD, and DELETE are not interoperable h
(<xref target="GET"/>, <xref target="HEAD"/>, <xref target="DELETE"/>) as been clarified.
(Sections <xref target="GET" format="counter"/>, <xref target="HEAD" format="
counter"/>, and <xref target="DELETE" format="counter"/>)
</t> </t>
<t> <t>
Allowed use of the <xref target="field.content-range" format="none">Content-R The use of the <xref target="field.content-range" format="none">Content-Range
ange</xref> header field </xref> header field
(<xref target="field.content-range"/>) as a request modifier on PUT. (<xref target="field.content-range"/>) as a request modifier on PUT is allowe
d.
(<xref target="PUT"/>) (<xref target="PUT"/>)
</t> </t>
<t> <t>
Removed a superfluous requirement about setting <xref target="field.content-l A superfluous requirement about setting <xref target="field.content-length" f
ength" format="none">Content-Length</xref> ormat="none">Content-Length</xref>
from the description of the OPTIONS method. has been removed from the description of the OPTIONS method.
(<xref target="OPTIONS"/>) (<xref target="OPTIONS"/>)
</t> </t>
<t> <t>
Removed normative requirement to use the "message/http" media type in The normative requirement to use the "message/http" media type in
TRACE responses. TRACE responses has been removed.
(<xref target="TRACE"/>) (<xref target="TRACE"/>)
</t> </t>
<t> <t>
Restore list-based grammar for <xref target="field.expect" format="none">Expe ct</xref> for compatibility with List-based grammar for <xref target="field.expect" format="none">Expect</xref > has been restored for compatibility with
RFC 2616. RFC 2616.
(<xref target="field.expect"/>) (<xref target="field.expect"/>)
</t> </t>
<t> <t>
Allow <xref target="field.accept" format="none">Accept</xref> and <xref targe t="field.accept-encoding" format="none">Accept-Encoding</xref> in response <xref target="field.accept" format="none">Accept</xref> and <xref target="fie ld.accept-encoding" format="none">Accept-Encoding</xref> are allowed in response
messages; the latter was introduced by <xref target="RFC7694"/>. messages; the latter was introduced by <xref target="RFC7694"/>.
(<xref target="request.content.negotiation"/>) (<xref target="request.content.negotiation"/>)
</t> </t>
<t> <t>
"Accept Parameters" (accept-params and accept-ext ABNF production) have "Accept Parameters" (accept-params and accept-ext ABNF production) have
been removed from the definition of the Accept field. been removed from the definition of the Accept field.
(<xref target="field.accept"/>) (<xref target="field.accept"/>)
</t> </t>
<t> <t>
The "Accept-Charset" field now is deprecated. The Accept-Charset field is now deprecated.
(<xref target="field.accept-charset"/>) (<xref target="field.accept-charset"/>)
</t> </t>
<t> <t>
The semantics of "*" in the <xref target="field.vary" format="none">Vary</xre f> header field when other The semantics of "*" in the <xref target="field.vary" format="none">Vary</xre f> header field when other
values are present was clarified. values are present was clarified.
(<xref target="field.vary"/>) (<xref target="field.vary"/>)
</t> </t>
<t> <t>
Range units are compared in a case insensitive fashion. Range units are compared in a case-insensitive fashion.
(<xref target="range.units"/>) (<xref target="range.units"/>)
</t> </t>
<t> <t>
Use of "Accept-Ranges" is not restricted to origin servers. The use of the Accept-Ranges field is not restricted to origin servers.
(<xref target="field.accept-ranges"/>) (<xref target="field.accept-ranges"/>)
</t> </t>
<t> <t>
The process of creating a redirected request has been clarified. The process of creating a redirected request has been clarified.
(<xref target="status.3xx"/>) (<xref target="status.3xx"/>)
</t> </t>
<t> <t>
Added status code 308 (previously defined in <xref target="RFC7538"/>) Status code 308 (previously defined in <xref target="RFC7538"/>)
so that it's defined closer to status codes 301, 302, and 307. has been added so that it's defined closer to status codes 301, 302, and 307.
(<xref target="status.308"/>) (<xref target="status.308"/>)
</t> </t>
<t> <t>
Added status code 421 (previously defined in Status code 421 (previously defined in
<xref target="HTTP2" section="9.1.2"/>) because of its general <xref target="RFC7540" section="9.1.2"/>) has been added because of its gener
applicability. 421 is no longer defined as heuristically cacheable, since al
applicability. 421 is no longer defined as heuristically cacheable since
the response is specific to the connection (not the target resource). the response is specific to the connection (not the target resource).
(<xref target="status.421"/>) (<xref target="status.421"/>)
</t> </t>
<t> <t>
Added status code 422 (previously defined in Status code 422 (previously defined in
<xref target="WEBDAV" section="11.2"/>) because of its general <xref target="WEBDAV" section="11.2"/>) has been added because of its general
applicability. applicability.
(<xref target="status.422"/>) (<xref target="status.422"/>)
</t> </t>
</section> </section>
<section anchor="changes.from.rfc.7232" title="Changes from RFC 7232"> <section anchor="changes.from.rfc.7232" title="Changes from RFC 7232">
<t> <t>
Previous revisions of HTTP imposed an arbitrary 60-second limit on the Previous revisions of HTTP imposed an arbitrary 60-second limit on the
determination of whether Last-Modified was a strong validator to guard determination of whether Last-Modified was a strong validator to guard
against the possibility that the Date and Last-Modified values are against the possibility that the Date and Last-Modified values are
generated from different clocks or at somewhat different times during the generated from different clocks or at somewhat different times during the
preparation of the response. This specification has relaxed that to allow preparation of the response. This specification has relaxed that to allow
reasonable discretion. reasonable discretion.
(<xref target="lastmod.comparison"/>) (<xref target="lastmod.comparison"/>)
</t> </t>
<t> <t>
Removed edge case requirement on If-Match and If-Unmodified-Since that a An edge-case requirement on If-Match and If-Unmodified-Since
validator not be sent in a 2xx response when validation fails and the server has been removed that required a validator not to be sent in a 2xx
decides that the same change request has already been applied. response if validation fails because the change request has already
(<xref target="field.if-match"/> and been applied.
<xref target="field.if-unmodified-since"/>) (Sections <xref target="field.if-match" format="counter"/> and
<xref target="field.if-unmodified-since" format="counter"/>)
</t> </t>
<t> <t>
Clarified that If-Unmodified-Since doesn't apply to a resource without a The fact that If-Unmodified-Since does not apply to a resource without a
concept of modification time. concept of modification time has been clarified.
(<xref target="field.if-unmodified-since"/>) (<xref target="field.if-unmodified-since"/>)
</t> </t>
<t> <t>
Preconditions can now be evaluated before the request content is processed Preconditions can now be evaluated before the request content is processed
rather than waiting until the response would otherwise be successful. rather than waiting until the response would otherwise be successful.
(<xref target="evaluation"/>) (<xref target="evaluation"/>)
</t> </t>
</section> </section>
<section anchor="changes.from.rfc.7233" title="Changes from RFC 7233"> <section anchor="changes.from.rfc.7233" title="Changes from RFC 7233">
<t> <t>
skipping to change at line 13231 skipping to change at line 12642
None. None.
</t> </t>
</section> </section>
<section anchor="changes.from.rfc.7615" title="Changes from RFC 7615"> <section anchor="changes.from.rfc.7615" title="Changes from RFC 7615">
<t> <t>
None. None.
</t> </t>
</section> </section>
<section anchor="changes.from.rfc.7694" title="Changes from RFC 7694"> <section anchor="changes.from.rfc.7694" title="Changes from RFC 7694">
<t> <t>
This specification includes the extension defined in <xref target="RFC7694"/> , This specification includes the extension defined in <xref target="RFC7694"/>
but leaves out examples and deployment considerations. but leaves out examples and deployment considerations.
</t> </t>
</section> </section>
</section> </section>
<section anchor="change.log" title="Change Log">
<t>This section is to be removed before publishing as an RFC.</t>
<section anchor="changes.since.publication.as.rfc"
title="Between RFC723x and draft 00">
<t>
The changes were purely editorial:
</t>
<ul>
<li>Change boilerplate and abstract to indicate the "draft" statu
s, and update references to ancestor specifications.</li>
<li>Remove version "1.1" from document title, indicating that thi
s specification applies to all HTTP versions.</li>
<li>Adjust historical notes.</li>
<li>Update links to sibling specifications.</li>
<li>Replace sections listing changes from RFC 2616 by new empty s
ections referring to RFC 723x.</li>
<li>Remove acknowledgements specific to RFC 723x.</li>
<li>Move "Acknowledgements" to the very end and make them unnumbe
red.</li>
</ul>
</section>
<section anchor="changes.since.00" title="Since draft-ietf-httpbis-sema
ntics-00">
<t>
The changes in this draft are editorial, with respect to HTTP as a whole,
to merge core HTTP semantics into this document:
</t>
<ul>
<li>Merged introduction, architecture, conformance, and ABNF exte
nsions from
<xref target="RFC7230" format="none">RFC 7230 (Messaging)</xref>.</li>
<li>Rearranged architecture to extract conformance, http(s) schem
es, and
protocol versioning into a separate major section.</li>
<li>Moved discussion of MIME differences to <xref target="HTTP11"
/> since
that is primarily concerned with transforming 1.1 messages.</li>
<li>Merged entire content of <xref target="RFC7232" format="none"
>RFC 7232 (Conditional Requests)</xref>.</li>
<li>Merged entire content of <xref target="RFC7233" format="none"
>RFC 7233 (Range Requests)</xref>.</li>
<li>Merged entire content of <xref target="RFC7235" format="none"
>RFC 7235 (Auth Framework)</xref>.</li>
<li>Moved all extensibility tips, registration procedures, and re
gistry
tables from the IANA considerations to normative sections, reducing the
IANA considerations to just instructions that will be removed prior to
publication as an RFC.</li>
</ul>
</section>
<section anchor="changes.since.01" title="Since draft-ietf-httpbis-sema
ntics-01">
<ul>
<li>Improve [Welch] citation (<eref target="https://github.com/ht
tpwg/http-core/issues/63" brackets="angle"/>)</li>
<li>Remove HTTP/1.1-ism about Range Requests (<eref target="https
://github.com/httpwg/http-core/issues/71" brackets="angle"/>)</li>
<li>Cite RFC 8126 instead of RFC 5226 (<eref target="https://gith
ub.com/httpwg/http-core/issues/75" brackets="angle"/>)</li>
<li>Cite RFC 7538 instead of RFC 7238 (<eref target="https://gith
ub.com/httpwg/http-core/issues/76" brackets="angle"/>)</li>
<li>Cite RFC 8288 instead of RFC 5988 (<eref target="https://gith
ub.com/httpwg/http-core/issues/77" brackets="angle"/>)</li>
<li>Cite RFC 8187 instead of RFC 5987 (<eref target="https://gith
ub.com/httpwg/http-core/issues/78" brackets="angle"/>)</li>
<li>Cite RFC 7578 instead of RFC 2388 (<eref target="https://gith
ub.com/httpwg/http-core/issues/79" brackets="angle"/>)</li>
<li>Cite RFC 7595 instead of RFC 4395 (<eref target="https://gith
ub.com/httpwg/http-core/issues/80" brackets="angle"/>)</li>
<li>improve ABNF readability for qdtext (<eref target="https://gi
thub.com/httpwg/http-core/issues/81" brackets="angle"/>, <eref target="https://w
ww.rfc-editor.org/errata/eid4891" brackets="angle"/>)</li>
<li>Clarify "resource" vs "representation" in definition of statu
s code 416 (<eref target="https://github.com/httpwg/http-core/issues/83" bracket
s="angle"/>, <eref target="https://www.rfc-editor.org/errata/eid4664" brackets="
angle"/>)</li>
<li>Resolved erratum 4072, no change needed here (<eref target="h
ttps://github.com/httpwg/http-core/issues/84" brackets="angle"/>, <eref target="
https://www.rfc-editor.org/errata/eid4072" brackets="angle"/>)</li>
<li>Clarify DELETE status code suggestions (<eref target="https:/
/github.com/httpwg/http-core/issues/85" brackets="angle"/>, <eref target="https:
//www.rfc-editor.org/errata/eid4436" brackets="angle"/>)</li>
<li>In <xref target="field.content-range"/>, fix ABNF for "other-
range-resp" to use VCHAR instead of CHAR (<eref target="https://github.com/httpw
g/http-core/issues/86" brackets="angle"/>, <eref target="https://www.rfc-editor.
org/errata/eid4707" brackets="angle"/>)</li>
<li>Resolved erratum 5162, no change needed here (<eref target="h
ttps://github.com/httpwg/http-core/issues/89" brackets="angle"/>, <eref target="
https://www.rfc-editor.org/errata/eid5162" brackets="angle"/>)</li>
<li>Replace "response code" with "response status code" and "stat
us-code" (the ABNF production name from the HTTP/1.1 message format) by "status
code" (<eref target="https://github.com/httpwg/http-core/issues/94" brackets="an
gle"/>, <eref target="https://www.rfc-editor.org/errata/eid4050" brackets="angle
"/>)</li>
<li>Added a missing word in <xref target="status.3xx"/> (<eref ta
rget="https://github.com/httpwg/http-core/issues/98" brackets="angle"/>, <eref t
arget="https://www.rfc-editor.org/errata/eid4452" brackets="angle"/>)</li>
<li>In <xref target="abnf.extension"/>, fixed an example that had
trailing whitespace where it shouldn't (<eref target="https://github.com/httpwg
/http-core/issues/104"
brackets="angle"/>, <eref target="https://www.rfc-editor
.org/errata/eid4169" brackets="angle"/>)</li>
<li>In <xref target="status.206"/>, remove words that were potent
ially misleading with respect to the relation to the requested ranges (<eref tar
get="https://github.com/httpwg/http-core/issues/102"
brackets="angle"/>, <eref target="https://www.rfc-editor
.org/errata/eid4358" brackets="angle"/>)</li>
</ul>
</section>
<section anchor="changes.since.02" title="Since draft-ietf-httpbis-sema
ntics-02">
<ul>
<li>Included (Proxy-)Auth-Info header field definition from RFC 7
615 (<eref target="https://github.com/httpwg/http-core/issues/9" brackets="angle
"/>)</li>
<li>In <xref target="POST"/>, clarify POST caching (<eref target=
"https://github.com/httpwg/http-core/issues/17" brackets="angle"/>)</li>
<li>Add <xref target="status.418"/> to reserve the 418 status cod
e (<eref target="https://github.com/httpwg/http-core/issues/43" brackets="angle"
/>)</li>
<li>In <xref target="messages"/> and <xref target="field.expect"/
>, clarified when a response can be sent (<eref target="https://github.com/httpw
g/http-core/issues/82" brackets="angle"/>)</li>
<li>In <xref target="charset"/>, explain the difference between t
he "token" production, the RFC 2978 ABNF for charset names, and the actual regis
tration practice (<eref target="https://github.com/httpwg/http-core/issues/100"
brackets="angle"/>, <eref target="https://www.rfc-editor
.org/errata/eid4689" brackets="angle"/>)</li>
<li>In <xref target="resources"/>, removed the fragment component
in the URI scheme definitions as per <xref target="URI" section="4.3"/>,
furthermore moved fragment discussion into a separate section
(<eref target="https://github.com/httpwg/http-core/issues/103"
brackets="angle"/>, <eref target="https://www.rfc-editor
.org/errata/eid4251" brackets="angle"/>, <eref target="https://www.rfc-editor.or
g/errata/eid4252" brackets="angle"/>)</li>
<li>In <xref target="protocol.version"/>, add language about mino
r HTTP version number defaulting (<eref target="https://github.com/httpwg/http-c
ore/issues/115"
brackets="angle"/>)</li>
<li>Added <xref target="status.422"/> for status code 422, previo
usly defined in <xref target="WEBDAV" section="11.2"/> (<eref target="https://gi
thub.com/httpwg/http-core/issues/123"
brackets="angle"/>)</li>
<li>In <xref target="status.416"/>, fixed prose about byte range
comparison (<eref target="https://github.com/httpwg/http-core/issues/135"
brackets="angle"/>, <eref target="https://www.rfc-edito
r.org/errata/eid5474" brackets="angle"/>)</li>
<li>In <xref target="messages"/>, explain that request/response c
orrelation is version specific (<eref target="https://github.com/httpwg/http-cor
e/issues/145"
brackets="angle"/>)</li>
</ul>
</section>
<section anchor="changes.since.03" title="Since draft-ietf-httpbis-sema
ntics-03">
<ul>
<li>In <xref target="status.308"/>, include status code 308 from
RFC 7538 (<eref target="https://github.com/httpwg/http-core/issues/3" brackets="
angle"/>)</li>
<li>In <xref target="media.type"/>, clarify that the charset para
meter value is case-insensitive due to the definition in RFC 2046 (<eref target=
"https://github.com/httpwg/http-core/issues/13" brackets="angle"/>)</li>
<li>Define a separate registry for HTTP header field names (<eref
target="https://github.com/httpwg/http-core/issues/42" brackets="angle"/>)</li>
<li>In <xref target="proactive.negotiation"/>, refactor and clari
fy description of wildcard ("*") handling (<eref target="https://github.com/http
wg/http-core/issues/46" brackets="angle"/>)</li>
<li>Deprecate Accept-Charset (<eref target="https://github.com/ht
tpwg/http-core/issues/61" brackets="angle"/>)</li>
<li>In <xref target="evaluation"/>, mention Cache-Control: immuta
ble (<eref target="https://github.com/httpwg/http-core/issues/69" brackets="angl
e"/>)</li>
<li>In <xref target="fields.order"/>, clarify when header field c
ombination is allowed (<eref target="https://github.com/httpwg/http-core/issues/
74" brackets="angle"/>)</li>
<li>In <xref target="field.name.registration"/>, instruct IANA to
mark Content-MD5 as obsolete (<eref target="https://github.com/httpwg/http-core
/issues/93" brackets="angle"/>)</li>
<li>Use RFC 7405 ABNF notation for case-sensitive string constant
s (<eref target="https://github.com/httpwg/http-core/issues/133"
brackets="angle"/>)</li>
<li>Rework <xref target="messages"/> to be more version-independe
nt (<eref target="https://github.com/httpwg/http-core/issues/142"
brackets="angle"/>)</li>
<li>In <xref target="DELETE"/>, clarify that DELETE needs to be s
uccessful to invalidate cache (<eref target="https://github.com/httpwg/http-core
/issues/167"
brackets="angle"/>, <eref target="https://www.rfc-editor
.org/errata/eid5541" brackets="angle"/>)</li>
</ul>
</section>
<section anchor="changes.since.04" title="Since draft-ietf-httpbis-sema
ntics-04">
<ul>
<li>In <xref target="fields.values"/>, fix field-content ABNF (<e
ref target="https://github.com/httpwg/http-core/issues/19" brackets="angle"/>, <
eref target="https://www.rfc-editor.org/errata/eid4189" brackets="angle"/>)</li>
<li>Move <xref target="parameter"/> into its own section (<eref t
arget="https://github.com/httpwg/http-core/issues/45" brackets="angle"/>)</li>
<li>In <xref target="field.content-type"/>, reference MIME Sniffi
ng (<eref target="https://github.com/httpwg/http-core/issues/51" brackets="angle
"/>)</li>
<li>In <xref target="abnf.extension"/>, simplify the #rule mappin
g for recipients (<eref target="https://github.com/httpwg/http-core/issues/164"
brackets="angle"/>, <eref target="https://www.rfc-editor
.org/errata/eid5257" brackets="angle"/>)</li>
<li>In <xref target="OPTIONS"/>, remove misleading text about "ex
tension" of HTTP is needed to define method content (<eref target="https://githu
b.com/httpwg/http-core/issues/204"
brackets="angle"/>)</li>
<li>Fix editorial issue in <xref target="representations"/> (<ere
f target="https://github.com/httpwg/http-core/issues/223"
brackets="angle"/>)</li>
<li>In <xref target="status.422"/>, rephrase language not to use
"entity" anymore, and also avoid lowercase "may" (<eref target="https://github.c
om/httpwg/http-core/issues/224"
brackets="angle"/>)</li>
<li>Move discussion of retries from <xref target="HTTP11"/> into
<xref target="idempotent.methods"/> (<eref target="https://github.com/httpwg/htt
p-core/issues/230"
brackets="angle"/>)</li>
</ul>
</section>
<section anchor="changes.since.05" title="Since draft-ietf-httpbis-sema
ntics-05">
<ul>
<li>Moved transport-independent part of the description of traile
rs into <xref target="trailer.fields"/> (<eref target="https://github.com/httpwg
/http-core/issues/16" brackets="angle"/>)</li>
<li>Loosen requirements on retries based upon implementation beha
vior (<eref target="https://github.com/httpwg/http-core/issues/27" brackets="ang
le"/>)</li>
<li>In <xref target="port.reg"/>, update IANA port registry for T
CP/UDP on ports 80 and 443 (<eref target="https://github.com/httpwg/http-core/is
sues/36" brackets="angle"/>)</li>
<li>In <xref target="considerations.for.new.field.values"/>, revi
se guidelines for new header field names (<eref target="https://github.com/httpw
g/http-core/issues/47" brackets="angle"/>)</li>
<li>In <xref target="cacheable.methods"/>, remove concept of "cac
heable methods" in favor of prose (<eref target="https://github.com/httpwg/http-
core/issues/54" brackets="angle"/>, <eref target="https://www.rfc-editor.org/err
ata/eid5300" brackets="angle"/>)</li>
<li>In <xref target="establishing.authority"/>, mention that the
concept of authority can be modified by protocol extensions (<eref target="https
://github.com/httpwg/http-core/issues/143"
brackets="angle"/>)</li>
<li>Create new subsection on content in <xref target="content"/>,
taken from portions of message body (<eref target="https://github.com/httpwg/ht
tp-core/issues/159"
brackets="angle"/>)</li>
<li>Moved definition of "Whitespace" into new container "Generic
Syntax" (<eref target="https://github.com/httpwg/http-core/issues/162"
brackets="angle"/>)</li>
<li>In <xref target="resources"/>, recommend minimum URI size sup
port for implementations (<eref target="https://github.com/httpwg/http-core/issu
es/169"
brackets="angle"/>)</li>
<li>In <xref target="range.units"/>, refactored the range-unit an
d ranges-specifier grammars (<eref target="https://github.com/httpwg/http-core/i
ssues/196"
brackets="angle"/>, <eref target="https://www.rfc-editor
.org/errata/eid5620" brackets="angle"/>)</li>
<li>In <xref target="GET"/>, caution against a request content mo
re strongly (<eref target="https://github.com/httpwg/http-core/issues/202"
brackets="angle"/>)</li>
<li>Reorganized text in <xref target="considerations.for.new.fiel
d.values"/> (<eref target="https://github.com/httpwg/http-core/issues/214"
brackets="angle"/>)</li>
<li>In <xref target="status.403"/>, replace "authorize" with "ful
fill" (<eref target="https://github.com/httpwg/http-core/issues/218"
brackets="angle"/>)</li>
<li>In <xref target="OPTIONS"/>, removed a misleading statement a
bout Content-Length (<eref target="https://github.com/httpwg/http-core/issues/23
5"
brackets="angle"/>, <eref target="https://www.rfc-editor
.org/errata/eid5806" brackets="angle"/>)</li>
<li>In <xref target="establishing.authority"/>, add text from RFC
2818 (<eref target="https://github.com/httpwg/http-core/issues/236"
brackets="angle"/>)</li>
<li>Changed "cacheable by default" to "heuristically cacheable" t
hroughout (<eref target="https://github.com/httpwg/http-core/issues/242"
brackets="angle"/>)</li>
</ul>
</section>
<section anchor="changes.since.06" title="Since draft-ietf-httpbis-sema
ntics-06">
<ul>
<li>In <xref target="field.via"/>, simplify received-by grammar (
and disallow comma character) (<eref target="https://github.com/httpwg/http-core
/issues/24" brackets="angle"/>)</li>
<li>In <xref target="fields.names"/>, give guidance on interopera
ble field names (<eref target="https://github.com/httpwg/http-core/issues/30" br
ackets="angle"/>)</li>
<li>In <xref target="whitespace"/>, define the semantics and poss
ible replacement of whitespace when it is known to occur (<eref target="https://
github.com/httpwg/http-core/issues/53" brackets="angle"/>, <eref target="https:/
/www.rfc-editor.org/errata/eid5163" brackets="angle"/>)</li>
<li>In <xref target="header.fields"/>, introduce field terminolog
y and distinguish between field line values and field values; use terminology co
nsistently throughout (<eref target="https://github.com/httpwg/http-core/issues/
111"
brackets="angle"/>)</li>
<li>Moved #rule definition into <xref target="fields.values"/> an
d whitespace into <xref target="notation"/> (<eref target="https://github.com/ht
tpwg/http-core/issues/162"
brackets="angle"/>)</li>
<li>In <xref target="range.units"/>, explicitly call out range un
it names as case-insensitive, and encourage registration (<eref target="https://
github.com/httpwg/http-core/issues/179"
brackets="angle"/>)</li>
<li>In <xref target="content.codings"/>, explicitly call out cont
ent codings as case-insensitive, and encourage registration (<eref target="https
://github.com/httpwg/http-core/issues/179"
brackets="angle"/>)</li>
<li>In <xref target="fields.names"/>, explicitly call out field n
ames as case-insensitive (<eref target="https://github.com/httpwg/http-core/issu
es/179"
brackets="angle"/>)</li>
<li>In <xref target="fingerprinting"/>, cite <xref target="Bujlow
"/> (<eref target="https://github.com/httpwg/http-core/issues/185"
brackets="angle"/>)</li>
<li>In <xref target="status.codes"/>, formally define "final" and
"interim" status codes (<eref target="https://github.com/httpwg/http-core/issue
s/245"
brackets="angle"/>)</li>
<li>In <xref target="DELETE"/>, caution against a request content
more strongly (<eref target="https://github.com/httpwg/http-core/issues/258"
brackets="angle"/>)</li>
<li>In <xref target="field.etag"/>, note that Etag can be used in
trailers (<eref target="https://github.com/httpwg/http-core/issues/262"
brackets="angle"/>)</li>
<li>In <xref target="field.name.registration"/>, consider reserve
d fields as well (<eref target="https://github.com/httpwg/http-core/issues/273"
brackets="angle"/>)</li>
<li>In <xref target="http.userinfo"/>, be more correct about what
was deprecated by RFC 3986 (<eref target="https://github.com/httpwg/http-core/i
ssues/278"
brackets="angle"/>, <eref target="https://www.rfc-editor
.org/errata/eid5964" brackets="angle"/>)</li>
<li>In <xref target="fields.order"/>, recommend comma SP when com
bining field lines (<eref target="https://github.com/httpwg/http-core/issues/148
"
brackets="angle"/>)</li>
<li>In <xref target="field.host"/>, make explicit requirements on
origin server to use authority from absolute-form when available (<eref target=
"https://github.com/httpwg/http-core/issues/191"
brackets="angle"/>)</li>
<li>In <xref target="http.uri"/>, <xref target="https.uri"/>, <xr
ef target="origin"/>, and <xref target="routing.origin"/>, refactored schemes to
define origin and authoritative access to an origin server for both "http" and
"https" URIs to account for alternative services and secured connections that ar
e not necessarily based on TCP (<eref target="https://github.com/httpwg/http-cor
e/issues/237"
brackets="angle"/>)</li>
<li>In <xref target="requirements.notation"/>, reference RFC 8174
as well (<eref target="https://github.com/httpwg/http-core/issues/303"
brackets="angle"/>)</li>
</ul>
</section>
<section anchor="changes.since.07" title="Since draft-ietf-httpbis-sema
ntics-07">
<ul>
<li>In <xref target="field.range"/>, explicitly reference the def
inition of representation data as including any content codings (<eref target="h
ttps://github.com/httpwg/http-core/issues/11" brackets="angle"/>)</li>
<li>Move TE: trailers from <xref target="HTTP11"/> into <xref tar
get="trailers.limitations"/> (<eref target="https://github.com/httpwg/http-core/
issues/18" brackets="angle"/>)</li>
<li>In <xref target="field.content-length"/>, adjust requirements
for handling multiple content-length values (<eref target="https://github.com/h
ttpwg/http-core/issues/59" brackets="angle"/>)</li>
<li>In <xref target="field.if-match"/> and <xref target="field.if
-none-match"/>, clarified condition evaluation (<eref target="https://github.com
/httpwg/http-core/issues/72" brackets="angle"/>)</li>
<li>In <xref target="fields.values"/>, remove concept of obs-fold
, as that is HTTP/1-specific (<eref target="https://github.com/httpwg/http-core/
issues/116"
brackets="angle"/>)</li>
<li>In <xref target="content.negotiation"/>, introduce the concep
t of request content negotiation (<xref target="request.content.negotiation"/>)
and define for <xref target="field.accept-encoding" format="none">Accept-Encodin
g</xref> (<eref target="https://github.com/httpwg/http-core/issues/119"
brackets="angle"/>)</li>
<li>In <xref target="status.205"/>, <xref target="status.408"/>,
and <xref target="status.413"/>, remove HTTP/1-specific, connection-related requ
irements (<eref target="https://github.com/httpwg/http-core/issues/144"
brackets="angle"/>)</li>
<li>In <xref target="CONNECT"/>, correct language about what is f
orwarded (<eref target="https://github.com/httpwg/http-core/issues/170"
brackets="angle"/>)</li>
<li>Throughout, replace "effective request URI", "request-target"
and similar with "target URI" (<eref target="https://github.com/httpwg/http-cor
e/issues/259"
brackets="angle"/>)</li>
<li>In <xref target="considerations.for.new.field.values"/> and <
xref target="considerations.for.new.status.codes"/>, describe how extensions sho
uld consider scope of applicability (<eref target="https://github.com/httpwg/htt
p-core/issues/265"
brackets="angle"/>)</li>
<li>In <xref target="messages"/>, don't rely on the HTTP/1.1 Mess
aging specification to define "message" (<eref target="https://github.com/httpwg
/http-core/issues/311"
brackets="angle"/>)</li>
<li>In <xref target="field.content-location"/> and <xref target="
field.referer"/>, note that URL resolution is necessary (<eref target="https://g
ithub.com/httpwg/http-core/issues/321"
brackets="angle"/>)</li>
<li>In <xref target="representations"/>, explicitly reference 206
as one of the status codes that provide representation data (<eref target="http
s://github.com/httpwg/http-core/issues/325"
brackets="angle"/>)</li>
<li>In <xref target="field.if-unmodified-since"/>, refine require
ments so that they don't apply to resources without a concept of modification ti
me (<eref target="https://github.com/httpwg/http-core/issues/326"
brackets="angle"/>)</li>
<li>In <xref target="field.proxy-authenticate"/>, specify the sco
pe as a request, not a target resource (<eref target="https://github.com/httpwg/
http-core/issues/331"
brackets="angle"/>)</li>
<li>In <xref target="messages"/>, introduce concept of "complete"
messages (<eref target="https://github.com/httpwg/http-core/issues/334"
brackets="angle"/>)</li>
<li>In <xref target="target.resource"/>, <xref target="CONNECT"/>
, and <xref target="OPTIONS"/>, refine use of "request target" (<eref target="ht
tps://github.com/httpwg/http-core/issues/340"
brackets="angle"/>)</li>
<li>Throughout, remove "status-line" and "request-line", as these
are HTTP/1.1-specific (<eref target="https://github.com/httpwg/http-core/issues
/361"
brackets="angle"/>)</li>
</ul>
</section>
<section anchor="changes.since.08" title="Since draft-ietf-httpbis-sema
ntics-08">
<ul>
<li>In <xref target="status.416"/>, remove duplicate definition o
f what makes a range satisfiable and refer instead to each range unit's definiti
on (<eref target="https://github.com/httpwg/http-core/issues/12" brackets="angle
"/>)</li>
<li>In <xref target="byte.ranges"/> and <xref target="field.range
"/>, clarify that a selected representation of zero length can only be satisfiab
le as a suffix range and that a server can still ignore Range for that case (<er
ef target="https://github.com/httpwg/http-core/issues/12" brackets="angle"/>)</l
i>
<li>In <xref target="field.accept"/> and <xref target="status.415
"/>, allow "Accept" as response field (<eref target="https://github.com/httpwg/h
ttp-core/issues/48" brackets="angle"/>)</li>
<li>
<xref target="collected.abnf"/> now uses the sender variant of
the "#" list expansion (<eref target="https://github.com/httpwg/http-core/issue
s/192"
brackets="angle"/>)</li>
<li>In <xref target="field.vary"/>, make the field list-based eve
n when "*" is present (<eref target="https://github.com/httpwg/http-core/issues/
272"
brackets="angle"/>)</li>
<li>In <xref target="fields.registry"/>, add optional "Comments"
entry (<eref target="https://github.com/httpwg/http-core/issues/273"
brackets="angle"/>)</li>
<li>In <xref target="field.name.registration"/>, reserve "*" as f
ield name (<eref target="https://github.com/httpwg/http-core/issues/274"
brackets="angle"/>)</li>
<li>In <xref target="method.registration"/>, reserve "*" as metho
d name (<eref target="https://github.com/httpwg/http-core/issues/274"
brackets="angle"/>)</li>
<li>In <xref target="field.if-match"/> and <xref target="field.if
-none-match"/>, state that multiple "*" is unlikely to be interoperable (<eref t
arget="https://github.com/httpwg/http-core/issues/305"
brackets="angle"/>)</li>
<li>In <xref target="field.accept"/>, avoid use of obsolete media
type parameter on text/html (<eref target="https://github.com/httpwg/http-core/
issues/375"
brackets="angle"/>, <eref target="https://www.rfc-editor
.org/errata/eid6149" brackets="angle"/>)</li>
<li>Rephrase prose in <xref target="messages"/> to become version
-agnostic (<eref target="https://github.com/httpwg/http-core/issues/372"
brackets="angle"/>)</li>
<li>In <xref target="fields.values"/>, instruct recipients how to
deal with control characters in field values (<eref target="https://github.com/
httpwg/http-core/issues/377"
brackets="angle"/>)</li>
<li>In <xref target="fields.values"/>, update note about field AB
NF (<eref target="https://github.com/httpwg/http-core/issues/380"
brackets="angle"/>)</li>
<li>Add <xref target="extending"/> about Extending and Versioning
HTTP (<eref target="https://github.com/httpwg/http-core/issues/384"
brackets="angle"/>)</li>
<li>In <xref target="overview.of.status.codes"/>, include status
308 in list of heuristically cacheable status codes (<eref target="https://githu
b.com/httpwg/http-core/issues/385"
brackets="angle"/>)</li>
<li>In <xref target="field.content-encoding"/>, make it clearer t
hat "identity" is not to be included (<eref target="https://github.com/httpwg/ht
tp-core/issues/388"
brackets="angle"/>)</li>
</ul>
</section>
<section anchor="changes.since.09" title="Since draft-ietf-httpbis-sema
ntics-09">
<ul>
<li>Switch to xml2rfc v3 mode for draft generation (<eref target=
"https://github.com/httpwg/http-core/issues/394"
brackets="angle"/>)</li>
</ul>
</section>
<section anchor="changes.since.10" title="Since draft-ietf-httpbis-sema
ntics-10">
<ul>
<li>In <xref target="compression.attacks"/>, mention compression
attacks (<eref target="https://github.com/httpwg/http-core/issues/6" brackets="a
ngle"/>)</li>
<li>In <xref target="content.coding.registry"/>, advise to make n
ew content codings self-descriptive (<eref target="https://github.com/httpwg/htt
p-core/issues/21" brackets="angle"/>)</li>
<li>In <xref target="parameter"/>, introduced the "parameters" AB
NF rule, allowing empty parameters and trailing semicolons within media type, me
dia range, and expectation (<eref target="https://github.com/httpwg/http-core/is
sues/33" brackets="angle"/>)</li>
<li>In <xref target="status.3xx"/>, explain how to create a redir
ected request (<eref target="https://github.com/httpwg/http-core/issues/38" brac
kets="angle"/>)</li>
<li>In <xref target="field.content-type"/>, defined error handlin
g for multiple members (<eref target="https://github.com/httpwg/http-core/issues
/39" brackets="angle"/>)</li>
<li>In <xref target="introduction"/>, revise the introduction and
introduce HTTP/2 and HTTP/3 (<eref target="https://github.com/httpwg/http-core/
issues/64" brackets="angle"/>)</li>
<li>In <xref target="field.content-length"/>, added a definition
for <xref target="field.content-length" format="none">Content-Length</xref> that
encompasses its various roles in describing message content or selected represe
ntation length; in <xref target="status.206"/>, noted that <xref target="field.c
ontent-length" format="none">Content-Length</xref> counts only the message conte
nt (not the selected representation) and that the representation length is in ea
ch <xref target="field.content-range" format="none">Content-Range</xref> (<eref
target="https://github.com/httpwg/http-core/issues/118"
brackets="angle"/>)</li>
<li>Noted that "WWW-Authenticate" with more than one value on a l
ine is sometimes not interoperable <xref target="HTTP11"/> (<eref target="https:
//github.com/httpwg/http-core/issues/136"
brackets="angle"/>)</li>
<li>In <xref target="field.if-match"/> and <xref target="field.if
-unmodified-since"/>, removed requirement that a validator not be sent in a 2xx
response when validation fails and the server decides that the same change reque
st has already been applied (<eref target="https://github.com/httpwg/http-core/
issues/166"
brackets="angle"/>)</li>
<li>Moved requirements specific to HTTP/1.1 from <xref target="fi
eld.host"/> to <xref target="HTTP11"/> (<eref target="https://github.com/httpwg/
http-core/issues/182"
brackets="angle"/>)</li>
<li>In <xref target="fields.values"/>, introduce the terms "singl
eton field" and "list-based field" (also - in various places - discuss what to
do when a singleton field is received as a list) (<eref target="https://github.c
om/httpwg/http-core/issues/193"
brackets="angle"/>)</li>
<li>In <xref target="field.expect"/>, change the ABNF back to be
a list of expectations, as defined in RFC 2616 (<eref target="https://github.com
/httpwg/http-core/issues/203"
brackets="angle"/>)</li>
<li>In <xref target="field.trailer"/> (<xref target="field.traile
r" format="none">Trailer</xref>),
<xref target="field.via"/> (<xref target="field.via" format="none">Via<
/xref>),
<xref target="field.upgrade"/> (<xref target="field.upgrade" format="no
ne">Upgrade</xref>),
<xref target="field.connection"/> (<xref target="field.connection" form
at="none">Connection</xref>),
<xref target="field.content-encoding"/> (<xref target="field.content-en
coding" format="none">Content-Encoding</xref>),
<xref target="field.content-language"/> (<xref target="field.content-la
nguage" format="none">Content-Language</xref>),
<xref target="field.expect"/> (<xref target="field.expect" format="none
">Expect</xref>),
<xref target="field.if-match"/> (<xref target="field.if-match" format="
none">If-Match</xref>),
<xref target="field.if-none-match"/> (<xref target="field.if-none-match
" format="none">If-None-Match</xref>),
<xref target="field.accept-charset"/> (<xref target="field.accept-chars
et" format="none">Accept-Charset</xref>),
<xref target="field.accept-language"/> (<xref target="field.accept-lang
uage" format="none">Accept-Language</xref>),
<xref target="field.vary"/> (<xref target="field.vary" format="none">Va
ry</xref>),
<xref target="field.www-authenticate"/> (<xref target="field.www-authen
ticate" format="none">WWW-Authenticate</xref>), and
<xref target="field.proxy-authenticate"/> (<xref target="field.proxy-au
thenticate" format="none">Proxy-Authenticate</xref>),
adjust ABNF to allow empty lists (<eref target="https://github.com/http
wg/http-core/issues/210"
brackets="angle"/>)</li>
<li>In <xref target="GET"/> and <xref target="sensitive.informati
on.in.uris"/>, provide a more nuanced explanation of sensitive data in GET-based
forms and describe workarounds (<eref target="https://github.com/httpwg/http-co
re/issues/277"
brackets="angle"/>)</li>
<li>In <xref target="evaluation"/>, allow preconditions to be eva
luated before the request content (if any) is processed (<eref target="https://g
ithub.com/httpwg/http-core/issues/261"
brackets="angle"/>)</li>
<li>In <xref target="header.fields"/> and <xref target="trailers.
processing"/>, allow for trailer fields in multiple trailer sections, depending
on the HTTP version and framing in use, with processing being iterative as each
section is received (<eref target="https://github.com/httpwg/http-core/issues/31
3"
brackets="angle"/>)</li>
<li>Moved definitions of "TE" and "Upgrade" from <xref target="HT
TP11"/> (<eref target="https://github.com/httpwg/http-core/issues/392"
brackets="angle"/>)</li>
<li>Moved 1.1-specific discussion of TLS to Messaging and rewrote
<xref target="https.verify"/> to refer to RFC6125 (<eref target="https://github
.com/httpwg/http-core/issues/404"
brackets="angle"/>)</li>
<li>Moved definition of "Connection" from <xref target="HTTP11"/>
(<eref target="https://github.com/httpwg/http-core/issues/407"
brackets="angle"/>)</li>
</ul>
</section>
<section anchor="changes.since.11" title="Since draft-ietf-httpbis-sema
ntics-11">
<ul>
<li>The entire document has been reorganized, with no changes to
content except editorial for the reorganization (<eref target="https://github.co
m/httpwg/http-core/issues/368"
brackets="angle"/>)</li>
<li>Move IANA Upgrade Token Registry instructions from <xref targ
et="HTTP11"/> (<eref target="https://github.com/httpwg/http-core/issues/450"
brackets="angle"/>)</li>
</ul>
</section>
<section anchor="changes.since.12" title="Since draft-ietf-httpbis-sema
ntics-12">
<ul>
<li>In <xref xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-n
s#"
xmlns:x="http://purl.org/net/xml2rfc/ext"
target="acks">Appendix "Acknowledgements"</xref>, added
acks for the work since 2014 (<eref target="https://github.com/httpwg/http-core/
issues/442"
brackets="angle"/>)</li>
<li>In <xref target="status.206"/>, specifically require that a c
lient check the 206 response header fields to determine what ranges are enclosed
, since it cannot assume they exactly match those requested (<eref target="https
://github.com/httpwg/http-core/issues/445"
brackets="angle"/>)</li>
<li>In <xref target="fields.extensibility"/>, explain why new fie
lds need to be backwards-compatible (<eref target="https://github.com/httpwg/htt
p-core/issues/448"
brackets="angle"/>)</li>
<li>In <xref target="fields.order"/>, constrain field combination
to be within a section (<eref target="https://github.com/httpwg/http-core/issue
s/454"
brackets="angle"/>)</li>
<li>In <xref target="http.date"/>, mention that caching relaxes d
ate sensitivity (<eref target="https://github.com/httpwg/http-core/issues/473"
brackets="angle"/>)</li>
<li>In <xref target="field.name.registration"/>, moved "*" field
registration into main table (<eref target="https://github.com/httpwg/http-core/
issues/476"
brackets="angle"/>)</li>
<li>In <xref target="history.and.evolution"/>, reference HTTP/0.9
(<eref target="https://github.com/httpwg/http-core/issues/497"
brackets="angle"/>)</li>
<li>In <xref target="PUT"/>, clarify handling of unrecognized fie
lds (<eref target="https://github.com/httpwg/http-core/issues/502"
brackets="angle"/>)</li>
<li>In <xref target="status.1xx"/>, align language about bodies a
nd trailers with 204 and 304 (<eref target="https://github.com/httpwg/http-core/
issues/503"
brackets="angle"/>)</li>
<li>Moved table of content codings into <xref target="content.cod
ing.registration"/>, moved table of range units into <xref target="range.unit.re
gistration"/> (<eref target="https://github.com/httpwg/http-core/issues/506"
brackets="angle"/>)</li>
<li>In <xref target="message.abstraction"/>, add an abstract data
type for message to help define semantics without being dependent on the specif
ic structure of HTTP/1.1 (<eref target="https://github.com/httpwg/http-core/issu
es/557"
brackets="angle"/>)</li>
<li>In <xref target="lastmod.comparison"/>, relax arbitrary 60-se
cond comparison limit (<eref target="https://github.com/httpwg/http-core/issues/
510"
brackets="angle"/>)</li>
<li>In <xref target="field.host"/>, add ":authority" pseudo-heade
r to Host discussion and make section applicable to both (<eref target="https://
github.com/httpwg/http-core/issues/511"
brackets="angle"/>)</li>
<li>In <xref target="field.name.registration"/>, note that this d
ocument updates <xref target="RFC3864"/> (<eref target="https://github.com/httpw
g/http-core/issues/515"
brackets="angle"/>)</li>
<li>Moved transfer-coding ABNF from <xref target="HTTP11"/> to <x
ref target="field.te"/> and replaced "t-ranking" ABNF by equivalent "weight" (<e
ref target="https://github.com/httpwg/http-core/issues/531"
brackets="angle"/>)</li>
<li>In <xref target="protection.space"/>, replace "canonical root
URI" by "origin" (<eref target="https://github.com/httpwg/http-core/issues/542"
brackets="angle"/>)</li>
<li>In <xref target="field.expect"/>, remove obsolete note about
a change in RFC 723x (<eref target="https://github.com/httpwg/http-core/issues/5
47"
brackets="angle"/>)</li>
<li>Changed to using "payload" when defining requirements about t
he data being conveyed within a message, instead of the terms "payload body" or
"response body" or "representation body", since they often get confused with the
HTTP/1.1 message body (which includes transfer coding) (<eref target="https://g
ithub.com/httpwg/http-core/issues/553"
brackets="angle"/>)</li>
<li>Rewrite definition of <xref target="HEAD" format="none">HEAD<
/xref> method (<eref target="https://github.com/httpwg/http-core/issues/559"
brackets="angle"/>)</li>
<li>In <xref target="field.if-range"/>, fix an off-by-one bug abo
ut how many chars to consider when checking for etags (<eref target="https://git
hub.com/httpwg/http-core/issues/570"
brackets="angle"/>)</li>
<li>In <xref target="overview.of.status.codes"/>, clarify that "n
o reason phrase" is fine as well (<eref target="https://github.com/httpwg/http-c
ore/issues/571"
brackets="angle"/>)</li>
<li>In <xref target="status.203"/>, remove an obsolete reference
to the Warning response header field (<eref target="https://github.com/httpwg/ht
tp-core/issues/573"
brackets="angle"/>)</li>
<li>In <xref target="status.408"/>, rephrase prose about connecti
on re-use (<eref target="https://github.com/httpwg/http-core/issues/579"
brackets="angle"/>)</li>
<li>In <xref target="field.range"/>, potentially allow Range hand
ling on methods other than GET (<eref target="https://github.com/httpwg/http-cor
e/issues/581"
brackets="angle"/>)</li>
<li>In <xref target="status.code.registration"/>, remove redundan
t text about status code 418 (<eref target="https://github.com/httpwg/http-core/
issues/583"
brackets="angle"/>)</li>
<li>In <xref target="confidentiality.of.credentials"/>, rewrite r
equirement to refer to "secured connection" (<eref target="https://github.com/ht
tpwg/http-core/issues/587"
brackets="angle"/>)</li>
<li>Make reference to <xref target="TLS13"/> normative (<eref tar
get="https://github.com/httpwg/http-core/issues/589"
brackets="angle"/>)</li>
</ul>
</section>
<section anchor="changes.since.13" title="Since draft-ietf-httpbis-sema
ntics-13">
<ul>
<li>In <xref target="field.accept"/>, remove the unused "accept p
arameters" (<eref target="https://github.com/httpwg/http-core/issues/568"
brackets="angle"/>)</li>
<li>In <xref target="history.and.evolution"/>, mention that RFC 1
945 describes HTTP/0.9 as well (<eref target="https://github.com/httpwg/http-cor
e/issues/614"
brackets="angle"/>)</li>
<li>In <xref target="partial.PUT"/>, describe non-standard use of
the <xref target="field.content-range" format="none">Content-Range</xref> heade
r field (<xref target="field.content-range"/>) as a request modifier to perform
a partial PUT (<eref target="https://github.com/httpwg/http-core/issues/618"
brackets="angle"/>)</li>
<li>In <xref target="status.421"/>, import the 421 (Misdirected R
equest) status code from <xref target="HTTP2"/> (<eref target="https://github.co
m/httpwg/http-core/issues/622"
brackets="angle"/>)</li>
<li>In <xref target="length.requirements"/>, rephrase the actual
recipient parsing requirements (<eref target="https://github.com/httpwg/http-cor
e/issues/634"
brackets="angle"/>)</li>
<li>In <xref target="considerations.for.new.methods"/>, mention r
equest target forms in considerations for new methods (<eref target="https://git
hub.com/httpwg/http-core/issues/636"
brackets="angle"/>)</li>
<li>Changed to using "content" instead of "payload" or "payload d
ata" to avoid confusion with the payload of version-specific messaging frames (<
eref target="https://github.com/httpwg/http-core/issues/654"
brackets="angle"/>)</li>
<li>In <xref target="field.if-modified-since"/>, <xref target="fi
eld.if-unmodified-since"/>, and <xref target="field.if-range"/>, specify evaluat
ion in a way similar to other conditional header fields (<eref target="https://g
ithub.com/httpwg/http-core/issues/665"
brackets="angle"/>)</li>
<li>In <xref target="field.date"/>, specify that recipients can r
eplace an invalid Date header field value with the time received (<eref target="
https://github.com/httpwg/http-core/issues/669"
brackets="angle"/>)</li>
</ul>
</section>
<section anchor="changes.since.14" title="Since draft-ietf-httpbis-sema
ntics-14">
<ul>
<li>In <xref target="fields.values"/>, relax prohibition of chara
cters in field values to CR and NUL (<eref target="https://github.com/httpwg/htt
p-core/issues/683"
brackets="angle"/>)</li>
<li>In <xref target="status.codes"/>, clarify that status code va
lues outside the range 100..599 are invalid, and recommend error handling (<eref
target="https://github.com/httpwg/http-core/issues/684"
brackets="angle"/>)</li>
<li>In <xref target="requirements.notation"/>, replaced requireme
nt on semantic conformance with permission to ignore/workaround implementation-s
pecific failures (<eref target="https://github.com/httpwg/http-core/issues/687"
brackets="angle"/>)</li>
<li>Avoid the term "whitelist" (<eref target="https://github.com/
httpwg/http-core/issues/688"
brackets="angle"/>)</li>
<li>In <xref target="TRACE"/>, remove the normative requirement t
o use the message/http media type (<eref target="https://github.com/httpwg/http-
core/issues/690"
brackets="angle"/>)</li>
<li>In <xref target="message.forwarding"/>, discuss extensibility
(<eref target="https://github.com/httpwg/http-core/issues/692"
brackets="angle"/>)</li>
<li>In <xref target="fields.values"/>, tighten the recommendation
for characters in newly defined fields, making it consistent with obs-text (<er
ef target="https://github.com/httpwg/http-core/issues/696"
brackets="angle"/>)</li>
<li>In <xref target="fields.values"/>, leading/trailing whitespac
e removal is at time of use, not parsing (<eref target="https://github.com/httpw
g/http-core/issues/697"
brackets="angle"/>)</li>
<li>In <xref target="message.abstraction"/>, clarify that HTTP se
lf-descriptive messages have an exception in that the request must be understood
in order to parse and interpret the response (<eref target="https://github.com/
httpwg/http-core/issues/700"
brackets="angle"/>)</li>
<li>Remove "Canonicalization and Text Defaults" (<eref target="ht
tps://github.com/httpwg/http-core/issues/703"
brackets="angle"/>)</li>
<li>In <xref target="field.referer"/>, refine what can be sent in
Referer, and when (<eref target="https://github.com/httpwg/http-core/issues/709
"
brackets="angle"/>)</li>
<li>In <xref target="protection.space"/>, explain that the protec
tion space is not defined without additional information (<eref target="https://
github.com/httpwg/http-core/issues/710"
brackets="angle"/>)</li>
<li>Simplify description of reactive content negotiation in <xref
target="reactive.negotiation"/> (<eref target="https://github.com/httpwg/http-c
ore/issues/712"
brackets="angle"/>)</li>
<li>In <xref target="charset"/>, remove the "charset" ABNF produc
tion, and clarify where charsets appear (<eref target="https://github.com/httpwg
/http-core/issues/713"
brackets="angle"/>)</li>
<li>In <xref target="field.accept-encoding"/>, clarify that selec
tion <em>between</em> multiple acceptable codings is only relevant when they hav
e the same purpose (<eref target="https://github.com/httpwg/http-core/issues/714
"
brackets="angle"/>)</li>
<li>In <xref target="conditional.requests"/>, rewrite introductio
n, mentioning extensibility (<eref target="https://github.com/httpwg/http-core/i
ssues/715"
brackets="angle"/>)</li>
<li>Throughout, be consistent about 'content coding' vs 'content-
coding' (<eref target="https://github.com/httpwg/http-core/issues/719"
brackets="angle"/>)</li>
<li>In <xref target="CONNECT"/>, clarify that the port is mandato
ry in a CONNECT request target (<eref target="https://github.com/httpwg/http-cor
e/issues/736"
brackets="angle"/>) and that the tunnel begins after the
header section (<eref target="https://github.com/httpwg/http-core/issues/737"
brackets="angle"/>)</li>
<li>In <xref target="trailer.fields"/>, remove mid-stream trailer
s (<eref target="https://github.com/httpwg/http-core/issues/740"
brackets="angle"/>)</li>
<li>In <xref target="connections"/>, clarify duplexing semantics
(<eref target="https://github.com/httpwg/http-core/issues/741"
brackets="angle"/>)</li>
<li>In <xref target="connections"/>, explain the implications of
statelessness more clearly (<eref target="https://github.com/httpwg/http-core/is
sues/743"
brackets="angle"/>)</li>
<li>In <xref target="field.content-length"/>, be more explicit ab
out invalid and incorrect values (<eref target="https://github.com/httpwg/http-c
ore/issues/748"
brackets="angle"/> and <eref target="https://github.com/
httpwg/http-core/issues/749"
brackets="angle"/>)</li>
<li>Move discussion of statelessness from <xref target="intermedi
aries"/> to <xref target="connections"/> (<eref target="https://github.com/httpw
g/http-core/issues/753"
brackets="angle"/>)</li>
<li>In <xref target="status.101"/>, clarify that the upgraded pro
tocol is in effect after the 101 response (<eref target="https://github.com/http
wg/http-core/issues/776"
brackets="angle"/>)</li>
<li>In <xref target="CONNECT"/>, state that data received after t
he headers of a CONNECT message is version-specific (<eref target="https://githu
b.com/httpwg/http-core/issues/780"
brackets="angle"/>)</li>
<li>In <xref target="uri.comparison"/>, clarify how normalization
works, and align with RF3986 (<eref target="https://github.com/httpwg/http-core
/issues/788"
brackets="angle"/>)</li>
<li>In <xref target="field.trailer"/>, note that the Trailer fiel
d can be used to discover deleted trailers (<eref target="https://github.com/htt
pwg/http-core/issues/793"
brackets="angle"/>)</li>
<li>Throughout, remove unneeded normative references to <xref tar
get="HTTP11"/> (<eref target="https://github.com/httpwg/http-core/issues/795"
brackets="angle"/>)</li>
<li>In <xref target="field.te"/>, explicitly require listing in C
onnection (<eref target="https://github.com/httpwg/http-core/issues/809"
brackets="angle"/>)</li>
</ul>
</section>
<section anchor="changes.since.15" title="Since draft-ietf-httpbis-sema
ntics-15">
<ul>
<li>For <xref target="HTTP3"/>, add an RFC Editor note to rename
to "RFCnnn" before publication (<eref target="https://github.com/httpwg/http-cor
e/issues/815"
brackets="angle"/>)</li>
<li>In <xref target="HEAD"/>, align prose about content in HEAD r
equests with description of GET (<eref target="https://github.com/httpwg/http-co
re/issues/826"
brackets="angle"/>)</li>
<li>In <xref target="fields.order"/>, remove the restriction to n
on-empty field line values (<eref target="https://github.com/httpwg/http-core/is
sues/836"
brackets="angle"/>)</li>
<li>Add forward references to definition of OWS (<eref target="ht
tps://github.com/httpwg/http-core/issues/841"
brackets="angle"/>)</li>
<li>In <xref target="underscore.in.fields"/>, add a security cons
ideration regarding application handling of field names (<eref target="https://g
ithub.com/httpwg/http-core/issues/843"
brackets="angle"/>)</li>
</ul>
</section>
<section anchor="changes.since.16" title="Since draft-ietf-httpbis-sema
ntics-16">
<t>
This draft addresses mostly editorial issues raised during or past IETF
Last Call; see <eref target="https://github.com/httpwg/http-core/issues?q=labe
l%3Asemantics+created%3A%3E2021-05-26"
brackets="angle"/>
for a summary.
</t>
<t>
Furthermore:
</t>
<ul>
<li>In <xref target="status.206"/>, reinstate 'to a request' (<er
ef target="https://github.com/httpwg/http-core/issues/857"
brackets="angle"/>)</li>
<li>Align <xref target="fields.registry"/> with <xref target="con
siderations.for.new.field.names"/> (<eref target="https://github.com/httpwg/http
-core/issues/857"
brackets="angle"/>)</li>
<li>In <xref target="field.accept-ranges"/>, clarify that Accept-
Ranges can be sent by any server, remove "none" from the ABNF because it is now
a reserved range unit, and allow the field to be sent in a trailer section while
noting why that is much less useful than as a header field (<eref target="https
://github.com/httpwg/http-core/issues/857"
brackets="angle"/>)</li>
<li>In <xref target="field.via"/>, don't specify TCP (<eref targe
t="https://github.com/httpwg/http-core/issues/865"
brackets="angle"/>)</li>
<li>In <xref target="content"/>, explain the "Content-" prefix (<
eref target="https://github.com/httpwg/http-core/issues/878"
brackets="angle"/>)</li>
<li>In <xref target="routing.reject"/>, check all target URIs for
scheme semantic mismatches (<eref target="https://github.com/httpwg/http-core/i
ssues/896"
brackets="angle"/>)</li>
<li>In <xref target="GET"/>, <xref target="HEAD"/>, and <xref tar
get="DELETE"/>, clarify (again) that sending content in a request for a method t
hat does not define such content will not interoperate without prior agreement,
even if it is parsed correctly, and cannot be relied upon by an origin server un
less they control the entire request chain (<eref target="https://github.com/htt
pwg/http-core/issues/904"
brackets="angle"/>)</li>
</ul>
</section>
<section anchor="changes.since.17" title="Since draft-ietf-httpbis-sema
ntics-17">
<ul>
<li>Move ABNF for obs-text into <xref target="fields.values"/> (<
eref target="https://github.com/httpwg/http-core/issues/914"
brackets="angle"/>)</li>
<li>In <xref target="content.semantics"/>, note that response met
adata can be relevant as well (<eref target="https://github.com/httpwg/http-core
/issues/914"
brackets="angle"/>)</li>
<li>In <xref target="field.trailer"/>, use the term "signature" t
hrougout and lower expectations on what Trailer indicates without a trailer sect
ion (<eref target="https://github.com/httpwg/http-core/issues/914"
brackets="angle"/>)</li>
<li>In <xref target="field.content-type"/>, cleanup mime sniffing
discussion (<eref target="https://github.com/httpwg/http-core/issues/914"
brackets="angle"/>)</li>
<li>In <xref target="field.te"/>, add a forward reference to "wei
ght" (<eref target="https://github.com/httpwg/http-core/issues/914"
brackets="angle"/>)</li>
<li>In <xref target="field.accept-encoding"/>, clarify that the e
xamples contains multiple values; also remove obsolete HTTP/1.0 note about qvalu
es (<eref target="https://github.com/httpwg/http-core/issues/914"
brackets="angle"/>)</li>
<li>In <xref target="status.3xx"/>, remove incorrect mention of E
tag as request field (<eref target="https://github.com/httpwg/http-core/issues/9
14"
brackets="angle"/>)</li>
<li>Move text about obs-fold in message/http to <xref target="HTT
P11"/>; also note that LF is forbidden in field values just as CR and NUL (<eref
target="https://github.com/httpwg/http-core/issues/923"
brackets="angle"/>)</li>
<li>In <xref target="message.transformations"/>, properly refer t
o text that has moved to <xref target="HTTP11"/> (<eref target="https://github.c
om/httpwg/http-core/issues/930"
brackets="angle"/>)</li>
<li>Rewrite description of validators and move cache-related aspe
cts into <xref target="CACHING"/> (<eref target="https://github.com/httpwg/http-
core/issues/933"
brackets="angle"/>)</li>
<li>In <xref target="field.vary"/>, rephrase description to be mo
re explanatory (<eref target="https://github.com/httpwg/http-core/issues/938"
brackets="angle"/>)</li>
<li>In <xref target="precedence"/>, clarify that a false If-Range
means ignore the Range (<eref target="https://github.com/httpwg/http-core/issue
s/940"
brackets="angle"/>)</li>
<li>In <xref target="field.if-modified-since"/> and <xref target=
"field.if-unmodified-since"/>, restore text about missing modification date (<er
ef target="https://github.com/httpwg/http-core/issues/942"
brackets="angle"/>)</li>
<li>In <xref target="abnf.extension.sender"/>, avoid duplicate no
rmative requirement (<eref target="https://github.com/httpwg/http-core/issues/94
3"
brackets="angle"/>)</li>
<li>In <xref target="lastmod.generation"/>, reference 'Date' more
visibly (<eref target="https://github.com/httpwg/http-core/issues/945"
brackets="angle"/>)</li>
<li>In <xref target="field.proxy-authentication-info"/>, state th
at Proxy-Authentication-Info can be used as trailer (<eref target="https://githu
b.com/httpwg/http-core/issues/946"
brackets="angle"/>)</li>
<li>In <xref target="status.3xx"/>, slightly clarify history of r
edirect status codes (<eref target="https://github.com/httpwg/http-core/issues/9
47"
brackets="angle"/>)</li>
<li>In <xref target="fields.registry"/>, fix requirements for pro
visional registrations (<eref target="https://github.com/httpwg/http-core/issues
/950"
brackets="angle"/>)</li>
<li>In <xref target="authoritative.access"/>, explicitly refer to
how this spec defines access to http or https resources (<eref target="https://
github.com/httpwg/http-core/issues/951"
brackets="angle"/>)</li>
<li>In <xref target="field.date"/>, make clock a defined term and
use that definition throughout the spec (<eref target="https://github.com/httpw
g/http-core/issues/953"
brackets="angle"/>)</li>
<li>In <xref target="preconditions"/>, make preconditions consist
ent on when they are required to be evaluated (<eref target="https://github.com/
httpwg/http-core/issues/954"
brackets="angle"/>)</li>
<li>Throughout, disambiguate "selected representation" and "selec
ted response" (now "chosen response") (<eref target="https://github.com/httpwg/h
ttp-core/issues/958"
brackets="angle"/>)</li>
</ul>
</section>
<section anchor="changes.since.18" title="Since draft-ietf-httpbis-sema
ntics-18">
<ul>
<li>In <xref target="field.accept"/>, align text about "q" parame
ter with recent changes to IANA media types registry,
and instruct IANA to reference this document with respect to the "q" special c
ase (<eref target="https://github.com/httpwg/http-core/issues/970"
brackets="angle"/>)</li>
<li>In <xref target="field.name.registration"/>, rephrase text ab
out the relation with <xref target="RFC3864"/> (<eref target="https://github.com
/httpwg/http-core/pull/973" brackets="angle"/>)</li>
<li>In <xref target="intermediaries"/>, avoid bare "for the sake
of security" (<eref target="https://github.com/httpwg/http-core/pull/974" bracke
ts="angle"/>)</li>
<li>In <xref target="reactive.negotiation"/>, wordsmith future gu
idance on reactive negotiation (<eref target="https://github.com/httpwg/http-cor
e/pull/975" brackets="angle"/>)</li>
<li>In <xref target="status.301"/> and <xref target="status.308"/
>, improve text about automatic link-editing (<eref target="https://github.com/h
ttpwg/http-core/pull/976" brackets="angle"/>)</li>
<li>In <xref target="security.considerations"/>, reference <xref
target="URI"/> security considerations (<eref target="https://github.com/httpwg/
http-core/pull/977" brackets="angle"/>)</li>
</ul>
</section>
</section>
<section anchor="acks" numbered="false" title="Acknowledgements"> <section anchor="acks" numbered="false" title="Acknowledgements">
<t> <t>
Aside from the current editors, the following individuals deserve special Aside from the current editors, the following individuals deserve special
recognition for their contributions to early aspects of HTTP and its recognition for their contributions to early aspects of HTTP and its
core specifications: core specifications:
Marc Andreessen, Tim Berners-Lee, Robert Cailliau, Daniel W. Connolly, <contact fullname="Marc Andreessen"/>, <contact fullname="Tim Berners-Lee"/>,
Bob Denny, John Franks, Jim Gettys, <contact fullname="Robert Cailliau"/>, <contact fullname="Daniel W. Connolly"/>
,
<contact fullname="Bob Denny"/>, <contact fullname="John Franks"/>, <contact
fullname="Jim Gettys"/>,
<contact fullname="Jean-François Groff"/>, <contact fullname="Jean-François Groff"/>,
<contact fullname="Phillip M. Hallam-Baker"/>, <contact fullname="Phillip M. Hallam-Baker"/>,
Koen Holtman, <contact fullname="Jeffery L. Hostetler"/>, Shel Kaphan, <contact fullname="Koen Holtman"/>, <contact fullname="Jeffery L. Hostetler"/
Dave Kristol, Yves Lafon, <contact fullname="Scott D. Lawrence"/>, >, <contact fullname="Shel Kaphan"/>,
<contact fullname="Dave Kristol"/>, <contact fullname="Yves Lafon"/>, <contac
t fullname="Scott D. Lawrence"/>,
<contact fullname="Paul J. Leach"/>, <contact fullname="Håkon W. Lie"/>, <contact fullname="Paul J. Leach"/>, <contact fullname="Håkon W. Lie"/>,
Ari Luotonen, Larry Masinter, Rob McCool, <contact fullname="Ari Luotonen"/>, <contact fullname="Larry Masinter"/>, <co
<contact fullname="Jeffrey C. Mogul"/>, Lou Montulli, ntact fullname="Rob McCool"/>,
David Morris, Henrik Frystyk Nielsen, Dave Raggett, Eric Rescorla, <contact fullname="Jeffrey C. Mogul"/>, <contact fullname="Lou Montulli"/>,
Tony Sanders, <contact fullname="Lawrence C. Stewart"/>, <contact fullname="David Morris"/>, <contact fullname="Henrik Frystyk Nielsen
Marc VanHeyningen, and Steve Zilles. "/>, <contact fullname="Dave Raggett"/>, <contact fullname="Eric Rescorla"/>,
<contact fullname="Tony Sanders"/>, <contact fullname="Lawrence C. Stewart"/>
,
<contact fullname="Marc VanHeyningen"/>, and <contact fullname="Steve Zilles"
/>.
</t> </t>
<t> <t>
This edition builds on the many contributions This document builds on the many contributions
that went into past specifications of HTTP, including that went into past specifications of HTTP, including
<xref target="HTTP10" format="none">RFC 1945</xref>, <xref target="HTTP10" format="default"/>,
<xref target="RFC2068" format="none">RFC 2068</xref>, <xref target="RFC2068" format="default"/>,
<xref target="RFC2145" format="none">RFC 2145</xref>, <xref target="RFC2145" format="default"/>,
<xref target="RFC2616" format="none">RFC 2616</xref>, <xref target="RFC2616" format="default"/>,
<xref target="RFC2617" format="none">RFC 2617</xref>, <xref target="RFC2617" format="default"/>,
<xref target="RFC2818" format="none">RFC 2818</xref>, <xref target="RFC2818" format="default"/>,
<xref target="RFC7230" format="none">RFC 7230</xref>, <xref target="RFC7230" format="default"/>,
<xref target="RFC7231" format="none">RFC 7231</xref>, <xref target="RFC7231" format="default"/>,
<xref target="RFC7232" format="none">RFC 7232</xref>, <xref target="RFC7232" format="default"/>,
<xref target="RFC7233" format="none">RFC 7233</xref>, <xref target="RFC7233" format="default"/>,
<xref target="RFC7234" format="none">RFC 7234</xref>, and <xref target="RFC7234" format="default"/>, and
<xref target="RFC7235" format="none">RFC 7235</xref>. <xref target="RFC7235" format="default"/>.
The acknowledgements within those documents still apply. The acknowledgements within those documents still apply.
</t> </t>
<t> <t>
Since 2014, the following contributors have helped improve this Since 2014, the following contributors have helped improve this
specification by reporting bugs, asking smart questions, drafting or specification by reporting bugs, asking smart questions, drafting or
reviewing text, and evaluating open issues: reviewing text, and evaluating issues:
</t> </t>
<t> <t>
<contact fullname="Alan Egerton"/>, <contact fullname="Alan Egerton"/>,
<contact fullname="Alex Rousskov"/>, <contact fullname="Alex Rousskov"/>,
<contact fullname="Amichai Rothman"/>, <contact fullname="Amichai Rothman"/>,
<contact fullname="Amos Jeffries"/>, <contact fullname="Amos Jeffries"/>,
<contact fullname="Anders Kaseorg"/>, <contact fullname="Anders Kaseorg"/>,
<contact fullname="Andreas Gebhardt"/>, <contact fullname="Andreas Gebhardt"/>,
<contact fullname="Anne van Kesteren"/>, <contact fullname="Anne van Kesteren"/>,
<contact fullname="Armin Abfalterer"/>, <contact fullname="Armin Abfalterer"/>,
skipping to change at line 13940 skipping to change at line 12783
<contact fullname="Vasiliy Faronov"/>, <contact fullname="Vasiliy Faronov"/>,
<contact fullname="Vladimir Lashchev"/>, <contact fullname="Vladimir Lashchev"/>,
<contact fullname="Wenbo Zhu"/>, <contact fullname="Wenbo Zhu"/>,
<contact fullname="William A. Rowe Jr."/>, <contact fullname="William A. Rowe Jr."/>,
<contact fullname="Willy Tarreau"/>, <contact fullname="Willy Tarreau"/>,
<contact fullname="Xingwei Liu"/>, <contact fullname="Xingwei Liu"/>,
<contact fullname="Yishuai Li"/>, and <contact fullname="Yishuai Li"/>, and
<contact fullname="Zaheduzzaman Sarker"/>. <contact fullname="Zaheduzzaman Sarker"/>.
</t> </t>
</section> </section>
</back> </back>
</rfc> </rfc>
 End of changes. 608 change blocks. 
2831 lines changed or deleted 1100 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/