<script src =“ http：//…”>でhttp：//を//に置き換えることは有効ですか？

私は次の要素を持っています：

<script type="text/javascript" src="https://cdn.example.com/js_file.js"></script>

この場合、サイトはHTTPSですが、サイトは単なるHTTPの場合もあります。（JSファイルは別のドメインにあります。）便宜上、次の操作を行うことが有効かどうか疑問に思っています。

<script type="text/javascript" src="//cdn.example.com/js_file.js"></script>

http:またはを削除することが有効かどうか疑問に思っていhttps:ますか？

私がテストしたすべての場所で動作するようですが、動作しない場合はありますか？

スキームなしの相対URL（http：またはhttps :)は、RFC 3986： "Uniform Resource Identifier（URI）：Generic Syntax"、Section 4.2に従って有効です。クライアントがそれをチョークする場合、それらはRFCで指定されたURI構文に準拠していないため、クライアントの責任です。

あなたの例は有効であり、うまくいくはずです。トラフィック量の多いサイトでは、この相対URLメソッドを自分で使用し、苦情はありませんでした。また、Firefox、Safari、IE6、IE7、Operaでサイトをテストします。これらのブラウザはすべて、そのURL形式を理解しています。

どのメインストリームブラウザでも動作することが保証されています（市場シェアが0.05％未満のブラウザは考慮していません）。いや、それはInternet Explorer 3.0で動作します。

RFC 3986は、URIを次の部分で構成されるものとして定義しています。

     foo://example.com:8042/over/there?name=ferret#nose
     \_/   \______________/\_________/ \_________/ \__/
      |           |            |            |        |
   scheme     authority       path        query   fragment

相対URIを定義する場合（セクション5.2）、これらのセクションは常に左から順に省略できます。疑似コードでは、次のようになります。

 result = ""

  if defined(scheme) then
     append scheme to result;
     append ":" to result;
  endif;

  if defined(authority) then
     append "//" to result;
     append authority to result;
  endif;

  append path to result;

  if defined(query) then
     append "?" to result;
     append query to result;
  endif;

  if defined(fragment) then
     append "#" to result;
     append fragment to result;
  endif;

  return result;

説明しているURIは、スキームのない相対URIです。

それが機能しないケースはありますか？

親ページがから読み込まれた場合、file://おそらく機能しません（file://cdn.example.com/js_file.jsもちろん、ローカルで提供することもできます）を取得しようとします。

多くの人がこれをプロトコル相対URLと呼んでいます。

IE 7および8でCSSファイルの二重ダウンロードが発生します。

ここで私はHTMLの隠し機能の答えを複製します：

プロトコルに依存しない絶対パスを使用する：

<img src="//domain.com/img/logo.png"/>

ブラウザがSSLを介してHTTPSでページを表示している場合は、httpsプロトコルでそのアセットをリクエストします。それ以外の場合は、HTTPでリクエストします。

これにより、IEの「このページには安全なアイテムと安全でないアイテムの両方が含まれています」というエラーメッセージが表示されなくなり、すべてのアセットリクエストが同じプロトコル内に保持されます。

警告：<link>スタイルシートのa または@importで使用すると、IE7とIE8 はファイルを2回ダウンロードします。ただし、他のすべての用途は問題ありません。

プロトコルを省略することは完全に有効です。URL仕様はこれについて何年もの間非常に明確でした、そして私はそれを理解しないブラウザをまだ見つけていません。この手法がよく知られていない理由はわかりません。これは、HTTP / HTTPSの境界を越えるという厄介な問題に対する完璧なソリューションです。詳細：Http-https遷移と相対URL

それが機能しないケースはありますか？

これをミックスして投入するだけで、ローカルサーバーで開発している場合は、機能しない可能性があります。スキームを指定する必要があります。そうしないと、ブラウザーはそれをと想定する可能性があります。これsrc="//cdn.example.com/js_file.js"はsrc="file://cdn.example.com/js_file.js"、このリソースをローカルでホストしていないため、これは機能しなくなります。

Microsoft Internet Explorerはこれに特に敏感であるようです。次の質問を参照してください：ローカルホスト（WAMP）のInternet ExplorerでjQueryをロードできません

おそらく、常に最小限の変更で、すべての環境で機能するソリューションを見つけようとするでしょう。

HTML5Boilerplateで使用されるソリューションは、リソースが正しくロードされない場合にフォールバックを行うことですが、これはチェックを組み込んだ場合にのみ機能します。

<script src="//ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js"></script>
<!-- If jQuery is not defined, something went wrong and we'll load the local file -->
<script>window.jQuery || document.write('<script src="js/vendor/jquery-1.10.2.min.js"><\/script>')</script>

更新：HTML5Boilerplateは<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js、プロトコル相対URLを廃止することを決定した後に使用するようになりました。[こちら] [3]を参照してください。

gnudのリファレンスに従い、RFC 3986セクション5.2は次のように述べています。

スキームコンポーネントが定義されていて、参照がスキーム名で始まることを示している場合、参照は絶対URIとして解釈され、完了です。それ以外の場合、参照URIのスキーマは、ベースURIのスキーマコンポーネントから継承されます。

だから//正しいです:-)

はい、これはRFC 3986のセクション5.2に記載されています。

（編集：おっと、私のRFC参照は古くなっています）。

他の回答が述べているように、それは確かに正しいです。ただし、一部のWebクローラーは、ローカルURLのようにサーバーで要求することにより、これらの404をオフに設定することに注意してください。（ダブルスラッシュは無視され、1つのスラッシュとして扱われます）。

これらをキャッチしてリダイレクトするように、ウェブサーバーにルールを設定することができます。

たとえば、Nginxでは、次のようなものを追加します。

location ~* /(?<redirect_domain>((([a-z]|[0-9]|\-)+)\.)+([a-z])+)/(?<redirect_path>.*) {
  return 301 $scheme:/$redirect_domain/$redirect_path;
}

ただし、URIでピリオドを使用する場合は、具体性を高める必要があります。そうしないと、これらのページが存在しないドメインにリダイレクトされることになります。

また、これは各クエリに対して実行されるかなり大規模な正規表現です-私の意見では、非準拠のブラウザーを、ほとんどの準拠ブラウザーでの（わずかな）パフォーマンスヒットよりも404で罰する価値があります。

//somedomain.comをJSファイルへの参照として使用すると、ログに404エラーが表示されます。

404の原因となる参照は次のようになります。ref：

<script src="//somedomain.com/somescript.js" />

404リクエスト：

http://mydomain.com//somedomain.com/somescript.js

これらはWebサーバーのログに定期的に表示されるため、次のように言っても安全です：すべてのブラウザーとボットはRFC 3986セクション4.2を尊重しません。最も安全な方法は、可能な限りプロトコルを含めることです。

1.まとめ

2019年の回答：プロトコル相対URLは引き続き使用できますが、この手法 はアンチパターンです。

また：

1. 開発に問題があるかもしれません。
2. 一部のサードパーティツールはそれらをサポートしない場合があります。

プロトコル相対URLからhttps://それに移行するとよいでしょう。

2.関連性

この回答は2019年1月に関連しています。将来、この回答のデータは廃止される可能性があります。

3.アンチパターン

3.1。議論

Paul Irish — フロントエンドエンジニアであり、Google Chromeの開発者である — 2014年12月に執筆：

今、SSLがされていることを皆のための奨励とパフォーマンスの懸念を持っていない、この技術は現在、アンチパターンです。必要なアセットがSSLで利用できる場合は、常にそのhttps://アセットを使用してください。

スニペットがHTTP経由でリクエストできるようにすると、最近のGitHub Man-on-the-side攻撃のような攻撃の可能性が開かれます。サイトがHTTP上にある場合でもHTTPSアセットをリクエストしても常に安全ですが、その逆は当てはまりません。

3.2。別のリンク

• プロトコル相対URIを使用してページリソースをロードします
• プロトコル相対URLの使用を停止する

3.3。例

• 2017年、Stack Overflowはプロトコル相対URLから https
• 2018年、Chromeは暗号化されていないすべてのウェブサイトに「安全でない」というフラグを立てます

4.開発プロセス

たとえば、私はclean-consoleを使用しようとします。

• ファイルの例KiraCleanConsole__cdn_links_demo.html：

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>clean-console without protocol demonstration</title>
    <!-- Really dead link -->
    <script src="https://unpkg.com/bowser@latest/bowser.min.js"></script>
    <!-- Package exists; link without “https:” -->
    <script src="//cdn.jsdelivr.net/npm/jquery@3.3.1/dist/jquery.min.js"></script>
    <!-- Package exists: link with “https:” -->
    <script src="https://cdn.jsdelivr.net/npm/gemini-scrollbar/index.js"></script>
</head>
<body>
    Kira Goddess!
</body>
</html>

• 出力：

D:\SashaDebugging>clean-console -i KiraCleanConsole__cdn_links_demo.html
checking KiraCleanConsole__cdn_links_demo.html
phantomjs: opening page KiraCleanConsole__cdn_links_demo.html

phantomjs: Unable to load resource (#3URL:file://cdn.jsdelivr.net/npm/jquery@3.3.1/dist/jquery.min.js)


phantomjs:   phantomjs://code/runner.js:30 in onResourceError
Error code: 203. Description: Error opening //cdn.jsdelivr.net/npm/jquery@3.3.1/dist/jquery.min.js: The network path was not found.

  phantomjs://code/runner.js:31 in onResourceError

phantomjs: Unable to load resource (#5URL:https://unpkg.com/bowser@2.1.0/bowser.min.js)


phantomjs:   phantomjs://code/runner.js:30 in onResourceError
Error code: 203. Description: Error downloading https://unpkg.com/bowser@2.1.0/bowser.min.js - server replied: Not Found

  phantomjs://code/runner.js:31 in onResourceError

phantomjs: Checking errors after sleeping for 1000ms
2 error(s) on KiraCleanConsole__cdn_links_demo.html

phantomjs process exited with code 2

リンク//cdn.jsdelivr.net/npm/jquery@3.3.1/dist/jquery.min.jsは有効ですが、エラーが発生します。

Thiloとbg17awの回答に注意しfile://cdn.jsdelivr.net/npm/jquery@3.3.1/dist/jquery.min.jsて読んでください。file://

私はこの動作について知らなかったし、なぜpageresでこのような問題が発生するのか理解できませんでした。

5.サードパーティツール

クリック可能なURLの崇高なテキストパッケージを使用しています。それを使用して、ブラウザーでテキストエディターからリンクを開くだけです。

例の両方のリンクが有効です。しかし、ブラウザで正常に開くことができる最初のリンクは、クリック可能なURL、2番目のリンクを使用します—いいえ。これはあまり便利ではないかもしれません。

6.まとめ

はい：

1. Developing processアイテムのように問題がある場合は、開発ワークフローを設定できます。
2. そうでなければ、Third-party toolsアイテムのように問題があれば、ツールを提供することができます。

しかし、この追加の問題は必要ありません。Anti-patternアイテム内のリンクごとに情報を読み取ります。プロトコル相対URLは廃止されました。

私がhtml5-boilerplateに表示するパターンは次のとおりです。

<script src="//ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js"></script>
<script>window.jQuery || document.write('<script src="js/vendor/jquery-1.10.2.min.js"><\/script>')</script>

それはのような異なる方式にスムーズに動作しますhttp、https、file。

この例は外部ドメインにリンクしているため、HTTPSを使用している場合は、外部ドメインもSSL用に設定されていることを確認する必要があります。そうしないと、ユーザにSSLエラーや404エラーが表示される場合があります（たとえば、古いバージョンのPleskはHTTPとHTTPSを別々のフォルダに保存します）。CDNの場合は問題になりませんが、他のWebサイトの場合は問題になる可能性があります。

余談ですが、古いWebサイトの更新中にテストされ、META REFRESHのurl =の部分でも機能します。