5.1. Forwarded By

5.1. Forwarded By

The "by" parameter is used to disclose the interface where the request came in to the proxy server. When proxies choose to use the "by" parameter, its default configuration SHOULD contain an obfuscated identifier as described in Section 6.3. If the server receiving proxied requests requires some address-based functionality, this parameter MAY instead contain an IP address (and, potentially, a port number). A third option is the "unknown" identifier described in Section 6.2.

"by"パラメーターは、リクエストがプロキシサーバーに入ってきたインターフェースを開示するために使用されます。プロキシが"by"パラメーターを使用することを選択した場合、そのデフォルトの設定は、セクション6.3で説明されているような難読化された識別子を含むべきです（SHOULD）。プロキシ化されたリクエストを受信するサーバーが何らかのアドレスベースの機能を必要とする場合、このパラメーターは代わりにIPアドレス（および可能性としてはポート番号）を含む場合があります（MAY）。3つ目のオプションは、セクション6.2で説明されている"unknown"識別子です。

The syntax of a "by" value, after potential quoted-string unescaping, conforms to the "node" ABNF described in Section 6.

潜在的なquoted-stringのアンエスケープ後の"by"値の構文は、セクション6で説明されている"node"のABNFに準拠します。

This is primarily added by reverse proxies that wish to forward this information to the backend server. It can also be interesting in a multihomed environment to signal to backend servers from which the request came.

これは主に、この情報をバックエンドサーバーに転送したいリバースプロキシによって追加されます。また、マルチホーム環境では、どのリクエストが来たかをバックエンドサーバーに通知するのにも有用です。

5.2. Forwarded For

5.2. Forwarded For

The "for" parameter is used to disclose information about the client that initiated the request and subsequent proxies in a chain of proxies. When proxies choose to use the "for" parameter, its default configuration SHOULD contain an obfuscated identifier as described in Section 6.3. If the server receiving proxied requests requires some address-based functionality, this parameter MAY instead contain an IP address (and, potentially, a port number). A third option is the "unknown" identifier described in Section 6.2.

"for"パラメーターは、リクエストを開始したクライアントとプロキシチェーン内の後続のプロキシに関する情報を開示するために使用されます。プロキシが"for"パラメーターを使用することを選択した場合、そのデフォルトの設定は、セクション6.3で説明されているような難読化された識別子を含むべきです（SHOULD）。プロキシ化されたリクエストを受信するサーバーが何らかのアドレスベースの機能を必要とする場合、このパラメーターは代わりにIPアドレス（および可能性としてはポート番号）を含む場合があります（MAY）。3つ目のオプションは、セクション6.2で説明されている"unknown"識別子です。

The syntax of a "for" value, after potential quoted-string unescaping, conforms to the "node" ABNF described in Section 6.

潜在的なquoted-stringのアンエスケープ後の"for"値の構文は、セクション6で説明されている"node"のABNFに準拠します。

In a chain of proxy servers where this is fully utilized, the first "for" parameter will disclose the client where the request was first made, followed by any subsequent proxy identifiers. The last proxy in the chain is not part of the list of "for" parameters. The last proxy's IP address, and optionally a port number, are, however, readily available as the remote IP address at the transport layer. It can, however, be more relevant to read information about the last proxy from preceding "Forwarded" header field's "by" parameter, if present.

これが完全に利用されているプロキシサーバーのチェーンでは、最初の"for"パラメーターは、リクエストが最初に行われたクライアントを開示し、その後に続く任意のプロキシ識別子を続けます。チェーン内の最後のプロキシは"for"パラメーターのリストの一部ではありません。ただし、最後のプロキシのIPアドレスと、オプションでポート番号は、トランスポート層のリモートIPアドレスとして容易に利用できます。ただし、存在する場合、先行する"Forwarded"ヘッダーフィールドの"by"パラメーターから最後のプロキシに関する情報を読み取る方が関連性があります。

5.3. Forwarded Host

5.3. Forwarded Host

The "host" parameter is used to forward the original value of the "Host" header field. This can be used, for example, by the origin server if a reverse proxy is rewriting the "Host" header field to some internal host name.

"host"パラメーターは、元の"Host"ヘッダーフィールドの値を転送するために使用されます。これは、例えば、リバースプロキシが"Host"ヘッダーフィールドを何らかの内部ホスト名に書き換えている場合、オリジンサーバーによって使用することができます。

The syntax for a "host" value, after potential quoted-string unescaping, MUST conform to the Host ABNF described in Section 5.4 of [RFC7230].

潜在的なquoted-stringのアンエスケープ後の"host"値の構文は、[RFC7230]のSection 5.4で説明されているHost ABNFに準拠しなければなりません（MUST）。

5.4. Forwarded Proto

5.4. Forwarded Proto

The "proto" parameter has the value of the used protocol type. The syntax of a "proto" value, after potential quoted-string unescaping, MUST conform to the URI scheme name as defined in Section 3.1 in [RFC3986] and registered with IANA according to [RFC4395]. Typical values are "http" or "https".

"proto"パラメーターは、使用されたプロトコルタイプの値を持ちます。潜在的なquoted-stringのアンエスケープ後の"proto"値の構文は、[RFC3986]のセクション3.1で定義されているURIスキーム名に準拠しなければなりません（MUST）。そして、[RFC4395]に従ってIANAに登録されます。典型的な値は"http"または"https"です。

For example, in an environment where a reverse proxy is also used as a crypto offloader, this allows the origin server to rewrite URLs in a document to match the type of connection as the user agent requested, even though all connections to the origin server are unencrypted HTTP.

例えば、リバースプロキシが暗号化オフローダとしても使用されている環境では、オリジンサーバーは、オリジンサーバーへのすべての接続が暗号化されていないHTTPであるにもかかわらず、ユーザーエージェントが要求した接続のタイプに合わせてドキュメント内のURLを書き換えることができます。

5.5. Extensions

5.5. 拡張機能

Extensions allow for additional parameters and values. Extensions can be particularly useful in reverse proxy environments. All extension parameters SHOULD be registered in the "HTTP Forwarded Parameter" registry. If certain extensions are expected to have widespread deployment, they SHOULD also be standardized. This is further discussed in Section 9.

拡張機能により、追加のパラメーターと値が可能になります。拡張機能は、特にリバースプロキシ環境で特に有用です。すべての拡張パラメーターは"HTTP Forwarded Parameter"レジストリに登録すべきです（SHOULD）。特定の拡張機能が広範囲に展開されることが予想される場合、それらもまた標準化すべきです（SHOULD）。これについてはセクション9でさらに議論されています。

6.1. IPv4 and IPv6 Identifiers

6.1. IPv4とIPv6の識別子

The ABNF rules for "IPv6address" and "IPv4address" are defined in [RFC3986]. The "IPv6address" SHOULD comply with textual representation recommendations [RFC5952] (for example, lowercase, compression of zeros).

"IPv6address"と"IPv4address"のABNFルールは、[RFC3986]で定義されています。"IPv6address"は、テキスト表現の推奨事項[RFC5952]（例えば、小文字、ゼロの圧縮）に準拠すべきです（SHOULD）。

Note that the IP address may be one from the internal nets, as defined in [RFC1918] and [RFC4193]. Also, note that an IPv6 address is always enclosed in square brackets.

IPアドレスは、[RFC1918]および[RFC4193]で定義されている内部ネットのものである可能性があることに注意してください。また、IPv6アドレスは常に角括弧で囲まれていることに注意してください。

6.2. The "unknown" Identifier

6.2. "unknown"識別子

The "unknown" identifier is used when the identity of the preceding entity is not known, but the proxy server still wants to signal that a forwarding of the request was made. One example would be a proxy server process generating an outgoing request without direct access to the incoming request TCP socket.

"unknown"識別子は、前のエンティティの識別が不明であるが、プロキシサーバーがリクエストの転送が行われたことを示したい場合に使用されます。一つの例として、直接的なアクセスなしに受信リクエストのTCPソケットを生成するプロキシサーバープロセスがあります。

6.3. Obfuscated Identifier

6.3. 難読化された識別子

A generated identifier may be used where there is a wish to keep the internal IP addresses secret, while still allowing the "Forwarded" header field to be used for tracing and debugging. This can also be useful if the proxy uses some sort of interface labels and there is a desire to pass them rather than an IP address. Unless static assignment of identifiers is necessary for the server's use of the identifiers, obfuscated identifiers SHOULD be randomly generated for each request. If the server requires that identifiers persist across requests, they SHOULD NOT persist longer than client IP addresses. To distinguish the obfuscated identifier from other identifiers, it MUST have a leading underscore "_". Furthermore, it MUST also consist of only "ALPHA", "DIGIT", and the characters ".", "_", and "-". Example:

生成された識別子は、内部IPアドレスを秘密に保ちつつ、"Forwarded"ヘッダーフィールドをトレースとデバッグに使用したい場合に使用できます。これは、プロキシが何らかのインターフェースラベルを使用しており、IPアドレスではなくそれらを渡したいという願望がある場合にも便利です。識別子のサーバーによる使用に静的な識別子の割り当てが必要でない限り、難読化された識別子は各リクエストごとにランダムに生成すべきです（SHOULD）。識別子がリクエストを超えて持続することがサーバーに必要な場合、それらはクライアントIPアドレスより長く持続すべきではありません（SHOULD NOT）。難読化された識別子を他の識別子と区別するために、それは先頭にアンダースコア"_"を持つ必要があります（MUST）。さらに、それは"ALPHA"、"DIGIT"、そして文字"."、"_"、および"-"のみで構成される必要があります（MUST）。 例:

7.1. HTTP Lists

7.1. HTTPリスト

Note that an HTTP list allows white spaces to occur between the identifiers, and the list may be split over multiple header fields. As an example, the header field

HTTPリストでは、識別子の間に空白を許可し、リストは複数のヘッダーフィールドに分割することができることに注意してください。例として、ヘッダーフィールドは次のようになります。

is equivalent to the header field

は、ヘッダーフィールドと同等です

which is equivalent to the header fields

これは、ヘッダーフィールドと同等です

7.2. Header Field Preservation

7.2. ヘッダーフィールドの保存

There are some cases when this header field should be kept and some cases where it should not be kept. A directly forwarded request should preserve and possibly extend it. If a single incoming request causes the proxy to make multiple outbound requests, special care must be taken to decide whether or not the header field should be preserved. In many cases, the header field should be preserved, but if the outbound request is not a direct consequence of the incoming request, the header field should not be preserved. Consider also the case when a proxy has detected a content mismatch in a 304 response and is following the instructions in [RFC7232], Section 4.1 to repeat the request unconditionally, in which case the new request is still basically a direct consequence of the origin request, and the header field should probably be kept.

このヘッダーフィールドを保持すべき場合とそうでない場合があります。直接転送されたリクエストは、それを保持し、可能であれば拡張すべきです。単一の受信リクエストがプロキシに複数の送信リクエストを行わせる場合、ヘッダーフィールドを保持すべきかどうかを決定する際には特別な注意が必要です。多くの場合、ヘッダーフィールドは保持すべきですが、送信リクエストが受信リクエストの直接的な結果でない場合、ヘッダーフィールドは保持すべきではありません。また、プロキシが304レスポンスのコンテンツの不一致を検出し、[RFC7232], Section 4.1の指示に従ってリクエストを無条件に繰り返す場合も考慮してください。この場合、新しいリクエストは基本的には元のリクエストの直接的な結果であり、ヘッダーフィールドはおそらく保持すべきです。

7.3. Relation to Via

7.3. Viaとの関係

The "Via" header field (see [RFC7230], Section 5.7.1) is a header field with a similar use case as this header field. The "Via" header field, however, only provides information about the proxy itself, and thereby leaves out the information about the client connecting to the proxy server. The "Forwarded" header field, on the other hand, has relaying information from the client-facing side of the proxy server as its main purpose. As "Via" is already widely deployed, its format cannot be changed to address the problems that "Forwarded" addresses.

"Via"ヘッダーフィールド（参照 [RFC7230], Section 5.7.1）は、このヘッダーフィールドと同様の使用ケースを持つヘッダーフィールドです。しかし、"Via"ヘッダーフィールドは、プロキシ自体についての情報のみを提供し、プロキシサーバーに接続するクライアントについての情報は省略します。一方、"Forwarded"ヘッダーフィールドは、プロキシサーバーのクライアント対面側からの中継情報を主な目的としています。"Via"はすでに広く展開されているため、その形式を変更して"Forwarded"が解決する問題を対処することはできません。

Note that it is not possible to combine information from this header field with the information from the Via header field. Some proxies will not update the "Forwarded" header field, some proxies will not update the Via header field, and some proxies will update both.

このヘッダーフィールドからの情報とViaヘッダーフィールドからの情報を組み合わせることはできないことに注意してください。一部のプロキシは"Forwarded"ヘッダーフィールドを更新しない、一部のプロキシはViaヘッダーフィールドを更新しない、そして一部のプロキシは両方を更新します。

7.4. Transition

7.4. 移行

If a proxy gets incoming requests with X-Forwarded-* header fields present, it is encouraged to convert these into the header field described in this document, if it can be done in a sensible way. If the request only contains one type -- for example, X-Forwarded-For -- this can be translated to "Forwarded", by prepending each element with "for=". Note that IPv6 addresses may not be quoted in X-Forwarded-For and may not be enclosed by square brackets, but they are quoted and enclosed in square brackets in "Forwarded".

プロキシがX-Forwarded-*ヘッダーフィールドを含む受信リクエストを取得した場合、それをこのドキュメントで説明されているヘッダーフィールドに変換することが推奨されます。これは、それが適切な方法で行うことができる場合に限ります。リクエストが一種類のみを含む場合 -- 例えば、X-Forwarded-For -- これは、各要素の前に"for="を追加することで"Forwarded"に変換できます。X-Forwarded-ForではIPv6アドレスは引用符で囲まれず、角括弧で囲まれませんが、"Forwarded"では引用符と角括弧で囲まれます。

becomes:

次のようになります:

However, special care must be taken if, for example, both X-Forwarded-For and X-Forwarded-By exist. In such cases, it may not be possible to do a conversion, since it is not possible to know in which order the already existing fields were added. Also, note that removing the X-Forwarded-For header field may cause issues for parties that have not yet implemented support for this new header field.

ただし、例えば、X-Forwarded-ForとX-Forwarded-Byの両方が存在する場合には、特別な注意が必要です。そのような場合、既存のフィールドがどの順序で追加されたかを知ることができないため、変換を行うことができないかもしれません。また、X-Forwarded-Forヘッダーフィールドを削除すると、この新しいヘッダーフィールドのサポートをまだ実装していない当事者に問題を引き起こす可能性があることに注意してください。

7.5. Example Usage

7.5. 使用例

A request from a client with IP address 192.0.2.43 passes through a proxy with IP address 198.51.100.17, then through another proxy with IP address 203.0.113.60 before reaching an origin server. This could, for example, be an office client behind a corporate malware filter talking to a origin server through a reverse proxy.

IPアドレス192.0.2.43のクライアントからのリクエストが、IPアドレス198.51.100.17のプロキシを経由し、その後IPアドレス203.0.113.60の別のプロキシを経由してオリジンサーバーに到達します。これは、例えば、企業のマルウェアフィルターの背後にあるオフィスクライアントが、リバースプロキシを経由してオリジンサーバーと通信する場合などです。

• The HTTP request between the client and the first proxy has no "Forwarded" header field.

• クライアントと最初のプロキシ間のHTTPリクエストには"Forwarded"ヘッダーフィールドはありません。

• The HTTP request between the first and second proxy has a "Forwarded: for=192.0.2.43" header field.

• 最初のプロキシと二番目のプロキシ間のHTTPリクエストには"Forwarded: for=192.0.2.43"ヘッダーフィールドがあります。

• The HTTP request between the second proxy and the origin server has a "Forwarded: for=192.0.2.43, for=198.51.100.17;by=203.0.113.60;proto=http;host=example.com" header field.

• 二番目のプロキシとオリジンサーバー間のHTTPリクエストには"Forwarded: for=192.0.2.43, for=198.51.100.17;by=203.0.113.60;proto=http;host=example.com"ヘッダーフィールドがあります。

Note that, at some points in a connection chain, the information might not be updated in the "Forwarded" header field, either because of lack of support of this HTTP extension or because of a policy decision not to disclose information about this network component.

接続チェーンの一部のポイントでは、このHTTP拡張のサポートがないため、またはこのネットワークコンポーネントに関する情報を公開しないというポリシー決定のため、"Forwarded"ヘッダーフィールドの情報が更新されない可能性があることに注意してください。

8.1. Header Validity and Integrity

8.1. ヘッダーの有効性と完全性

The "Forwarded" HTTP header field cannot be relied upon to be correct, as it may be modified, whether mistakenly or for malicious reasons, by every node on the way to the server, including the client making the request.

"Forwarded" HTTPヘッダーフィールドは、間違ってまたは悪意を持って変更される可能性があり、リクエストを行うクライアントを含むサーバーへの道のり上のすべてのノードによって、正確であるとは限らないことに注意してください。

One approach to ensure that the "Forwarded" HTTP header field is correct is to verify the correctness of proxies and to whitelist them as trusted. This approach has at least two weaknesses. First, the chain of IP addresses listed before the request came to the proxy cannot be trusted. Second, unless the communication between proxies and the endpoint is secured, the data can be modified by an attacker with access to the network.

"Forwarded" HTTPヘッダーフィールドが正しいことを確認する一つの方法は、プロキシの正確さを検証し、それらを信頼できるものとしてホワイトリストに登録することです。この方法には少なくとも二つの弱点があります。第一に、リクエストがプロキシに到達する前にリストされたIPアドレスのチェーンは信頼できません。第二に、プロキシとエンドポイント間の通信が保護されていない限り、ネットワークにアクセス可能な攻撃者によってデータが改ざんされる可能性があります。

8.2. Information Leak

8.2. 情報漏洩

The "Forwarded" HTTP header field can reveal internal structures of the network setup behind the NAT or proxy setup, which may be undesired. This can be addressed either by using obfuscated elements, by preventing the internal nodes from updating the HTTP header field, or by having an egress proxy remove entries that reveal internal network information.

"Forwarded" HTTPヘッダーフィールドは、NATまたはプロキシ設定の背後にあるネットワーク構造を明らかにする可能性があり、これは望ましくないかもしれません。これは、難読化された要素を使用する、内部ノードがHTTPヘッダーフィールドを更新するのを防ぐ、または内部ネットワーク情報を明らかにするエントリを削除する出口プロキシを持つことで対処できます。

This header field should never be copied into response messages by origin servers or intermediaries, as it can reveal the whole proxy chain to the client. As a side effect, special care must be taken in hosting environments not to allow the TRACE request where the "Forwarded" field is used, as it would appear in the body of the response message.

このヘッダーフィールドは、クライアントにプロキシチェーン全体を明らかにする可能性があるため、オリジンサーバーや中間者によってレスポンスメッセージにコピーされるべきではありません。副作用として、ホスティング環境では、"Forwarded"フィールドが使用されている場合にTRACEリクエストを許可しないように特別な注意が必要です。なぜなら、それはレスポンスメッセージの本文に表示されるからです。

8.3. Privacy Considerations

8.3. プライバシーに関する考慮事項

In recent years, there have been growing concerns about privacy. There is a trade-off between ensuring privacy for users versus disclosing information that is useful, for example, for debugging, statistics, and generating location-dependent content. The "Forwarded" HTTP header field, by design, exposes information that some users consider privacy sensitive, in order to allow for such uses. For any proxy, if the HTTP request contains header fields that specifically request privacy semantics, the proxy SHOULD NOT use the "Forwarded" header field, nor in any other manner pass private information, such as IP addresses, on to the next hop.

近年、プライバシーに対する懸念が高まっています。ユーザーのプライバシーを確保するという目標と、デバッグ、統計、位置依存のコンテンツ生成などに有用な情報を開示するという目標との間にはトレードオフが存在します。"Forwarded" HTTPヘッダーフィールドは、その設計上、ユーザーがプライバシーに敏感と考える情報を公開し、そのような用途を可能にします。任意のプロキシについて、HTTPリクエストがプライバシーのセマンティクスを特に要求するヘッダーフィールドを含む場合、プロキシは"Forwarded"ヘッダーフィールドを使用すべきではなく、また、IPアドレスなどのプライベート情報を次のホップに渡すべきではありません（SHOULD NOT）。

The client's IP address, that may be forwarded in the "for" parameter of this header field, is considered to be privacy sensitive by many people, as the IP address may be able to uniquely identify a client, what operator the user is using, and possibly a rough estimation of where the user is geographically located.

このヘッダーフィールドの"for"パラメーターで転送される可能性があるクライアントのIPアドレスは、多くの人々にとってプライバシーに敏感な情報と考えられています。なぜなら、IPアドレスによってクライアントを一意に識別したり、ユーザーがどのオペレーターを使用しているか、おそらくユーザーが地理的にどこに位置しているかの大まかな推定を可能にするからです。

Proxies using this extension will preserve the information of a direct connection. This has an end-user privacy impact regardless of whether the end-user or deployer knows or expects that this is the case.

この拡張を使用するプロキシは、直接接続の情報を保持します。これは、エンドユーザーまたはデプロイヤーがこれが事実であることを知っているか、または予期しているかどうかに関係なく、エンドユーザーのプライバシーに影響を与えます。

Implementers and deployers of such proxies need to consider whether, and how, deploying this extension affects user privacy.

このようなプロキシの実装者やデプロイヤーは、この拡張をデプロイすることがユーザープライバシーにどのように影響を与えるか、または影響を与えるかどうかを考慮する必要があります。

The default configuration for both the "by" and "for" parameters SHOULD contain obfuscated identifiers. These identifiers SHOULD be randomly generated per request. If identifiers that persist across requests are required, their lifetimes SHOULD be limited and they SHOULD NOT persist longer than client IP addresses. When generating obfuscated identifiers, care must be taken not to include potentially sensitive information in them.

"by"パラメーターと"for"パラメーターのデフォルトの設定は、難読化された識別子を含むべきです（SHOULD）。これらの識別子は、リクエストごとにランダムに生成されるべきです（SHOULD）。リクエストを超えて持続する識別子が必要な場合、その寿命は制限され、クライアントのIPアドレスよりも長く持続すべきではありません（SHOULD NOT）。難読化された識別子を生成する際には、それらに潜在的に敏感な情報を含めないように注意を払う必要があります。

Note that users' IP addresses may already be forwarded by proxies using the header field X-Forwarded-For, which is widely used. It should also be noted that if the user were doing the connection directly without passing the proxy, the client's IP address would be sent to the web server. Users that do not actively choose an anonymizing proxy cannot rely on having their IP address shielded. These users who want to minimize the risk of being tracked must also note that there are other ways information may leak, for example, by browser header field fingerprinting. The Forwarded header field itself, even when used without a uniquely identifying client identifier, may make fingerprinting more feasible by revealing the chain of proxies traversed by the client's request.

ユーザーのIPアドレスは、すでに広く使用されているヘッダーフィールドX-Forwarded-Forを使用してプロキシによって転送されている可能性があることに注意してください。また、ユーザーがプロキシを経由せずに直接接続を行っていた場合、クライアントのIPアドレスはウェブサーバーに送信されます。匿名化プロキシを積極的に選択しないユーザーは、IPアドレスが保護されることを期待することはできません。追跡のリスクを最小限に抑えたいと考えるこれらのユーザーは、ブラウザのヘッダーフィールドのフィンガープリントによって情報が漏洩する可能性がある他の方法にも注意を払う必要があります。クライアントの一意に識別する識別子なしで使用された場合でも、Forwardedヘッダーフィールド自体が、クライアントのリクエストが通過したプロキシのチェーンを明らかにすることで、フィンガープリントをより実行可能にする可能性があります。