RFC 9209 — The Proxy-Status HTTP Response Header Field （日本語訳）

◎要約

この文書は、 `媒介者$による応答の取扱いを成す詳細を — `生成-$された~errorも含めて — 伝達するための~HTTP応答~field `Proxy-Status$h を定義する。 ◎ This document defines the Proxy-Status HTTP response field to convey the details of an intermediary's response handling, including generated errors.

1. 序論

`媒介者$【！Section 3.7 of [HTTP]】 — `回送-~proxy$と`~gateway$（`逆~proxy$としても知られる）両者を含む — は、ますます，~HTTP配備の有意な一部を成すようになってきた。特に，`逆~proxy$と~CDN（内容~送達~network）は、多くの~web~siteに~criticalな基盤の一部を形成している。 ◎ HTTP intermediaries (see Section 3.7 of [HTTP]) -- including both forward proxies and gateways (also known as "reverse proxies") -- have become an increasingly significant part of HTTP deployments. In particular, reverse proxies and content delivery networks (CDNs) form part of the critical infrastructure of many websites.

`媒介者$は、概して，`生成元~server$へ向けて（`内方$へ）要請を回送して，対する応答を`~client$へ戻すよう（`外方$へ）回送する。しかしながら，`内方$にある~serverから応答が得される前に~error生じた場合、当の応答は，`媒介者$自身により`生成-$されることが多い。 ◎ Typically, HTTP intermediaries forward requests towards the origin server (inbound) and then forward their responses back to clients (outbound). However, if an error occurs before a response is obtained from an inbound server, the response is often generated by the intermediary itself.

~HTTPは、これらの種別の~errorを，少数の`状態s~code$で収容する — 例えば， `502$st や `504$st 。しかしながら、［ ~debug法を援助する／何が起きたか`~client$に通信する］ためには，もっと情報が必要yなことが、経験から示された。加えて，`媒介者$は、自身が当の応答を`生成-$しなかった場合でも，［自身による応答の取扱いについて，追加的な情報を伝達したい］と求めるときもある。 ◎ HTTP accommodates these types of errors with a few status codes -- for example, 502 (Bad Gateway) and 504 (Gateway Timeout). However, experience has shown that more information is necessary to aid debugging and communicate what's happened to the client. Additionally, intermediaries sometimes want to convey additional information about their handling of a response, even if they did not generate it.

これらの利用を可能化するため、 `2＠#header§では，新たな~HTTP応答~fieldを定義する — それは、［そのような応答の取扱いについて詳細を伝達する］ことを`媒介者$に許容する。 `2.1＠#params§では、この~fieldに`媒介者$が追加できる情報を列挙する — それらは、 `2.2＠#register-param§に従って拡張し得る。 `2.3＠#error-types§では、［ ~proxyが要請~用に応答を得するとき，課題に遭遇したとき］に利用するための，一群の~error種別を定義する — これらも同様に， `2.4＠#register-error§に従って拡張し得る。 ◎ To enable these uses, Section 2 defines a new HTTP response field to allow intermediaries to convey details of their handling of a response. Section 2.1 enumerates the information that can be added to the field by intermediaries, which can be extended per Section 2.2. Section 2.3 defines a set of error types for use when a proxy encounters an issue when obtaining a response for the request; these can likewise be extended per Section 2.4.

1.1. 表記上の規約

この文書~内の~keyword "MUST" … 【以下、この段落の内容は`~IETF日本語訳共通~page＠~IETFcommon#requirements-notation$に移譲。】 ◎ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

この文書は、次に挙げる`各種~有構造~data型＠~STRUCTURED-FIELDS#types$ `STRUCTURED-FIELDS$r を利用して，構文と構文解析を指定する ⇒＃ `~sf~list$, `~sf文字列$, `~sf~token$, `~sf整数$, `~sf~byte列$ ◎ This document uses the following terminology from Section 3 of [STRUCTURED-FIELDS] to specify syntax and parsing: List, String, Token, Integer, and Byte Sequence.

この仕様における `~proxy@ は、 `回送-~proxy$, `逆~proxy$（`~gateway$とも呼ばれる）の総称として利用されることに注意。 ◎ Note that in this specification, "proxy" is used to indicate both forward and reverse proxies, otherwise known as gateways.＼

“`next hop^en” は、要請~用に`生成元~server$へ向かう方向の接続を指示する。 ◎ "Next hop" indicates the connection in the direction leading to the origin server for the request.

【すなわち、 `内方$にある次の`~server$。この訳では、この用語は利用せず，直に “内方にある次の~server” と記すことにする。】

2. `Proxy-Status^h ~HTTP~field

`Proxy-Status^h ~HTTP応答~fieldは、次を`媒介者$に許容する ⇒ 当の応答, それが応対した要請をどう取扱ったかについて，追加的な情報を伝達する。 ◎ The Proxy-Status HTTP response field allows an intermediary to convey additional information about its handling of a response and its associated request.

その値は、 `~sf~list$である。この~listを成す各~memberは、応答を取扱った`媒介者$を表現する。最初の~memberは，`生成元~server$に最も近い`媒介者$を表現し、最後の~memberは，`~UA$に最も近い`媒介者$を表現する。 ◎ Its value is a List (see Section 3.1 of [STRUCTURED-FIELDS]). Each member of the List represents an intermediary that has handled the response. The first member represents the intermediary closest to the origin server, and the last member represents the intermediary closest to the user agent.

例えば、次のものは： ◎ For example:

Proxy-Status: revproxy1.example.net, ExampleCDN

まず `revproxy1.example.net^c【！(a reverse proxy adjacent to the origin server)】, 次に `ExampleCDN^c が，当の応答を取扱ったことを指示する。 ◎ indicates that this response was handled first by revproxy1.example.net (a reverse proxy adjacent to the origin server) and then ExampleCDN.

応答に `Proxy-Status^h ~fieldをいつ追加するのが適切になるかは、当の`媒介者$が決定する。すべての応答に追加するものと裁定する`媒介者$もあれば、［特定的に環境設定されたとき／当の要請が~debug用の~modeを作動化する~headerを包含するとき］に限り，そうする`媒介者$もあろう。 ◎ 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 others might only do so when specifically configured to or when the request contains a header field that activates a debugging mode.

この~listを成す各~memberは、それを挿入した`媒介者$を識別する。それは、［ `~sf文字列$／`~sf~token$ ］でなければナラナイ。これは、配備に依存して，次に挙げるいずれにもなり得る ⇒＃ ~service名†／ ~hostname（例： "`proxy-3.example.com^c" ）／ ~IP~address／【当の`媒介者$により】`生成-$された文字列

（† ~softwareや~hardwareの製品~名は，~service名として適切でない — 例： "`ExampleCDN^c" は適切であるが、 "`ExampleProxy^c" は配備を識別しないので，適切でない。）

◎ Each member of the List identifies the intermediary that inserted the value and MUST have a type of either String or Token. Depending on the deployment, this might be a service name (but not a software or hardware product name; e.g., "ExampleCDN" is appropriate, but "ExampleProxy" is not because it doesn't identify the deployment), a hostname ("proxy-3.example.com"), an IP address, or a generated string.

各~memberに伴われる`~sf~parameter群$は、 `媒介者$による応答の取扱いと，当の応答が応対した要請についての追加的な情報を伝達する — `2.1＠#params§を見よ。これら各~parameter（`~sf~parameter$）の利用は，`任意選択^2119であるが、 `媒介者$には，アリな限り多くの情報を供することが奨励される（が、そうすることには，`~securityの考慮点＠#security$もある）。 ◎ Parameters of each member (per Section 3.1.2 of [STRUCTURED-FIELDS]) convey additional information about that intermediary's handling of the response and its associated request; see Section 2.1. While all of these parameters are OPTIONAL, intermediaries are encouraged to provide as much information as possible (but see Section 4 for security considerations in doing so).

当の要請を取扱っている`媒介者$たちが成す連鎖~全体に対し，~debugすることを許容するため、 `Proxy-Status^h ~fieldに値を追加する`媒介者$は，当の~fieldの既存の~memberを保全するベキである — ただし、それらを除去するよう明示的に環境設定されている場合は除く（例：内部~networkの詳細が漏洩されるのを防止するため — `4＠#security§を見よ）。 ◎ When adding a value to the Proxy-Status field, intermediaries SHOULD preserve the existing members of the field to allow debugging of the entire chain of intermediaries handling the request unless explicitly configured to remove them (e.g., to prevent internal network details from leaking; see Section 4).

`生成元~server$は、 `Proxy-Status^h ~fieldを生成してはナラナイ。 ◎ Origin servers MUST NOT generate the Proxy-Status field.

`Proxy-Status^h は、 `~trailer$として送信してもヨイ。例えば，応答を~streamしている`媒介者$は、 `内方$への接続が突如~終了された場合には — `外方$への~messageの`~header節$をすでに送信したので — `~trailer節$にしか `Proxy-Status^h を付加できない。ただし， `~header節$に送信することはアリでない場合を除いて、 `Proxy-Status^h を`~trailer$として送信するべキでない — どの`~trailer$も，`~UA$までの経路のどこかで黙って破棄され得るので `HTTP$r 。 ◎ Proxy-Status MAY be sent as an HTTP trailer field. For example, if an intermediary is streaming a response and the inbound connection suddenly terminates, Proxy-Status can only be appended to the trailer section of the outbound message since the header section has already been sent.＼ However, because it might be silently discarded along the path to the user agent (as is the case for all trailer fields; see Section 6.5 of [HTTP]), Proxy-Status SHOULD NOT be sent as a trailer field unless it is not possible to send it in the header section.

［ `~trailer$として伝達された `Proxy-Status^h の~memberたち］と［ `~header$として伝達されたそれら］との相対的な順序付けを構築し直すこと†を`受信者$に許容するため、当の~message内に同じ~member††を伴う `Proxy-Status^h `~header$を`生成-$していない限り， `Proxy-Status^h を`~trailer$として送信してはナラナイ（これらは、異なる~parameterを伴い得るが）。 ◎ To allow recipients to reconstruct the relative ordering of Proxy-Status members conveyed in trailer fields with those conveyed in header fields, an intermediary MUST NOT send Proxy-Status as a trailer field unless it has also generated a Proxy-Status header field with the same member (although potentially different parameters) in that message.

【この要件は，［上で述べた，`~header節$に送信することはアリでない場合］には施行し得ないので、その場合は免除されると解釈するよりないであろう。】【† 下の手続きを見よ。】【†† 下の例に見られるように、 ~trailer内には，自身が~header内に生成しなかった~memberを含める必要はない。】

例えば、 `ThisProxy^c として識別される`~proxy$が，次の~headerを伴う応答を受信したなら： ◎ For example, a proxy identified as 'ThisProxy' that receives a response bearing a header field:

Proxy-Status: SomeOtherProxy

当の~headerに自前の~entryを追加することになろう： ◎ would add its own entry to the header field:

Proxy-Status: SomeOtherProxy, ThisProxy

したがって、 `~trailer$として付加することも許容される： ◎ thus allowing it to append a trailer field:

Proxy-Status: ThisProxy; error=read_timeout

それ【~headerの方】は、［ `下流$にある`受信者$が次を解する］ことを許容する ⇒ `SomeOtherProxy^c による処理は `ThisProxy^c より前に生じた ◎ which would thereby allow a downstream recipient to understand that processing by 'SomeOtherProxy' occurred before 'ThisProxy'.

`~client$は、次の手続きにより， `Proxy-Status^h `~trailer$を`~header$に格上げしてもヨイ：

%~trailer値 ~LET `Proxy-Status^h `~trailer$の`~field値$を表現している有構造~data `STRUCTURED-FIELDS$r
%~header値 ~LET `Proxy-Status^h `~header$の`~field値$を表現している有構造~data `STRUCTURED-FIELDS$r
~Assert： %~trailer値, %~header値は、いずれも`~sf~list$である
%~trailer値を成す ~EACH( %~trailer~member ) に対し：
1. ~Assert： %~trailer~member の値は［ `~sf文字列$／`~sf~token$ ］である
2. %~header値を成す ~EACH( %~header~member ) に対し：
  1. ~Assert： %~header~member の値は［ `~sf文字列$／`~sf~token$ ］である
  2. ~IF［ %~header~member の値を成す文字列 ~NEQ %~trailer~member の値を成す文字列］ ⇒ ~CONTINUE
    
    この比較においては ⇒＃ `~sf文字列$, `~sf~token$は，いずれも文字列と見なす（型の相違は無視する）。 ~parameter群は無視する。
  3. %~header値内で %~header~member を %~trailer~member で置換する — ~parameter群も含めて
  4. %~trailer値から %~trailer~member を除去する
  5. ~BREAK
~IF［ %~trailer値は空である］ ⇒ `~trailer節$から `Proxy-Status^h `~trailer$を除去する

【各 ~Assert は、この訳による追加。［構文解析に失敗した／いずれかの ~Assert に失敗した］場合、その取扱いは，この仕様には明示的に述べられていないので、 `有構造~field$の既定の挙動としては，当の~fieldはまるごと無視されることになる。（とは言え、そうすると，他の`媒介者$が追加した~memberも一緒に無視されることになるので、本当にそうなるべきかは疑わしい。）】

◎ A client MAY promote the Proxy-Status trailer field into a header field by following these steps: • For each member trailer_member of the Proxy-Status trailer field value: •• Let header_member be the first (leftmost) value of the Proxy-Status header field value, comparing the String or Token character by character without consideration of parameters. •• If no matching header_member is found, continue processing the next trailer_member. •• Replace header_member with trailer_member in its entirety, including any parameters. • Remove the Proxy-Status trailer field if empty.

2.1. `Proxy-Status^h 用の~parameter

この節は、 `Proxy-Status$h ~fieldの各~memberに利用できる~parameterを挙げる。認識されない~parameterは、無視しなければナラナイ。 ◎ This section lists parameters that can be used on the members of the Proxy-Status field. Unrecognised parameters MUST be ignored.

2.1.1. `error^c

`error^c ~parameterの値は、 `~sf~token$であり， `~proxy~error種別@ を与える。在るならば、当の`媒介者$は，当の応答を得するときに課題に遭遇したことを指示する。 ◎ The error parameter's value is a Token that is a proxy error type. When present, it indicates that the intermediary encountered an issue when obtaining this response.

一部の`~proxy~error種別$は、 `媒介者$自身が当の応答を`生成-$したことを指示する — 応答を回送したのではなく。これは、例えば，次の事例が該当する ⇒ 当の`~proxy$は、 `生成元~server$に接触できなかったので，自前の応答を作成する必要があった ◎ The presence of some proxy error types indicates that the response was generated by the intermediary itself, rather than being forwarded from the origin server. This is the case when, for example, the origin server can't be contacted, so the proxy has to create its own response.

他の`~proxy~error種別$は、［ `生成元~server$／他の`内方$にある`~server$ ］により`生成-$された（`部分的$にもなり得る）応答に追加できる。例えば，当の回送-接続が中途で~closeされた場合、 `媒介者$は，適切な~errorを伴う `Proxy-Status$h を`~trailer$として追加することもあろう。 ◎ Other proxy error types can be added to (potentially partial) responses that were generated by the origin server or some other inbound server. For example, if the forward connection abruptly closes, an intermediary might add Proxy-Status with an appropriate error as a trailer field.

`~proxy~error種別$のうち， `媒介者が生成した応答に限られるか@ に ~T を伴って登録されたものは、当の`媒介者$が`生成-$した応答~内に限り，生じ得ることを指示する。 ~F を伴って登録されたものは、他の応答~内にも生じ得る。 ◎ Proxy error types that are registered with a 'Response only generated by intermediaries' value of 'true' indicate that they can only occur in responses generated by the intermediary. If the value is 'false', the response might be generated by the intermediary or an inbound server.

【 ~F を伴って登録された~error種別のうち一部は、実質的に，当の媒介者`以外^emが`生成-$した応答に限られよう（例： `http_response_header_section_size^c など， “〜が長過ぎる~error” に類するもの）。】

この文書にて定義される`~proxy~error種別$は、 `2.3＠#error-types§にて挙げられる — 新たなものは、 `2.4＠#register-error§に要旨される手続-を利用して，定義できる／され得る。 ◎ Section 2.3 lists the proxy error types defined in this document; new ones can be defined using the procedure outlined in Section 2.4.

例えば、次は： ◎ For example:

HTTP/1.1 504 Gateway Timeout
Proxy-Status: ExampleCDN; error=connection_timeout

この `504$st0 応答は、回送する際の接続~時間切れに因り， `ExampleCDN^c により`生成-$されたことを指示する。 ◎ indicates that this 504 response was generated by ExampleCDN due to a connection timeout when going forward.

あるいは次は： ◎ Or:

HTTP/1.1 429 Too Many Requests
Proxy-Status: r34.example.net; error=http_request_error, ExampleCDN

この `429$st0 応答は、 `r34.example.net^c により`生成-$されたことを指示する — ~CDN（ `ExampleCDN^c ）や`生成元~server$ではなく。 ◎ indicates that this 429 (Too Many Requests) response was generated by r34.example.net, not the CDN or the origin.

`error^c ~parameterを送信するときは、当の~error条件を正確aに表現する限りにおいて，最も特定な`~proxy~error種別$を送信するベキである。適切な`~proxy~error種別$が定義されてない場合、利用できる汎用な~error種別が，いくつかある（例： `proxy_internal_error^c, `http_protocol_error^c ）。それらが相応でない場合、新たな`~proxy~error種別$の登録を考慮すること（`2.4＠#register-error§を見よ）。 ◎ When sending the error parameter, the most specific proxy error type SHOULD be sent, provided that it accurately represents the error condition. If an appropriate proxy error type is not defined, there are a number 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 type (see Section 2.4).

各`~proxy~error種別$には、 `推奨される~HTTP状態s~code@ がある。 `error^c を包含している~HTTP応答を`生成-$するときは、応答の`状態s~code$を推奨される~HTTP状態s~codeに設定するベキである。しかしながら、別の状態s~codeが利用され得る状況下もある（例：以前の挙動との後方-互換性を得るため, すでに状態s~codeを送信した†）。 ◎ Each proxy error type has a recommended HTTP status code. When generating an HTTP response containing the error, its HTTP status code SHOULD be set to the recommended HTTP status code. However, there may be circumstances (e.g., for backwards compatibility with previous behaviours, a status code has already been sent) when another status code might be used.

【† ~commaで分離された 2 つの句の関係が不明瞭（ “以前の挙動” は “状態s~codeを送信した” ことを指す？）】

各`~proxy~error種別$は、その種別と伴に利用するための `~extra~parameter@ （ `extra parameter^en ）をいくつでも定義し得る。それらの利用は、すべての~parameterと同様に，任意選択~である。よって、ある`~proxy~error種別$に対し，それ用に定義されていない`~extra~parameter$を利用した場合、無視されることになる。 ◎ Proxy error types can also define any number of extra parameters for 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 defined, it will be ignored.

2.1.2. `next-hop^c

`next-hop^c ~parameterの値は、［ `~sf文字列$／`~sf~token$ ］であり，当の応答を得するために選定された［ `媒介者$／`生成元~server$ ］（順不同）（接触した【~~実際に接続した】場合は、利用されたそれ）を識別する。それは、［ ~hostname, ~IP~address, 別名］いずれもあり得る。 ◎ The next-hop parameter's value is a String or Token that identifies the intermediary or origin server selected (and used, if contacted) to obtain this response. It might be a hostname, IP address, or alias.

例えば： ◎ For example:

Proxy-Status: cdn.example.org; next-hop=backend.example.org:8001

`cdn.example.org^c は、当の要請に対し， `内方$にある次の`~server$として `backend.example.org:8001^c を利用したことを指示する。 ◎ indicates that cdn.example.org used backend.example.org:8001 as the next hop for this request.

2.1.3. `next-protocol^c

`next-protocol^c ~parameterの値は、［ `~sf~token$／`~sf~byte列$ ］であり，次を指示する ⇒ この応答を得するとき，［ `内方$にある次の`~server$へ接続するために当の`媒介者$により利用された~protocol ］の~ALPN（ `Application-Layer Protocol Negotiation^en ）~protocol識別子 `RFC7301$r ◎ The next-protocol parameter's value indicates the Application-Layer Protocol Negotiation (ALPN) protocol identifier [RFC7301] of the protocol used by the intermediary to connect to the next hop when obtaining this response.

値は、 ~TLS~ALPN~protocol~IDを表現していなければナラナイ（`~TLS~ALPN~protocol~ID~registry$cite を見よ）。当の~protocol識別子は、 ~ASCII符号化法を利用して`~sf~token$として表出-可能な場合には，その形を利用しなければナラナイ。 ◎ The value MUST be either a Token or Byte Sequence representing a TLS ALPN Protocol ID (see <https://www.iana.org/assignments/tls-extensiontype-values#alpn-protocol-ids>). If the protocol identifier is able to be expressed as a Token using ASCII encoding, that form MUST be used.

例えば： ◎ For example:

Proxy-Status: "proxy.example.org"; next-protocol=h2

ここで利用された~ALPN識別子は、利用-中にある~protocolを識別することに注意 — それは、当の~protocol折衝に実際に利用されたものと同じとは限らない。 ◎ Note that the ALPN identifier is being used here to identify the protocol in use; it may or may not have been actually used in the protocol negotiation.

2.1.4. `received-status^c

`received-status^c ~parameterは、当の`媒介者$が当の応答を得するとき， `内方$にある次の`~server$から受信した`状態s~code$を指示する。 ◎ The received-status parameter's value indicates the HTTP status code that the intermediary received from the next-hop server when obtaining this response.

値は、 `~sf整数$でなければナラナイ。 ◎ The value MUST be an Integer.

例えば： ◎ For example:

Proxy-Status: ExampleCDN; received-status=200

2.1.5. `details^c

`details^c ~parameterの値は、 `~sf文字列$であり，他所では捕捉されなかった追加的な情報を包含する。これは、［実装／配備］に特有な情報を内包し得る。 ◎ The details parameter's value is a String containing additional information not captured anywhere else. This can include implementation-specific or deployment-specific information.

例えば： ◎ For example:

Proxy-Status: proxy.example.net; error="http_protocol_error";
              details="Malformed response header: space before colon"

2.2. `Proxy-Status^h 用の新たな~parameterの定義-法

新たな `Proxy-Status$h ~parameterは、 `~HTTP Proxy-Status ~parameter~registry$cite 内に登録することにより，定義できる。 ◎ New Proxy-Status parameters can be defined by registering them in the "HTTP Proxy-Status Parameters" registry.

登録~要請は、 `8126/4.5$rfc に従って，専門家により考査された上で認可される。仕様~文書は、在った方が良いが，要求されてはいない。 ◎ Registration requests are reviewed and approved by Expert Review, per [RFC8126], Section 4.5. A specification document is appreciated but not required.

専門家（たち）は、登録~要請を評価する際に，次に挙げる要因を考慮するべきである： ◎ The expert(s) should consider the following factors when evaluating requests:

~communityからの~feedback。 ◎ Community feedback
当の【~parameterの】値は、不足なくきちんと定義されたかどうか。 ◎ If the value is sufficiently well defined
~parameterの名前【！値】は、［ ~vendor／応用／配備］に特有なものより，汎用なものの方が選好される。汎用な名前【！値】が~community内で合意できなかった場合、 ~parameterの名前は，~~相応に特有な何かにするべきである（例：当の［ ~vendor／応用／配備］を識別する接頭辞を伴わせる）。 ◎ Generic parameters are preferred over vendor-specific, application-specific, or deployment-specific values. If a generic value cannot be agreed upon in the community, the parameter's name should be correspondingly specific (e.g., with a prefix that identifies the vendor, application, or deployment).
~parameterの名前は、 `~HTTP~proxy~error種別~registry^cite 内に登録された`~extra~parameter$と競合するべきでない。 ◎ Parameter names should not conflict with registered extra parameters in the "HTTP Proxy Error Types" registry.

`Proxy-Status$h ~parameterの登録~要請は、次の雛形を利用するべきである： ◎ Registration requests should use the following template:

名前 ⇒ `~sf~key$に合致する，当の~parameterの名前。 ◎ Name: • [a name for the Proxy-Status parameter that matches key]
記述 ⇒ 当の~parameterの意味論と値を成す記述。 ◎ Description: • [a description of the parameter semantics and value]
参照 ⇒ 当の~parameterを定義している仕様 — 省略可能。 ◎ Reference: • [to a specification defining this parameter; optional]

登録~要請の送信-先の詳細は、 `当の~registry＠~IANA-a/http-proxy-status$を見よ。 ◎ See the registry at <https://www.iana.org/assignments/http-proxy-status> for details on where to send registration requests.

2.3. ~proxy~error種別

この節では、この文書により定義される`~proxy~error種別$を挙げる。新たな`~proxy~error種別$の定義-法について情報は、 `2.4＠#register-error§を見よ。 ◎ This section lists the proxy error types defined by this document. See Section 2.4 for information about defining new proxy error types.

実装は、あらゆる`~proxy~error種別$を生産するとは限らないことに注意。以下に挙げる種別は，実装における既存の【既知な】状態に対応付けるよう設計されたので、一部の状態には，適用-可能なものが無いこともあろう。 ◎ Note that implementations might not produce all proxy error types. The set of types below is designed to map to existing states in implementations and therefore may not be applicable to some.

2.3.1. ~DNS時間切れ

名前 ⇒ `dns_timeout^c ◎ Name: • dns_timeout
記述 ⇒ `媒介者$は、 `内方$にある次の`~server$の~hostname用の~IP~addressを見出そうと試行したとき，時間切れに遭遇した。 ◎ Description: • The intermediary encountered a timeout when trying to find an IP address for the next-hop hostname.
`~extra~parameter$ ⇒ ナシ ◎ Extra Parameters: • None
`推奨される~HTTP状態s~code$ ⇒ `504$st0 ◎ Recommended HTTP Status Code: • 504
`媒介者が生成した応答に限られるか$ ⇒ ~T ◎ Response Only Generated by Intermediaries: • true
参照 ⇒ ~RFC 9209 ◎ Reference: • RFC 9209

2.3.2. ~DNS~error

名前 ⇒ `dns_error^c ◎ Name: • dns_error
記述 ⇒ `媒介者$は、 `内方$にある次の`~server$の~hostname用の~IP~addressを見出そうと試行したとき， ~DNS~errorに遭遇した。 ◎ Description: • The intermediary encountered a DNS error when trying to find an IP address for the next-hop hostname.
`~extra~parameter$ ⇒ ◎ Extra Parameters:
- `rcode^c ⇒ 次を伝達する`~sf文字列$ ⇒ 当の~error種別を指示する ~DNS RCODE — `8499/3$rfc を見よ。 ◎ rcode: • A String conveying the DNS RCODE that indicates the error type. See [RFC8499], Section 3.
- `info-code^c ⇒ 次を伝達する`~sf整数$ ⇒ 拡張された~DNS~error~code（ `the Extended DNS Error Code^en ） INFO-CODE — `RFC8914$r を見よ。 ◎ info-code: • An Integer conveying the Extended DNS Error Code INFO-CODE. See [RFC8914].
`推奨される~HTTP状態s~code$ ⇒ `502$st0 ◎ Recommended HTTP Status Code: • 502
`媒介者が生成した応答に限られるか$ ⇒ ~T ◎ Response Only Generated by Intermediaries: • true
参照 ⇒ ~RFC 9209 ◎ Reference: • RFC 9209

2.3.3. 行先を見出せない

名前 ⇒ `destination_not_found^c ◎ Name: • destination_not_found
記述 ⇒ `媒介者$は、当の要請~用に利用する適切な`内方$にある次の`~server$を決定できなかった — 例えば、それ用に環境設定されてないとき。この~errorは、 `~gateway$に特有であることに注意 — それは，概して、 “~backend” ~serverを識別するために特有な環境設定を要求する。対して，`回送-~proxy$は、帯域内の情報を利用して`生成元~server$を識別する。 ◎ Description: • The intermediary cannot determine the appropriate next hop to use for this request; for example, it may not be configured. Note that this error is specific to gateways, which typically require specific configuration to identify the "backend" server; forward proxies use in-band information to identify the origin server.
`~extra~parameter$ ⇒ ナシ ◎ Extra Parameters: • None
`推奨される~HTTP状態s~code$ ⇒ `500$st0 ◎ Recommended HTTP Status Code: • 500
`媒介者が生成した応答に限られるか$ ⇒ ~T ◎ Response Only Generated by Intermediaries: • true
参照 ⇒ ~RFC 9209 ◎ Reference: • RFC 9209

2.3.4. 行先は可用でない

名前 ⇒ `destination_unavailable^c ◎ Name: • destination_unavailable
記述 ⇒ `媒介者$は、 `内方$にある次の`~server$は可用でないと見なした — 例 ⇒＃ `内方$にある次の`~server$と通信する近過去の試みに失敗した／ `health check^en から`内方$にある次の`~server$は~downしていることが指示された ◎ Description: • The intermediary considers the next hop to be unavailable; e.g., recent attempts to communicate with it may have failed, or a health check may indicate that it is down.
`~extra~parameter$ ⇒ ナシ ◎ Extra Parameters: • None
`推奨される~HTTP状態s~code$ ⇒ `503$st0 ◎ Recommended HTTP Status Code: • 503
`媒介者が生成した応答に限られるか$ ⇒ ~T ◎ Response Only Generated by Intermediaries: • true
参照 ⇒ ~RFC 9209 ◎ Reference: • RFC 9209

2.3.5. 行先~IPは禁制されている

名前 ⇒ `destination_ip_prohibited^c ◎ Name: • destination_ip_prohibited
記述 ⇒ `媒介者$は、 `内方$にある次の`~server$の~IP~addressへの接続を禁制するよう環境設定されている。 ◎ Description: • The intermediary is configured to prohibit connections to the next-hop IP address.
`~extra~parameter$ ⇒ ナシ ◎ Extra Parameters: • None
`推奨される~HTTP状態s~code$ ⇒ `502$st0 ◎ Recommended HTTP Status Code: • 502
`媒介者が生成した応答に限られるか$ ⇒ ~T ◎ Response Only Generated by Intermediaries: • true
参照 ⇒ ~RFC 9209 ◎ Reference: • RFC 9209

2.3.6. 行先~IPへ~route不能

名前 ⇒ `destination_ip_unroutable^c ◎ Name: • destination_ip_unroutable
記述 ⇒ `媒介者$は、 `内方$にある次の`~server$の~IP~addressへの~routeを見出せなかった。 ◎ Description: • The intermediary cannot find a route to the next-hop IP address.
`~extra~parameter$ ⇒ ナシ ◎ Extra Parameters: • None
`推奨される~HTTP状態s~code$ ⇒ `502$st0 ◎ Recommended HTTP Status Code: • 502
`媒介者が生成した応答に限られるか$ ⇒ ~T ◎ Response Only Generated by Intermediaries: • true
参照 ⇒ ~RFC 9209 ◎ Reference: • RFC 9209

2.3.7. 接続は拒否された

名前 ⇒ `connection_refused^c ◎ Name: • connection_refused
記述 ⇒ `媒介者$による`内方$にある次の`~server$への接続は拒否された。 ◎ Description: • The intermediary's connection to the next hop was refused.
`~extra~parameter$ ⇒ ナシ ◎ Extra Parameters: • None
`推奨される~HTTP状態s~code$ ⇒ `502$st0 ◎ Recommended HTTP Status Code: • 502
`媒介者が生成した応答に限られるか$ ⇒ ~T ◎ Response Only Generated by Intermediaries: • true
参照 ⇒ ~RFC 9209 ◎ Reference: • RFC 9209

2.3.8. 接続は終了された

名前 ⇒ `connection_terminated^c ◎ Name: • connection_terminated
記述 ⇒ `媒介者$による`内方$にある次の`~server$への接続は、完全な応答を受信する前に~closeされた。 ◎ Description: • The intermediary's connection to the next hop was closed before a complete response was received.
`~extra~parameter$ ⇒ ナシ ◎ Extra Parameters: • None
`推奨される~HTTP状態s~code$ ⇒ `502$st0 ◎ Recommended HTTP Status Code: • 502
`媒介者が生成した応答に限られるか$ ⇒ ~F ◎ Response Only Generated by Intermediaries: • false
参照 ⇒ ~RFC 9209 ◎ Reference: • RFC 9209

2.3.9. 接続~時間切れ

名前 ⇒ `connection_timeout^c ◎ Name: • connection_timeout
記述 ⇒ `媒介者$による`内方$にある次の`~server$へ接続を~openしようとする試みは、時間切れした。 ◎ Description: • The intermediary's attempt to open a connection to the next hop timed out.
`~extra~parameter$ ⇒ ナシ ◎ Extra Parameters: • None
`推奨される~HTTP状態s~code$ ⇒ `504$st0 ◎ Recommended HTTP Status Code: • 504
`媒介者が生成した応答に限られるか$ ⇒ ~T ◎ Response Only Generated by Intermediaries: • true
参照 ⇒ ~RFC 9209 ◎ Reference: • RFC 9209

2.3.10. 接続~読取n時間切れ

名前 ⇒ `connection_read_timeout^c ◎ Name: • connection_read_timeout
記述 ⇒ `媒介者$は、接続~上に~data（例：応答の一部）を期待していたが，環境設定された制限時間-内に新たな~dataは受信されなかった。 ◎ Description: • The intermediary was expecting data on a connection (e.g., part of a response) but did not receive any new data in a configured time limit.
`~extra~parameter$ ⇒ ナシ ◎ Extra Parameters: • None
`推奨される~HTTP状態s~code$ ⇒ `504$st0 ◎ Recommended HTTP Status Code: • 504
`媒介者が生成した応答に限られるか$ ⇒ ~F ◎ Response Only Generated by Intermediaries: • false
参照 ⇒ ~RFC 9209 ◎ Reference: • RFC 9209

2.3.11. 接続~書込n時間切れ

名前 ⇒ `connection_write_timeout^c ◎ Name: • connection_write_timeout
記述 ⇒ `媒介者$は、接続に~dataを書込むよう試みていたが，可能でなかった（例：~bufferが満杯であったため）。 ◎ Description: • The intermediary was attempting to write data to a connection but was not able to (e.g., because its buffers were full).
`~extra~parameter$ ⇒ ナシ ◎ Extra Parameters: • None
`推奨される~HTTP状態s~code$ ⇒ `504$st0 ◎ Recommended HTTP Status Code: • 504
`媒介者が生成した応答に限られるか$ ⇒ ~F ◎ Response Only Generated by Intermediaries: • false
参照 ⇒ ~RFC 9209 ◎ Reference: • RFC 9209

2.3.12. 接続~制限-に到達した

名前 ⇒ `connection_limit_reached^c ◎ Name: • connection_limit_reached
記述 ⇒ `媒介者$は、 `内方$にある次の`~server$への接続の個数を制限するよう環境設定されていて，その上限を超過した。 ◎ Description: • The intermediary is configured to limit the number of connections it has to the next hop, and that limit has been exceeded.
`~extra~parameter$ ⇒ ナシ ◎ Extra Parameters: • None
`推奨される~HTTP状態s~code$ ⇒ `503$st0 ◎ Recommended HTTP Status Code: • 503
`媒介者が生成した応答に限られるか$ ⇒ ~T ◎ Response Only Generated by Intermediaries: • true
参照 ⇒ ~RFC 9209 ◎ Reference: • RFC 9209

2.3.13. ~TLS~protocol~error

名前 ⇒ `tls_protocol_error^c ◎ Name: • tls_protocol_error
記述 ⇒ `媒介者$は、 ~handshakeまたはそれ以降の間に`内方$にある次の`~server$と通信するとき， ~TLS~errorに遭遇した。 ◎ Description: • The intermediary encountered a TLS error when communicating with the next hop, either during the handshake or afterwards.
`~extra~parameter$ ⇒ ナシ ◎ Extra Parameters: • None
`推奨される~HTTP状態s~code$ ⇒ `502$st0 ◎ Recommended HTTP Status Code: • 502
`媒介者が生成した応答に限られるか$ ⇒ ~F ◎ Response Only Generated by Intermediaries: • false
参照 ⇒ ~RFC 9209 ◎ Reference: • RFC 9209
注記 ⇒ ~TLS~alertを受信したときには適切でない — `tls_alert_received^c を見よ。 ◎ Notes: • Not appropriate when a TLS alert is received; see tls_alert_received.

2.3.14. ~TLS証明書~error

名前 ⇒ `tls_certificate_error^c ◎ Name: • tls_certificate_error
記述 ⇒ `媒介者$は、 `内方$にある次の`~server$により提示された証明書を検証yするとき， ~errorに遭遇した。 ◎ Description: • The intermediary encountered an error when verifying the certificate presented by the next hop.
`~extra~parameter$ ⇒ ナシ ◎ Extra Parameters: • None
`推奨される~HTTP状態s~code$ ⇒ `502$st0 ◎ Recommended HTTP Status Code: • 502
`媒介者が生成した応答に限られるか$ ⇒ ~T ◎ Response Only Generated by Intermediaries: • true
参照 ⇒ ~RFC 9209 ◎ Reference: • RFC 9209

2.3.15. ~TLS~alertを受信した

名前 ⇒ `tls_alert_received^c ◎ Name: • tls_alert_received
記述 ⇒ `媒介者$は、 `内方$にある次の`~server$から~TLS~alertを受信した。 ◎ Description: • The intermediary received a TLS alert from the next hop.
`~extra~parameter$： ◎ Extra Parameters:
- `alert-id^c ⇒ 次を包含している`~sf整数$ ⇒ `~TLS~alert~registry$cite `TLS$r 内の適用-可能な値 ◎ alert-id: • An Integer containing the applicable value from the "TLS Alerts" registry. See [TLS].
- `alert-message^c ⇒ 次を包含している［ `~sf~token$／`~sf文字列$ ］ ⇒ `~TLS~alert~registry$cite `TLS$r 内の適用-可能な記述~文字列 ◎ alert-message: • A Token or String containing the applicable description string from the "TLS Alerts" registry. See [TLS].
`推奨される~HTTP状態s~code$ ⇒ `502$st0 ◎ Recommended HTTP Status Code: • 502
`媒介者が生成した応答に限られるか$ ⇒ ~F ◎ Response Only Generated by Intermediaries: • false
参照 ⇒ ~RFC 9209 ◎ Reference: • RFC 9209

2.3.16. ~HTTP要請~error

名前 ⇒ `http_request_error^c ◎ Name: • http_request_error
記述 ⇒ `媒介者$は、生成元~serverに利するため， `4xx$st0 （~client~error）応答を生成している。適用-可能な状態s~codeは、次に挙げるものを含む（が，それらに制限されない） ⇒ `400$st0, `403$st0, `405$st0, `406$st0, `408$st0, `411$st0, `413$st0, `414$st0, `415$st0, `416$st0, `417$st0, `429$st0 ◎ Description: • The intermediary is generating a client (4xx) response on the origin's behalf. Applicable status codes include (but are not limited to) 400, 403, 405, 406, 408, 411, 413, 414, 415, 416, 417, and 429.
`~extra~parameter$： ◎ Extra Parameters:
- `status-code^c ⇒ 次を包含している`~sf整数$ ⇒ 生成した状態s~code ◎ status-code: • An Integer containing the generated status code.
- `status-phrase^c ⇒ 次を包含している`~sf文字列$ ⇒ 生成した`事由~句$ ◎ status-phrase: • A String containing the generated status phrase.
`推奨される~HTTP状態s~code$ ⇒ 適用-可能な `4xx$st0 状態s~code ◎ Recommended HTTP Status Code: • The applicable 4xx status code
`媒介者が生成した応答に限られるか$ ⇒ ~T ◎ Response Only Generated by Intermediaries: • true
参照 ⇒ ~RFC 9209 ◎ Reference: • RFC 9209
注記 ⇒ この種別は、 `媒介者$が`生成-$した応答を`生成元~server$により`生成-$されたものと判別する助けになる。 ◎ Notes: • This type helps distinguish between responses generated by intermediaries from those generated by the origin.

2.3.17. ~HTTP要請は否認された

名前 ⇒ `http_request_denied^c ◎ Name: • http_request_denied
記述 ⇒ `媒介者$は、自身の［環境設定／施策~設定群］に基づいて，当の~HTTP要請を却下した。当の要請は、 `内方$にある次の`~server$へ回送されなかった。 ◎ Description: • The intermediary rejected the HTTP request based on its configuration and/or policy settings. The request wasn't forwarded to the next hop.
`~extra~parameter$ ⇒ ナシ ◎ Extra Parameters: • None
`推奨される~HTTP状態s~code$ ⇒ `403$st0 ◎ Recommended HTTP Status Code: • 403
`媒介者が生成した応答に限られるか$ ⇒ ~T ◎ Response Only Generated by Intermediaries: • true
参照 ⇒ ~RFC 9209 ◎ Reference: • RFC 9209

2.3.18. ~HTTP不完全な応答

名前 ⇒ `http_response_incomplete^c ◎ Name: • http_response_incomplete
記述 ⇒ `媒介者$は、当の要請に対し，`内方$にある次の`~server$から`不完全$な応答を受信した。 ◎ Description: • The intermediary received an incomplete response to the request from the next hop.
`~extra~parameter$ ⇒ ナシ ◎ Extra Parameters: • None
`推奨される~HTTP状態s~code$ ⇒ `502$st0 ◎ Recommended HTTP Status Code: • 502
`媒介者が生成した応答に限られるか$ ⇒ ~F ◎ Response Only Generated by Intermediaries: • false
参照 ⇒ ~RFC 9209 ◎ Reference: • RFC 9209

2.3.19. ~HTTP応答の~header節が長過ぎる

名前 ⇒ `http_response_header_section_size^c ◎ Name: • http_response_header_section_size
記述 ⇒ `媒介者$は、［要請に対し受信した応答の`~header節$ ］が長過ぎると見なした。 ◎ Description: • The intermediary received a response to the request whose header section was considered too large.
`~extra~parameter$： ◎ Extra Parameters:
- `header-section-size^c ⇒ 次を指示している`~sf整数$ ⇒ 受信した`~header節$の~size
  
  そのような~header節は、完全でないかもしれないことに注意 — すなわち，当の`媒介者$は、追加的な【超過した】~dataを［破棄する／拒否する］こともある。
  ◎ header-section-size: • An Integer indicating how large the received headers were.＼ Note that they might not be complete; i.e., the intermediary may have discarded or refused additional data.
`推奨される~HTTP状態s~code$ ⇒ `502$st0 ◎ Recommended HTTP Status Code: • 502
`媒介者が生成した応答に限られるか$ ⇒ ~F ◎ Response Only Generated by Intermediaries: • false
参照 ⇒ ~RFC 9209 ◎ Reference: • RFC 9209

2.3.20. ~HTTP応答~headerの~field行lが長過ぎる

名前 ⇒ `http_response_header_size^c ◎ Name: • http_response_header_size
記述 ⇒ `媒介者$は、［当の要請に対し受信した応答の`~header節$ ］を成すある`~field行l$が長過ぎると見なした。 ◎ Description: • The intermediary received a response to the request containing an individual header field line that was considered too large.
`~extra~parameter$： ◎ Extra Parameters:
- `header-name^c ⇒ 次を指示している`~sf文字列$ ⇒ 当の~errorを誘発した`~header$の名前 ◎ header-name: • A String indicating the name of the header field that triggered the error.
- `header-size^c ⇒ 次を指示している`~sf整数$ ⇒ 当の~errorを誘発した`~header$の~size ◎ header-size: • An Integer indicating the size of the header field that triggered the error.
`推奨される~HTTP状態s~code$ ⇒ `502$st0 ◎ Recommended HTTP Status Code: • 502
`媒介者が生成した応答に限られるか$ ⇒ ~F ◎ Response Only Generated by Intermediaries: • false
参照 ⇒ ~RFC 9209 ◎ Reference: • RFC 9209

2.3.21. ~HTTP応答の本体が長過ぎる

名前 ⇒ `http_response_body_size^c ◎ Name: • http_response_body_size
記述 ⇒ `媒介者$は、［当の要請に対し受信した応答の本体【`内容$】］が長過ぎると見なした。 ◎ Description: • The intermediary received a response to the request whose body was considered too large.
`~extra~parameter$： ◎ Extra Parameters:
- `body-size^c ⇒ 次を指示している`~sf整数$ ⇒ 受信した本体の~size
  
  そのような本体は、完全でないかもしれないことに注意 — すなわち，当の`媒介者$は、追加的な【超過した】~dataを［破棄する／拒否する］こともある。
  ◎ body-size: • An Integer indicating how large the received body was.＼ Note that it may not have been complete; i.e., the intermediary may have discarded or refused additional data.
`推奨される~HTTP状態s~code$ ⇒ `502$st0 ◎ Recommended HTTP Status Code: • 502
`媒介者が生成した応答に限られるか$ ⇒ ~F ◎ Response Only Generated by Intermediaries: • false
参照 ⇒ ~RFC 9209 ◎ Reference: • RFC 9209

2.3.22. ~HTTP応答の~trailer節が長過ぎる

名前 ⇒ `http_response_trailer_section_size^c ◎ Name: • http_response_trailer_section_size
記述 ⇒ `媒介者$は、［当の要請に対し受信した応答の`~trailer節$ ］が長過ぎると見なした。 ◎ Description: • The intermediary received a response to the request whose trailer section was considered too large.
`~extra~parameter$： ◎ Extra Parameters:
- `trailer-section-size^c ⇒ 次を指示している`~sf整数$ ⇒ 受信した`~trailer節$の~size
  
  そのような~trailer節は、完全でないかもしれないことに注意 — すなわち，当の`媒介者$は、追加的な【超過した】~dataを［破棄する／拒否する］こともある。
  ◎ trailer-section-size: • An Integer indicating how large the received trailers were.＼ Note that they might not be complete; i.e., the intermediary may have discarded or refused additional data.
`推奨される~HTTP状態s~code$ ⇒ `502$st0 ◎ Recommended HTTP Status Code: • 502
`媒介者が生成した応答に限られるか$ ⇒ ~F ◎ Response Only Generated by Intermediaries: • false
参照 ⇒ ~RFC 9209 ◎ Reference: • RFC 9209

2.3.23. ~HTTP応答~trailerの~field行lが長過ぎる

名前 ⇒ `http_response_trailer_size^c ◎ Name: • http_response_trailer_size
記述 ⇒ `媒介者$は、［当の要請に対し受信した応答の`~trailer節$ ］を成すある`~field行l$が長過ぎると見なした。 ◎ Description: • The intermediary received a response to the request containing an individual trailer field line that was considered too large.
`~extra~parameter$： ◎ Extra Parameters:
- `trailer-name^c ⇒ 次を指示している`~sf文字列$ ⇒ 当の~errorを誘発した`~trailer$の名前 ◎ trailer-name: • A String indicating the name of the trailer field that triggered the error.
- `trailer-size^c ⇒ 次を指示している`~sf整数$ ⇒ 当の~errorを誘発した`~trailer$の~size ◎ trailer-size: • An Integer indicating the size of the trailer field that triggered the error.
`推奨される~HTTP状態s~code$ ⇒ `502$st0 ◎ Recommended HTTP Status Code: • 502
`媒介者が生成した応答に限られるか$ ⇒ ~F ◎ Response Only Generated by Intermediaries: • false
参照 ⇒ ~RFC 9209 ◎ Reference: • RFC 9209

2.3.24. ~HTTP応答の転送~符号法~error

名前 ⇒ `http_response_transfer_coding^c ◎ Name: • http_response_transfer_coding
記述 ⇒ `媒介者$は、当の応答の`転送~符号法$を復号するとき， ~errorに遭遇した。 ◎ Description: • The intermediary encountered an error decoding the transfer coding of the response.
`~extra~parameter$： ◎ Extra Parameters:
- `coding^c ⇒ 次を包含している`~sf~token$ ⇒ 当の~errorの原因になった特定の符号法（`~HTTP転送~符号法~registry$cite 内の）。 ◎ coding: • A Token containing the specific coding (from the "HTTP Transfer Coding Registry") that caused the error.
`推奨される~HTTP状態s~code$ ⇒ `502$st0 ◎ Recommended HTTP Status Code: • 502
`媒介者が生成した応答に限られるか$ ⇒ ~F ◎ Response Only Generated by Intermediaries: • false
参照 ⇒ ~RFC 9209 ◎ Reference: • RFC 9209

2.3.25. ~HTTP応答の内容~符号法~error

名前 ⇒ `http_response_content_coding^c ◎ Name: • http_response_content_coding
記述 ⇒ `媒介者$は、当の応答の`内容~符号法$を復号するとき， ~errorに遭遇した。 ◎ Description: • The intermediary encountered an error decoding the content coding of the response.
`~extra~parameter$： ◎ Extra Parameters:
- `coding^c ⇒ 次を包含している`~sf~token$ ⇒ 当の~errorの原因になった特定の符号法（`~HTTP内容~符号法~registry$cite 内の）。 ◎ coding: • A Token containing the specific coding (from the "HTTP Content Coding Registry") that caused the error.
`推奨される~HTTP状態s~code$ ⇒ `502$st0 ◎ Recommended HTTP Status Code: • 502
`媒介者が生成した応答に限られるか$ ⇒ ~F ◎ Response Only Generated by Intermediaries: • false
参照 ⇒ ~RFC 9209 ◎ Reference: • RFC 9209

2.3.26. ~HTTP応答~時間切れ

名前 ⇒ `http_response_timeout^c ◎ Name: • http_response_timeout
記述 ⇒ `媒介者$は、完全な応答を待機するためとして環境設定された制限時間に達した。 ◎ Description: • The intermediary reached a configured time limit waiting for the complete response.
`~extra~parameter$ ⇒ ナシ ◎ Extra Parameters: • None
`推奨される~HTTP状態s~code$ ⇒ `504$st0 ◎ Recommended HTTP Status Code: • 504
`媒介者が生成した応答に限られるか$ ⇒ ~F ◎ Response Only Generated by Intermediaries: • false
参照 ⇒ ~RFC 9209 ◎ Reference: • RFC 9209

2.3.27. ~HTTP~version昇格に失敗した

名前 ⇒ `http_upgrade_failed^c ◎ Name: • http_upgrade_failed
記述 ⇒ 当の`媒介者$と`内方$にある次の`~server$との間で， ~HTTP~versionの昇格†を折衝する処理nに失敗した。 ◎ Description: • The process of negotiating an upgrade of the HTTP version between the intermediary and the next hop failed.

【† おそらく， `Upgrade§h `HTTP$r を指す。字義どおり解釈するなら、 ~HTTP以外の~protocolへの昇格は該当しないことになるが，はっきりしない（ “~HTTPの`ある~versionから何か^emへの昇格” かも？）。】
`~extra~parameter$ ⇒ ナシ ◎ Extra Parameters: • None
`推奨される~HTTP状態s~code$ ⇒ `502$st0 ◎ Recommended HTTP Status Code: • 502
`媒介者が生成した応答に限られるか$ ⇒ ~T ◎ Response Only Generated by Intermediaries: • true
参照 ⇒ ~RFC 9209 ◎ Reference: • RFC 9209

2.3.28. ~HTTP~protocol~error

名前 ⇒ `http_protocol_error^c ◎ Name: • http_protocol_error
記述 ⇒ `媒介者$は、 `内方$にある次の`~server$と通信するとき， ~HTTP~protocol~errorに遭遇した。この~errorの利用は、より特定な種別が定義されていないときに限るべきである。 ◎ Description: • The intermediary encountered an HTTP protocol error when communicating with the next hop. This error should only be used when a more specific one is not defined.
`~extra~parameter$ ⇒ ナシ ◎ Extra Parameters: • None
`推奨される~HTTP状態s~code$ ⇒ `502$st0 ◎ Recommended HTTP Status Code: • 502
`媒介者が生成した応答に限られるか$ ⇒ ~F ◎ Response Only Generated by Intermediaries: • false
参照 ⇒ ~RFC 9209 ◎ Reference: • RFC 9209

2.3.29. ~proxy内部~応答

名前 ⇒ `proxy_internal_response^c ◎ Name: • proxy_internal_response
記述 ⇒ `媒介者$は、 `内方$にある次の`~server$へ接続しようと試みることなく，当の応答を生成した。 ◎ Description: • The intermediary generated the response itself without attempting to connect to the next hop.
`~extra~parameter$ ⇒ ナシ ◎ Extra Parameters: • None
`推奨される~HTTP状態s~code$ ⇒ 当の応答に最も適切な`状態s~code$ ◎ Recommended HTTP Status Code: • The most appropriate status code for the response
`媒介者が生成した応答に限られるか$ ⇒ ~T ◎ Response Only Generated by Intermediaries: • true
参照 ⇒ ~RFC 9209 ◎ Reference: • RFC 9209

2.3.30. ~proxy内部~error

名前 ⇒ `proxy_internal_error^c ◎ Name: • proxy_internal_error
記述 ⇒ `媒介者$は、 `生成元~server$には無関係な内部~errorに遭遇した。 ◎ Description: • The intermediary encountered an internal error unrelated to the origin.
`~extra~parameter$ ⇒ ナシ ◎ Extra Parameters: • None
`推奨される~HTTP状態s~code$ ⇒ `500$st0 ◎ Recommended HTTP Status Code: • 500
`媒介者が生成した応答に限られるか$ ⇒ ~T ◎ Response Only Generated by Intermediaries: • true
参照 ⇒ ~RFC 9209 ◎ Reference: • RFC 9209

2.3.31. ~proxy環境設定~error

名前 ⇒ `proxy_configuration_error^c ◎ Name: • proxy_configuration_error
記述 ⇒ `媒介者$は、自身の環境設定に関する~errorに遭遇した。 ◎ Description: • The intermediary encountered an error regarding its configuration.
`~extra~parameter$ ⇒ ナシ ◎ Extra Parameters: • None
`推奨される~HTTP状態s~code$ ⇒ `500$st0 ◎ Recommended HTTP Status Code: • 500
`媒介者が生成した応答に限られるか$ ⇒ ~T ◎ Response Only Generated by Intermediaries: • true
参照 ⇒ ~RFC 9209 ◎ Reference: • RFC 9209

2.3.32. ~proxy~loopが検出された

名前 ⇒ `proxy_loop_detected^c ◎ Name: • proxy_loop_detected
記述 ⇒ `媒介者$は、当の要請を自身へ回送しようと試行したか，異なる手段を利用して~loopを検出した（例： `RFC8586$r ）。 ◎ Description: • The intermediary tried to forward the request to itself, or a loop has been detected using different means (e.g., [RFC8586]).
`~extra~parameter$ ⇒ ナシ ◎ Extra Parameters: • None
`推奨される~HTTP状態s~code$ ⇒ `502$st0 ◎ Recommended HTTP Status Code: • 502
`媒介者が生成した応答に限られるか$ ⇒ ~T ◎ Response Only Generated by Intermediaries: • true
参照 ⇒ ~RFC 9209 ◎ Reference: • RFC 9209

2.4. 新たな~proxy~error種別の定義-法

新たな`~proxy~error種別$は `~HTTP~proxy~error種別~registry$cite （ `HTTP Proxy Error Types^en ）内に登録することにより定義できる。 ◎ New proxy error types can be defined by registering them in the "HTTP Proxy Error Types" registry.

~communityからの~feedback ◎ Community feedback
当の【~parameterの】値は、不足なくきちんと定義されたかどうか ◎ If the value is sufficiently well-defined
種別を与える~parameter名は、［ ~vendor／応用／配備］に特有なものより，汎用なものの方が選好される。汎用な名前【！値】が~community内で合意できなかった場合、 ~parameterの名前は，~~相応に特有な何かにするべきである（例：当の［ ~vendor／応用／配備］を識別する接頭辞を伴わせる）。 ◎ Generic types are preferred over vendor-specific, application-specific, 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).
`~extra~parameter$【の名前】は、登録-済みな `Proxy-Status^h `~parameter＠#register-param$と競合するべきでない。 ◎ Extra parameters should not conflict with registered Proxy-Status parameters.

登録~要請は、次の雛形を利用するべきである： ◎ Registration requests should use the following template:

名前 ⇒ 当の`~proxy~error種別$用の名前を与える`~sf~token$。 ◎ Name: • [a name for the proxy error type that is of type Token]
記述 ⇒ 当の`~proxy~error種別$が生成されるための条件を成す記述 ◎ Description: • [a description of the conditions that generate the proxy error type]
`~extra~parameter$ ⇒ 0 個以上の省略可能な~parameter, および各~parameterに許容-可能な`有構造~data型＠~STRUCTURED-FIELDS#types$（複数可） ◎ Extra Parameters: • [zero or more optional parameters, along with their allowable Structured Type(s)]
`推奨される~HTTP状態s~code$ ⇒ この~error種別~用に適切な`状態s~code$ ◎ Recommended HTTP Status Code: • [the appropriate HTTP status code for this entry]
`媒介者が生成した応答に限られるか$ ⇒ ~T ／ ~F ◎ Response Only Generated by Intermediaries: • ['true' or 'false']
参照 ⇒ この~error種別を定義している仕様 — 省略可能。 ◎ Reference: • [to a specification defining this error type; optional]
注記 ⇒ 省略可能 ◎ Notes: • [optional]

`~proxy~error種別$の “応答は`媒介者$のみにより生成されるか” は、［当の`媒介者$が`生成-$した応答~内にしか生じ得ない場合は ~T ／ ~ELSE_ ~F ］にするべきである。例えば，当の~errorが［ある回送-接続から応答が~streamされるに伴い検出される］場合、 `Proxy-Status$h を`~trailer$として付加することになるので， ~F になる。 ◎ If the proxy error type might occur in responses that are not generated 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 intermediary, it should be 'true'.

3. ~IANA考慮点

~IANAは、［ `~HTTP Proxy-Status ~parameter~registry$cite／ `~HTTP~proxy~error種別~registry$cite ］を作成して，［ `2.1＠#params§ ／ `2.3＠#error-types§ ］にて定義される種別で拡充した — 登録~手続-は、［ `2.2＠#register-param§／`2.4＠#register-error§ ］を見よ。 ◎ IANA has created the "HTTP Proxy-Status Parameters" registry and the "HTTP Proxy Error Types" registry at <https://www.iana.org/assignments/http-proxy-status> and has populated them with the types defined in Sections 2.1 and 2.3 respectively; see Sections 2.2 and 2.4 for their associated procedures.

加えて、 `~HTTP~field名~registry$cite に，次の~entryを追加した： ◎ Additionally, the following entry has been added to the "Hypertext Transfer Protocol (HTTP) Field Name Registry":

~field名 ⇒ `Proxy-Status^h ◎ Field name: • Proxy-Status
位置付け ⇒ 恒久的 ◎ Status: • permanent
仕様~文書 ⇒ ~RFC 9209 ◎ Specification document(s): • RFC 9209 ◎ Comments:

4. ~securityの考慮点

`Proxy-Status$h を利用する際の首な~securityの懸念の一つは、攻撃者を援助し得る情報を漏洩することである。例えば、［ `媒介者$の環境設定／~backendの~topology ］についての情報が公開され得る — その結果、［大容量な流通や不正形な入力］に対し準備されてない~backend~serviceを直に~targetにすることを，攻撃者に許容する。一部の情報は、権限付与された主体に限り露呈する方が，相応しくなるかもしれない。 ◎ One of the primary security concerns when using Proxy-Status is leaking information that might aid an attacker. For example, information about the intermediary's configuration and backend topology can be exposed, allowing attackers to directly target backend services that are not prepared for high traffic volume or malformed inputs. Some information might only be suitable to reveal to authorized parties.

よって、［ `Proxy-Status$h ~fieldを`生成-$するものと裁定する］とき, および［そこに何を情報として含めるか裁定する］ときには，~careが必要になる。 `媒介者$は、［どの応答においても， `Proxy-Status^h ~fieldを`生成-$することは要求されない］こと, および［要請の属性（例：認証~token, ~IP~address）に基づいて， `Proxy-Status^h ~fieldを条件付きで生成し得る］ことに注意。 ◎ As a result, care needs to be taken when deciding to generate a Proxy-Status 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 conditionally generate them based upon request attributes (e.g., authentication tokens, IP address).

同様に、どの~parameterも，その生成は、当の~field自体の生成と同じく，任意選択~である。また、当の~fieldの内容【が実際の動作に合致しているかどうか】は，検証yされない — `媒介者$は、ある種の動作を主張し得るが（例：暗号化された~channel越しに要請を送信する）、それを実際に行うことに失敗することもある。 ◎ Likewise, generation of all parameters is optional, as is the generation of the field itself. Also, the field's content is not verified; an intermediary can claim certain actions (e.g., sending a request over an encrypted channel) but fail to actually do that.

このメモの位置付け

著作権の告知

1. 序論

1.1. 表記上の規約

2. `Proxy-Status^h ~HTTP~field

2.1. `Proxy-Status^h 用の~parameter

2.1.1. `error^c

2.1.2. `next-hop^c

2.1.3. `next-protocol^c

2.1.4. `received-status^c

2.1.5. `details^c

2.2. `Proxy-Status^h 用の新たな~parameterの定義-法

2.3. ~proxy~error種別

2.3.1. ~DNS時間切れ

2.3.2. ~DNS~error

2.3.3. 行先を見出せない

2.3.4. 行先は可用でない

2.3.5. 行先~IPは禁制されている

2.3.6. 行先~IPへ~route不能

2.3.7. 接続は拒否された

2.3.8. 接続は終了された

2.3.9. 接続~時間切れ

2.3.10. 接続~読取n時間切れ

2.3.11. 接続~書込n時間切れ

2.3.12. 接続~制限-に到達した

2.3.13. ~TLS~protocol~error

2.3.14. ~TLS証明書~error

2.3.15. ~TLS~alertを受信した

2.3.16. ~HTTP要請~error

2.3.17. ~HTTP要請は否認された

2.3.18. ~HTTP不完全な応答

2.3.19. ~HTTP応答の~header節が長過ぎる

2.3.20. ~HTTP応答~headerの~field行lが長過ぎる

2.3.21. ~HTTP応答の本体が長過ぎる

2.3.22. ~HTTP応答の~trailer節が長過ぎる

2.3.23. ~HTTP応答~trailerの~field行lが長過ぎる

2.3.24. ~HTTP応答の転送~符号法~error

2.3.25. ~HTTP応答の内容~符号法~error

2.3.26. ~HTTP応答~時間切れ

2.3.27. ~HTTP~version昇格に失敗した

2.3.28. ~HTTP~protocol~error

2.3.29. ~proxy内部~応答

2.3.30. ~proxy内部~error

2.3.31. ~proxy環境設定~error

2.3.32. ~proxy~loopが検出された

2.4. 新たな~proxy~error種別の定義-法

3. ~IANA考慮点

4. ~securityの考慮点