rfc9209v1.xml   rfc9209.xml 
skipping to change at line 12 skipping to change at line 12
<!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;">
]> ]>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.5.6 --> <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.5.6 -->
<!-- [rfced] The sortRefs was absent in the submitted XML file. May we alphabeti <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
ze the references (i.e., set "sortRefs" to "true")? --> -ietf-httpbis-proxy-status-08" number="9209" obsoletes="" updates="" submissionT
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft ype="IETF" category="std" consensus="true" xml:lang="en" tocInclude="true" sortR
-ietf-httpbis-proxy-status-08" number="9209" obsoletes="" updates="" submissionT efs="true" symRefs="true" version="3">
ype="IETF" category="std" consensus="true" xml:lang="en" tocInclude="true" symRe
fs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.10.0 --> <!-- xml2rfc v2v3 conversion 3.10.0 -->
<front> <front>
<title abbrev="Proxy-Status Header">The Proxy-Status HTTP Response Header Fi eld</title> <title abbrev="Proxy-Status Header">The Proxy-Status HTTP Response Header Fi eld</title>
<seriesInfo name="RFC" value="9209"/> <seriesInfo name="RFC" value="9209"/>
<author initials="M." surname="Nottingham" fullname="Mark Nottingham"> <author initials="M." surname="Nottingham" fullname="Mark Nottingham">
<organization>Fastly</organization> <organization>Fastly</organization>
<address> <address>
<postal> <postal>
<postalLine>Prahran</postalLine> <postalLine>Prahran</postalLine>
skipping to change at line 39 skipping to change at line 38
</author> </author>
<author initials="P." surname="Sikora" fullname="Piotr Sikora"> <author initials="P." surname="Sikora" fullname="Piotr Sikora">
<organization>Google</organization> <organization>Google</organization>
<address> <address>
<email>piotrsikora@google.com</email> <email>piotrsikora@google.com</email>
</address> </address>
</author> </author>
<date year="2022" month="February" /> <date year="2022" month="February" />
<area>Applications and Real-Time</area> <area>Applications and Real-Time</area>
<workgroup>HTTP</workgroup> <workgroup>HTTP</workgroup>
<keyword>proxy</keyword>
<!-- [rfced] Please provide any keywords (beyond those that appear in the title) <keyword>intermediary</keyword>
for use on https://www.rfc-editor.org/search. --> <keyword>reverse proxy</keyword>
<keyword>example</keyword>
<abstract> <abstract>
<!-- [rfced] Abstract: Do the following updates improve the readability of the A <t>This document defines the Proxy-Status HTTP response field to convey th
bstract? e details of an intermediary's response handling, including generated errors.</t
>
Current:
This document defines the Proxy-Status HTTP field to convey the
details of intermediary response handling, including generated
errors.
Perhaps (specifying "response field" and making "intermediary" a noun):
This document defines the Proxy-Status HTTP response field to
convey the details of an intermediary's response handling,
including generated errors.
<t>This document defines the Proxy-Status HTTP field to convey the details
of intermediary response handling, including generated errors.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="introduction" numbered="true" toc="default"> <section anchor="introduction" numbered="true" toc="default">
<name>Introduction</name> <name>Introduction</name>
<t>HTTP intermediaries (see <xref section="3.7" sectionFormat="of" target= "HTTP" format="default"/>) -- including both forward proxies and gateways (also known as "reverse proxies") -- have become an increasingly significant part of H TTP deployments. In particular, reverse proxies and content delivery networks (C DNs) form part of the critical infrastructure of many websites.</t> <t>HTTP intermediaries (see <xref section="3.7" sectionFormat="of" target= "HTTP" format="default"/>) -- including both forward proxies and gateways (also known as "reverse proxies") -- have become an increasingly significant part of H TTP deployments. In particular, reverse proxies and content delivery networks (C DNs) form part of the critical infrastructure of many websites.</t>
<t>Typically, HTTP intermediaries forward requests towards the origin serv er (inbound) and then forward their responses back to clients (outbound). Howeve r, if an error occurs before a response is obtained from an inbound server, the response is often generated by the intermediary itself.</t> <t>Typically, HTTP intermediaries forward requests towards the origin serv er (inbound) and then forward their responses back to clients (outbound). Howeve r, if an error occurs before a response is obtained from an inbound server, the response is often generated by the intermediary itself.</t>
<t>HTTP accommodates these types of errors with a few status codes -- for example, 502 (Bad Gateway) and 504 (Gateway Timeout). However, experience has sh own that more information is necessary to aid debugging and communicate what's h appened to the client. Additionally, intermediaries sometimes want to convey add itional information about their handling of a response, even if they did not gen erate it.</t> <t>HTTP accommodates these types of errors with a few status codes -- for example, 502 (Bad Gateway) and 504 (Gateway Timeout). However, experience has sh own that more information is necessary to aid debugging and communicate what's h appened to the client. Additionally, intermediaries sometimes want to convey add itional information about their handling of a response, even if they did not gen erate it.</t>
<t>To enable these uses, <xref target="header" format="default"/> defines a new HTTP response field to allow intermediaries to convey details of their han dling of a response. <xref target="params" format="default"/> enumerates the inf ormation that can be added to the field by intermediaries, which can be extended per <xref target="register-param" format="default"/>. <xref target="error-types " format="default"/> defines a set of error types for use when a proxy encounter s an issue when obtaining a response for the request; these can likewise be exte nded per <xref target="register-error" format="default"/>.</t> <t>To enable these uses, <xref target="header" format="default"/> defines a new HTTP response field to allow intermediaries to convey details of their han dling of a response. <xref target="params" format="default"/> enumerates the inf ormation that can be added to the field by intermediaries, which can be extended per <xref target="register-param" format="default"/>. <xref target="error-types " format="default"/> defines a set of error types for use when a proxy encounter s an issue when obtaining a response for the request; these can likewise be exte nded per <xref target="register-error" format="default"/>.</t>
<section anchor="notational-conventions" numbered="true" toc="default"> <section anchor="notational-conventions" numbered="true" toc="default">
skipping to change at line 86 skipping to change at line 72
<t>Note that in this specification, "proxy" is used to indicate both for ward and reverse proxies, otherwise known as gateways. "Next hop" indicates the connection in the direction leading to the origin server for the request.</t> <t>Note that in this specification, "proxy" is used to indicate both for ward and reverse proxies, otherwise known as gateways. "Next hop" indicates the connection in the direction leading to the origin server for the request.</t>
</section> </section>
</section> </section>
<section anchor="header" numbered="true" toc="default"> <section anchor="header" numbered="true" toc="default">
<name>The Proxy-Status HTTP Field</name> <name>The Proxy-Status HTTP Field</name>
<t>The Proxy-Status HTTP response field allows an intermediary to convey a dditional information about its handling of a response and its associated reques t. The syntax of this header field conforms to <xref target="STRUCTURED-FIELDS" format="default"/>.</t> <t>The Proxy-Status HTTP response field allows an intermediary to convey a dditional information about its handling of a response and its associated reques t. The syntax of this header field conforms to <xref target="STRUCTURED-FIELDS" format="default"/>.</t>
<t>It is a List (<xref section="3.1" sectionFormat="comma" target="STRUCTU RED-FIELDS" format="default"/>):</t> <t>It is a List (<xref section="3.1" sectionFormat="comma" target="STRUCTU RED-FIELDS" format="default"/>):</t>
<sourcecode type="abnf"><![CDATA[ <sourcecode type="abnf"><![CDATA[
Proxy-Status = sf-list Proxy-Status = sf-list
]]></sourcecode> ]]></sourcecode>
<t>Each member of the list represents an intermediary that has handled the response. The first member of the list represents the intermediary closest to t he origin server, and the last member of the list represents the intermediary cl osest to the user agent.</t> <t>Each member of the List represents an intermediary that has handled the response. The first member of the List represents the intermediary closest to t he origin server, and the last member of the List represents the intermediary cl osest to the user agent.</t>
<t>For example:</t> <t>For example:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
Proxy-Status: revproxy1.example.net, ExampleCDN Proxy-Status: revproxy1.example.net, ExampleCDN
]]></sourcecode> ]]></sourcecode>
<t>indicates that this response was handled first by revproxy1.example.net (a reverse proxy adjacent to the origin server) and then ExampleCDN.</t> <t>indicates that this response was handled first by revproxy1.example.net (a reverse proxy adjacent to the origin server) and then ExampleCDN.</t>
<t>Intermediaries determine when it is appropriate to add the Proxy-Status field to a response. Some might decide to append it to all responses, whereas o thers might only do so when specifically configured to or when the request conta ins a header field that activates a debugging mode.</t> <t>Intermediaries determine when it is appropriate to add the Proxy-Status field to a response. Some might decide to append it to all responses, whereas o thers might only do so when specifically configured to or when the request conta ins a header field that activates a debugging mode.</t>
<t>Each member of the list identifies the intermediary that inserted the v <t>Each member of the List identifies the intermediary that inserted the v
alue and <bcp14>MUST</bcp14> have a type of either sf-string or sf-token. Depend alue and <bcp14>MUST</bcp14> have a type of either sf-string or sf-token. Depend
ing on the deployment, this might be a service name (but not a software or hardw ing on the deployment, this might be a service name (but not a software or hardw
are product name; e.g., "ExampleCDN" is appropriate, but "ExampleProxy" is not b are product name; e.g., "ExampleCDN" is appropriate, but "ExampleProxy" is not b
ecause it doesn't identify the deployment), a hostname ("proxy-3.example.com"), ecause it doesn't identify the deployment), a hostname ("proxy-3.example.com"),
an IP address, or a generated string.</t> an IP address, or a generated string.</t>
<!-- [rfced] Section 2: In the following sentence, should "Parameters on each me <t>Parameters of each member (per <xref section="3.1.2" sectionFormat="of"
mber" be "Parameters of each member"? target="STRUCTURED-FIELDS" format="default"/>) convey additional information ab
out that intermediary's handling of the response and its associated request; see
Current: <xref target="params" format="default"/>. While all of these parameters are <bc
Parameters on each member (as per Section 3.1.2 of p14>OPTIONAL</bcp14>, intermediaries are encouraged to provide as much informati
[STRUCTURED-FIELDS]) convey additional information about that on as possible (but see <xref target="security" format="default"/> for security
intermediary's handling of the response and its associated request considerations in doing so).</t>
<t>Parameters on each member (per <xref section="3.1.2" sectionFormat="of"
target="STRUCTURED-FIELDS" format="default"/>) convey additional information ab
out that intermediary's handling of the response and its associated request; see
<xref target="params" format="default"/>. While all of these parameters are <bc
p14>OPTIONAL</bcp14>, intermediaries are encouraged to provide as much informati
on as possible (but see <xref target="security" format="default"/> for security
considerations in doing so).</t>
<t>When adding a value to the Proxy-Status field, intermediaries <bcp14>SH OULD</bcp14> preserve the existing members of the field to allow debugging of th e entire chain of intermediaries handling the request unless explicitly configur ed to remove them (e.g., to prevent internal network details from leaking; see < xref target="security" format="default"/>).</t> <t>When adding a value to the Proxy-Status field, intermediaries <bcp14>SH OULD</bcp14> preserve the existing members of the field to allow debugging of th e entire chain of intermediaries handling the request unless explicitly configur ed to remove them (e.g., to prevent internal network details from leaking; see < xref target="security" format="default"/>).</t>
<t>Origin servers <bcp14>MUST NOT</bcp14> generate the Proxy-Status field. </t> <t>Origin servers <bcp14>MUST NOT</bcp14> generate the Proxy-Status field. </t>
<t>Proxy-Status <bcp14>MAY</bcp14> be sent as an HTTP trailer field. For e xample, if an intermediary is streaming a response and the inbound connection su ddenly terminates, Proxy-Status can only be appended to the trailer section of t he outbound message since the header section has already been sent. However, bec ause it might be silently discarded along the path to the user agent (as is the case for all trailer fields; see <xref section="6.5" sectionFormat="of" target=" HTTP" format="default"/>), Proxy-Status <bcp14>SHOULD NOT</bcp14> be sent as a t railer field unless it is not possible to send it in the header section.</t> <t>Proxy-Status <bcp14>MAY</bcp14> be sent as an HTTP trailer field. For e xample, if an intermediary is streaming a response and the inbound connection su ddenly terminates, Proxy-Status can only be appended to the trailer section of t he outbound message since the header section has already been sent. However, bec ause it might be silently discarded along the path to the user agent (as is the case for all trailer fields; see <xref section="6.5" sectionFormat="of" target=" HTTP" format="default"/>), Proxy-Status <bcp14>SHOULD NOT</bcp14> be sent as a t railer field unless it is not possible to send it in the header section.</t>
<t>To allow recipients to reconstruct the relative ordering of Proxy-Statu s members conveyed in trailer fields with those conveyed in header fields, an in termediary <bcp14>MUST NOT</bcp14> send Proxy-Status as a trailer field unless i t has also generated a Proxy-Status header field with the same member (although potentially different parameters) in that message.</t> <t>To allow recipients to reconstruct the relative ordering of Proxy-Statu s members conveyed in trailer fields with those conveyed in header fields, an in termediary <bcp14>MUST NOT</bcp14> send Proxy-Status as a trailer field unless i t has also generated a Proxy-Status header field with the same member (although potentially different parameters) in that message.</t>
<t>For example, a proxy identified as 'ThisProxy' that receives a response bearing a header field:</t> <t>For example, a proxy identified as 'ThisProxy' that receives a response bearing a header field:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
Proxy-Status: SomeOtherProxy Proxy-Status: SomeOtherProxy
]]></sourcecode> ]]></sourcecode>
<t>would add its own entry to the header field:</t> <t>would add its own entry to the header field:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
Proxy-Status: SomeOtherProxy, ThisProxy Proxy-Status: SomeOtherProxy, ThisProxy
]]></sourcecode> ]]></sourcecode>
<t>thus allowing it to append a trailer field:</t> <t>thus allowing it to append a trailer field:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
Proxy-Status: ThisProxy; error=read_timeout Proxy-Status: ThisProxy; error=read_timeout
]]></sourcecode> ]]></sourcecode>
<t>which would thereby allow a downstream recipient to understand that pro cessing by 'SomeOtherProxy' occurred before 'ThisProxy'.</t> <t>which would thereby allow a downstream recipient to understand that pro cessing by 'SomeOtherProxy' occurred before 'ThisProxy'.</t>
<!-- [rfced] Section 2: Is "promote" the correct word here? We note that RFC 911
0 uses the term "merge" when discussing moving content from the trailer field to
a header field.
Original:
A client MAY promote the Proxy-Status trailer field into a header
field by following these steps:
<t>A client <bcp14>MAY</bcp14> promote the Proxy-Status trailer field into a header field by following these steps:</t> <t>A client <bcp14>MAY</bcp14> promote the Proxy-Status trailer field into a header field by following these steps:</t>
<!-- [rfced] Section 2: In the following nested list, may we update the numberin
g to use letters?
Current:
1. For each member trailer_member of the Proxy-Status trailer field
value:
1. Let header_member be the first (leftmost) value of the Proxy-
Status header field value, comparing the sf-token or sf-
string character by character without consideration of
parameters.
2. If no matching header_member is found, continue processing
the next trailer_member.
3. Replace header_member with trailer_member in its entirety,
including any parameters.
2. Remove the Proxy-Status trailer field if empty.
Perhaps:
1. For each member trailer_member of the Proxy-Status trailer field
value:
a. Let header_member be the first (leftmost) value of the Proxy-
Status header field value, comparing the sf-token or sf-
string character by character without consideration of
parameters.
b. If no matching header_member is found, continue processing
the next trailer_member.
c. Replace header_member with trailer_member in its entirety,
including any parameters.
2. Remove the Proxy-Status trailer field if empty.
<ol spacing="normal" type="1"><li> <ol spacing="normal" type="1"><li>
<t>For each member trailer_member of the Proxy-Status trailer field va lue: <t>For each member trailer_member of the Proxy-Status trailer field va lue:
</t> </t>
<ol spacing="normal" type="1"><li>Let header_member be the first (left most) value of the Proxy-Status header field value, comparing the sf-token or sf -string character by character without consideration of parameters.</li> <ol spacing="normal" type="1"><li>Let header_member be the first (left most) value of the Proxy-Status header field value, comparing the sf-token or sf -string character by character without consideration of parameters.</li>
<li>If no matching header_member is found, continue processing the n ext trailer_member.</li> <li>If no matching header_member is found, continue processing the n ext trailer_member.</li>
<li>Replace header_member with trailer_member in its entirety, inclu ding any parameters.</li> <li>Replace header_member with trailer_member in its entirety, inclu ding any parameters.</li>
</ol> </ol>
</li> </li>
<li>Remove the Proxy-Status trailer field if empty.</li> <li>Remove the Proxy-Status trailer field if empty.</li>
</ol> </ol>
<section anchor="params" numbered="true" toc="default"> <section anchor="params" numbered="true" toc="default">
<name>Proxy-Status Parameters</name> <name>Proxy-Status Parameters</name>
<t>This section lists parameters that can be used on the members of the Proxy-Status field. Unrecognised parameters <bcp14>MUST</bcp14> be ignored.</t> <t>This section lists parameters that can be used on the members of the Proxy-Status field. Unrecognised parameters <bcp14>MUST</bcp14> be ignored.</t>
<section anchor="error" numbered="true" toc="default"> <section anchor="error" numbered="true" toc="default">
<name>error</name> <name>error</name>
<t>The <tt>error</tt> parameter's value is an sf-token that is a Proxy <t>The <tt>error</tt> parameter's value is an sf-token that is a proxy
Error Type. When present, it indicates that the intermediary encountered an iss error type. When present, it indicates that the intermediary encountered an iss
ue when obtaining this response.</t> ue when obtaining this response.</t>
<t>The presence of some Proxy Error Types indicates that the response <t>The presence of some proxy error types indicates that the response
was generated by the intermediary itself, rather than being forwarded from the o was generated by the intermediary itself, rather than being forwarded from the o
rigin server. This is the case when, for example, the origin server can't be con rigin server. This is the case when, for example, the origin server can't be con
tacted, so the proxy has to create its own response.</t> tacted, so the proxy has to create its own response.</t>
<t>Other Proxy Error Types can be added to (potentially partial) respo <t>Other proxy error types can be added to (potentially partial) respo
nses that were generated by the nses that were generated by the
origin server or some other inbound server. For example, if the forward connecti on abruptly closes, an intermediary might add Proxy-Status with an appropriate e rror as a trailer field.</t> origin server or some other inbound server. For example, if the forward connecti on abruptly closes, an intermediary might add Proxy-Status with an appropriate e rror as a trailer field.</t>
<t>Proxy Error Types that are registered with a 'Response only generat <t>Proxy error types that are registered with a 'Response only generat
ed by intermediaries' value of 'true' indicate that they can only occur in respo ed by intermediaries' value of 'true' indicate that they can only occur in respo
nses generated by the intermediary. If the value is 'false', the response might nses generated by the intermediary. If the value is 'false', the response might
be generated by the intermediary or an inbound server.</t> be generated by the intermediary or an inbound server.</t>
<t><xref target="error-types" format="default"/> lists the Proxy Error <t><xref target="error-types" format="default"/> lists the proxy error
Types defined in this document; new ones can be defined using the procedure out types defined in this document; new ones can be defined using the procedure out
lined in <xref target="register-error" format="default"/>.</t> lined in <xref target="register-error" format="default"/>.</t>
<t>For example:</t> <t>For example:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
HTTP/1.1 504 Gateway Timeout HTTP/1.1 504 Gateway Timeout
Proxy-Status: ExampleCDN; error=connection_timeout Proxy-Status: ExampleCDN; error=connection_timeout
]]></sourcecode> ]]></sourcecode>
<t>indicates that this 504 response was generated by ExampleCDN due to a connection timeout when going forward.</t> <t>indicates that this 504 response was generated by ExampleCDN due to a connection timeout when going forward.</t>
<t>Or:</t> <t>Or:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
HTTP/1.1 429 Too Many Requests HTTP/1.1 429 Too Many Requests
Proxy-Status: r34.example.net; error=http_request_error, ExampleCDN Proxy-Status: r34.example.net; error=http_request_error, ExampleCDN
]]></sourcecode> ]]></sourcecode>
<t>indicates that this 429 (Too Many Requests) response was generated by r34.example.net, not the CDN or the origin.</t> <t>indicates that this 429 (Too Many Requests) response was generated by r34.example.net, not the CDN or the origin.</t>
<t>When sending the error parameter, the most specific Proxy Error Typ <t>When sending the error parameter, the most specific proxy error typ
e <bcp14>SHOULD</bcp14> be sent, provided that it accurately represents the erro e <bcp14>SHOULD</bcp14> be sent, provided that it accurately represents the erro
r condition. If an appropriate Proxy Error Type is not defined, there are a numb r condition. If an appropriate proxy error type is not defined, there are a numb
er of generic error types (e.g., proxy_internal_error, http_protocol_error) that er of generic error types (e.g., proxy_internal_error, http_protocol_error) that
can be used. If they are not suitable, consider registering a new Proxy Error T can be used. If they are not suitable, consider registering a new proxy error t
ype (see <xref target="register-error" format="default"/>).</t> ype (see <xref target="register-error" format="default"/>).</t>
<t>Each Proxy Error Type has a recommended HTTP status code. When gene <t>Each proxy error type has a recommended HTTP status code. When gene
rating an HTTP response containing the <tt>error</tt>, its HTTP status code <bcp rating an HTTP response containing the <tt>error</tt>, its HTTP status code <bcp
14>SHOULD</bcp14> be set to the recommended HTTP status code. However, there may 14>SHOULD</bcp14> be set to the recommended HTTP status code. However, there may
be circumstances (e.g., for backwards compatibility with previous behaviours, a be circumstances (e.g., for backwards compatibility with previous behaviours, a
status code has already been sent) when another status code might be used.</t> status code has already been sent) when another status code might be used.</t>
<t>Proxy Error Types can also define any number of extra parameters fo <t>Proxy error types can also define any number of extra parameters fo
r use with that type. Their use, like all parameters, is optional. As a result, r use with that type. Their use, like all parameters, is optional. As a result,
if an extra parameter is used with a Proxy Error Type for which it is not define if an extra parameter is used with a proxy error type for which it is not define
d, it will be ignored.</t> d, it will be ignored.</t>
</section> </section>
<section anchor="next-hop" numbered="true" toc="default"> <section anchor="next-hop" numbered="true" toc="default">
<name>next-hop</name> <name>next-hop</name>
<t>The <tt>next-hop</tt> parameter's value is an sf-string or sf-token that identifies the intermediary or origin server selected (and used, if contac ted) to obtain this response. It might be a hostname, IP address, or alias.</t> <t>The <tt>next-hop</tt> parameter's value is an sf-string or sf-token that identifies the intermediary or origin server selected (and used, if contac ted) to obtain this response. It might be a hostname, IP address, or alias.</t>
<t>For example:</t> <t>For example:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
Proxy-Status: cdn.example.org; next-hop=backend.example.org:8001 Proxy-Status: cdn.example.org; next-hop=backend.example.org:8001
]]></sourcecode> ]]></sourcecode>
<t>indicates that cdn.example.org used backend.example.org:8001 as the next hop for this request.</t> <t>indicates that cdn.example.org used backend.example.org:8001 as the next hop for this request.</t>
</section> </section>
skipping to change at line 239 skipping to change at line 176
<t>The <tt>details</tt> parameter's value is an sf-string containing a dditional information not captured anywhere else. This can include implementatio n-specific or deployment-specific information.</t> <t>The <tt>details</tt> parameter's value is an sf-string containing a dditional information not captured anywhere else. This can include implementatio n-specific or deployment-specific information.</t>
<t>For example:</t> <t>For example:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
Proxy-Status: proxy.example.net; error="http_protocol_error"; Proxy-Status: proxy.example.net; error="http_protocol_error";
details="Malformed response header: space before colon" details="Malformed response header: space before colon"
]]></sourcecode> ]]></sourcecode>
</section> </section>
</section> </section>
<section anchor="register-param" numbered="true" toc="default"> <section anchor="register-param" numbered="true" toc="default">
<name>Defining New Proxy-Status Parameters</name> <name>Defining New Proxy-Status Parameters</name>
<t>New Proxy-Status Parameters can be defined by registering them in the "HTTP Proxy-Status Parameters" registry.</t> <t>New Proxy-Status parameters can be defined by registering them in the "HTTP Proxy-Status Parameters" registry.</t>
<t>Registration requests are reviewed and approved by Expert Review, per <xref section="4.5" sectionFormat="comma" target="RFC8126" format="default"/>. A specification document is appreciated but not required.</t> <t>Registration requests are reviewed and approved by Expert Review, per <xref section="4.5" sectionFormat="comma" target="RFC8126" format="default"/>. A specification document is appreciated but not required.</t>
<t>The expert(s) should consider the following factors when evaluating r equests:</t> <t>The expert(s) should consider the following factors when evaluating r equests:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Community feedback</li> <li>Community feedback</li>
<li>If the value is sufficiently well defined</li> <li>If the value is sufficiently well defined</li>
<li>Generic parameters are preferred over vendor-specific, application -specific, or deployment-specific values. If a generic value cannot be agreed up on in the community, the parameter's name should be correspondingly specific (e. g., with a prefix that identifies the vendor, application, or deployment).</li> <li>Generic parameters are preferred over vendor-specific, application -specific, or deployment-specific values. If a generic value cannot be agreed up on in the community, the parameter's name should be correspondingly specific (e. g., with a prefix that identifies the vendor, application, or deployment).</li>
<li>Parameter names should not conflict with registered extra paramete rs in the "HTTP Proxy Error Types" registry.</li> <li>Parameter names should not conflict with registered extra paramete rs in the "HTTP Proxy Error Types" registry.</li>
</ul> </ul>
<t>Registration requests should use the following template:</t> <t>Registration requests should use the following template:</t>
<dl> <dl>
<dt>Name:</dt><dd> [a name for the Proxy-Status Parameter that matches <dt>Name:</dt>
key]</dd> <dd>[a name for the Proxy-Status parameter that matches key]</dd>
<dt>Description:</dt><dd> [a description of the parameter semantics an <dt>Description:</dt>
d value]</dd> <dd>[a description of the parameter semantics and value]</dd>
<dt>Reference:</dt><dd> [to a specification defining this parameter; o <dt>Reference:</dt>
ptional]</dd> <dd>[to a specification defining this parameter; optional]</dd>
</dl> </dl>
<t>See the registry at <eref target="https://iana.org/assignments/http-p roxy-status" brackets="angle"/> for details on where to send registration reques ts.</t> <t>See the registry at <eref target="https://iana.org/assignments/http-p roxy-status" brackets="angle"/> for details on where to send registration reques ts.</t>
</section> </section>
<section anchor="error-types" numbered="true" toc="default"> <section anchor="error-types" numbered="true" toc="default">
<name>Proxy Error Types</name> <name>Proxy Error Types</name>
<t>This section lists the Proxy Error Types defined by this document. Se <t>This section lists the proxy error types defined by this document. Se
e <xref target="register-error" format="default"/> for information about definin e <xref target="register-error" format="default"/> for information about definin
g new Proxy Error Types.</t> g new proxy error types.</t>
<t>Note that implementations might not produce all Proxy Error Types. Th <t>Note that implementations might not produce all proxy error types. Th
e set of types below is designed to map to existing states in implementations an e set of types below is designed to map to existing states in implementations an
d therefore may not be applicable to some.</t> d therefore may not be applicable to some.</t>
<section anchor="dns-timeout" numbered="true" toc="default"> <section anchor="dns-timeout" numbered="true" toc="default">
<name>DNS Timeout</name> <name>DNS Timeout</name>
<dl> <dl>
<dt>Name:</dt><dd> dns_timeout</dd> <dt>Name:</dt>
<dt>Description:</dt><dd> The intermediary encountered a timeout whe <dd>dns_timeout</dd>
n trying to find an IP address for the next-hop hostname.</dd> <dt>Description:</dt>
<dt>Extra Parameters:</dt><dd> None.</dd> <dd>The intermediary encountered a timeout when trying to find an IP
<dt>Recommended HTTP status code:</dt><dd> 504</dd> address for the next-hop hostname.</dd>
<dt>Response only generated by intermediaries:</dt><dd> true</dd> <dt>Extra Parameters:</dt>
<dt>Reference:</dt><dd> RFC 9209</dd> <dd>None</dd>
<dt>Recommended HTTP Status Code:</dt>
<dd>504</dd>
<dt>Response Only Generated by Intermediaries:</dt>
<dd>true</dd>
<dt>Reference:</dt>
<dd>RFC 9209</dd>
</dl> </dl>
</section> </section>
<section anchor="dns-error" numbered="true" toc="default"> <section anchor="dns-error" numbered="true" toc="default">
<name>DNS Error</name> <name>DNS Error</name>
<dl> <dl>
<dt>Name:</dt><dd> dns_error</dd> <dt>Name:</dt>
<dt>Description:</dt><dd> The intermediary encountered a DNS error w <dd>dns_error</dd>
hen trying to find an IP address for the next-hop hostname.</dd> <dt>Description:</dt>
<dd>The intermediary encountered a DNS error when trying to find an
IP address for the next-hop hostname.</dd>
<dt>Extra Parameters:</dt> <dt>Extra Parameters:</dt>
<dd><t><br/></t> <dd><t><br/></t>
<dl> <dl>
<dt>rcode:</dt><dd> An sf-string conveying the DNS RCODE that in <dt>rcode:</dt>
dicates the error type. See <xref section="3" sectionFormat="comma" target="RFC8 <dd> An sf-string conveying the DNS RCODE that indicates the err
499" format="default"/>.</dd> or type. See <xref section="3" sectionFormat="comma" target="RFC8499" format="de
<dt>info-code:</dt><dd> An sf-integer conveying the Extended DNS fault"/>.</dd>
Error Code INFO-CODE. See <xref target="RFC8914" format="default"/>.</dd> <dt>info-code:</dt>
<dd>An sf-integer conveying the Extended DNS Error Code INFO-COD
E. See <xref target="RFC8914" format="default"/>.</dd>
</dl> </dl>
</dd> </dd>
<dt>Recommended HTTP status code:</dt><dd> 502</dd> <dt>Recommended HTTP Status Code:</dt>
<dt>Response only generated by intermediaries:</dt><dd> true</dd> <dd>502</dd>
<dt>Reference:</dt><dd> RFC 9209</dd> <dt>Response Only Generated by Intermediaries:</dt>
<dd>true</dd>
<dt>Reference:</dt>
<dd>RFC 9209</dd>
</dl> </dl>
</section> </section>
<section anchor="destination-not-found" numbered="true" toc="default"> <section anchor="destination-not-found" numbered="true" toc="default">
<name>Destination Not Found</name> <name>Destination Not Found</name>
<dl> <dl>
<dt>Name:</dt><dd> destination_not_found</dd> <dt>Name:</dt>
<dt>Description:</dt><dd> The intermediary cannot determine the appr <dd>destination_not_found</dd>
opriate next hop to use for this request; for example, it may not be configured. <dt>Description:</dt>
Note that this error is specific to gateways, which typically require specific <dd>The intermediary cannot determine the appropriate next hop to us
configuration to identify the "backend" server; forward proxies use in-band info e for this request; for example, it may not be configured. Note that this error
rmation to identify the origin server.</dd> is specific to gateways, which typically require specific configuration to ident
<dt>Extra Parameters:</dt><dd> None.</dd> ify the "backend" server; forward proxies use in-band information to identify th
<dt>Recommended HTTP status code:</dt><dd> 500</dd> e origin server.</dd>
<dt>Response only generated by intermediaries:</dt><dd> true</dd> <dt>Extra Parameters:</dt>
<dt>Reference:</dt><dd> RFC 9209</dd> <dd>None</dd>
<dt>Recommended HTTP Status Code:</dt>
<dd>500</dd>
<dt>Response Only Generated by Intermediaries:</dt>
<dd>true</dd>
<dt>Reference:</dt>
<dd>RFC 9209</dd>
</dl> </dl>
</section> </section>
<section anchor="destination-unavailable" numbered="true" toc="default"> <section anchor="destination-unavailable" numbered="true" toc="default">
<name>Destination Unavailable</name> <name>Destination Unavailable</name>
<dl> <dl>
<dt>Name:</dt><dd> destination_unavailable</dd> <dt>Name:</dt>
<dt>Description:</dt><dd> The intermediary considers the next hop to <dd>destination_unavailable</dd>
be unavailable; e.g., recent attempts to communicate with it may have failed, o <dt>Description:</dt>
r a health check may indicate that it is down.</dd> <dd>The intermediary considers the next hop to be unavailable; e.g.,
<dt>Extra Parameters:</dt><dd> None.</dd> recent attempts to communicate with it may have failed, or a health check may i
<dt>Recommended HTTP status code:</dt><dd> 503</dd> ndicate that it is down.</dd>
<dt>Response only generated by intermediaries:</dt><dd> true</dd> <dt>Extra Parameters:</dt>
<dt>Reference:</dt><dd> RFC 9209</dd> <dd>None</dd>
<dt>Recommended HTTP Status Code:</dt>
<dd>503</dd>
<dt>Response Only Generated by Intermediaries:</dt>
<dd>true</dd>
<dt>Reference:</dt>
<dd>RFC 9209</dd>
</dl> </dl>
</section> </section>
<section anchor="destination-ip-prohibited" numbered="true" toc="default "> <section anchor="destination-ip-prohibited" numbered="true" toc="default ">
<name>Destination IP Prohibited</name> <name>Destination IP Prohibited</name>
<dl> <dl>
<dt>Name:</dt><dd> destination_ip_prohibited</dd> <dt>Name:</dt>
<dt>Description:</dt><dd> The intermediary is configured to prohibit <dd>destination_ip_prohibited</dd>
connections to the next-hop IP address.</dd> <dt>Description:</dt>
<dt>Extra Parameters:</dt><dd> None.</dd> <dd>The intermediary is configured to prohibit connections to the ne
<dt>Recommended HTTP status code:</dt><dd> 502</dd> xt-hop IP address.</dd>
<dt>Response only generated by intermediaries:</dt><dd>true</dd> <dt>Extra Parameters:</dt>
<dt>Reference:</dt><dd> RFC 9209</dd> <dd>None</dd>
<dt>Recommended HTTP Status Code:</dt>
<dd>502</dd>
<dt>Response Only Generated by Intermediaries:</dt>
<dd>true</dd>
<dt>Reference:</dt>
<dd>RFC 9209</dd>
</dl> </dl>
</section> </section>
<section anchor="destination-ip-unroutable" numbered="true" toc="default "> <section anchor="destination-ip-unroutable" numbered="true" toc="default ">
<name>Destination IP Unroutable</name> <name>Destination IP Unroutable</name>
<dl> <dl>
<dt>Name:</dt><dd> destination_ip_unroutable</dd> <dt>Name:</dt>
<dt>Description:</dt><dd> The intermediary cannot find a route to th <dd>destination_ip_unroutable</dd>
e next-hop IP address.</dd> <dt>Description:</dt>
<dt>Extra Parameters:</dt><dd> None.</dd> <dd>The intermediary cannot find a route to the next-hop IP address.
<dt>Recommended HTTP status code:</dt><dd> 502</dd> </dd>
<dt>Response only generated by intermediaries:</dt><dd>true</dd> <dt>Extra Parameters:</dt>
<dt>Reference:</dt><dd> RFC 9209</dd> <dd>None</dd>
<dt>Recommended HTTP Status Code:</dt>
<dd>502</dd>
<dt>Response Only Generated by Intermediaries:</dt>
<dd>true</dd>
<dt>Reference:</dt>
<dd>RFC 9209</dd>
</dl> </dl>
</section> </section>
<section anchor="connection-refused" numbered="true" toc="default"> <section anchor="connection-refused" numbered="true" toc="default">
<name>Connection Refused</name> <name>Connection Refused</name>
<dl> <dl>
<dt>Name:</dt><dd> connection_refused</dd> <dt>Name:</dt>
<dt>Description:</dt><dd> The intermediary's connection to the next <dd>connection_refused</dd>
hop was refused.</dd> <dt>Description:</dt>
<dt>Extra Parameters:</dt><dd> None.</dd> <dd>The intermediary's connection to the next hop was refused.</dd>
<dt>Recommended HTTP status code:</dt><dd> 502</dd> <dt>Extra Parameters:</dt>
<dt>Response only generated by intermediaries:</dt><dd> true</dd> <dd>None</dd>
<dt>Reference:</dt><dd> RFC 9209</dd> <dt>Recommended HTTP Status Code:</dt>
<dd>502</dd>
<dt>Response Only Generated by Intermediaries:</dt>
<dd>true</dd>
<dt>Reference:</dt>
<dd>RFC 9209</dd>
</dl> </dl>
</section> </section>
<section anchor="connection-terminated" numbered="true" toc="default"> <section anchor="connection-terminated" numbered="true" toc="default">
<name>Connection Terminated</name> <name>Connection Terminated</name>
<dl> <dl>
<dt>Name:</dt><dd> connection_terminated</dd> <dt>Name:</dt>
<dt>Description:</dt><dd> The intermediary's connection to the next <dd>connection_terminated</dd>
hop was closed before a complete response was received.</dd> <dt>Description:</dt>
<dt>Extra Parameters:</dt><dd> None.</dd> <dd>The intermediary's connection to the next hop was closed before
<dt>Recommended HTTP status code:</dt><dd> 502</dd> a complete response was received.</dd>
<dt>Response only generated by intermediaries:</dt><dd> false</dd> <dt>Extra Parameters:</dt>
<dt>Reference:</dt><dd> RFC 9209</dd> <dd>None</dd>
<dt>Recommended HTTP Status Code:</dt>
<dd>502</dd>
<dt>Response Only Generated by Intermediaries:</dt>
<dd>false</dd>
<dt>Reference:</dt>
<dd>RFC 9209</dd>
</dl> </dl>
</section> </section>
<section anchor="connection-timeout" numbered="true" toc="default"> <section anchor="connection-timeout" numbered="true" toc="default">
<name>Connection Timeout</name> <name>Connection Timeout</name>
<dl> <dl>
<dt>Name:</dt><dd> connection_timeout</dd> <dt>Name:</dt>
<dt>Description:</dt><dd> The intermediary's attempt to open a conne <dd>connection_timeout</dd>
ction to the next hop timed out.</dd> <dt>Description:</dt>
<dt>Extra Parameters:</dt><dd> None.</dd> <dd>The intermediary's attempt to open a connection to the next hop
<dt>Recommended HTTP status code:</dt><dd> 504</dd> timed out.</dd>
<dt>Response only generated by intermediaries:</dt><dd> true</dd> <dt>Extra Parameters:</dt>
<dt>Reference:</dt><dd> RFC 9209</dd> <dd>None</dd>
<dt>Recommended HTTP Status Code:</dt>
<dd>504</dd>
<dt>Response Only Generated by Intermediaries:</dt>
<dd>true</dd>
<dt>Reference:</dt>
<dd>RFC 9209</dd>
</dl> </dl>
</section> </section>
<section anchor="connection-read-timeout" numbered="true" toc="default"> <section anchor="connection-read-timeout" numbered="true" toc="default">
<name>Connection Read Timeout</name> <name>Connection Read Timeout</name>
<dl> <dl>
<dt>Name:</dt><dd> connection_read_timeout</dd> <dt>Name:</dt>
<dt>Description:</dt><dd> The intermediary was expecting data on a c <dd>connection_read_timeout</dd>
onnection (e.g., part of a response) but did not receive any new data in a confi <dt>Description:</dt>
gured time limit.</dd> <dd>The intermediary was expecting data on a connection (e.g., part
<dt>Extra Parameters:</dt><dd> None.</dd> of a response) but did not receive any new data in a configured time limit.</dd>
<dt>Recommended HTTP status code:</dt><dd> 504</dd> <dt>Extra Parameters:</dt>
<dt>Response only generated by intermediaries:</dt><dd> false</dd> <dd>None</dd>
<dt>Reference:</dt><dd> RFC 9209</dd> <dt>Recommended HTTP Status Code:</dt>
<dd>504</dd>
<dt>Response Only Generated by Intermediaries:</dt>
<dd>false</dd>
<dt>Reference:</dt>
<dd>RFC 9209</dd>
</dl> </dl>
</section> </section>
<section anchor="connection-write-timeout" numbered="true" toc="default" > <section anchor="connection-write-timeout" numbered="true" toc="default" >
<name>Connection Write Timeout</name> <name>Connection Write Timeout</name>
<dl> <dl>
<dt>Name:</dt><dd> connection_write_timeout</dd> <dt>Name:</dt>
<dt>Description:</dt><dd> The intermediary was attempting to write d <dd>connection_write_timeout</dd>
ata to a connection but was not able to (e.g., because its buffers were full).</ <dt>Description:</dt>
dd> <dd>The intermediary was attempting to write data to a connection bu
<dt>Extra Parameters:</dt><dd> None.</dd> t was not able to (e.g., because its buffers were full).</dd>
<dt>Recommended HTTP status code:</dt><dd> 504</dd> <dt>Extra Parameters:</dt>
<dt>Response only generated by intermediaries:</dt><dd> false</dd> <dd>None</dd>
<dt>Reference:</dt><dd> RFC 9209</dd> <dt>Recommended HTTP Status Code:</dt>
<dd>504</dd>
<dt>Response Only Generated by Intermediaries:</dt>
<dd>false</dd>
<dt>Reference:</dt>
<dd>RFC 9209</dd>
</dl> </dl>
</section> </section>
<section anchor="connection-limit-reached" numbered="true" toc="default" > <section anchor="connection-limit-reached" numbered="true" toc="default" >
<name>Connection Limit Reached</name> <name>Connection Limit Reached</name>
<dl> <dl>
<dt>Name:</dt><dd> connection_limit_reached</dd> <dt>Name:</dt>
<!-- [rfced] Section 2.3.12: Should "passed" be "exceeded" in the following? <dd>connection_limit_reached</dd>
<dt>Description:</dt>
Current: <dd>The intermediary is configured to limit the number of connection
Description: The intermediary is configured to limit the number of s it has to the next hop, and that limit has been exceeded.</dd>
connections it has to the next hop, and that limit has been <dt>Extra Parameters:</dt>
passed. <dd>None</dd>
<dt>Recommended HTTP Status Code:</dt>
Perhaps: <dd>503</dd>
Description: The intermediary is configured to limit the number of <dt>Response Only Generated by Intermediaries:</dt>
connections it has to the next hop, and that limit has been <dd>true</dd>
exceeded. <dt>Reference:</dt>
<dt>Description:</dt><dd> The intermediary is configured to limit th <dd>RFC 9209</dd>
e number of connections it has to the next hop, and that limit has been passed.<
/dd>
<dt>Extra Parameters:</dt><dd> None.</dd>
<dt>Recommended HTTP status code:</dt><dd> 503</dd>
<dt>Response only generated by intermediaries:</dt><dd> true</dd>
<dt>Reference:</dt><dd> RFC 9209</dd>
</dl> </dl>
</section> </section>
<section anchor="tls-protocol-error" numbered="true" toc="default"> <section anchor="tls-protocol-error" numbered="true" toc="default">
<name>TLS Protocol Error</name> <name>TLS Protocol Error</name>
<dl> <dl>
<dt>Name:</dt><dd> tls_protocol_error</dd> <dt>Name:</dt>
<dt>Description:</dt><dd> The intermediary encountered a TLS error w <dd>tls_protocol_error</dd>
hen communicating with the next hop, either during the handshake or afterwards.< <dt>Description:</dt>
/dd> <dd>The intermediary encountered a TLS error when communicating with
<dt>Extra Parameters:</dt><dd> None.</dd> the next hop, either during the handshake or afterwards.</dd>
<dt>Recommended HTTP status code:</dt><dd> 502</dd> <dt>Extra Parameters:</dt>
<dt>Response only generated by intermediaries:</dt><dd> false</dd> <dd>None</dd>
<dt>Reference:</dt><dd> RFC 9209</dd> <dt>Recommended HTTP Status Code:</dt>
<dt>Notes:</dt><dd> Not appropriate when a TLS alert is received; se <dd>502</dd>
e tls_alert_received.</dd> <dt>Response Only Generated by Intermediaries:</dt>
<dd>false</dd>
<dt>Reference:</dt>
<dd>RFC 9209</dd>
<dt>Notes:</dt>
<dd>Not appropriate when a TLS alert is received; see tls_alert_rece
ived.</dd>
</dl> </dl>
</section> </section>
<section anchor="tls-certificate-error" numbered="true" toc="default"> <section anchor="tls-certificate-error" numbered="true" toc="default">
<name>TLS Certificate Error</name> <name>TLS Certificate Error</name>
<dl> <dl>
<dt>Name:</dt><dd> tls_certificate_error</dd> <dt>Name:</dt>
<dt>Description:</dt><dd> The intermediary encountered an error when <dd>tls_certificate_error</dd>
verifying the certificate presented by the next hop.</dd> <dt>Description:</dt>
<dt>Extra Parameters:</dt><dd> None.</dd> <dd>The intermediary encountered an error when verifying the certifi
<dt>Recommended HTTP status code:</dt><dd> 502</dd> cate presented by the next hop.</dd>
<dt>Response only generated by intermediaries:</dt><dd>true</dd> <dt>Extra Parameters:</dt>
<dt>Reference:</dt><dd> RFC 9209</dd> <dd>None</dd>
<dt>Recommended HTTP Status Code:</dt>
<dd>502</dd>
<dt>Response Only Generated by Intermediaries:</dt>
<dd>true</dd>
<dt>Reference:</dt>
<dd>RFC 9209</dd>
</dl> </dl>
</section> </section>
<section anchor="tls-alert-received" numbered="true" toc="default"> <section anchor="tls-alert-received" numbered="true" toc="default">
<name>TLS Alert Received</name> <name>TLS Alert Received</name>
<dl> <dl>
<dt>Name:</dt><dd> tls_alert_received</dd> <dt>Name:</dt>
<dt>Description:</dt><dd> The intermediary received a TLS alert from <dd>tls_alert_received</dd>
the next hop.</dd> <dt>Description:</dt>
<dd>The intermediary received a TLS alert from the next hop.</dd>
<dt>Extra Parameters: <dt>Extra Parameters:</dt>
</dt><dd><t><br/></t> <dd><t><br/></t>
<dl> <dl>
<dt>alert-id:</dt><dd> An sf-integer containing the applicable v <dt>alert-id:</dt>
alue from the "TLS Alerts" registry. See <xref target="RFC8446" format="default" <dd>An sf-integer containing the applicable value from the "TLS
/>.</dd> Alerts" registry. See <xref target="RFC8446" format="default"/>.</dd>
<dt>alert-message:</dt><dd> An sf-token or sf-string containing <dt>alert-message:</dt>
the applicable description string from the "TLS Alerts" registry. See <xref targ <dd>An sf-token or sf-string containing the applicable descripti
et="RFC8446" format="default"/>.</dd> on string from the "TLS Alerts" registry. See <xref target="RFC8446" format="def
ault"/>.</dd>
</dl> </dl>
</dd> </dd>
<dt>Recommended HTTP status code:</dt><dd> 502</dd> <dt>Recommended HTTP Status Code:</dt>
<dt>Response only generated by intermediaries:</dt><dd> false</dd> <dd>502</dd>
<dt>Reference:</dt><dd> RFC 9209</dd> <dt>Response Only Generated by Intermediaries:</dt>
<dd>false</dd>
<dt>Reference:</dt>
<dd>RFC 9209</dd>
</dl> </dl>
</section> </section>
<section anchor="http-request-error" numbered="true" toc="default"> <section anchor="http-request-error" numbered="true" toc="default">
<name>HTTP Request Error</name> <name>HTTP Request Error</name>
<dl> <dl>
<dt>Name:</dt><dd> http_request_error</dd> <dt>Name:</dt>
<dt>Description:</dt><dd> The intermediary is generating a client (4 <dd>http_request_error</dd>
xx) response on the origin's behalf. Applicable status codes include (but are no <dt>Description:</dt>
t limited to) 400, 403, 405, 406, 408, 411, 413, 414, 415, 416, 417, and 429.</d <dd>The intermediary is generating a client (4xx) response on the or
d> igin's behalf. Applicable status codes include (but are not limited to) 400, 403
<dt>Extra Parameters: , 405, 406, 408, 411, 413, 414, 415, 416, 417, and 429.</dd>
</dt><dd><t><br/></t> <dt>Extra Parameters:</dt>
<dl> <dd><t><br/></t>
<dt>status-code:</dt><dd> An sf-integer containing the generated <dl>
status code.</dd> <dt>status-code:</dt>
<dt>status-phrase:</dt><dd> An sf-string containing the generate <dd>An sf-integer containing the generated status code.</dd>
d status phrase.</dd> <dt>status-phrase:</dt>
</dl> <dd>An sf-string containing the generated status phrase.</dd>
</dl>
</dd> </dd>
<dt>Recommended HTTP status code:</dt><dd> The applicable 4xx status <dt>Recommended HTTP Status Code:</dt>
code</dd> <dd>The applicable 4xx status code</dd>
<dt>Response only generated by intermediaries:</dt><dd> true</dd> <dt>Response Only Generated by Intermediaries:</dt>
<dt>Reference:</dt><dd> RFC 9209</dd> <dd>true</dd>
<dt>Notes:</dt><dd> This type helps distinguish between responses ge <dt>Reference:</dt>
nerated by intermediaries from those generated by the origin.</dd> <dd>RFC 9209</dd>
<dt>Notes:</dt>
<dd>This type helps distinguish between responses generated by inter
mediaries from those generated by the origin.</dd>
</dl> </dl>
</section> </section>
<section anchor="http-request-denied" numbered="true" toc="default"> <section anchor="http-request-denied" numbered="true" toc="default">
<name>HTTP Request Denied</name> <name>HTTP Request Denied</name>
<dl> <dl>
<dt>Name:</dt><dd> http_request_denied</dd> <dt>Name:</dt>
<dt>Description:</dt><dd> The intermediary rejected the HTTP request <dd>http_request_denied</dd>
based on its configuration and/or policy settings. The request wasn't forwarded <dt>Description:</dt>
to the next hop.</dd> <dd>The intermediary rejected the HTTP request based on its configur
<dt>Extra Parameters: </dt><dd>None.</dd> ation and/or policy settings. The request wasn't forwarded to the next hop.</dd>
<dt>Recommended HTTP status code:</dt><dd> 403</dd> <dt>Extra Parameters:</dt>
<dt>Response only generated by intermediaries:</dt><dd> true</dd> <dd>None</dd>
<dt>Reference:</dt><dd> RFC 9209</dd> <dt>Recommended HTTP Status Code:</dt>
<dd>403</dd>
<dt>Response Only Generated by Intermediaries:</dt>
<dd>true</dd>
<dt>Reference:</dt>
<dd>RFC 9209</dd>
</dl> </dl>
</section> </section>
<section anchor="http-incomplete-response" numbered="true" toc="default" > <section anchor="http-incomplete-response" numbered="true" toc="default" >
<name>HTTP Incomplete Response</name> <name>HTTP Incomplete Response</name>
<dl> <dl>
<dt>Name:</dt><dd> http_response_incomplete</dd> <dt>Name:</dt>
<dt>Description:</dt><dd> The intermediary received an incomplete re <dd>http_response_incomplete</dd>
sponse to the request from the next hop.</dd> <dt>Description:</dt>
<dt>Extra Parameters:</dt><dd> None.</dd> <dd>The intermediary received an incomplete response to the request
<dt>Recommended HTTP status code:</dt><dd> 502</dd> from the next hop.</dd>
<dt>Response only generated by intermediaries:</dt><dd> false</dd> <dt>Extra Parameters:</dt>
<dt>Reference:</dt><dd> RFC 9209</dd> <dd>None</dd>
<dt>Recommended HTTP Status Code:</dt>
<dd>502</dd>
<dt>Response Only Generated by Intermediaries:</dt>
<dd>false</dd>
<dt>Reference:</dt>
<dd>RFC 9209</dd>
</dl> </dl>
</section> </section>
<section anchor="http-response-header-section-too-large" numbered="true" toc="default"> <section anchor="http-response-header-section-too-large" numbered="true" toc="default">
<name>HTTP Response Header Section Too Large</name> <name>HTTP Response Header Section Too Large</name>
<dl> <dl>
<dt>Name:</dt><dd> http_response_header_section_size</dd> <dt>Name:</dt>
<dt>Description:</dt><dd> The intermediary received a response to th <dd>http_response_header_section_size</dd>
e request whose header section was considered too large.</dd> <dt>Description:</dt>
<dt>Extra Parameters: <dd>The intermediary received a response to the request whose header
</dt><dd><t><br/></t> section was considered too large.</dd>
<dt>Extra Parameters:</dt>
<dd><t><br/></t>
<dl> <dl>
<dt>header-section-size:</dt><dd> An sf-integer indicating how l <dt>header-section-size:</dt>
arge the received headers were. Note that they might not be complete; i.e., the <dd>An sf-integer indicating how large the received headers were
intermediary may have discarded or refused additional data.</dd> . Note that they might not be complete; i.e., the intermediary may have discarde
d or refused additional data.</dd>
</dl> </dl>
</dd> </dd>
<dt>Recommended HTTP status code:</dt><dd> 502</dd> <dt>Recommended HTTP Status Code:</dt>
<dt>Response only generated by intermediaries:</dt><dd> false</dd> <dd>502</dd>
<dt>Reference:</dt><dd> RFC 9209</dd> <dt>Response Only Generated by Intermediaries:</dt>
<dd>false</dd>
<dt>Reference:</dt>
<dd>RFC 9209</dd>
</dl> </dl>
</section> </section>
<section anchor="http-response-header-field-line-too-large" numbered="tr ue" toc="default"> <section anchor="http-response-header-field-line-too-large" numbered="tr ue" toc="default">
<name>HTTP Response Header Field Line Too Large</name> <name>HTTP Response Header Field Line Too Large</name>
<dl> <dl>
<dt>Name:</dt><dd> http_response_header_size</dd> <dt>Name:</dt>
<dt>Description:</dt><dd> The intermediary received a response to th <dd>http_response_header_size</dd>
e request containing an individual header field line that was considered too lar <dt>Description:</dt>
ge.</dd> <dd>The intermediary received a response to the request containing a
n individual header field line that was considered too large.</dd>
<dt>Extra Parameters: <dt>Extra Parameters:</dt>
</dt><dd><t><br/></t> <dd><t><br/></t>
<dl> <dl>
<dt>header-name:</dt><dd> An sf-string indicating the name of th <dt>header-name:</dt>
e header field that triggered the error.</dd> <dd>An sf-string indicating the name of the header field that tr
<dt>header-size:</dt><dd> An sf-integer indicating the size of t iggered the error.</dd>
he header field that triggered the error.</dd> <dt>header-size:</dt>
<dd>An sf-integer indicating the size of the header field that t
riggered the error.</dd>
</dl> </dl>
</dd> </dd>
<dt>Recommended HTTP status code:</dt><dd> 502</dd> <dt>Recommended HTTP Status Code:</dt>
<dt>Response only generated by intermediaries:</dt><dd> false</dd> <dd>502</dd>
<dt>Reference:</dt><dd> RFC 9209</dd> <dt>Response Only Generated by Intermediaries:</dt>
<dd>false</dd>
<dt>Reference:</dt>
<dd>RFC 9209</dd>
</dl> </dl>
</section> </section>
<section anchor="http-response-body-too-large" numbered="true" toc="defa ult"> <section anchor="http-response-body-too-large" numbered="true" toc="defa ult">
<name>HTTP Response Body Too Large</name> <name>HTTP Response Body Too Large</name>
<dl> <dl>
<dt>Name:</dt><dd> http_response_body_size</dd> <dt>Name:</dt>
<dt>Description:</dt><dd> The intermediary received a response to th <dd>http_response_body_size</dd>
e request whose body was considered too large.</dd> <dt>Description:</dt>
<dd>The intermediary received a response to the request whose body w
<dt>Extra Parameters: as considered too large.</dd>
</dt><dd><t><br/></t> <dt>Extra Parameters:</dt>
<dd><t><br/></t>
<dl> <dl>
<dt>body-size:</dt><dd> An sf-integer indicating how large the r <dt>body-size:</dt>
eceived body was. Note that it may not have been complete; i.e., the intermediar <dd>An sf-integer indicating how large the received body was. No
y may have discarded or refused additional data.</dd> te that it may not have been complete; i.e., the intermediary may have discarded
or refused additional data.</dd>
</dl> </dl>
</dd> </dd>
<dt>Recommended HTTP status code:</dt><dd> 502</dd> <dt>Recommended HTTP Status Code:</dt>
<dt>Response only generated by intermediaries:</dt><dd> false</dd> <dd>502</dd>
<dt>Reference:</dt><dd> RFC 9209</dd> <dt>Response Only Generated by Intermediaries:</dt>
<dd>false</dd>
<dt>Reference:</dt>
<dd>RFC 9209</dd>
</dl> </dl>
</section> </section>
<section anchor="http-response-trailer-section-too-large" numbered="true " toc="default"> <section anchor="http-response-trailer-section-too-large" numbered="true " toc="default">
<name>HTTP Response Trailer Section Too Large</name> <name>HTTP Response Trailer Section Too Large</name>
<dl> <dl>
<dt>Name:</dt><dd> http_response_trailer_section_size</dd> <dt>Name:</dt>
<dt>Description:</dt><dd> The intermediary received a response to th <dd>http_response_trailer_section_size</dd>
e request whose trailer section was considered too large.</dd> <dt>Description:</dt>
<dt>Extra Parameters: <dd>The intermediary received a response to the request whose traile
</dt><dd><t><br/></t> r section was considered too large.</dd>
<dt>Extra Parameters:</dt>
<dd><t><br/></t>
<dl> <dl>
<dt>trailer-section-size:</dt><dd>An sf-integer indicating how l <dt>trailer-section-size:</dt>
arge the received trailers were. Note that they might not be complete; i.e., the <dd>An sf-integer indicating how large the received trailers wer
intermediary may have discarded or refused additional data.</dd> e. Note that they might not be complete; i.e., the intermediary may have discard
ed or refused additional data.</dd>
</dl> </dl>
</dd> </dd>
<dt>Recommended HTTP status code:</dt><dd> 502</dd> <dt>Recommended HTTP Status Code:</dt>
<dt>Response only generated by intermediaries:</dt><dd> false</dd> <dd>502</dd>
<dt>Reference:</dt><dd> RFC 9209</dd> <dt>Response Only Generated by Intermediaries:</dt>
<dd>false</dd>
<dt>Reference:</dt>
<dd>RFC 9209</dd>
</dl> </dl>
</section> </section>
<section anchor="http-response-trailer-field-line-too-large" numbered="t rue" toc="default"> <section anchor="http-response-trailer-field-line-too-large" numbered="t rue" toc="default">
<name>HTTP Response Trailer Field Line Too Large</name> <name>HTTP Response Trailer Field Line Too Large</name>
<dl> <dl>
<dt>Name:</dt><dd>http_response_trailer_size</dd> <dt>Name:</dt>
<dt>Description:</dt><dd> The intermediary received a response to th <dd>http_response_trailer_size</dd>
e request containing an individual trailer field line that was considered too la <dt>Description:</dt>
rge.</dd> <dd>The intermediary received a response to the request containing a
<dt>Extra Parameters: n individual trailer field line that was considered too large.</dd>
</dt><dd><t><br/></t> <dt>Extra Parameters:</dt>
<dd><t><br/></t>
<dl> <dl>
<dt>trailer-name:</dt><dd> An sf-string indicating the name of t <dt>trailer-name:</dt>
he trailer field that triggered the error.</dd> <dd>An sf-string indicating the name of the trailer field that t
<dt>trailer-size:</dt><dd> An sf-integer indicating the size of riggered the error.</dd>
the trailer field that triggered the error.</dd> <dt>trailer-size:</dt>
<dd>An sf-integer indicating the size of the trailer field that
triggered the error.</dd>
</dl> </dl>
</dd> </dd>
<dt>Recommended HTTP status code:</dt><dd> 502</dd> <dt>Recommended HTTP Status Code:</dt>
<dt>Response only generated by intermediaries:</dt><dd> false</dd> <dd>502</dd>
<dt>Reference:</dt><dd> RFC 9209</dd> <dt>Response Only Generated by Intermediaries:</dt>
<dd>false</dd>
<dt>Reference:</dt>
<dd>RFC 9209</dd>
</dl> </dl>
</section> </section>
<section anchor="http-response-transfer-coding-error" numbered="true" to c="default"> <section anchor="http-response-transfer-coding-error" numbered="true" to c="default">
<name>HTTP Response Transfer-Coding Error</name> <name>HTTP Response Transfer-Coding Error</name>
<dl> <dl>
<dt>Name:</dt><dd>http_response_transfer_coding</dd> <dt>Name:</dt>
<dt>Description:</dt><dd> The intermediary encountered an error deco <dd>http_response_transfer_coding</dd>
ding the transfer coding of the response.</dd> <dt>Description:</dt>
<dt>Extra Parameters: <dd>The intermediary encountered an error decoding the transfer codi
</dt><dd><t><br/></t> ng of the response.</dd>
<dt>Extra Parameters:</dt>
<dd><t><br/></t>
<dl> <dl>
<dt>coding:</dt><dd>An sf-token containing the specific coding ( <dt>coding:</dt>
from the "HTTP Transfer Coding Registry") that caused the error.</dd> <dd>An sf-token containing the specific coding (from the "HTTP T
ransfer Coding Registry") that caused the error.</dd>
</dl> </dl>
</dd> </dd>
<dt>Recommended HTTP status code:</dt><dd> 502</dd> <dt>Recommended HTTP Status Code:</dt>
<dt>Response only generated by intermediaries:</dt><dd> false</dd> <dd>502</dd>
<dt>Reference:</dt><dd> RFC 9209</dd> <dt>Response Only Generated by Intermediaries:</dt>
<dd>false</dd>
<dt>Reference:</dt>
<dd>RFC 9209</dd>
</dl> </dl>
</section> </section>
<section anchor="http-response-content-coding-error" numbered="true" toc ="default"> <section anchor="http-response-content-coding-error" numbered="true" toc ="default">
<name>HTTP Response Content-Coding Error</name> <name>HTTP Response Content-Coding Error</name>
<dl> <dl>
<dt>Name:</dt><dd>http_response_content_coding</dd> <dt>Name:</dt>
<dt>Description:</dt><dd>The intermediary encountered an error decod <dd>http_response_content_coding</dd>
ing the content coding of the response.</dd> <dt>Description:</dt>
<dd>The intermediary encountered an error decoding the content codin
<dt>Extra Parameters: g of the response.</dd>
</dt><dd><t><br/></t> <dt>Extra Parameters:</dt>
<dl> <dd><t><br/></t>
<dt>coding:</dt><dd>An sf-token containing the specific coding ( <dl>
from the "HTTP Content Coding Registry") that caused the error.</dd> <dt>coding:</dt>
<dd>An sf-token containing the specific coding (from the "HTTP
Content Coding Registry") that caused the error.</dd>
</dl> </dl>
</dd> </dd>
<dt>Recommended HTTP status code:</dt><dd> 502</dd> <dt>Recommended HTTP Status Code:</dt>
<dt>Response only generated by intermediaries:</dt><dd> false</dd> <dd>502</dd>
<dt>Reference:</dt><dd> RFC 9209</dd> <dt>Response Only Generated by Intermediaries:</dt>
<dd>false</dd>
<dt>Reference:</dt>
<dd>RFC 9209</dd>
</dl> </dl>
</section> </section>
<section anchor="http-response-timeout" numbered="true" toc="default"> <section anchor="http-response-timeout" numbered="true" toc="default">
<name>HTTP Response Timeout</name> <name>HTTP Response Timeout</name>
<dl> <dl>
<dt>Name:</dt><dd> http_response_timeout</dd> <dt>Name:</dt>
<dt>Description:</dt><dd> The intermediary reached a configured time <dd>http_response_timeout</dd>
limit waiting for the complete response.</dd> <dt>Description:</dt>
<dt>Extra Parameters:</dt><dd> None.</dd> <dd>The intermediary reached a configured time limit waiting for the
<dt>Recommended HTTP status code:</dt><dd> 504</dd> complete response.</dd>
<dt>Response only generated by intermediaries:</dt><dd> false</dd> <dt>Extra Parameters:</dt>
<dt>Reference:</dt><dd> RFC 9209</dd> <dd>None</dd>
<dt>Recommended HTTP Status Code:</dt>
<dd>504</dd>
<dt>Response Only Generated by Intermediaries:</dt>
<dd>false</dd>
<dt>Reference:</dt>
<dd>RFC 9209</dd>
</dl> </dl>
</section> </section>
<!-- [rfced] Section 2.3.27: Does this Proxy Error Type define an error with the
Upgrade header field or with the process of negotiating an upgrade of the HTTP
version?
Current:
2.3.27. HTTP Upgrade Failed
Name: http_upgrade_failed
Description: The HTTP Upgrade between the intermediary and the next
hop failed.
<section anchor="http-upgrade-failed" numbered="true" toc="default"> <section anchor="http-upgrade-failed" numbered="true" toc="default">
<name>HTTP Upgrade Failed</name> <name>HTTP Upgrade Failed</name>
<dl> <dl>
<dt>Name:</dt><dd> http_upgrade_failed</dd> <dt>Name:</dt>
<dt>Description:</dt><dd> The HTTP Upgrade between the intermediary <dd>http_upgrade_failed</dd>
and the next hop failed.</dd> <dt>Description:</dt>
<dt>Extra Parameters:</dt><dd> None.</dd> <dd>The process of negotiating an upgrade of the HTTP version betwee
<dt>Recommended HTTP status code:</dt><dd> 502</dd> n the intermediary and the next hop failed.</dd>
<dt>Response only generated by intermediaries:</dt><dd> true</dd> <dt>Extra Parameters:</dt>
<dt>Reference:</dt><dd> RFC 9209</dd> <dd>None</dd>
<dt>Recommended HTTP Status Code:</dt>
<dd>502</dd>
<dt>Response Only Generated by Intermediaries:</dt>
<dd>true</dd>
<dt>Reference:</dt>
<dd>RFC 9209</dd>
</dl> </dl>
</section> </section>
<section anchor="http-protocol-error" numbered="true" toc="default"> <section anchor="http-protocol-error" numbered="true" toc="default">
<name>HTTP Protocol Error</name> <name>HTTP Protocol Error</name>
<dl> <dl>
<dt>Name:</dt><dd> http_protocol_error</dd> <dt>Name:</dt>
<dt>Description:</dt><dd> The intermediary encountered an HTTP proto <dd>http_protocol_error</dd>
col error when communicating with the next hop. This error should only be used w <dt>Description:</dt>
hen a more specific one is not defined.</dd> <dd>The intermediary encountered an HTTP protocol error when communi
<dt>Extra Parameters:</dt><dd> None.</dd> cating with the next hop. This error should only be used when a more specific on
<dt>Recommended HTTP status code:</dt><dd> 502</dd> e is not defined.</dd>
<dt>Response only generated by intermediaries:</dt><dd> false</dd> <dt>Extra Parameters:</dt>
<dt>Reference:</dt><dd> RFC 9209</dd> <dd>None</dd>
<dt>Recommended HTTP Status Code:</dt>
<dd>502</dd>
<dt>Response Only Generated by Intermediaries:</dt>
<dd>false</dd>
<dt>Reference:</dt>
<dd>RFC 9209</dd>
</dl> </dl>
</section> </section>
<!-- [rfced] Section 2.3.29: We having difficulty parsing the following example.
Did the intermediary terminate the connection because it was requested to debug
something?
Current:
Description: The intermediary generated the response locally without
attempting to connect to the next hop (e.g., in response to a
request to a debug endpoint terminated at the intermediary).
<section anchor="proxy-internal-response" numbered="true" toc="default"> <section anchor="proxy-internal-response" numbered="true" toc="default">
<name>Proxy Internal Response</name> <name>Proxy Internal Response</name>
<dl> <dl>
<dt>Name:</dt><dd> proxy_internal_response</dd> <dt>Name:</dt>
<dt>Description:</dt><dd> The intermediary generated the response lo <dd>proxy_internal_response</dd>
cally without attempting to connect to the next hop (e.g., in response to a requ <dt>Description:</dt>
est to a debug endpoint terminated at the intermediary).</dd> <dd>The intermediary generated the response locally without attempti
<dt>Extra Parameters:</dt><dd> None.</dd> ng to connect to the next hop (i.e., the intermediary has generated the response
<dt>Recommended HTTP status code:</dt><dd> The most appropriate stat itself).</dd>
us code for the response</dd> <dt>Extra Parameters:</dt>
<dt>Response only generated by intermediaries:</dt><dd> true</dd> <dd>None</dd>
<dt>Reference:</dt><dd>RFC 9209</dd> <dt>Recommended HTTP Status Code:</dt>
<dd>The most appropriate status code for the response</dd>
<dt>Response Only Generated by Intermediaries:</dt>
<dd>true</dd>
<dt>Reference:</dt>
<dd>RFC 9209</dd>
</dl> </dl>
</section> </section>
<section anchor="proxy-internal-error" numbered="true" toc="default"> <section anchor="proxy-internal-error" numbered="true" toc="default">
<name>Proxy Internal Error</name> <name>Proxy Internal Error</name>
<dl> <dl>
<dt>Name:</dt><dd> proxy_internal_error</dd> <dt>Name:</dt>
<dt>Description:</dt><dd>The intermediary encountered an internal er <dd>proxy_internal_error</dd>
ror unrelated to the origin.</dd> <dt>Description:</dt>
<dt>Extra Parameters:</dt><dd> None</dd> <dd>The intermediary encountered an internal error unrelated to the
<dt>Recommended HTTP status code:</dt><dd> 500</dd> origin.</dd>
<dt>Response only generated by intermediaries:</dt><dd> true</dd> <dt>Extra Parameters:</dt>
<dt>Reference:</dt><dd> RFC 9209</dd> <dd>None</dd>
<dt>Recommended HTTP Status Code:</dt>
<dd>500</dd>
<dt>Response Only Generated by Intermediaries:</dt>
<dd>true</dd>
<dt>Reference:</dt>
<dd>RFC 9209</dd>
</dl> </dl>
</section> </section>
<section anchor="proxy-configuration-error" numbered="true" toc="default "> <section anchor="proxy-configuration-error" numbered="true" toc="default ">
<name>Proxy Configuration Error</name> <name>Proxy Configuration Error</name>
<dl> <dl>
<dt>Name:</dt><dd> proxy_configuration_error</dd> <dt>Name:</dt>
<dt>Description:</dt><dd> The intermediary encountered an error rega <dd>proxy_configuration_error</dd>
rding its configuration.</dd> <dt>Description:</dt>
<dt>Extra Parameters:</dt><dd> None</dd> <dd>The intermediary encountered an error regarding its configuratio
<dt>Recommended HTTP status code: </dt><dd>500</dd> n.</dd>
<dt>Response only generated by intermediaries:</dt><dd> true</dd> <dt>Extra Parameters:</dt>
<dt>Reference:</dt><dd>RFC 9209</dd> <dd>None</dd>
<dt>Recommended HTTP Status Code:</dt>
<dd>500</dd>
<dt>Response Only Generated by Intermediaries:</dt>
<dd>true</dd>
<dt>Reference:</dt>
<dd>RFC 9209</dd>
</dl> </dl>
</section> </section>
<section anchor="proxy-loop-detected" numbered="true" toc="default"> <section anchor="proxy-loop-detected" numbered="true" toc="default">
<name>Proxy Loop Detected</name> <name>Proxy Loop Detected</name>
<dl> <dl>
<dt>Name:</dt><dd> proxy_loop_detected</dd> <dt>Name:</dt>
<dt>Description:</dt><dd> The intermediary tried to forward the requ <dd>proxy_loop_detected</dd>
est to itself, or a loop has been detected using different means (e.g., <xref ta <dt>Description:</dt>
rget="RFC8586" format="default"/>).</dd> <dd>The intermediary tried to forward the request to itself, or a lo
<dt>Extra Parameters: </dt><dd>None.</dd> op has been detected using different means (e.g., <xref target="RFC8586" format=
<dt>Recommended HTTP status code:</dt><dd> 502</dd> "default"/>).</dd>
<dt>Response only generated by intermediaries:</dt><dd> true</dd> <dt>Extra Parameters:</dt>
<dt>Reference: </dt><dd>RFC 9209</dd> <dd>None</dd>
<dt>Recommended HTTP Status Code:</dt>
<dd>502</dd>
<dt>Response Only Generated by Intermediaries:</dt>
<dd>true</dd>
<dt>Reference:</dt><dd>RFC 9209</dd>
</dl> </dl>
</section> </section>
</section> </section>
<section anchor="register-error" numbered="true" toc="default"> <section anchor="register-error" numbered="true" toc="default">
<name>Defining New Proxy Error Types</name> <name>Defining New Proxy Error Types</name>
<t>New Proxy Error Types can be defined by registering them in the "HTTP Proxy Error Types" registry.</t> <t>New proxy error types can be defined by registering them in the "HTTP Proxy Error Types" registry.</t>
<t>Registration requests are reviewed and approved by Expert Review, per <xref section="4.5" sectionFormat="comma" target="RFC8126" format="default"/>. A specification document is appreciated but not required.</t> <t>Registration requests are reviewed and approved by Expert Review, per <xref section="4.5" sectionFormat="comma" target="RFC8126" format="default"/>. A specification document is appreciated but not required.</t>
<t>The expert(s) should consider the following factors when evaluating r equests:</t> <t>The expert(s) should consider the following factors when evaluating r equests:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Community feedback</li> <li>Community feedback</li>
<li>If the value is sufficiently well-defined</li> <li>If the value is sufficiently well-defined</li>
<li>Generic types are preferred over vendor-specific, application-spec ific, or deployment-specific values. If a generic value cannot be agreed upon in the community, the type's name should be correspondingly specific (e.g., with a prefix that identifies the vendor, application, or deployment).</li> <li>Generic types are preferred over vendor-specific, application-spec ific, or deployment-specific values. If a generic value cannot be agreed upon in the community, the type's name should be correspondingly specific (e.g., with a prefix that identifies the vendor, application, or deployment).</li>
<li>Extra Parameters should not conflict with registered Proxy-Status parameters.</li> <li>Extra parameters should not conflict with registered Proxy-Status parameters.</li>
</ul> </ul>
<t>Registration requests should use the following template:</t> <t>Registration requests should use the following template:</t>
<dl> <dl>
<!-- [rfced] Section 2.4: Does the following suggested update improve clarity? <dt>Name:</dt>
<dd>[a name for the proxy error type that is of type sf-token]</dd>
Current: <dt>Description:</dt>
Name: [a name for the Proxy Error Type that matches sf-token] <dd>[a description of the conditions that generate the proxy error typ
e]</dd>
Perhaps: <dt>Extra Parameters:</dt>
Name: [a name for the Proxy Error Type that is of type sf-token] <dd>[zero or more optional parameters, along with their allowable type
<dt>Name:</dt><dd> [a name for the Proxy Error Type that matches sf-to (s)]</dd>
ken]</dd> <dt>Recommended HTTP Status Code:</dt>
<dt>Description:</dt><dd> [a description of the conditions that genera <dd>[the appropriate HTTP status code for this entry]</dd>
te the Proxy Error Type]</dd> <dt>Response Only Generated by Intermediaries:</dt>
<dt>Extra Parameters:</dt><dd> [zero or more optional parameters, alon <dd>['true' or 'false']</dd>
g with their allowable type(s)]</dd> <dt>Reference:</dt>
<dt>Recommended HTTP status code:</dt><dd> [the appropriate HTTP statu <dd>[to a specification defining this error type; optional]</dd>
s code for this entry]</dd> <dt>Notes:</dt>
<dt>Response only generated by intermediaries:</dt><dd> ['true' or 'fa <dd>[optional]</dd>
lse']</dd>
<dt>Reference:</dt><dd> [to a specification defining this error type;
optional]</dd>
<dt>Notes:</dt><dd> [optional]</dd>
</dl> </dl>
<t>If the Proxy Error Type might occur in responses that are not generat ed by the intermediary -- for example, when an error is detected as the response is streamed from a forward connection, causing a Proxy-Status trailer field to be appended -- the 'Response only generated by intermediaries' should be 'false' . If the Proxy Error Type only occurs in responses that are generated by the int ermediary, it should be 'true'.</t> <t>If the proxy error type might occur in responses that are not generat ed by the intermediary -- for example, when an error is detected as the response is streamed from a forward connection, causing a Proxy-Status trailer field to be appended -- the 'Response only generated by intermediaries' should be 'false' . If the proxy error type only occurs in responses that are generated by the int ermediary, it should be 'true'.</t>
<t>See the registry at <eref target="https://iana.org/assignments/http-p roxy-status" brackets="angle"/> for details on where to send registration reques ts.</t> <t>See the registry at <eref target="https://iana.org/assignments/http-p roxy-status" brackets="angle"/> for details on where to send registration reques ts.</t>
</section> </section>
</section> </section>
<!-- [rfced] Sections 2.1, 2.3 and IANA Considerations:
FYI, we will ask IANA to update the "HTTP Proxy-Status Parameters" registry and
the "HTTP Proxy Error Types" registry after all approvals are received so that t
he registries and this document are aligned.
a) Currently, the "HTTP Proxy Error Types" registry capitalizes column headers,
but the template in this document does not. Would you like to capitalize the te
mplate used for the descriptions to match? We also recommend removing the perio
d after "None.". For instance:
Current:
Name: dns_timeout
Description: The intermediary encountered a timeout when trying to
find an IP address for the next-hop hostname.
Extra Parameters: None.
Recommended HTTP status code: 504
Response only generated by intermediaries: true
Reference: RFC 9209
Perhaps:
Name: dns_timeout
Description: The intermediary encountered a timeout when trying to
find an IP address for the next-hop hostname.
Extra Parameters: None
Recommended HTTP Status Code: 504
Response Only Generated by Intermediaries: true
Reference: RFC 9209
b) The "HTTP Proxy Error Types" registry has hyphens in front of Extra Parameter
s. Should these be removed? For example:
Current:
- status-code: an sf-integer containing the generated status code.
- status-phrase: an sf-string containing the generated status phrase.
Perhaps:
status-code: an sf-integer containing the generated status code.
status-phrase: an sf-string containing the generated status phrase.
<section anchor="iana-considerations" numbered="true" toc="default"> <section anchor="iana-considerations" numbered="true" toc="default">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>IANA has created the "HTTP Proxy-Status Parameters" registry and the "H TTP Proxy Error Types" registry at <eref target="https://iana.org/assignments/ht tp-proxy-status" brackets="angle"/> and has populated them with the types define d in Sections <xref target="params" format="counter"/> and <xref target="error-t ypes" format="counter"/>, respectively; see Sections <xref target="register-para m" format="counter"/> and <xref target="register-error" format="counter"/> for t heir associated procedures.</t> <t>IANA has created the "HTTP Proxy-Status Parameters" registry and the "H TTP Proxy Error Types" registry at <eref target="https://www.iana.org/assignment s/http-proxy-status" brackets="angle"/> and has populated them with the types de fined in Sections <xref target="params" format="counter"/> and <xref target="err or-types" format="counter"/>, respectively; see Sections <xref target="register- param" format="counter"/> and <xref target="register-error" format="counter"/> f or their associated procedures.</t>
<t>Additionally, the following entry has been added to the "Hypertext Tran sfer Protocol (HTTP) Field Name Registry":</t> <t>Additionally, the following entry has been added to the "Hypertext Tran sfer Protocol (HTTP) Field Name Registry":</t>
<dl spacing="compact"> <dl spacing="compact">
<dt>Field name:</dt><dd> Proxy-Status</dd> <dt>Field name:</dt>
<dt>Status:</dt><dd> permanent</dd> <dd>Proxy-Status</dd>
<dt>Specification document(s):</dt><dd> RFC 9209</dd> <dt>Status:</dt>
<dt>Comments:</dt><dd/> <dd>permanent</dd>
<dt>Specification document(s):</dt>
<dd>RFC 9209</dd>
<dt>Comments:</dt>
<dd/>
</dl> </dl>
</section> </section>
<section anchor="security" numbered="true" toc="default"> <section anchor="security" numbered="true" toc="default">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>One of the primary security concerns when using Proxy-Status is leaking information that might aid an attacker. For example, information about the inte rmediary's configuration and backend topology can be exposed, allowing attackers to directly target backend services that are not prepared for high traffic volu me or malformed inputs. Some information might only be suitable to reveal to au thorized parties.</t> <t>One of the primary security concerns when using Proxy-Status is leaking information that might aid an attacker. For example, information about the inte rmediary's configuration and backend topology can be exposed, allowing attackers to directly target backend services that are not prepared for high traffic volu me or malformed inputs. Some information might only be suitable to reveal to au thorized parties.</t>
<t>As a result, care needs to be taken when deciding to generate a Proxy-S tatus field and what information to include in it. Note that intermediaries are not required to generate a Proxy-Status field in any response and can conditiona lly generate them based upon request attributes (e.g., authentication tokens, IP address).</t> <t>As a result, care needs to be taken when deciding to generate a Proxy-S tatus field and what information to include in it. Note that intermediaries are not required to generate a Proxy-Status field in any response and can conditiona lly generate them based upon request attributes (e.g., authentication tokens, IP address).</t>
<t>Likewise, generation of all parameters is optional, as is the generatio n of the field itself. Also, the field's content is not verified; an intermediar y can claim certain actions (e.g., sending a request over an encrypted channel) but fail to actually do that.</t> <t>Likewise, generation of all parameters is optional, as is the generatio n of the field itself. Also, the field's content is not verified; an intermediar y can claim certain actions (e.g., sending a request over an encrypted channel) but fail to actually do that.</t>
</section> </section>
</middle> </middle>
<back> <back>
skipping to change at line 854 skipping to change at line 914
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.8914.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.8914.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.8446.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.8446.xml"/>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.5234.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.5234.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.8586.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.8586.xml"/>
</references> </references>
</references> </references>
</back> </back>
<!-- [rfced] Terminology:
For the following terms, we chose the latter form:
Content Delivery Network / content delivery network
info-code / INFO-CODE (RFC8914)
next hop / next-hop (when used as an adjective)
back-end / backend
The following was inconsistently capitalized. Please let us know if we may make
it consistent.
List / list (we note that RFC 8941 capitalizes "List")
May we change the following capitalized terms to their lowercase forms?
Original:
Extra Parameters
Proxy Error Type
Proxy-Status Parameter
Perhaps:
extra parameters (when not used to describe an IANA registry column)
proxy error type
Proxy-Status parameter
<!-- [rfced] Please review the "Inclusive Language" portion of the online Style
Guide
<https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. -->
</rfc> </rfc>
 End of changes. 74 change blocks. 
571 lines changed or deleted 573 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/