[3] Max-Forwards: ヘッダーは、 要求メッセージが串によって転送されても良い最大回数を表します。

仕様書

意味

[10] Max-Forwards: ヘッダーは、 要求が串によって転送される回数を制限するものです >>9。

[21] 応答には適用されないようです。

文脈

[4] クライアントは、OPTIONS >>6 や TRACE の要求に Max-Forwards: ヘッダーを含めることができます。

[5] 串は、OPTIONS 要求に関して、 Max-Forwards: を含む要求を転送する場合を除き、 これを生成してはなりません >>6。

[19] 以前は拡張メソッドでも使えるとされていましたが、 RFC 7231 で >>4 の2つのメソッドに限定されました >>8。

構文

[11] 値は、非負整数です >>9。

[12] この値は当該要求メッセージが転送されることができる残り回数を示す十進整数です >>9。

処理モデル

[13] 中間器は、 OPTIONS や TRACE の要求を受信した時 Max-Forwards: ヘッダーが含まれている場合、

[16] 受信者は、他の要求メソッドの場合 Max-Forwards: を無視して構いません >>9。

[17] ということは適用しても良いということになりますが、 例えば串が自身宛でない GET を処理するとどうなるのでしょうか。。。

歴史

[18] RFC 2068・2616 (HTTP/1.1) 14.31 Max-Forwards

The Max-Forwards request-header field may be used provides a mechanism with the TRACE method (section 14.31) (section 9.8) and OPTIONS (section 9.2) methods to limit the number of proxies or gateways that can forward the request to the next inbound server. This can be useful when the client is attempting to trace a request chain which appears to be failing or looping in mid-chain.

Max-Forwards 要求頭欄は、 TRACE 方式および OPTIONS と共に使って、次の上りサーバーに要求を転送することができる串または関門の数を制限する機構を提供します。 これは、クライアントが鎖途中で失敗したり循環したりしているっぽい要求鎖を追跡しようとする時に便利です。

  • Max-Forwards = "Max-Forwards" ":" 1*DIGIT

The Max-Forwards value is a decimal integer indicating the remaining number of times this request message may be forwarded.

Max-Forwards 値は、この要求メッセージが転送されても良い残り回数を示す十進整数です。

Each proxy or gateway recipient of a TRACE or OPTIONS request containing a Max-Forwards header field SHOULD MUST check and update its value prior to forwarding the request. If the received value is zero (0), the recipient SHOULD NOT MUST NOT forward the request; instead, it SHOULD MUST respond as the final recipient with a 200 (OK) response containing the received request message as the response entity-body (as described in section 9.8). If the received Max-Forwards value is greater than zero, then the forwarded message SHOULD MUST contain an updated Max-Forwards field with a value decremented by one (1).

Max-Forwards 頭欄を含んだ TRACE 要求または OPTIONS 要求のそれぞれの串または関門である受信者は、]] 要求を転送する前に Max-Forwards 頭欄の値を確認し、更新しなければなりません。受信した値が零 (0) なら、受信者はその要求を転送してはなりません。 代わりに、最終受信者として応答します。受信した Max-Forwards 値が零より大きければ、転送されるメッセージは一 (1) 減らした値の Max-Forwards 欄を含まなければなりません。

The Max-Forwards header field SHOULD MAY be ignored for all other methods defined by this specification and for any extension methods for which it is not explicitly referred to as part of that method definition.

Max-Forwards 頭欄は、この仕様書で定義されたほかのすべてのメソッドおよびメソッド定義の中で陽に言及していない拡張メソッドでは無視しても構いません。

[1] RFC 2068 では、 Max-Forwards: 頭欄に串・関門が対応することは推奨 (SHOULD) でしたが、 RFC 2616 では必須 (MUST) になりました。

ですから、 RFC 2068 に従う中継者が要求鎖中に要ると正しく機能しないかもしれません。 (RFC 2068 に従う中継者ばかりであったら正しく機能する保証がありませんでしたが、 RFC 2616 に従う中継者ばかりなら必ず正しく機能します。もっとも、どちらの RFC に従うか判定する方法はありませんけどね。)

[2] RFC 2068 では、 Max-Forwards に対応していないメソッドでは無視するべきだと言っていましたが、 RFC 2616 は無視しても良いと言っています。

ですから、どちらに従っていても、 Max-Forwards: に影響されないはずのメソッドを使っているときに中継者が数を減らしてしまう可能性があります。 0 に反応して要求鎖の途中で応答が戻ってくる可能性もあります。

実装

[20] Apache 2.2 は(おそらくどのメソッドでも) Max-Forwards: に対応しているようです。 OPTIONS や TRACE では仕様通り串が返答するようです。 GET では 502 Proxy Error が返されており、本体に含まれるエラーメッセージによると Max-Forwards: 0 を受信したらループと判断するようです。