6

HTTP 要求 URI に「..」セグメントを含めることは許可されていますか?

RFC 2616 のセクション 5.1.2 によると、絶対 URI または絶対パスを参照できます (そのセクションの他のオプションは、この質問には関係ありません)。

絶対 URI と絶対パスの意味は、RFC 3986 で説明されています。RFC 3986 では、パスを正規化するアルゴリズムも説明されています (これには、単一および二重ドット要素の削除が含まれます)。

ただし、RFC 準拠のリクエスト URI に「..」セグメントを含めることができるかどうかの正確な仕様を見つけることができません。それらは絶対パス/URI で許可されており、サーバーはそのような URI を正規化する必要がありますか? それともクライアント次第？

"Location:" 応答ヘッダーに違いはありますか? 仕様によると、絶対URIのみを含めることができますが、「..」の部分は含まれますか? 参照されたリソースを要求する前に、クライアントもそれらを正規化する必要がありますか?

../foo明確にするために、これらの状況では のような URI が違法であることは知っていますが、ではどうhttp://example.com/../fooでしょうか? それは有効な絶対 URI ですか?

現在、クライアントをそのような URI にリダイレクトしていますが、それが仕様に準拠しているかどうかを知りたいです。

4

3 に答える 3

5

「それが仕様に適合しているか知りたい」なら、その仕様書を参照してみませんか？

RFC 3986 セクション 5.2は、URI ドット セグメントをどのように解決する必要があるかについて非常に明確です。

このセクションでは、特定のベース URI に関連している可能性のある URI 参照を、参照のターゲットの解析済みコンポーネントに変換するためのアルゴリズムについて説明します。その後、セクション 5.3 で説明されているように、コンポーネントを再構成して、ターゲット URI を形成できます。このアルゴリズムは、他の実装の出力をテストするために使用できる決定的な結果を提供します。結果がこのアルゴリズムによって得られるものと一致する場合、アプリケーションは他のアルゴリズムを使用して相対参照解決を実装できます。

たとえば、Location:ヘッダーをフォローしている場合は、通常、無効な相対パスを正規化して解決することをお勧めします (Location:ヘッダーは絶対 URI である必要があります)。このような場合、RFC 3986 の指示に従って、ベース URI に対してこれらのパスを解決する必要があります。

URI のあちこちにドット セグメントを渡す必要がありますか? 仕様を正しく実装するために他の人に頼っているので、あなたがそれを助けることができるなら、おそらくそうではありません. しかし、ドット セグメントを含む URI を渡すことは URI 仕様に違反しますか? いいえ。

于 2012-11-08T01:08:27.823 に答える
2

構文的に言えば、http://example.com/../fooは有効なURIです。

サーバーがそのURIをどのように解釈するかは別の問題です。明らかなセキュリティ上の理由から、サーバーはURIをファイルパスに変換する方法について非常に注意する必要があります。通常、サーバーは..セグメントを削除するか、ファイルパスがドキュメントルート内にあることを確認するために何らかの後処理を実行します。

于 2012-11-07T20:18:48.010 に答える