http-proxy-status-ja.html

<!DOCTYPE html><html lang="ja"><head><meta charset="utf-8">
<title>RFC 9209 — The Proxy-Status HTTP Response Header Field （日本語訳）</title>

<link rel="stylesheet" href="common.css" type="text/css">
<link rel="stylesheet" href="http-common.css" type="text/css">

<script src="common0.js"></script>
<script src="http-common.js"></script>
<script src="common1.js" async></script>

<script type="text/plain" id="_source_data">

●●options
spec_title:The Proxy-Status HTTP Response Header Field
	spec_date:2022-06-06
trans_update:2022-08-09
source_checked:220600
page_state_key:HTTP
original_url:https://httpwg.org/specs/rfc9209.html
	abbr_url:HTTPproxystatus
spec_status:IETFPR
no_original_dfn:true
ref_rfc:true
trans_1st_pub:2022-08-09

●●class_map

●●tag_map


●●original_id_map

●●mdn_urls
	field:HTTP/Headers/Proxy-Status

●●link_map

h.Proxy-Status:#header
st.429:~RFC6585#status-429

~proxy:#proxy
~proxy~error種別:#proxy-error-type
~extra~parameter:#extra-parameter
媒介者が生成した応答に限られるか:#only-generated-by-intermediaries
推奨される~HTTP状態s~code:#recommended-status-code

~sf~item:~STRUCTURED-FIELDS#sf-item
~sf~list:~STRUCTURED-FIELDS#sf-list
~sf~token:~STRUCTURED-FIELDS#sf-token
~sf整数:~STRUCTURED-FIELDS#sf-integer
~sf文字列:~STRUCTURED-FIELDS#sf-string
~sf~byte列:~STRUCTURED-FIELDS#sf-binary
~sf~parameter群:~STRUCTURED-FIELDS#sf-parameters
~sf~parameter:~STRUCTURED-FIELDS#sf-parameter
~sf~key:~STRUCTURED-FIELDS#sf-key
有構造~field:~STRUCTURED-FIELDS#structured-field

cite.~TLS~alert~registry:~IANA-a/tls-parameters/#tls-parameters-6
cite.~HTTP内容~符号法~registry:~IANA-a/http-parameters/#content-coding
cite.~HTTP転送~符号法~registry:~IANA-a/http-parameters/#transfer-coding
cite.~HTTP~field名~registry:~IANA-a/http-fields
cite.~HTTP Proxy-Status ~parameter~registry:~IANA-a/http-proxy-status#http-proxy-status-parameters
cite.~HTTP~proxy~error種別~registry:~IANA-a/http-proxy-status#http-proxy-error-types
cite.~TLS~ALPN~protocol~ID~registry:~IANA-a/tls-extensiontype-values#alpn-protocol-ids


●●words_table1
sf:<sub>sf-</sub>
RFC6585:http-status-code-428-429-431-511-ja.html

●●words_table

	●network
ALPN:
CDN:
DNS:
IP:
hostname::::ホスト名
backend::::バックエンド
帯域内:in-band:~
handshake::::ハンドシェイク
alert:
topology::::トポロジー
	逆~proxy:reverse proxy
	`内方$にある次の`~server$:next hop／:next-hop
接触-:contact:~
down::::ダウン

	RCODE
	INFO-CODE

	●構文
不正形な:malformedな:不正な形の
裸:bare::~

	●処理
中途で:abruptに:~
格上げ:promote:~
満杯:full:~
書込n:write::書き込み
書込む:writeする::書き込む
時間切れ:timeout:~
時間切れした:time outした:時間切れになった
制限時間:time limit:~
黙って:silentに:~

	%~trailer~member:trailer_member
	%~header~member:header_member

	●保安
証明書:certificate::~

	●仕様
critical:
製品:product:~
捕捉-:capture:~
指名-:designate:~
専門家:expert:~
合意-:agree:~
雛形:template::~::テンプレート
表記上の:notationalな:~
ナシ:none:なし
extra:::追加
見出そう:findしよう:~
収容-:accommodate:~
提示-:present:~

	助けに:help
	在った方が良い:appreciated
	不足なく:sufficiently
	きちんと:well
	~debug用の／~debug法／~debugすること:debugging
	ますます:increasingly
	突如:suddenly
	認識されない:unrecognised
	在った方が良い:appreciated
	不足なく:sufficiently
	~~相応に:correspondingly
	に利するため:behalf
	助けに:help
	されたものとは限らない:may or may not
	ときもある:sometimes
	得る／にもなり得る:potentially
	伴う:bearing
	在るならば:the presence of
	する限りにおいて:provided that
	（複数可）:(s)
	よって:As a result,
	注記:note
	原因になった:cause
	^en:health check

	●言い換え
	総称として:indicate both
	~~相応に:correspondingly
	同じ値をとる:shares the same value
	事由~句:status phrase

	有構造~data型:the Structured Type
	大容量な流通:high traffic volume
	専門家により考査され:by Expert Review
	転送~符号法:Transfer-Coding
	転送~符号法:Transfer Coding
	内容~符号法:Content-Coding
	内容~符号法:Content Coding
	~registry:Registry
	状態s~code:HTTP status code
	~size:how large
	この~error種別:this entry
	~TLS~alert~registry:"TLS Alerts" registry
	~HTTP内容~符号法~registry:"HTTP Content Coding Registry"
	~HTTP転送~符号法~registry:"HTTP Transfer Coding Registry"
	~HTTP~field名~registry:"Hypertext Transfer Protocol (HTTP) Field Name Registry"
	~HTTP Proxy-Status ~parameter~registry:"HTTP Proxy-Status Parameters" registry
	~HTTP~proxy~error種別~registry:"HTTP Proxy Error Types" registry
	~TLS~ALPN~protocol~ID~registry:TLS ALPN Protocol ID
	拡張された~DNS~error~code:Extended DNS Error Code

	●他
	一群の:set of
	へ向かう:leading to
	-:its entirety
	多くの:much
	最も近い:closest
	それ以降:afterwards
	長過ぎる:too large
	-:leftmost

●●ref_normative

[HTTP]
    Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., ＜HTTP Semantics＞, STD 97, ~RFC9110, June 2022
[RFC2119]
    Bradner, S., ＜Key words for use in RFCs to Indicate Requirement Levels＞, BCP 14, ~RFC2119, March 1997
[RFC7301]
    Friedl, S., Popov, A., Langley, A., and E. Stephan, ＜Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension＞, ~RFC7301, July 2014.
[RFC8126]
    Cotton, M., Leiba, B., and T. Narten, ＜Guidelines for Writing an IANA Considerations Section in RFCs＞, BCP 26, ~RFC8126, June 2017
[RFC8174]
    Leiba, B., ＜Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words＞, BCP 14, ~RFC8174, May 2017
[RFC8499]
    Hoffman, P., Sullivan, A., and K. Fujiwara, ＜DNS Terminology＞, BCP 219, ~RFC8499, January 2019
[RFC8914]
    Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D. Lawrence, ＜Extended DNS Errors＞, ~RFC8914, October 2020
[STRUCTURED-FIELDS]
    Nottingham, M. and P-H. Kamp, ＜Structured Field Values for HTTP＞, ~RFC8941, February 2021
[TLS]
    Rescorla, E., ＜The Transport Layer Security (TLS) Protocol Version 1.3＞, ~RFC8446, August 2018

●●ref_informative

[RFC8586]
    Ludin, S., Nottingham, M., and N. Sullivan, ＜Loop Detection in Content Delivery Networks (CDNs)＞, ~RFC8586, April 2019


●●trans_metadata
<p>
~THIS_PAGEは、
~IETF により PROPOSED STANDARD として公表された，
RFC 9209
<a href="~SPEC_URL">The Proxy-Status HTTP Response Header Field</a>
を日本語に翻訳したものです。
~PUB
</p>

●●spec_metadata
公表者
	Internet Engineering Task Force (IETF)
RFC
	9209
分類
	Standards Track
日付
	2022 年 6 月
編集
	M. Nottingham (Fastly)
	P. Sikora (Google)
履歴
	https://datatracker.ietf.org/doc/rfc9209/
現在の位置付け, 正誤表, フィードバックの方法
	https://www.rfc-editor.org/info/rfc9209
著作者のアドレス
	Mark Nottingham, Prahran Australia, EMail: mnot@mnot.net, URI: https://www.mnot.net/

</script>
</head><body>

<header>
	<hgroup>
<h1>Proxy-Status HTTP 応答フィールド</h1>
<p>RFC 9209 — The Proxy-Status HTTP Response Header Field</p>
	</hgroup>
</header>

<div id="MAIN" hidden>
	<section id="rfc.abstract">
◎要約

<p>
この文書は、
`媒介者$による応答の取扱いを成す詳細を
— `生成-$された~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.
</p>

	</section>
	<section id="rfc.status">
<h2 title="Status of This Memo">このメモの位置付け</h2>

<p class="trans-note">【
この節の内容は
`~IETF日本語訳 共通~page＠~IETFcommon#status$に移譲。
】</p>

	</section>
	<section id="rfc.copyrightnotice">
<h2 title="Copyright Notice">著作権の告知</h2>

<p lang="en">
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
</p>

<p class="trans-note">【
以下、この節の他の内容は
`~IETF日本語訳 共通~page＠~IETFcommon#copyright-notice$に移譲。
】</p>

	</section>

<main id="MAIN0">

	<section id="introduction">
<h2 title="Introduction">1. 序論</h2>

<p>
`媒介者$【！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.
</p>

<p>
`媒介者$は、
概して，`生成元~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.
</p>

<p>
~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.
</p>

<p>
これらの利用を可能化するため、
`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.
</p>

		<section id="notational-conventions">
<h3 title="Notational Conventions">1.1. 表記上の規約</h3>

<p>
この文書~内の~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.
</p>

<p>
この文書は、
次に挙げる`各種~有構造~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.
</p>

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

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

<p class="trans-note">【
すなわち、
`内方$にある次の`~server$。
この訳では、
この用語は利用せず，直に “内方にある次の~server” と記すことにする。
】</p>

		</section>
	</section>
	<section id="header">
<h2 title="The Proxy-Status HTTP Field">2. `Proxy-Status^h ~HTTP~field</h2>

<p>
`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.
</p>

<p>
その値は、
`~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.
</p>

<div class="example">
<p>
例えば、
次のものは：
◎
For example:
</p>

<pre class="lang-http">
Proxy-Status: revproxy1.example.net, ExampleCDN
</pre>

<p>
まず `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.
</p>
</div>

<p>
応答に `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.
</p>

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

<p>
（† ~softwareや~hardwareの製品~名は，~service名として適切でない
— 例：
"`ExampleCDN^c" は適切であるが、
"`ExampleProxy^c" は配備を識別しないので，適切でない。）
</p>
◎
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.
</div>

<p>
各~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).
</p>

<p>
当の要請を取扱っている`媒介者$たちが成す連鎖~全体に対し，~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).
</p>

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

<p>
`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.
</p>

<p>
［
`~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.
</p>

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

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

<pre class="lang-http">
Proxy-Status: SomeOtherProxy
</pre>

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

<pre class="lang-http">
Proxy-Status: SomeOtherProxy, ThisProxy
</pre>

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

<pre class="lang-http">
Proxy-Status: ThisProxy; error=read_timeout
</pre>

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

<div class="algo">
<p>
`~client$は、
次の手続きにより，
`Proxy-Status^h `~trailer$を`~header$に格上げしてもヨイ：
</p>
<ol>
	<li>
%~trailer値 ~LET `Proxy-Status^h `~trailer$の`~field値$を表現している有構造~data
`STRUCTURED-FIELDS$r
</li>
	<li>
%~header値 ~LET `Proxy-Status^h `~header$の`~field値$を表現している有構造~data
`STRUCTURED-FIELDS$r
</li>
	<li>
~Assert：
%~trailer値, %~header値 は、
いずれも`~sf~list$である
</li>
	<li>
<p>
%~trailer値 を成す
~EACH( %~trailer~member )
に対し：
</p>
		<ol>
			<li>
~Assert：
%~trailer~member の値は［
`~sf文字列$／`~sf~token$
］である
</li>
			<li>
<p>
%~header値 を成す
~EACH( %~header~member )
に対し：
</p>
				<ol>
					<li>
~Assert：
%~header~member の値は［
`~sf文字列$／`~sf~token$
］である
</li>
					<li>
<p>
~IF［
%~header~member の値を成す文字列 ~NEQ %~trailer~member の値を成す文字列
］
⇒
~CONTINUE
</p>

<p>
この比較においては
⇒＃
`~sf文字列$, `~sf~token$は，いずれも文字列と見なす（型の相違は無視する）。
~parameter群は無視する。
</p>
					</li>
					<li>
%~header値 内で %~header~member を %~trailer~member で置換する
— ~parameter群も含めて
</li>
					<li>
%~trailer値 から %~trailer~member を除去する
</li>
					<li>
~BREAK
</li>
				</ol>
			</li>
		</ol>
	</li>
	<li>
~IF［
%~trailer値 は空である
］
⇒
`~trailer節$から `Proxy-Status^h `~trailer$を除去する
</li>
</ol>

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

◎
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.
</div>

		<section id="params">
<h3 title="Proxy-Status Parameters">2.1. `Proxy-Status^h 用の~parameter</h3>

<p>
この節は、
`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.
</p>

			<section id="error">
<h4 title="error">2.1.1. `error^c</h4>

<p>
`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.
</p>

<p>
一部の`~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.
</p>

<p>
他の`~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.
</p>

<p>
`~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.
</p>

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

<p>
この文書にて定義される`~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.
</p>

<div class="example">
<p>
例えば、
次は：
◎
For example:
</p>

<pre class="lang-http">
HTTP/1.1 504 Gateway Timeout
Proxy-Status: ExampleCDN; error=connection_timeout
</pre>

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

<p>
あるいは次は：
◎
Or:
</p>

<pre class="lang-http">
HTTP/1.1 429 Too Many Requests
Proxy-Status: r34.example.net; error=http_request_error, ExampleCDN
</pre>

<p>
この `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.
</p>
</div>

<p>
`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).
</p>

<p>
各`~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.
</p>

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

<p>
各`~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.
</p>

			</section>
			<section id="next-hop">
<h4 title="next-hop">2.1.2. `next-hop^c</h4>

<p>
`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.
</p>

<div class="example">
<p>
例えば：
◎
For example:
</p>

<pre class="lang-http">
Proxy-Status: cdn.example.org; next-hop=backend.example.org:8001
</pre>

<p>
`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.
</p>
</div>

			</section>
			<section id="next-protocol">
<h4 title="next-protocol">2.1.3. `next-protocol^c</h4>

<p>
`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.
</p>

<p>
値は、
~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 &lt;https://www.iana.org/assignments/tls-extensiontype-values#alpn-protocol-ids&gt;). If the protocol identifier is able to be expressed as a Token using ASCII encoding, that form MUST be used.
</p>

<div class="example">
<p>
例えば：
◎
For example:
</p>

<pre class="lang-http">
Proxy-Status: "proxy.example.org"; next-protocol=h2
</pre>

<p>
ここで利用された~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.
</p>
</div>

			</section>
			<section id="received-status">
<h4 title="received-status">2.1.4. `received-status^c</h4>

<p>
`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.
</p>

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

<div class="example">
<p>
例えば：
◎
For example:
</p>

<pre class="lang-http">
Proxy-Status: ExampleCDN; received-status=200
</pre>
</div>

			</section>
			<section id="details">
<h4 title="details">2.1.5. `details^c</h4>

<p>
`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.
</p>

<div class="example">
<p>
例えば：
◎
For example:
</p>

<pre class="lang-http">
Proxy-Status: proxy.example.net; error="http_protocol_error";
              details="Malformed response header: space before colon"
</pre>
</div>

			</section>
		</section>
		<section id="register-param">
<h3 title="Defining New Proxy-Status Parameters">2.2. `Proxy-Status^h 用の新たな~parameterの定義-法</h3>

<p>
新たな `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.
</p>

<p>
登録~要請は、
`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.
</p>

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

<ul>
	<li>
~communityからの~feedback。
◎
Community feedback
</li>
	<li>
当の【~parameterの】値は、
不足なく きちんと定義されたかどうか。
◎
If the value is sufficiently well defined
</li>
	<li>
~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).
</li>
	<li>
~parameterの名前は、
`~HTTP~proxy~error種別~registry^cite
内に登録された`~extra~parameter$と競合するべきでない。
◎
Parameter names should not conflict with registered extra parameters in the "HTTP Proxy Error Types" registry.
</li>
</ul>

<p>
`Proxy-Status$h ~parameterの登録~要請は、
次の雛形を利用するべきである：
◎
Registration requests should use the following template:
</p>
<ul>
	<li>
名前
⇒
`~sf~key$に合致する，当の~parameterの名前。
◎
Name:
• [a name for the Proxy-Status parameter that matches key]
</li>
	<li>
記述
⇒
当の~parameterの意味論と値を成す記述。
◎
Description:
• [a description of the parameter semantics and value]
</li>
	<li>
参照
⇒
当の~parameterを定義している仕様
— 省略可能。
◎
Reference:
• [to a specification defining this parameter; optional]
</li>
</ul>

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

		</section>
		<section id="error-types">
<h3 title="Proxy Error Types">2.3. ~proxy~error種別</h3>

<p>
この節では、
この文書により定義される`~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.
</p>

<p>
実装は、
あらゆる`~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.
</p>

			<section id="dns-timeout">
<h4 title="DNS Timeout">2.3.1. ~DNS時間切れ</h4>

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

			</section>
			<section id="dns-error">
<h4 title="DNS Error">2.3.2. ~DNS~error</h4>

<ul>
	<li>
名前
⇒
`dns_error^c
◎
Name:
• dns_error
</li>
	<li>
記述
⇒
`媒介者$は、
`内方$にある次の`~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.
</li>
	<li>
<p>
`~extra~parameter$
⇒
◎
Extra Parameters:
</p>
		<ul>
			<li>
`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.
</li>
	<li>
`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].
</li>
		</ul>
	</li>
	<li>
`推奨される~HTTP状態s~code$
⇒
`502$st0
◎
Recommended HTTP Status Code:
• 502
</li>
	<li>
`媒介者が生成した応答に限られるか$
⇒
~T
◎
Response Only Generated by Intermediaries:
• true
</li>
	<li>
参照
⇒
~RFC 9209
◎
Reference:
• RFC 9209
</li>
</ul>

			</section>
			<section id="destination-not-found">
<h4 title="Destination Not Found">2.3.3. 行先を見出せない</h4>

<ul>
	<li>
名前
⇒
`destination_not_found^c
◎
Name:
• destination_not_found
</li>
	<li>
記述
⇒
`媒介者$は、
当の要請~用に利用する適切な`内方$にある次の`~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.
</li>
	<li>
`~extra~parameter$
⇒
ナシ
◎
Extra Parameters:
• None
</li>
	<li>
`推奨される~HTTP状態s~code$
⇒
`500$st0
◎
Recommended HTTP Status Code:
• 500
</li>
	<li>
`媒介者が生成した応答に限られるか$
⇒
~T
◎
Response Only Generated by Intermediaries:
• true
</li>
	<li>
参照
⇒
~RFC 9209
◎
Reference:
• RFC 9209
</li>
</ul>

			</section>
			<section id="destination-unavailable">
<h4 title="Destination Unavailable">2.3.4. 行先は可用でない</h4>

<ul>
	<li>
名前
⇒
`destination_unavailable^c
◎
Name:
• destination_unavailable
</li>
	<li>
記述
⇒
`媒介者$は、
`内方$にある次の`~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.
</li>
	<li>
`~extra~parameter$
⇒
ナシ
◎
Extra Parameters:
• None
</li>
	<li>
`推奨される~HTTP状態s~code$
⇒
`503$st0
◎
Recommended HTTP Status Code:
• 503
</li>
	<li>
`媒介者が生成した応答に限られるか$
⇒
~T
◎
Response Only Generated by Intermediaries:
• true
</li>
	<li>
参照
⇒
~RFC 9209
◎
Reference:
• RFC 9209
</li>
</ul>

			</section>
			<section id="destination-ip-prohibited">
<h4 title="Destination IP Prohibited">2.3.5. 行先~IPは禁制されている</h4>

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

			</section>
			<section id="destination-ip-unroutable">
<h4 title="Destination IP Unroutable">2.3.6. 行先~IPへ~route不能</h4>

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

			</section>
			<section id="connection-refused">
<h4 title="Connection Refused">2.3.7. 接続は拒否された</h4>

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

			</section>
			<section id="connection-terminated">
<h4 title="Connection Terminated">2.3.8. 接続は終了された</h4>

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

			</section>
			<section id="connection-timeout">
<h4 title="Connection Timeout">2.3.9. 接続~時間切れ</h4>

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

			</section>
			<section id="connection-read-timeout">
<h4 title="Connection Read Timeout">2.3.10. 接続~読取n時間切れ</h4>

<ul>
	<li>
名前
⇒
`connection_read_timeout^c
◎
Name:
• connection_read_timeout
</li>
	<li>
記述
⇒
`媒介者$は、
接続~上に~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.
</li>
	<li>
`~extra~parameter$
⇒
ナシ
◎
Extra Parameters:
• None
</li>
	<li>
`推奨される~HTTP状態s~code$
⇒
`504$st0
◎
Recommended HTTP Status Code:
• 504
</li>
	<li>
`媒介者が生成した応答に限られるか$
⇒
~F
◎
Response Only Generated by Intermediaries:
• false
</li>
	<li>
参照
⇒
~RFC 9209
◎
Reference:
• RFC 9209
</li>
</ul>

			</section>
			<section id="connection-write-timeout">
<h4 title="Connection Write Timeout">2.3.11. 接続~書込n時間切れ</h4>

<ul>
	<li>
名前
⇒
`connection_write_timeout^c
◎
Name:
• connection_write_timeout
</li>
	<li>
記述
⇒
`媒介者$は、
接続に~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).
</li>
	<li>
`~extra~parameter$
⇒
ナシ
◎
Extra Parameters:
• None
</li>
	<li>
`推奨される~HTTP状態s~code$
⇒
`504$st0
◎
Recommended HTTP Status Code:
• 504
</li>
	<li>
`媒介者が生成した応答に限られるか$
⇒
~F
◎
Response Only Generated by Intermediaries:
• false
</li>
	<li>
参照
⇒
~RFC 9209
◎
Reference:
• RFC 9209
</li>
</ul>

			</section>
			<section id="connection-limit-reached">
<h4 title="Connection Limit Reached">2.3.12. 接続~制限-に到達した</h4>

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

			</section>
			<section id="tls-protocol-error">
<h4 title="TLS Protocol Error">2.3.13. ~TLS~protocol~error</h4>

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

			</section>
			<section id="tls-certificate-error">
<h4 title="TLS Certificate Error">2.3.14. ~TLS証明書~error</h4>

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

			</section>
			<section id="tls-alert-received">
<h4 title="TLS Alert Received">2.3.15. ~TLS~alertを受信した</h4>

<ul>
	<li>
名前
⇒
`tls_alert_received^c
◎
Name:
• tls_alert_received
</li>
	<li>
記述
⇒
`媒介者$は、
`内方$にある次の`~server$から~TLS~alertを受信した。
◎
Description:
• The intermediary received a TLS alert from the next hop.
</li>
	<li>
<p>
`~extra~parameter$：
◎
Extra Parameters:
</p>
		<ul>
			<li>
`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].
</li>
	<li>
`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].
</li>
		</ul>
	</li>
	<li>
`推奨される~HTTP状態s~code$
⇒
`502$st0
◎
Recommended HTTP Status Code:
• 502
</li>
	<li>
`媒介者が生成した応答に限られるか$
⇒
~F
◎
Response Only Generated by Intermediaries:
• false
</li>
	<li>
参照
⇒
~RFC 9209
◎
Reference:
• RFC 9209
</li>
</ul>

			</section>
			<section id="http-request-error">
<h4 title="HTTP Request Error">2.3.16. ~HTTP要請~error</h4>

<ul>
	<li>
名前
⇒
`http_request_error^c
◎
Name:
• http_request_error
</li>
	<li>
記述
⇒
`媒介者$は、
生成元~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.
</li>
	<li>
<p>
`~extra~parameter$：
◎
Extra Parameters:
</p>
		<ul>
			<li>
`status-code^c
⇒
次を包含している`~sf整数$
⇒
生成した状態s~code
◎
status-code:
• An Integer containing the generated status code.
</li>
	<li>
`status-phrase^c
⇒
次を包含している`~sf文字列$
⇒
生成した`事由~句$
◎
status-phrase:
• A String containing the generated status phrase.
</li>
		</ul>
	</li>
	<li>
`推奨される~HTTP状態s~code$
⇒
適用-可能な `4xx$st0 状態s~code
◎
Recommended HTTP Status Code:
• The applicable 4xx status code
</li>
	<li>
`媒介者が生成した応答に限られるか$
⇒
~T
◎
Response Only Generated by Intermediaries:
• true
</li>
	<li>
参照
⇒
~RFC 9209
◎
Reference:
• RFC 9209
</li>
	<li>
注記
⇒
この種別は、
`媒介者$が`生成-$した応答を`生成元~server$により`生成-$されたものと判別する助けになる。
◎
Notes:
• This type helps distinguish between responses generated by intermediaries from those generated by the origin.
</li>
</ul>

			</section>
			<section id="http-request-denied">
<h4 title="HTTP Request Denied">2.3.17. ~HTTP要請は否認された</h4>

<ul>
	<li>
名前
⇒
`http_request_denied^c
◎
Name:
• http_request_denied
</li>
	<li>
記述
⇒
`媒介者$は、
自身の［
環境設定／施策~設定群
］に基づいて，当の~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.
</li>
	<li>
`~extra~parameter$
⇒
ナシ
◎
Extra Parameters:
• None
</li>
	<li>
`推奨される~HTTP状態s~code$
⇒
`403$st0
◎
Recommended HTTP Status Code:
• 403
</li>
	<li>
`媒介者が生成した応答に限られるか$
⇒
~T
◎
Response Only Generated by Intermediaries:
• true
</li>
	<li>
参照
⇒
~RFC 9209
◎
Reference:
• RFC 9209
</li>
</ul>

			</section>
			<section id="http-incomplete-response">
<h4 title="HTTP Incomplete Response">2.3.18. ~HTTP不完全な応答</h4>

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

			</section>
			<section id="http-response-header-section-too-large">
<h4 title="HTTP Response Header Section Too Large">2.3.19. ~HTTP応答の~header節が長過ぎる</h4>

<ul>
	<li>
名前
⇒
`http_response_header_section_size^c
◎
Name:
• http_response_header_section_size
</li>
	<li>
記述
⇒
`媒介者$は、［
要請に対し受信した応答の`~header節$
］が長過ぎると見なした。
◎
Description:
• The intermediary received a response to the request whose header section was considered too large.
</li>
	<li>
<p>
`~extra~parameter$：
◎
Extra Parameters:
</p>
		<ul>
			<li>
<p>
`header-section-size^c
⇒
次を指示している`~sf整数$
⇒
受信した`~header節$の~size
</p>

<p>
そのような~header節は、
完全でないかもしれないことに注意
— すなわち，当の`媒介者$は、
追加的な【超過した】~dataを［
破棄する／拒否する
］こともある。
</p>
◎
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.
</li>
		</ul>
	</li>
	<li>
`推奨される~HTTP状態s~code$
⇒
`502$st0
◎
Recommended HTTP Status Code:
• 502
</li>
	<li>
`媒介者が生成した応答に限られるか$
⇒
~F
◎
Response Only Generated by Intermediaries:
• false
</li>
	<li>
参照
⇒
~RFC 9209
◎
Reference:
• RFC 9209
</li>
</ul>

			</section>
			<section id="http-response-header-field-line-too-large">
<h4 title="HTTP Response Header Field Line Too Large">2.3.20. ~HTTP応答~headerの~field行lが長過ぎる</h4>

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

			</section>
			<section id="http-response-body-too-large">
<h4 title="HTTP Response Body Too Large">2.3.21. ~HTTP応答の本体が長過ぎる</h4>

<ul>
	<li>
名前
⇒
`http_response_body_size^c
◎
Name:
• http_response_body_size
</li>
	<li>
記述
⇒
`媒介者$は、［
当の要請に対し受信した応答の本体【`内容$】
］が長過ぎると見なした。
◎
Description:
• The intermediary received a response to the request whose body was considered too large.
</li>
	<li>
<p>
`~extra~parameter$：
◎
Extra Parameters:
</p>
		<ul>
			<li>
<p>
`body-size^c
⇒
次を指示している`~sf整数$
⇒
受信した本体の~size
</p>

<p>
そのような本体は、
完全でないかもしれないことに注意
— すなわち，当の`媒介者$は、
追加的な【超過した】~dataを［
破棄する／拒否する
］こともある。
</p>
◎
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.
</li>
		</ul>
	</li>
	<li>
`推奨される~HTTP状態s~code$
⇒
`502$st0
◎
Recommended HTTP Status Code:
• 502
</li>
	<li>
`媒介者が生成した応答に限られるか$
⇒
~F
◎
Response Only Generated by Intermediaries:
• false
</li>
	<li>
参照
⇒
~RFC 9209
◎
Reference:
• RFC 9209
</li>
</ul>

			</section>
			<section id="http-response-trailer-section-too-large">
<h4 title="HTTP Response Trailer Section Too Large">2.3.22. ~HTTP応答の~trailer節が長過ぎる</h4>

<ul>
	<li>
名前
⇒
`http_response_trailer_section_size^c
◎
Name:
• http_response_trailer_section_size
</li>
	<li>
記述
⇒
`媒介者$は、［
当の要請に対し受信した応答の`~trailer節$
］が長過ぎると見なした。
◎
Description:
• The intermediary received a response to the request whose trailer section was considered too large.
</li>
	<li>
<p>
`~extra~parameter$：
◎
Extra Parameters:
</p>
		<ul>
			<li>
<p>
`trailer-section-size^c
⇒
次を指示している`~sf整数$
⇒
受信した`~trailer節$の~size
</p>

<p>
そのような~trailer節は、
完全でないかもしれないことに注意
— すなわち，当の`媒介者$は、
追加的な【超過した】~dataを［
破棄する／拒否する
］こともある。
</p>
◎
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.
</li>
		</ul>
	</li>
	<li>
`推奨される~HTTP状態s~code$
⇒
`502$st0
◎
Recommended HTTP Status Code:
• 502
</li>
	<li>
`媒介者が生成した応答に限られるか$
⇒
~F
◎
Response Only Generated by Intermediaries:
• false
</li>
	<li>
参照
⇒
~RFC 9209
◎
Reference:
• RFC 9209
</li>
</ul>

			</section>
			<section id="http-response-trailer-field-line-too-large">
<h4 title="HTTP Response Trailer Field Line Too Large">2.3.23. ~HTTP応答~trailerの~field行lが長過ぎる</h4>

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

			</section>
			<section id="http-response-transfer-coding-error">
<h4 title="HTTP Response Transfer-Coding Error">2.3.24. ~HTTP応答の転送~符号法~error</h4>

<ul>
	<li>
名前
⇒
`http_response_transfer_coding^c
◎
Name:
• http_response_transfer_coding
</li>
	<li>
記述
⇒
`媒介者$は、
当の応答の`転送~符号法$を復号するとき，
~errorに遭遇した。
◎
Description:
• The intermediary encountered an error decoding the transfer coding of the response.
</li>
	<li>
<p>
`~extra~parameter$：
◎
Extra Parameters:
</p>
		<ul>
			<li>
`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.
</li>
		</ul>
	</li>
	<li>
`推奨される~HTTP状態s~code$
⇒
`502$st0
◎
Recommended HTTP Status Code:
• 502
</li>
	<li>
`媒介者が生成した応答に限られるか$
⇒
~F
◎
Response Only Generated by Intermediaries:
• false
</li>
	<li>
参照
⇒
~RFC 9209
◎
Reference:
• RFC 9209
</li>
</ul>

			</section>
			<section id="http-response-content-coding-error">
<h4 title="HTTP Response Content-Coding Error">2.3.25. ~HTTP応答の内容~符号法~error</h4>

<ul>
	<li>
名前
⇒
`http_response_content_coding^c
◎
Name:
• http_response_content_coding
</li>
	<li>
記述
⇒
`媒介者$は、
当の応答の`内容~符号法$を復号するとき，
~errorに遭遇した。
◎
Description:
• The intermediary encountered an error decoding the content coding of the response.
</li>
	<li>
<p>
`~extra~parameter$：
◎
Extra Parameters:
</p>
		<ul>
			<li>
`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.
</li>
		</ul>
	</li>
	<li>
`推奨される~HTTP状態s~code$
⇒
`502$st0
◎
Recommended HTTP Status Code:
• 502
</li>
	<li>
`媒介者が生成した応答に限られるか$
⇒
~F
◎
Response Only Generated by Intermediaries:
• false
</li>
	<li>
参照
⇒
~RFC 9209
◎
Reference:
• RFC 9209
</li>
</ul>

			</section>
			<section id="http-response-timeout">
<h4 title="HTTP Response Timeout">2.3.26. ~HTTP応答~時間切れ</h4>

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

			</section>
			<section id="http-upgrade-failed">
<h4 title="HTTP Upgrade Failed">2.3.27. ~HTTP~version昇格に失敗した</h4>

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

<p class="trans-note">【†
おそらく， `Upgrade§h `HTTP$r を指す。
字義どおり解釈するなら、
~HTTP以外の~protocolへの昇格は該当しないことになるが，
はっきりしない
（ “~HTTPの`ある~versionから何か^emへの昇格” かも？）。
】</p>

	</li>
	<li>
`~extra~parameter$
⇒
ナシ
◎
Extra Parameters:
• None
</li>
	<li>
`推奨される~HTTP状態s~code$
⇒
`502$st0
◎
Recommended HTTP Status Code:
• 502
</li>
	<li>
`媒介者が生成した応答に限られるか$
⇒
~T
◎
Response Only Generated by Intermediaries:
• true
</li>
	<li>
参照
⇒
~RFC 9209
◎
Reference:
• RFC 9209
</li>
</ul>

			</section>
			<section id="http-protocol-error">
<h4 title="HTTP Protocol Error">2.3.28. ~HTTP~protocol~error</h4>

<ul>
	<li>
名前
⇒
`http_protocol_error^c
◎
Name:
• http_protocol_error
</li>
	<li>
記述
⇒
`媒介者$は、
`内方$にある次の`~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.
</li>
	<li>
`~extra~parameter$
⇒
ナシ
◎
Extra Parameters:
• None
</li>
	<li>
`推奨される~HTTP状態s~code$
⇒
`502$st0
◎
Recommended HTTP Status Code:
• 502
</li>
	<li>
`媒介者が生成した応答に限られるか$
⇒
~F
◎
Response Only Generated by Intermediaries:
• false
</li>
	<li>
参照
⇒
~RFC 9209
◎
Reference:
• RFC 9209
</li>
</ul>

			</section>
			<section id="proxy-internal-response">
<h4 title="Proxy Internal Response">2.3.29. ~proxy内部~応答</h4>

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

			</section>
			<section id="proxy-internal-error">
<h4 title="Proxy Internal Error">2.3.30. ~proxy内部~error</h4>

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

			</section>
			<section id="proxy-configuration-error">
<h4 title="Proxy Configuration Error">2.3.31. ~proxy環境設定~error</h4>

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

			</section>
			<section id="proxy-loop-detected">
<h4 title="Proxy Loop Detected">2.3.32. ~proxy~loopが検出された</h4>

<ul>
	<li>
名前
⇒
`proxy_loop_detected^c
◎
Name:
• proxy_loop_detected
</li>
	<li>
記述
⇒
`媒介者$は、
当の要請を自身へ回送しようと試行したか，
異なる手段を利用して~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]).
</li>
	<li>
`~extra~parameter$
⇒
ナシ
◎
Extra Parameters:
• None
</li>
	<li>
`推奨される~HTTP状態s~code$
⇒
`502$st0
◎
Recommended HTTP Status Code:
• 502
</li>
	<li>
`媒介者が生成した応答に限られるか$
⇒
~T
◎
Response Only Generated by Intermediaries:
• true
</li>
	<li>
参照
⇒
~RFC 9209
◎
Reference:
• RFC 9209
</li>
</ul>

			</section>
		</section>
		<section id="register-error">
<h3 title="Defining New Proxy Error Types">2.4. 新たな~proxy~error種別の定義-法</h3>

<p>
新たな`~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.
</p>

<p>
登録~要請は、
`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.
</p>

<p>
専門家（たち）は、
登録~要請を評価する際に，次に挙げる要因を考慮するべきである：
◎
The expert(s) should consider the following factors when evaluating requests:
</p>
<ul>
	<li>
~communityからの~feedback
◎
Community feedback
</li>
	<li>
当の【~parameterの】値は、
不足なく きちんと定義されたかどうか
◎
If the value is sufficiently well-defined
</li>
	<li>
種別を与える~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).
</li>
	<li>
`~extra~parameter$【の名前】は、
登録-済みな `Proxy-Status^h `~parameter＠#register-param$と競合するべきでない。
◎
Extra parameters should not conflict with registered Proxy-Status parameters.
</li>
</ul>

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

<p>
`~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'.
</p>

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

		</section>
	</section>
	<section id="iana-considerations">
<h2 title="IANA Considerations">3. ~IANA考慮点</h2>

<p>
~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 &lt;https://www.iana.org/assignments/http-proxy-status&gt; 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.
</p>

<p>
加えて、
`~HTTP~field名~registry$cite に，次の~entryを追加した：
◎
Additionally, the following entry has been added to the "Hypertext Transfer Protocol (HTTP) Field Name Registry":
</p>
<ul>
	<li>
~field名
⇒
`Proxy-Status^h
◎
Field name:
• Proxy-Status
</li>
	<li>
位置付け
⇒
恒久的
◎
Status:
• permanent
</li>
	<li>
仕様~文書
⇒
~RFC 9209
◎
Specification document(s):
• RFC 9209
◎
Comments:
</li>
</ul>

	</section>
	<section id="security">
<h2 title="Security Considerations">4. ~securityの考慮点</h2>

<p>
`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.
</p>

<p>
よって、［
`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).
</p>

<p>
同様に、
どの~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.
</p>

	</section>
</main></div>