rfc9532.original.xml   rfc9532.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.4 (Ruby 2.6.1 <rfc xmlns:xi="http://www.w3.org/2001/XInclude"
0) --> ipr="trust200902"
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft docName="draft-ietf-httpbis-alias-proxy-status-07"
-ietf-httpbis-alias-proxy-status-07" category="std" consensus="true" tocInclude= submissionType="IETF"
"true" sortRefs="true" symRefs="true" version="3"> number="9532"
updates=""
obsoletes=""
xml:lang="en"
category="std"
consensus="true"
tocInclude="true"
sortRefs="true"
symRefs="true"
version="3">
<!-- xml2rfc v2v3 conversion 3.18.2 --> <!-- xml2rfc v2v3 conversion 3.18.2 -->
<front> <front>
<title abbrev="DNS Aliases Proxy-Status">HTTP Proxy-Status Parameter for Nex <title abbrev="Next-Hop Aliases Proxy-Status Parameter">HTTP Proxy-Status Pa
t-Hop Aliases</title> rameter for Next-Hop Aliases</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-alias-proxy-stat <seriesInfo name="RFC" value="9532"/>
us-07"/>
<author initials="T." surname="Pauly" fullname="Tommy Pauly"> <author initials="T." surname="Pauly" fullname="Tommy Pauly">
<organization>Apple, Inc.</organization> <organization>Apple, Inc.</organization>
<address> <address>
<email>tpauly@apple.com</email> <email>tpauly@apple.com</email>
</address> </address>
</author> </author>
<date/> <date month="January" year="2024"/>
<area>Applications and Real-Time</area> <area>Applications and Real-Time</area>
<workgroup>HTTP</workgroup> <workgroup>HTTP</workgroup>
<keyword>proxy status</keyword>
<abstract>
<?line 43?>
<t>This document defines the <tt>next-hop-aliases</tt> HTTP Proxy-Status Paramet <keyword>proxy status</keyword>
er. This parameter carries <abstract><t>This document defines the <tt>next-hop-aliases</tt> HTTP
the list of aliases and canonical names an intermediary received during DNS reso Proxy-Status Parameter. This parameter carries the list of aliases and
lution as part canonical names an intermediary received during DNS resolution as part of
of establishing a connection to the next hop.</t> establishing a connection to the next hop.</t>
</abstract> </abstract>
<note removeInRFC="true">
<name>About This Document</name>
<t>
Status information for this document may be found at <eref target="https
://datatracker.ietf.org/doc/draft-ietf-httpbis-alias-proxy-status/"/>.
</t>
<t>
Discussion of this document takes place on the
HTTP Working Group mailing list (<eref target="mailto:ietf-http-wg@w3.or
g"/>),
which is archived at <eref target="https://lists.w3.org/Archives/Public/
ietf-http-wg/"/>.
Working Group information can be found at <eref target="https://httpwg.o
rg/"/>.
</t>
<t>Source for this draft and an issue tracker can be found at
<eref target="https://github.com/httpwg/http-extensions/labels/alias-pro
xy-status"/>.</t>
</note>
</front> </front>
<middle> <middle>
<?line 49?>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t>The Proxy-Status HTTP response field <xref target="PROXY-STATUS"/> allo ws intermediaries to convey <t>The Proxy-Status HTTP response field <xref target="RFC9209"/> allows in termediaries to convey
information about how they handled the request in HTTP responses sent to clients . information about how they handled the request in HTTP responses sent to clients .
It defines a set of parameters that provide information, such as the name of the next It defines a set of parameters that provide information, such as the name of the next
hop.</t> hop.</t>
<t><xref target="PROXY-STATUS"/> defines a <tt>next-hop</tt> parameter, wh ich can contain a hostname, <t><xref target="RFC9209"/> defines a <tt>next-hop</tt> parameter, which c an contain a hostname,
IP address, or alias of the next hop. This parameter can contain only one such i tem, IP address, or alias of the next hop. This parameter can contain only one such i tem,
so it cannot be used to communicate a chain of aliases encountered during DNS re solution so it cannot be used to communicate a chain of aliases encountered during DNS re solution
when connecting to the next hop.</t> when connecting to the next hop.</t>
<t>Knowing the full chain of names that were used during DNS resolution vi a CNAME records <t>Knowing the full chain of names that were used during DNS resolution vi a CNAME records
<xref target="DNS"/> is particularly useful for clients of forward proxies, in w hich the <xref target="RFC1034"/> is particularly useful for clients of forward proxies, in which the
client is requesting to connect to a specific target hostname using the CONNECT method client is requesting to connect to a specific target hostname using the CONNECT method
<xref target="HTTP"/> or UDP proxying <xref target="CONNECT-UDP"/>. CNAME record s can be used to <xref target="RFC9110"/> or UDP proxying <xref target="RFC9298"/>. CNAME records can be used to
"cloak" hosts that perform tracking or malicious activity behind more innocuous hostnames, "cloak" hosts that perform tracking or malicious activity behind more innocuous hostnames,
and clients such as web browsers use the chain of DNS names to influence behavio r like cookie and clients such as web browsers use the chain of DNS names to influence behavio r like cookie
usage policies <xref target="COOKIES"/> or blocking of malicious hosts.</t> usage policies <xref target="RFC6265"/> or the blocking of malicious hosts.</t>
<t>This document allows clients to receive the CNAME chain of DNS names fo r the next hop <t>This document allows clients to receive the CNAME chain of DNS names fo r the next hop
by including the list of names in a new <tt>next-hop-aliases</tt> Proxy-Status p arameter.</t> by including the list of names in a new <tt>next-hop-aliases</tt> Proxy-Status p arameter.</t>
<section anchor="requirements"> <section anchor="requirements">
<name>Requirements</name> <name>Requirements</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL <t>
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
"MAY", and "OPTIONAL" in this document are to be interpreted as IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
only when, they 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
<?line -6?> 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>
</section> </section>
</section> </section>
<section anchor="parameter"> <section anchor="parameter">
<name>next-hop-aliases Parameter</name> <name>next-hop-aliases Parameter</name>
<t>The <tt>next-hop-aliases</tt> parameter's value is a String <xref targe t="STRUCTURED-FIELDS"/> that contains <t>The value of the <tt>next-hop-aliases</tt> parameter is a String <xref target="RFC8941"/> that contains
one or more DNS names in a comma-separated list. The items in the list include a ll alias names and one or more DNS names in a comma-separated list. The items in the list include a ll alias names and
canonical names received in CNAME records <xref target="DNS"/> during the course canonical names received in CNAME records <xref target="RFC1034"/> during the co
of resolving the next hop's urse of resolving the next hop's hostname using DNS and <bcp14>MAY</bcp14> inclu
hostname using DNS, and MAY include the original requested hostname itself. The de the original requested hostname itself. The names ought to appear in the orde
names ought to r in which they were received in DNS, for the sake of consistency. If there are
appear in the order in which they were received in DNS, for the sake of consiste multiple CNAME records in the chain, the first name in the <tt>next-hop-aliases<
ncy. If there /tt> list would
are multiple CNAME records in the chain, the first name in the <tt>next-hop-alia
ses</tt> list would
be the value in the CNAME record for the original hostname, and the final name i n the be the value in the CNAME record for the original hostname, and the final name i n the
<tt>next-hop-aliases</tt> list would be the name that ultimately resolved to one <tt>next-hop-aliases</tt> list would be the name that ultimately resolved
or more addresses.</t> to one or more addresses.</t>
<t>The list of DNS names in <tt>next-hop-aliases</tt> uses a comma (",") a <t>The list of DNS names in <tt>next-hop-aliases</tt> parameter uses a com
s a separator between names. ma (",") as a separator between names.
Note that if a comma is included in a name itself, the comma must be encoded as described in Note that if a comma is included in a name itself, the comma must be encoded as described in
<xref target="encoding"/>.</t> <xref target="encoding"/>.</t>
<t>For example, consider a proxy "proxy.example.net" that receives the fol lowing records when <t>For example, consider a proxy "proxy.example.net" that receives the fol lowing records when
performing DNS resolution for the next hop "host.example.com":</t> performing DNS resolution for the next hop "host.example.com":</t>
<sourcecode type="dns-example"><![CDATA[
<sourcecode type=""><![CDATA[
host.example.com. CNAME tracker.example.com. host.example.com. CNAME tracker.example.com.
tracker.example.com. CNAME service1.example.com. tracker.example.com. CNAME service1.example.com.
service1.example.com. AAAA 2001:db8::1 service1.example.com. AAAA 2001:db8::1
]]></sourcecode> ]]></sourcecode>
<t>The proxy could include the following proxy status in its response:</t> <t>The proxy could include the following proxy status in its response:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
Proxy-Status: proxy.example.net; next-hop="2001:db8::1"; Proxy-Status: proxy.example.net; next-hop="2001:db8::1";
next-hop-aliases="tracker.example.com,service1.example.com" next-hop-aliases="tracker.example.com,service1.example.com"
]]></sourcecode> ]]></sourcecode>
<t>This indicates that proxy.example.net, which used the IP address "2001: db8::1" as the next hop <t>This indicates that "proxy.example.net", which used the IP address "200 1:db8::1" as the next hop
for this request, encountered the names "tracker.example.com" and "service1.exam ple.com" for this request, encountered the names "tracker.example.com" and "service1.exam ple.com"
in the DNS resolution chain. Note that while this example includes both the <tt> next-hop</tt> and in the DNS resolution chain. Note that while this example includes both the <tt> next-hop</tt> and
<tt>next-hop-aliases</tt> parameters, <tt>next-hop-aliases</tt> can be included without including <tt>next-hop</tt>.</t> <tt>next-hop-aliases</tt> parameters, <tt>next-hop-aliases</tt> can be included without including <tt>next-hop</tt>.</t>
<t>The proxy can also include the name of the next hop as the first item i n the list. This is <t>The proxy can also include the name of the next hop as the first item i n the list. This is
particularly useful for reverse proxies when clients would not otherwise know th e name of the particularly useful for reverse proxies when clients would not otherwise know th e name of the
next hop, and the <tt>next-hop</tt> header is used to convey an IP address.</t> next hop, and the <tt>next-hop</tt> header is used to convey an IP address.</t>
<t>For example, consider a proxy "reverseproxy.example.net" that receives the following records <t>For example, consider a proxy "reverseproxy.example.net" that receives the following records
when performing DNS resolution for the next hop "host.example.com":</t> when performing DNS resolution for the next hop "host.example.com":</t>
<sourcecode type="dns-example"><![CDATA[ <sourcecode type=""><![CDATA[
host2.example.com. CNAME service2.example.com. host2.example.com. CNAME service2.example.com.
service2.example.com. AAAA 2001:db8::2 service2.example.com. AAAA 2001:db8::2
]]></sourcecode> ]]></sourcecode>
<t>The proxy could include the following proxy status in its response:</t> <t>The proxy could include the following proxy status in its response:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
Proxy-Status: reverseproxy.example.net; next-hop="2001:db8::2"; Proxy-Status: reverseproxy.example.net; next-hop="2001:db8::2";
next-hop-aliases="host2.example.com,service2.example.com" next-hop-aliases="host2.example.com,service2.example.com"
]]></sourcecode> ]]></sourcecode>
<t>The <tt>next-hop-aliases</tt> parameter only applies when DNS was used <t>The <tt>next-hop-aliases</tt> parameter only applies when DNS was used
to resolve the next hop's name, and to resolve the next hop's name, and it
does not apply in all situations. Clients can use the information in this parame does not apply in all situations. Clients can use the information in this parame
ter to determine ter to determine how to use the connection established through the proxy, but th
how to use the connection established through the proxy, but need to gracefully ey need to gracefully handle situations in which this parameter is not present.<
handle situations /t>
in which this parameter is not present.</t> <t>The proxy <bcp14>MAY</bcp14> send the empty string ("") as the value of
<t>The proxy MAY send the empty string ("") as the value of <tt>next-hop-a <tt>next-hop-aliases</tt> parameter to indicate that
liases</tt> to indicate that
no CNAME records were encountered when resolving the next hop's name.</t> no CNAME records were encountered when resolving the next hop's name.</t>
<section anchor="encoding"> <section anchor="encoding">
<name>Encoding special characters</name> <name>Encoding Special Characters</name>
<t>DNS names commonly just contain alphanumeric characters and hyphens ( <t>DNS names commonly contain just alphanumeric characters and hyphens (
"-"), although they "-"), although they
are allowed to contain any character (<xref section="3.1" sectionFormat="comma" target="RFC1035"/>), including a comma. To are allowed to contain any character (<xref section="3.1" sectionFormat="comma" target="RFC1035"/>), including a comma. To
prevent commas or other special characters in names leading to incorrect parsing , prevent commas or other special characters in names leading to incorrect parsing ,
any characters that appear in names in this list that do not belong to the set o f URI any characters that appear in names in this list that do not belong to the set o f URI
Unreserved Characters (<xref section="2.3" sectionFormat="comma" target="RFC3986 "/>) MUST be percent-encoded as unreserved characters (<xref section="2.3" sectionFormat="comma" target="RFC3986 "/>) <bcp14>MUST</bcp14> be percent-encoded as
defined in <xref section="2.1" sectionFormat="comma" target="RFC3986"/>.</t> defined in <xref section="2.1" sectionFormat="comma" target="RFC3986"/>.</t>
<t>For example, consider the DNS name <tt>comma,name.example.com</tt>. T his name would be encoded <t>For example, consider the DNS name "comma,name.example.com". This nam e would be encoded
within a <tt>next-hop-aliases</tt> parameter as follows:</t> within a <tt>next-hop-aliases</tt> parameter as follows:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
Proxy-Status: proxy.example.net; next-hop="2001:db8::1"; Proxy-Status: proxy.example.net; next-hop="2001:db8::1";
next-hop-aliases="comma%2Cname.example.com,service1.example.com" next-hop-aliases="comma%2Cname.example.com,service1.example.com"
]]></sourcecode> ]]></sourcecode>
<t>It is also possible for a DNS name to include a period character ("." <t>It is also possible for a DNS name to include a period character ("."
) within a label, ) within a label instead of as a label separator. In this case, the period chara
instead of as a label separator. In this case, the period character MUST be firs cter <bcp14>MUST</bcp14> first be escaped
t escaped
as "\.". Since the "\" character itself will be percent-encoded, the name as "\.". Since the "\" character itself will be percent-encoded, the name
"dot\.label.example.com" would be encoded within a <tt>next-hop-aliases</tt> par ameter as follows:</t> "dot\.label.example.com" would be encoded within a <tt>next-hop-aliases</tt> par ameter as follows:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
Proxy-Status: proxy.example.net; next-hop="2001:db8::1"; Proxy-Status: proxy.example.net; next-hop="2001:db8::1";
next-hop-aliases="dot%5C.label.example.com,service1.example.com" next-hop-aliases="dot%5C.label.example.com,service1.example.com"
]]></sourcecode> ]]></sourcecode>
<t>Upon parsing this name, "dot%5C.label" MUST be treated as a single la <t>Upon parsing this name, "dot%5C.label" <bcp14>MUST</bcp14> be treated
bel.</t> as a single label.</t>
<t>Similarly the "\" character in a label MUST be escaped as "\\" and th <t>Similarly, the "\" character in a label <bcp14>MUST</bcp14> be escape
en percent-encoded. d as "\\" and then percent-encoded. Other uses of "\" <bcp14>MUST NOT</bcp14> ap
Other uses of "\" MUST NOT appear in the label after percent-decoding. For examp pear in the label after percent-decoding. For example, if there is a DNS name "b
le, ackslash\name.example.com", it would first be escaped as "backslash\\name.exampl
if there is a DNS name "backslash\name.example.com", it would first be escaped a e.com" and then percent-encoded as follows:</t>
s
"backslash\\name.example.com", and then percent-encoded as follows:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
Proxy-Status: proxy.example.net; next-hop="2001:db8::1"; Proxy-Status: proxy.example.net; next-hop="2001:db8::1";
next-hop-aliases="backslash%5C%5Cname.example.com,service1.example.com" next-hop-aliases="backslash%5C%5Cname.example.com,s1.example.com"
]]></sourcecode> ]]></sourcecode>
</section> </section>
</section> </section>
<section anchor="implementation-considerations"> <section anchor="implementation-considerations">
<name>Implementation Considerations</name> <name>Implementation Considerations</name>
<t>In order to include the <tt>next-hop-aliases</tt> parameter, a proxy ne eds to have access to the chain <t>In order to include the <tt>next-hop-aliases</tt> parameter, a proxy ne eds to have access to the chain
of alias names and canonical names received in CNAME records.</t> of alias names and canonical names received in CNAME records.</t>
<t>Implementations ought to note that the full chain of names might not be available in common DNS <t>Implementations ought to note that the full chain of names might not be available in common DNS
resolution APIs, such as <tt>getaddrinfo</tt> <xref target="POSIX"/>. <tt>getadd rinfo</tt> does have an option for <tt>AI_CANONNAME</tt> resolution APIs, such as <tt>getaddrinfo</tt> <xref target="POSIX"/>. <tt>getadd rinfo</tt> does have an option for <tt>AI_CANONNAME</tt>
(<xref section="6.1" sectionFormat="of" target="RFC3493"/>), but this will only return the last name in the chain (<xref section="6.1" sectionFormat="comma" target="RFC3493"/>), but this will on ly return the last name in the chain
(the canonical name), not the alias names.</t> (the canonical name), not the alias names.</t>
<t>An implementation MAY include incomplete information in the <tt>next-ho p-aliases</tt> parameter to accommodate cases where it is unable to include the full chain, such as only including the canonical name if the implementation can only use <tt>getaddrinfo</tt> as described above.</t> <t>An implementation <bcp14>MAY</bcp14> include incomplete information in the <tt>next-hop-aliases</tt> parameter to accommodate cases where it is unable to include the full chain, such as only including the canonical name if the impl ementation can only use <tt>getaddrinfo</tt> as described above.</t>
</section> </section>
<section anchor="sec-considerations"> <section anchor="sec-considerations">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>The <tt>next-hop-aliases</tt> parameter does not include any DNSSEC inf ormation or imply that DNSSEC was used. <t>The <tt>next-hop-aliases</tt> parameter does not include any DNSSEC inf ormation or imply that DNSSEC was used.
The information included in the parameter can only be trusted to be valid insofa r as the client The information included in the parameter can only be trusted to be valid insofa r as the client
trusts the proxy to provide accurate information. This information is intended t o be used as trusts the proxy to provide accurate information. This information is intended t o be used as
a hint, and SHOULD NOT be used for making security decisions about the identity of a resource accessed a hint and <bcp14>SHOULD NOT</bcp14> be used for making security decisions about the identity of a resource accessed
through the proxy.</t> through the proxy.</t>
<t>Inspecting CNAME chains can be used to detect cloaking of trackers or m alicious hosts. However, the <t>Inspecting CNAME chains can be used to detect cloaking of trackers or m alicious hosts. However, the
CNAME records could be omitted by a recursive or authoritative resolver that is trying to hide this form of cloaking. CNAME records could be omitted by a recursive or authoritative resolver that is trying to hide this form of cloaking.
In particular, recursive or authoritative resolvers can omit these records for b oth clients directly performing DNS name In particular, recursive or authoritative resolvers can omit these records for b oth clients directly performing DNS name
resolution and proxies performing DNS name resolution on behalf of client. A mal icious proxy could resolution and proxies performing DNS name resolution on behalf of a client. A m alicious proxy could
also choose to not report these CNAME chains in order to hide the cloaking. In g eneral, clients can also choose to not report these CNAME chains in order to hide the cloaking. In g eneral, clients can
trust information included (or not included) in the <tt>next-hop-aliases</tt> pa rameter to the degree trust information included (or not included) in the <tt>next-hop-aliases</tt> pa rameter to the degree
that the proxy and any resolvers used by the proxy are trusted.</t> that the proxy and any resolvers used by the proxy are trusted.</t>
</section> </section>
<section anchor="iana-considerations"> <section anchor="iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>This document registers the "next-hop-aliases" parameter <t>This document registers the <tt>next-hop-aliases</tt> parameter
in the "HTTP Proxy-Status Parameters" registry in the "HTTP Proxy-Status Parameters" registry <eref target="https://www.iana.or
&lt;<eref target="https://www.iana.org/assignments/http-proxy-status"/>&gt;.</t> g/assignments/http-proxy-status" brackets="angle"/> as shown in <xref target="ta
<dl> ble_1"/>.</t>
<dt>Name:</dt>
<dd> <table anchor="table_1">
<t>next-hop-aliases</t> <name>HTTP Proxy-Status Parameters Registry</name>
</dd> <thead>
<dt>Description:</dt> <tr>
<dd> <th>Name</th>
<t>A string containing one or more DNS aliases or canonical names used <th>Description</th>
to establish a <th>Reference</th>
proxied connection to the next hop.</t> </tr>
</dd> </thead>
<dt>Reference:</dt> <tbody>
<dd> <tr>
<t>This document</t> <td>next&nbhy;hop&nbhy;aliases</td>
</dd> <td>A string containing one or more DNS aliases or canonical names used to
</dl> establish a proxied connection to the next hop.</td>
<td>RFC 9532</td>
</tr>
</tbody>
</table>
</section> </section>
</middle> </middle>
<back> <back>
<displayreference target="RFC9209" to="PROXY-STATUS"/>
<displayreference target="RFC1034" to="DNS"/>
<displayreference target="RFC9110" to="HTTP"/>
<displayreference target="RFC9298" to="CONNECT-UDP"/>
<displayreference target="RFC8941" to="STRUCTURED-FIELDS"/>
<displayreference target="RFC6265" to="COOKIES"/>
<references> <references>
<name>References</name> <name>References</name>
<references anchor="sec-normative-references"> <references anchor="sec-normative-references">
<name>Normative References</name> <name>Normative References</name>
<reference anchor="PROXY-STATUS">
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.
<title>The Proxy-Status HTTP Response Header Field</title> 9209.xml"/>
<author fullname="M. Nottingham" initials="M." surname="Nottingham"/ <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.
> 1034.xml"/>
<author fullname="P. Sikora" initials="P." surname="Sikora"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.
<date month="June" year="2022"/> 9110.xml"/>
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.
<t>This document defines the Proxy-Status HTTP response field to c 9298.xml"/>
onvey the details of an intermediary's response handling, including generated er <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.
rors.</t> 2119.xml"/>
</abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.
</front> 8174.xml"/>
<seriesInfo name="RFC" value="9209"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.
<seriesInfo name="DOI" value="10.17487/RFC9209"/> 8941.xml"/>
</reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.
<reference anchor="DNS"> 3986.xml"/>
<front>
<title>Domain names - concepts and facilities</title>
<author fullname="P. Mockapetris" initials="P." surname="Mockapetris
"/>
<date month="November" year="1987"/>
<abstract>
<t>This RFC is the revised basic definition of The Domain Name Sys
tem. It obsoletes RFC-882. This memo describes the domain style names and their
used for host address look up and electronic mail forwarding. It discusses the c
lients and servers in the domain name system and the protocol used between them.
</t>
</abstract>
</front>
<seriesInfo name="STD" value="13"/>
<seriesInfo name="RFC" value="1034"/>
<seriesInfo name="DOI" value="10.17487/RFC1034"/>
</reference>
<reference anchor="HTTP">
<front>
<title>HTTP Semantics</title>
<author fullname="R. Fielding" initials="R." role="editor" surname="
Fielding"/>
<author fullname="M. Nottingham" initials="M." role="editor" surname
="Nottingham"/>
<author fullname="J. Reschke" initials="J." role="editor" surname="R
eschke"/>
<date month="June" year="2022"/>
<abstract>
<t>The Hypertext Transfer Protocol (HTTP) is a stateless applicati
on-level protocol for distributed, collaborative, hypertext information systems.
This document describes the overall architecture of HTTP, establishes common te
rminology, and defines aspects of the protocol that are shared by all versions.
In this definition are core protocol elements, extensibility mechanisms, and the
"http" and "https" Uniform Resource Identifier (URI) schemes.</t>
<t>This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7
232, 7233, 7235, 7538, 7615, 7694, and portions of 7230.</t>
</abstract>
</front>
<seriesInfo name="STD" value="97"/>
<seriesInfo name="RFC" value="9110"/>
<seriesInfo name="DOI" value="10.17487/RFC9110"/>
</reference>
<reference anchor="CONNECT-UDP">
<front>
<title>Proxying UDP in HTTP</title>
<author fullname="D. Schinazi" initials="D." surname="Schinazi"/>
<date month="August" year="2022"/>
<abstract>
<t>This document describes how to proxy UDP in HTTP, similar to ho
w the HTTP CONNECT method allows proxying TCP in HTTP. More specifically, this d
ocument defines a protocol that allows an HTTP client to create a tunnel for UDP
communications through an HTTP server that acts as a proxy.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9298"/>
<seriesInfo name="DOI" value="10.17487/RFC9298"/>
</reference>
<reference anchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit
le>
<author fullname="S. Bradner" initials="S." surname="Bradner"/>
<date month="March" year="1997"/>
<abstract>
<t>In many standards track documents several words are used to sig
nify the requirements in the specification. These words are often capitalized. T
his document defines these words as they should be interpreted in IETF documents
. This document specifies an Internet Best Current Practices for the Internet Co
mmunity, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<date month="May" year="2017"/>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protoco
l specifications. This document aims to reduce the ambiguity by clarifying that
only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="STRUCTURED-FIELDS">
<front>
<title>Structured Field Values for HTTP</title>
<author fullname="M. Nottingham" initials="M." surname="Nottingham"/
>
<author fullname="P-H. Kamp" surname="P-H. Kamp"/>
<date month="February" year="2021"/>
<abstract>
<t>This document describes a set of data types and associated algo
rithms that are intended to make it easier and safer to define and handle HTTP h
eader and trailer fields, known as "Structured Fields", "Structured Headers", or
"Structured Trailers". It is intended for use by specifications of new HTTP fie
lds that wish to use a common syntax that is more restrictive than traditional H
TTP field values.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8941"/>
<seriesInfo name="DOI" value="10.17487/RFC8941"/>
</reference>
<reference anchor="RFC3986">
<front>
<title>Uniform Resource Identifier (URI): Generic Syntax</title>
<author fullname="T. Berners-Lee" initials="T." surname="Berners-Lee
"/>
<author fullname="R. Fielding" initials="R." surname="Fielding"/>
<author fullname="L. Masinter" initials="L." surname="Masinter"/>
<date month="January" year="2005"/>
<abstract>
<t>A Uniform Resource Identifier (URI) is a compact sequence of ch
aracters that identifies an abstract or physical resource. This specification de
fines the generic URI syntax and a process for resolving URI references that mig
ht be in relative form, along with guidelines and security considerations for th
e use of URIs on the Internet. The URI syntax defines a grammar that is a supers
et of all valid URIs, allowing an implementation to parse the common components
of a URI reference without knowing the scheme-specific requirements of every pos
sible identifier. This specification does not define a generative grammar for UR
Is; that task is performed by the individual specifications of each URI scheme.
[STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="STD" value="66"/>
<seriesInfo name="RFC" value="3986"/>
<seriesInfo name="DOI" value="10.17487/RFC3986"/>
</reference>
</references> </references>
<references anchor="sec-informative-references"> <references anchor="sec-informative-references">
<name>Informative References</name> <name>Informative References</name>
<reference anchor="POSIX" target="http://ieeexplore.ieee.org/servlet/opa c?punumber=6506089"> <reference anchor="POSIX" target="https://ieeexplore.ieee.org/document/8 277153">
<front> <front>
<title>Standard for Information Technology Portable Operating System Interface (POSIX(R)) Base Specifications, Issue 7</title> <title>IEEE Standard for Information Technology--Portable Operating System Interface (POSIX(TM)) Base Specifications, Issue 7</title>
<author> <author>
<organization>IEEE</organization> <organization>IEEE</organization>
</author> </author>
<date year="2013" month="April"/> <date year="2018" month="January"/>
</front>
<seriesInfo name="DOI" value="10.1109/ieeestd.2013.6506091"/>
</reference>
<reference anchor="COOKIES">
<front>
<title>HTTP State Management Mechanism</title>
<author fullname="A. Barth" initials="A." surname="Barth"/>
<date month="April" year="2011"/>
<abstract>
<t>This document defines the HTTP Cookie and Set-Cookie header fie
lds. These header fields can be used by HTTP servers to store state (called cook
ies) at HTTP user agents, letting the servers maintain a stateful session over t
he mostly stateless HTTP protocol. Although cookies have many historical infelic
ities that degrade their security and privacy, the Cookie and Set-Cookie header
fields are widely used on the Internet. This document obsoletes RFC 2965. [STAND
ARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6265"/>
<seriesInfo name="DOI" value="10.17487/RFC6265"/>
</reference>
<reference anchor="RFC1035">
<front>
<title>Domain names - implementation and specification</title>
<author fullname="P. Mockapetris" initials="P." surname="Mockapetris
"/>
<date month="November" year="1987"/>
<abstract>
<t>This RFC is the revised specification of the protocol and forma
t used in the implementation of the Domain Name System. It obsoletes RFC-883. Th
is memo documents the details of the domain name client - server communication.<
/t>
</abstract>
</front>
<seriesInfo name="STD" value="13"/>
<seriesInfo name="RFC" value="1035"/>
<seriesInfo name="DOI" value="10.17487/RFC1035"/>
</reference>
<reference anchor="RFC3493">
<front>
<title>Basic Socket Interface Extensions for IPv6</title>
<author fullname="R. Gilligan" initials="R." surname="Gilligan"/>
<author fullname="S. Thomson" initials="S." surname="Thomson"/>
<author fullname="J. Bound" initials="J." surname="Bound"/>
<author fullname="J. McCann" initials="J." surname="McCann"/>
<author fullname="W. Stevens" initials="W." surname="Stevens"/>
<date month="February" year="2003"/>
<abstract>
<t>The de facto standard Application Program Interface (API) for T
CP/IP applications is the "sockets" interface. Although this API was developed f
or Unix in the early 1980s it has also been implemented on a wide variety of non
-Unix systems. TCP/IP applications written using the sockets API have in the pas
t enjoyed a high degree of portability and we would like the same portability wi
th IPv6 applications. But changes are required to the sockets API to support IPv
6 and this memo describes these changes. These include a new socket address stru
cture to carry IPv6 addresses, new address conversion functions, and some new so
cket options. These extensions are designed to provide access to the basic IPv6
features required by TCP and UDP applications, including multicasting, while int
roducing a minimum of change into the system and providing complete compatibilit
y for existing IPv4 applications. Additional extensions for advanced IPv6 featur
es (raw sockets and access to the IPv6 extension headers) are defined in another
document. This memo provides information for the Internet community.</t>
</abstract>
</front> </front>
<seriesInfo name="RFC" value="3493"/> <seriesInfo name="IEEE Std" value="1003.1-2017"/>
<seriesInfo name="DOI" value="10.17487/RFC3493"/> <seriesInfo name="DOI" value="10.1109/IEEESTD.2018.8277153"/>
</reference> </reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.
6265.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.
1035.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.
3493.xml"/>
</references> </references>
</references> </references>
</back> </back>
<!-- ##markdown-source:
H4sIACnXeWUAA81a/W4bNxL/n0/B26CoA0hry07SWG2aqrZ7EZrYPsvGtWiK
mtqlJF5Wyy3JlSIY6bPcs9yT3cyQ+yXLbu+AKy4oKnmXH/Pxm9/MkOr3+8wp
l8khf3N9fckvjf646U+ccKXll8KIpXTS8Jk2/Fx+dP03uuCjTAkrLRPTqZGr
IT89n1TPOvNZqpMcFhjy1IiZ6yvpZv2Fc8VU2b7ACf2Chlsa3j/4gqXCwfC7
09H12SeWwB9zbTZDbl3KhJFiyEdFkSl4oXRuuchTfiVF1r9WS8nW2nyYG10W
XhXGVGGG3JnSusODg+ODQ/ZBbmBQOmS8z2ln7ndmDD7z9BeR6Ry234BuhRry
n5xOetxq44ycWfi2WeKXnxlbybyUsAxv78e52xQw/e8gh8rn/K/4Dp4uNJoA
9bbD/X38XM9jbeb78G4pVDbktWH66/k36yN8Ce+ESRbNvExZZ2P/cn8Er9RK
2v3Lcgrm2G8vgMsaWehm6ly5RTmNE70Mu9NHH9wpc4uG3M/EVGZ2/75PmJ/b
V9aWsk/DhnzHMCZKt9AGLQvbc65yO+TXMSCozDb0xAPhWi+Xm9ZTUMb7VPb4
OE9ieii9VVyBw74R+BaFB4fmgMMlOH9Fxuf88mIy/sF/Bet7GEcT9KUwKYF2
XE3ROb+WySLXmZ6DBOBUMc0kvyikgbfgrsnGOrmECYD3mUgk36PV966ePuXf
Arb5pJCJmlXgA3nRJvyLKGxfWyD8I9XGZ2dnlXjCzKXzXgGnKCnlxyLTRsb4
ldxqpVll0u3rQiSvizIvl1NpXr14fvDi4OVxWMZHyKgwKuOHB4Oj8BimKmnR
QI0EpxfjIR8cxIPBwTHtB2EU45yYljweMNbv97mYWmdE4hi7XijLIWjLpcwd
T+VM5RDSbiH5bY7Bv9CFj1tpbx+ji5jTSkVNH4kwKB7DpRDIXM94WIiCOBG5
zsGyGcEEnwGCYOJSpkqYDeA5keD0lKelQV8h4xhpdVaSYwXt5RisCjqCX5Vd
4DDBE53nMqFBTpMmqAiEZBF75ZcqTTPJ2BN0vNFpSYPRFLKrHKkLexbge8ln
SmYpv7v7y+XVxQ8/9ifXo+ubyaur706ODw+OP30C5TK9tm0lFFpSo0AruWmQ
jNJPdYkirVG+DV+AQTJQFYU18tcSNIJ1uvtb8Dd4CNfLFHyzMRs3DhPwlkxc
OwCdKBxy3kqlkrd2B1YrkwVakIwDw3FiZSjmDfWwns2WNUJum217fL1QsDq4
FxV3AvQQoKl1uFGPjS+5SFNQCqIJYpUQ0d6e/HQfS81iOs828D/plVAQvz1m
NXzBUbl2fCp5adGYaPnlskSQOYnAWND8BoYyT3SJ7noIZWy9kHkNKHh9H1Df
53pNb+DxrMyyZhcPa3LCGrbwQu0G80oJfnI+eneGqIdsZdH8MAatPjg4egZW
9/ZwKikzYcACsBpsR3wX8IB7wp9rpEEkakBfD1Hk/QHyMT8QlwogCyoFBfEr
4ChQXiCv2nWwY6XnycX5+dnJNQfnLHSKsiJSCSLAOyAsCHVzeunzLU6CEWFO
H557LB2//PQp7mpNfm7cx6Ik0+JDRCJUcAaiBhxzZC/KuLDVEvyZKA0BC4ym
VsptYBEgg5QvgWrBBDnQG76uVLE9RgwU7FZFw1pO+dRADGPwgAyka+1OdFlw
qcZoykqAj8SdxEqBFJn6AKO1/qAkK62YS15olAsm3N29Prm4+H58Rg59cfji
ubfRNNNBiVlLCdI23mbmwC6VzCBDIEjvETLjDlkRH23EsukGhE+yMq2cWXGz
H0/Rmsv1LvbvcGMdnCDpkydQkv1aKiNRVOuZFAovviavRu9uJtdRz3/y8wv6
fnX2t5vx1dkpfp+8Gb19W39hYcTkzcXN29PmWzPz5OLdu7PzUz8ZnvLOIxa9
G/0Ib9DF0cXl9fjifPQ2Qs1c16KADTDjVHrKLgxokwIOWCptYtQU/oA5355c
/uufg2cIYfDd4WCAFOj/eDn4AiMTOcLvRtTk/0RaZ1DGSGHIpkgMolBOZBCU
gDUL3J/zBfBCzL56nQGh8v6L118zzErblm/V5HdPart/8mbe4ad6yOeWrwTg
FCNe8IkzIRYn11c3J9c3YP3+d+Ozt6cEy5fHzwagDUVZ4FrLkGcxwjCOGlAR
SJBbRd9K3A0NhzhC4pbEydbbO8DLI06SGTzjVzk/Zdt1QJ33YYEuO9zdgQiY
gDyHUnTq0lhKX8Smq+p5BffPLdviL1jCOwtAUsuFU7RRc5WDGIEbQYJ6qnJW
ZjOvnZdSl/MFEmbLx36RVJoO6W48+be1IhGqwLTiA8kPJrdgKuCUTczHlA+N
xAaIL8vMKaiHt6wRdqSY7/n0owzY2gucP1TCkT/WusxSNvWKB4jkLSLxe9Qy
1qap0zhZ0O+ZB8+FFdije/KwJ00gqKFyUJbIbBNc6DN3G3ihXpCeFBvG6gBy
x7YllZoeqHwv6kVPMfKwUiLMIgFLt5aQ4WmVmJ1rF6RSs3qishVM0sCODSJ6
AYQ4bgk9J6qHRUVKRMLbRAJZkt4ABiHvMfYdbC8/iiW1QeR8RI4IPWpEH3EY
EOfSRV6wgCNfus00JgVEdQUKJB8WcuSOOmM7G/AIPVpvA4pEQ8Z+++03nua2
Hx6z7TExb/55vHCfjyEZtIexXQ+3J2L/oxI56M7c+TTMHME//IQGfzBMpy+H
wwGK7LHhzZcQ1trR3ZiqfQiADgVP1jV2UJ5aZUAEZnHWznpDfs8vX9Z0/Spq
SRR96TvgLVC+inbYpLdL26jSifCXUg3blPRdGaqa29dNoG1TZPOOUHXNX1UD
HhBNQdjr1MSuprtdYkc+w+4WPtDJFv6IrGLexBnInUkvQZheec3yqXaLLovd
UsJ4LONBct3xOpSVdRivFdStpWsVQs0WcQdHAlM3dhctKG03TBRIwbCegjEB
tvNf6GeUZQ+V8EauJCayULdz33eEWs8zJ7Y2GrPCWsHAD7nvHdvSsEqahp5b
pltIQbnJtroj7Eux8W7w8vvMFET97wjKN1T/C4I6fIChtnjmcCfP7Jx8n2cO
/zyeecjKu+nm8EG6uWea3i6Vo0axx6LLF7h4OFdjFP23Fg2mQg7fKsJ4XTSw
VMNUxDIus6lqY6tc6c/YoCUMsMfgq7qw9tlJVcg3YsG+KX4BRCEY1vig7t+a
06D6nIiozWAJR0PIyD0+BUbIpVdjDnSHwZlVZzMtCVmrvOuIobxi0EjgSU2H
SLDYhIc+KOWycIgMqmL3Il+WNJUYBPMOJ1DT6dMABRrL9VZBSHVmm77JQQ/V
xeQS37udhbrEt/6CjjDwcBDb4LsnddXCWFNwYclDYPgHVj31OU9WgLWguzIq
aS+CbLTYFCCOBX370VOAQoYU7B2woTKXGtyamPx6+aZZhu9BG+3PQ573+CT4
9CiGpuVpr0XloW4DztWswDDKnX9isaAkBt2lqApVIM+AJ8O5CCyqjcGTEXAy
dg94brBpzyLKa1qAuholZFCdSiNSzf3JVKabQ6RwYHdzNWY3OWLGYO170iy+
59vMo+OXLxqFD+MjUJhTKw05Dag0AQ37TdXJ/PkcFau7Fxg8UoBWSZvSyi3Z
rUdIabHFbchnNKYu64MEDJMr1cmPMomwgSrtn1BzkRqfHZ5sK/JY4TWmczJK
/oW2VuHFAWYn0ZjHNXWBQEconbbhGsUQ2bU16B6lB9wBPZ5I6RTSVo+bjgRa
vwCeBET37cW9lSvf+2IDegxRgN1huej9+ziK+UThwRROhQdRa6JvWkAmYNz7
2OnV9QSLUu1gLRKuW/Jtu5v/H7obhP/s+cl96R9z9w3k5SrKvQN8yuosFtWm
d0YKf1qE/STMAXT4/RibqKXyBd4uF9RYqNcKDuTegTg8VG/5todidkH0RY0t
IIjWrg7VePckwu8hZrhptUwqPZXHvB38TIXTBn9MVMM7mkLJbzNhF+/fb0dO
1MMDdw8GD8OOIqw9d+fsh1T8c5FSSwkuhv/+E354wsf4BE8SfVlyEig0FAkM
AtmfBrlu+/BYnPTqMhsLETrlXQiopkSSYC8XEgd1Uay6x2iO0u5dqT14lAYo
7UrfHGhhogrN2UNXGkuFQ8NVi1gJQPuUGrdQFiCEWKuoH12ObXPndDuXDpsN
LOluIUPRjSteBXRfUJ3olYeti7o7uB2NfzkZnV+coz63DHJkldhexAOUEWuE
o2fHR1QWYE1H0UycRxWLka40VYxsnZd5y+7R144tYSnUF1+0jA5mHEE92sVB
+1wRCwh863ZUsL9TauNdTEL2xNtfSgdUcmOYUmoqc7L6FroafzUWJ7W7h/5d
7bhngG1NsACnuVhLd73TOdwSU72iUhJrjNLg/Us3GKCKtDLpJ52Hf+D8mtfN
Qp1nofwCdE3OTjoGBVyg7BuP2zCgakti2qdr/+Y8jzJs56KRVCaOL+kU2N8R
QG2ucILVM2Gqgt136IxG2qaXwCnVvSs4scQD8rYA1XlAWyR/cZyn9YbUUQGV
Cg751XnGbC5C6hEzugCjWyRbWR94Xln/axm6ZybfpiApvkTeoK6gBOINzALl
w72GCDkix0KZbglbF0zb13TUe0GNTJd14TYrHBfZ7vWcv9nib6DOXyHZ4ZnF
1gVgVV7opXJo/OmGpAXFLN51YQFGv7lQjn4SUvWbJhzbghPMJlTvC5WGoyW6
McQz9iBhjOTcHMX0/sgGXmsUC8W2shYZHUBHVdVxTaqwZQAMbR1zUGXV/gVD
Xt/T7hraPhbROd0zQu1GWuA+MR+1LNs6jmBUsyYLra0MfE6/DTKV4B1XqlaW
CgaTjZ2wGp3LHEI269X6gR084nfH1B7YoxWy6dM/Snc4JpVzIyWr04/XCy2F
kd/4gqA33bTHmDpiiYrGo/PRvZzcvVI1co43LsZHbrQtXtSIVx1nRo/8AAbG
+wXNhn3108971S+x1ut1rEQu6Nc+AjqJeU63pP4HWe1fVD39GiQ/x99MseG9
YgW6byJcyoQ4YFSdIIRumSJv67quukDU5l5tUAVvfSjCBfNoTB//Bc2VnEES
gg4DhegYlP0bEDGZMlkoAAA=
</rfc> </rfc>
 End of changes. 43 change blocks. 
428 lines changed or deleted 148 lines changed or added

This html diff was produced by rfcdiff 1.48.