[解決済み] HTTP URL のパス部分にあるスラッシュ ("/") は、エンコードされたスラッシュ ("%2F") と同じですか？

質問

URL のパス部分 (クエリ文字列ではない) で "/" と "%2F" を異なるものとして扱っているサイトがあります。 これは、RFC または現実世界のいずれかに従って行うには悪いことですか?

私が質問するのは、使用している Web フレームワーク (Ruby on Rails) とその下のレイヤー (Passenger, Apache, 例: Apache で "ALLOW_ENCODED_SLASHES" を有効にしなければならない) で小さな驚きに遭遇し続けるからです。 私は現在、エンコードされたスラッシュを完全に取り除く方向に傾いていますが、エンコードされたスラッシュを含む奇妙な動作を見た場合、バグ レポートを提出すべきかどうか疑問に思っています。

そもそもなぜエンコードされたスラッシュを持っているかというと、基本的に私はこのようなルートを持っています。

:controller/:foo/:bar

ここで、:fooはスラッシュを含むことができるパスのようなものです。 一番簡単なのは、URLエスケープを行うことだと思いました。 foo を URL エスケープして、ルーティング メカニズムによってスラッシュが無視されるようにすることです。 今、私は疑問を持っていて、フレームワークがこれを本当にサポートしていないことは明らかですが、RFCによると、この方法で行うことは間違っているのでしょうか？

以下は、私が収集したいくつかの情報です。

RFC 1738 (URL)です。

通常、URLはオクテットが文字で表されるときと、エンコードされるときとで同じ解釈をします。しかし、予約文字についてはそうではありません。特定のスキームで予約された文字をエンコードすると、URL のセマンティクスが変更されることがあります。

RFC 2396 (URI)を参照してください。

これらの文字は、URIコンポーネント内での使用が予約された目的に限定されるため、"reserved"と呼ばれています。URIコンポーネントのデータが予約された目的と衝突する場合、URIを形成する前に衝突するデータをエスケープする必要があります。

(ここでのエスケープは、予約された文字をエンコードする以外のことを意味するのでしょうか?)

rfc 2616 (http/1.1) を参照してください。

reserved" と "unsafe" のセット以外の文字 (RFC 2396 [42] 参照) は、その ""%" HEX HEX" エンコーディングと同じになります。

また このバグレポート があり、そこではエンコードされたスラッシュが異なる振る舞いをすることが期待されているようです。

そうですね、異なるリソースを指しているので、異なる結果を期待しています。

これは、ルートディレクトリにあるリテラルファイル 'foo/bar' を探しています。エスケープされていないバージョンは、ディレクトリ foo 内のファイル bar を探しています。

RFC から、raw と encoded が予約されていない文字と同等であることは明らかですが、予約された文字についてはどうなのでしょうか?

どのように解決するのですか?

収集したデータから、URI でエンコードされた "/" は、アプリケーション/cgi レベルで再度 "/" として見られることを意味していると言えるでしょう。

つまり、もしあなたが apache で mod_rewrite を使っている場合、エンコードされたスラッシュを含む URI に対してスラッシュを期待するパターンをマッチさせないということです。 しかし、適切なモジュール/cgi/...がリクエストを処理するために呼び出されると、デコードを行い、例えば、URIの最初のコンポーネントとしてスラッシュを含むパラメータを取得するのは、モジュール次第となるのです。

アプリケーションがこのデータを使ってファイル (ファイル名がスラッシュを含む) を取得する場合、それはおそらく悪いことです。

要約すると、"/" と "%2F" の解釈は異なるレベルで行われるため、動作の違いを見ることは完全に正常であると私は考えています。