web-dev-qa-db-ja.com

クエリ文字列の前にスラッシュをスキップしてもよろしいですか？

クエリ文字列を追加するときに常に末尾のスラッシュをスキップしても安全ですか？

つまり、私は使用できますか

http://example.com?querystring

の代わりに：

http://example.com/?querystring

？私が使用したすべてのWebホストはこれをサポートしていますが、すべてのサーバー環境がこの方法をサポートすると想定しても安全ですか？標準ですか？

urlquery-string
58
Chad

いいえ。スラッシュをスキップするのは正しくありません。最新のブラウザでは機能します可能性があります。ただし、これでは正しくなりません。

RFC1738-URL および RFC2396-URI を参照してください。

RFC1738による形式（ここではスキーマ形式を除外しています）：

// <user>：<password> @ <Host>：<port>/<url-path>

さらに、次のことに注意してください。

...ホスト（またはポート）とurl-pathの間の「/」は、url-pathの一部ではありません。

この場合、「？」 url-pathの一部である

...それが解釈される方法がそうであるように、使用されているスキームに依存します。

また、仕様ごとに、omit "/ url-path"に対して完全に有効であることにも注意してください。この場合、 "/"が明示的に含まれていることに注意してください。

したがって、url-pathの前に「/」がないため、「foo.com?bar」は無効です。

48
user166390

notと仮定しても安全です。 Webサーバーと自己完結型のWebアプリケーションは通常、リクエストで提供されたURLを検査しますが、/abcが/abc/と同等に扱われる保証はありません。 Webサーバーと自己完結型Webアプリケーションは、URLから収集した情報を使って好きなようにを実行できますが、必ずしも期待したものとは限りません。問題の特定のURLの規則は何かを調べる必要があります。

もちろん、ほとんどのWebサーバーとWebアプリケーションフレームワークは、あらゆる種類の入力を受け入れて適切に処理しようとすることに注意してください。したがって、ほとんどの場合、Webサーバーまたは自己完結型Webアプリケーションは/abcを/abc/と同等に扱います。ただし、サーバーはパスを使用して好きなように処理できるため、これは単なる例外であり、多数の例外が発生する可能性があることに注意してください。

4
yfeldblum

この問題を調査した後に私が見つけたいくつかの詳細情報を受け入れた回答に追加します：

http://tools.ietf.org/html/rfc2396

権限コンポーネントの前には二重スラッシュ「//」があり、次のスラッシュ「/」、疑問符「？」、またはURIの終わりで終わります。権限コンポーネント内では、文字「;」、「：」、「@」、「？」、および「/」は予約されています

このステートメントに基づいて、疑問符はスラッシュの有無にかかわらず、権限コンポーネントの終わりを示す必要があります。

http://tools.ietf.org/html/rfc1738 （置換されたタグ）

{path}はオプションであり、{searchpart}とその前の「？」も同様です。 {path}も{searchpart}も存在しない場合は、「/」も省略できます。

ただし、このステートメントは、パスとsearchpartの両方が事前設定されていない場合にのみ、末尾のスラッシュを省略できることを示しています。

現実の世界では、以前はクエリ値の前にあるスラッシュを省略することができましたが、最近、転倒する状況が見つかりました。このようなクエリがある場合 http://my.domain.com?do=something で、Internet ExplorerでHTMLページを表示すると、リンクはに固定されますIEによる。次に、[ファイル]、[送信]、[電子メールでページング...]をクリックすると、リンクが無効な形式で電子メールに追加されます。問題はクエリ値の内容によって異なりますが、無効なURLを作成することができました。

要約すると、は機能するはずですが機能しますが、エッジの場合は機能しません。

4
Chris Porter