クエリ文字列の前のスラッシュをスキップしても大丈夫ですか?

StackOverflow https://stackoverflow.com/questions/1617058

  •  06-07-2019
  •  | 
  •  

質問

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

つまり、使えますか

http://example.com?querystring

の代わりに：

http://example.com/?querystring

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

役に立ちましたか？

解決

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

RFC1738-URL および RFC2396-URI 。

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

  
    

// <！> lt; user <！> gt;：<！> lt; password <！> gt; @ <！> lt; host <！> gt;：<！> lt; port <！> gt; / <！> lt; url-path <！> gt;

  

そして次のことに注意してください：

  
    

... <！> quot; / <！> quot;ホスト（またはポート）とurl-pathの間はurl-pathの一部ではありません。

  

この場合、<！> quot;？<！> quot; url-pathの一部であり、

  
    

...解釈される方法と同様に、使用されているスキームに依存します。

  

また、仕様ごとに、除外 <！> quot; / url-path <！> quot; -<！> quot; / <！> quot;この場合、明示的に含まれています。

したがって、<！> quot; foo.com？bar <！> quot; <！> quot; / <！> quotがないため無効です。 url-pathの前。

他のヒント

現代のスペックとしては、 はい, 、スラッシュを省略してもかまいません, 、それとは反対に、 受け入れられた回答 ここで主張します。

受け入れられた回答は、RFC 1738 (20 年以上前にリリースされました!) を正しく引用していますが、RFC 2396 (1998 年にリリース) にはスラッシュが必要であると誤って主張し、それを無視しています。 両方 これらの仕様のうちの 1 つは、次によって廃止されました。 RFC 3986, 、2005年にリリースされ（受け入れられた回答が書かれるまでにはまだ数年前でした）、最近では WhatWG URL 標準, どちらもスラッシュを省略できます。

これらの各仕様を古いものから最新のものまで順に検討してみましょう。

RFC 1738:ユニフォーム リソース ロケーター (URL) （1994年発売）

スラッシュを含める必要があることを暗黙的に要求します。 それを指定する 5月 省略される もし URL にはパスもクエリ文字列も含まれていません (と呼ばれる searchpart, 、 ここ）。以下の太字は私のものです。

HTTP URL の形式は次のとおりです。

http://<host>:<port>/<path>?<searchpart>

どこ <host> そして <port> で説明されているとおりです セクション 3.1. 。もし ：<port>を省略した場合、ポートはデフォルトの 80 になります。ユーザー名やパスワードは許可されていません。 <path> HTTP セレクターであり、 <searchpart> クエリ文字列です。の <path> はオプションです。 <searchpart> そしてその前の「？」。 どちらでもない場合 <path> または <searchpart> 存在すると、「/」も省略できます。

RFC 2396:統一リソース識別子 (URI):一般的な構文 （1998年にリリース。「更新」RFC 1738)

ここではスラッシュを省略しても問題ありません。この RFC は、スキームの後に二重スラッシュがないいくつかの奇妙な URL 構文を合法化していますが、それらを無視すると ( opaque_part 仕様の中で BNF) ホストを含​​む URL に固執すると、 absoluteURI このように定義されています...

absoluteURI   = scheme ":" ( hier_part | opaque_part )

そしてそれは hier_part 次のようになります:

hier_part     = ( net_path | abs_path ) [ "?" query ]

そしてそれは net_path 次のようになります:

net_path      = "//" authority [ abs_path ]

どこに abs_path 次に、スラッシュで始まるように定義されます。注意してください。 abs_path は オプション 上記の文法では、フォームの URL を意味します。 scheme://authority?query 完全に合法です。

この変更の動機は付録でほのめかされています G.2.RFC 1738 と RFC 1808 の両方からの変更:

質問マーク「？」多くのアプリケーションがクエリコンポーネントを残りのURIから分離するために予約されていると扱うことがテストが示されたため、文字は機関コンポーネントのuserInfoの許可された文字のセットから削除されました。

言い換えれば、現実世界のコードは、URL の最初の疑問符がクエリ文字列の始まりであると想定していたので、現実に合わせて仕様が実際的に更新されました。

RFC 3986:統一リソース識別子 (URI):一般的な構文 （2005年発売。「時代遅れ」RFC 2396)

繰り返しますが、スラッシュを省略することもできます。仕様ではこれを、権限 (ホスト) を含むすべての URI に「パス」が必要であり、そのパスは必ず必要であると表現しています。 どちらか スラッシュで始まる または 文字が含まれていない:

3.構文コンポーネント

一般的なURI構文は、スキーム、権限、パス、クエリ、およびフラグメントと呼ばれるコンポーネントの階層シーケンスで構成されています。

URI         = scheme ":" hier-part [ "?" query ] [ "#" fragment ]

hier-part   = "//" authority path-abempty
            / path-absolute
            / path-rootless
            / path-empty

パスが空になる場合がありますが（文字なし）、スキームとパスコンポーネントが必要です。権限が存在する場合、パスは空であるか、スラッシュ（ "/"）文字から始めなければなりません。

完全を期すために、次の点に注意してください。 path-abempty は後で次のように定義されます。

path-abempty  = *( "/" segment )

これにより、実際に文字を含めることができなくなります。

URL標準 WhatWG による (RFC 3986 を廃止することを目的として、2012 年に最初に作成されたアクティブなメンテナンス中の生活標準)

繰り返しますが、スラッシュの省略は許容されますが、今回は調べる BNF はなく、代わりに多くの散文を読む必要があります。

セクション 4.3 私たちにこう言います:

アン 絶対 URL 文字列 次のいずれかである必要があります

オプションで「？」が続きますおよびURLクエリ文字列。

HTTP と HTTPS は 特別な計画, 、HTTP または HTTPS URL は、これら 3 つのオプションのうちの最初のオプションを満たす必要があります。 http: または https: 続いて スキーム相対特別 URL 文字列, 、 どれの：

でなければなりません "//"、続いて 有効なホスト文字列, 、オプションでその後に「」が続く:"と URLポート文字列, 、オプションでその後に パスの絶対 URL 文字列.

あ パスの絶対 URL 文字列 スラッシュで始まるように定義されていますが、上記の絶対 URL 文字列の定義では明示的にオプションです。したがって、ホストから「」に直接アクセスすることが許可されます。?" とクエリ文字列、つまり次のような URL http://example.com?query 合法です。

もちろん、これらはすべての Web サーバーまたは HTTP ライブラリがそのような URL を受け入れること、またそれらの URL をスラッシュを含む URL と意味的に同等のものとして扱うことを完全に保証するものではありません。しかし、これまでのところ スペック つまり、スラッシュをスキップすることは完全に合法です。

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

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

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

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

  

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

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

http://tools.ietf.org/html/rfc1738 （タグが置き換えられました）

  

{searchpart}およびその前の<！> quot;？<！> quot;と同様に、{path}はオプションです。 {path}も{searchpart}も存在しない場合、<！> quot; / <！> quot;省略することもできます。

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

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

要約すると、それは はずです 動作しますが、エッジケースでは落ちます。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top