外部ドメインから画像をロードするスタイルシートがあり、現在のURLに基づいて、セキュアオーダーページからhttps://、他のページからhttp://からロードする必要があります。 URLをダブルスラッシュで開始すると、現在のプロトコルが継承されることがわかりました。すべてのブラウザーがこの手法をサポートしていますか?
html ex:
<img src="//cdn.domain.com/logo.png" />
css ex:
.class { background: url(//cdn.domain.com/logo.png); }
ブラウザが RFC 1808セクション4 、 RFC 2396セクション5.2 、または RFC 3986セクション5.2 をサポートする場合、実際にはページURLのスキームを使用します「//」で始まる参照の場合。
link
または@import
で使用すると、IE7/IE8は http://paulirish.com/2010/the-protocol-relative-url/ ごとに2回ファイルをダウンロードします=
2014年からの更新:
SSLが 全員に奨励 および パフォーマンスの懸念がない 、この手法はアンチパターンになりました。必要なアセットがSSLで利用可能な場合、always
https://
アセットを使用します。
URLがWebページのコンテキスト外で表示される場合、1つの欠点が発生します。たとえば、電子メールクライアント(Outlookなど)にある電子メールメッセージには事実上URLがなく、プロトコル相対URLを含むメッセージを表示しているときは、明らかなプロトコルコンテキストはまったくありません(メッセージ自体は独立しています) (POP3、IMAP、Exchange、uucp、その他)を取得するために使用されるプロトコルの(URLに関連するプロトコルがありません)。不足しているプロトコルハンドラーが表示されたときの動作を確認するために、電子メールクライアントとの互換性を調査したことはありません。 Apple Mailは、プロトコルなしでURLを入力することを拒否します。これは、同様にコンテキストが欠落しているために相対URLが電子メールで機能しない方法に似ています。
ツイート、SMSメッセージ、Word文書など)など、他の非HTTPコンテキストでも同様の問題が発生する可能性があります。
より一般的な説明は、匿名プロトコルURLは単独では機能しないということです。 there mustは関連するコンテキストであること。したがって、通常のWebページでは、そのようにスクリプトライブラリを取り込むことは問題ありませんが、外部リンクは常にプロトコルを指定する必要があります。私は1つの簡単なテストを試しました://stackoverflow.com
は、私が試したすべてのブラウザーでfile:///stackoverflow.com
にマップするため、reallydon '自分で働く。
その理由は、ポータブルWebページを提供することです。外側のページが暗号化されて(http)転送されない場合、リンクされたスクリプトを暗号化する必要があるのはなぜですか?これは不必要なパフォーマンスの低下のようです。場合には、外部ページは安全に暗号化されて転送され(https)、リンクされたコンテンツも暗号化される必要があります。ページが暗号化されている場合、リンクされたコンテンツではなく、IEはMixed Content警告を発行するようです。理由は攻撃者が途中でスクリプトを操作する可能性があります。詳細については、 http://ie.Microsoft.com/testdrive/Browser/MixedContent/Default.html?o=1 を参照してください。
EFFの HTTPS Everywhere キャンペーンは、可能な限りhttpsを使用することを提案しています。最近では、常に暗号化されたWebページを提供するサーバー容量があります。
完全を期すためだけに。これは別のスレッドで言及されました:
if (plain http environment) {
use 'http://example.com/my-resource.js'
} else {
use 'https://example.com/my-resource.js'
}
スレッド全体を確認してください。