[214] TRACE メソッドは、要求メッセージを応答に含めて送り返すことを要求するものです。
[213] TRACE は、試験や診断のために有用であるとされています >>206。
特に Via: が見られるのは有用と考えられています >>206。
[6] このメソッドはセキュリティー上の問題があり、実装されていないことが多々あります。 実装されていても、取り扱いに細心の注意が必要です。
[207] TRACE は、遠隔の応用レベルでの要求メッセージのループバックを要求するものです
>>206。
[2] 要求対象に特別な制限はなく、どのように処理に影響するのか明確にはなっていませんが、
串や鯖の構成次第で転送先が要求対象ごとに異なる可能性があり、
それを検査することも TRACE メソッドの用途の一つなのでしょう。
[209] 起源鯖か、 Max-Forwards: ヘッダーの値が 0
で受信した最初の鯖が、最終的な受信者です >>206。
[208] TRACE の最終的な受信者は、
受信したメッセージを、一部のヘッダーを除き、
Content-Type: が message/http
である 200 応答のメッセージ本体に含めて送信するべきです
>>206。
[211] クライアントも最終受信者も、要求において繊細なデータを含むヘッダーは除外するべき >>206 としています。
[212] credentials を含むものやクッキーを含むものがこれに含まれます >>206。 ただし具体的な一覧は仕様書には示されていません。
[5] 逆串の類は付加情報を要求ヘッダーに付加することがあります。
それより起源鯖側にある逆串や起源鯖が TRACE
に対応している場合、そのようなヘッダーが含まれる応答が返され、
意図せず鯖側の構成や内部情報が外部にさらされてしまう危険性がありますから、
注意が必要です。
[15] 不用意に情報が漏れることを防ぐため、すべてのヘッダーをそのまま返すことは期待されていませんし、 すべてのサーバーが正確に返答すること自体も期待できません。 有用であるためには経路上のすべてのサーバーが正確に応答する必要があるのです。
[16] 逆に言えば、この機能が役に立つ場面はほとんどありません。
[17] もっとも、この機能があれば問題解決につながっただろうに、というような話も聞いたことがありません。 あれば便利そうに見えて、実はそんなに需要もないということでしょう。
The TRACE method is used to invoke a remote, application-layer loop-back of the request message. The final recipient of the request SHOULD reflect the message received back to the client as the entity-body of a 200 (OK) response. The final recipient is either the origin server or the first proxy or gateway to receive a Max-Forwards value of zero (0) in the request (see section 14.31). A TRACE request MUST NOT include an entity.
TRACE 方式は、要求メッセージの遠隔の応用層 loop‐back
を呼出すのに使います。要求の最終受信者は、受信したメッセージをクライアントに
200 (了解) 応答の entity-body
として反映させるべきです。
最終受信者は、起源サーバーか、または要求で
Max-Forwards 値零 (0)
を受信した最初の串または関門です。
TRACE 要求は実体を含んではなりません。
TRACE allows the client to see what is being received at the other end of the request chain and use that data for testing or diagnostic information. The value of the Via header field (section
14.4414.45) is of particular interest, since it acts as a trace of the request chain. Use of the Max-Forwards header field allows the client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding messages in an infinite loop.
TRACE は、クライアントが、要求鎖の反対側で何を受信したかを見て、
そのデータを検査や診断情報として使うことを可能とします。
Via 頭欄の値は、要求鎖の追跡として働きますから、
特に興味深いです。 Max-Forwards
頭欄を使用することでクライアントは要求鎖の長さを制限できますが、
これは無限循環するメッセージ転送串鎖を検査するのに有用です。
If
successfulthe request is valid, the response SHOULD contain the entire request message in the entity-body, with a Content-Type of "message/http". Responses to this method MUST NOT be cached.
要求が妥当であれば、応答は要求メッセージ全体を
entity-body に含め、 Content-Type
を message/http とするべきです。
この方式への応答はキャッシュしてはなりません。
[4] 鯖によっては TRACE に特に対応しておらず、
GET と同じように処理することがあります。
[9] Apache 2.2 は httpd.conf の設定で処理用に追加したヘッダーも要求に元々含まれていたヘッダーと同様に
TRACE への応答に含めて返すようです。
[217] 297078 – setRequestHeader can be exploited using newline characters ( ( 版)) https://bugzilla.mozilla.org/show_bug.cgi?id=297078
[11] 実はそんなに怖くないTRACEメソッド | 徳丸浩の日記 ( 版) http://blog.tokumaru.org/2013/01/TRACE-method-is-not-so-dangerous-in-fact.html
この④についてGSX社のレポートに書かれていたことををまとめると
各主要ブラウザのTRACEメソッドへの対応状況は下記の通りになります。
・InternetExploer: Service Pack3(2008年4月21日リリース)以降は非対応
・FireFox: バージョン1.5(2005年11月29日リリース)以降は非対応
・Chrome: 正式リリース版(2008年12月12日リリース)以降は非対応
・Safari: Windows正式版(2008年3月18日リリース)以降は非対応
・Opera: バージョン8.0(2005年4月18日リリース)以降は非対応
[13] ( 版) http://www.gsx.co.jp/tts/activity/110413.pdf
[18] @nifty パレットのセキュリティホール まとめ | 鳩丸よもやま話 () http://bakera.jp/yomoyama/palette-hole
application/httpは認められていないようです。