重複の可能性:
先頭の二重スラッシュを使用して URL のプロトコルを継承することの欠点はありますか? つまり、src="//domain.com"</a>
多くの場所で次のロジックを見てきました。たとえば、分析スクリプトです。
script.src = ('https:' == document.location.protocol ? 'https' : 'http') +
'://example.com/cdn.js';
しかし、私の知る限り、次のこともできます。
script.src = '//example.com/cdn.js';
現在使用されているプロトコルを使用する必要があります。または、何か不足していますか？「ベストプラクティス」とは何ですか?
私はブラウザの互換性の答えを探しているわけではありません.Googleはすでに//CDNスクリプトを推奨しているため、ここではそうではありません.
ここにフィドルがありますが、このセットアップで動作するように見える以上のことはあまり言いません: http://jsfiddle.net/6ZGyb/
背景のビット:
追加の JavaScriptprotocolラッパーは、通常、すべてのブラウザがそのような をサポートすることを保証するために存在しますrelative path URL。いずれにせよ、現在のほとんどのブラウザーがそのような URL を適切に処理すると想定するのは正しいことですが、頭を休めて眠るためには、Web ページにアクセスするすべてのユーザー エージェントがそれほど精通しているわけではないことを想定することをお勧めします。私たちが期待するとおり (または、RFC 1808セクション 4、RFC 2396セクション 5.2、またはRFC 3986セクション 5.2 をサポートすることは既に説明したように、URL でプロトコルを継承するために先頭の二重スラッシュを使用するための欠点はありますか?スレッド@Brunoがコメントで指摘したように）
互換性に関する懸念:
このような相対パスを含むコンテンツが「コンテキスト外」でアクセスできるシナリオを想像してみてください。たとえば、電子メール クライアントなどです。この場合、そのような相対パスは完全修飾パスに間違った方法で解析され、ユーザーがコンテンツを適切に表示できないことから、本来あるべきではないコンテンツにアクセスすることまで、あらゆる種類の問題を引き起こす可能性があります。このような問題を回避するには、相対パスの使用は常に、親ドキュメントのパーサー (オープナー アプリケーション) が問題のリソースへの完全な絶対パスを決定できるコンテキスト内のケースに限定する必要があります。同じまたは互換性のあるプロトコルによってアクセスされる場合にのみ、相対パスが適切に機能することを期待する必要があります。
セキュリティ上の懸念:
提起された別の考えられる懸念は次のとおりです。
このような相対プロトコル URL は、さまざまな交換プロトコルによって (解析された URL) 親ドキュメントのコンテンツにアクセスすることによって、何らかの方法で悪用される可能性があります。
公式の IANA に登録された URL スキームの (長い) リストは、悪用者によって使用される可能性のある懸念される可能性のある交換プロトコルがたくさんあることを示唆していますが、 JavaScript は、JavaScript をサポートしていない (またはユーザーによって無効にされています)。それを念頭に置いて、私の答えは-いいえでなければなりません（「他のプロトコルを使用してアクセスを保護するJavaScript」の部分について）。
提起された懸念の残りの部分( 「そのような相対プロトコル URL が何らかの方法で悪用される可能性がある」 ) については、その答えは、そのようなコンテンツを提供する Web サーバーをセットアップするときにこれがどの程度考慮されたかに依存します。そのような要求 (そうでない場合、それは問題ではありません)、および展開前に考慮された攻撃/コンテンツの盗難の可能性のあるベクトル。言い換えれば、これは Web サーバー管理の問題であり、Web デザイナー/プログラマーが答えられる/答えるべきものではないことは確かです。エンドユーザーがアクセスできる各プロトコルには、その上に独自のセキュリティ プロトコル セットが必要です。