У меня есть таблица стилей, загружающая изображения из внешнего домена, и мне нужно загрузить ее с https://с защищенных страниц заказа и http://с других страниц на основе текущего URL. Я обнаружил, что запуск 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/
Обновление с 2014 года:
Теперь, когда SSL рекомендуется для всех и не имеет проблем с производительностью, этот метод теперь является анти-шаблоном. Если необходимый вам ресурс доступен по протоколу SSL, то всегда используйте ресурс
https://.
Один недостаток возникает, если ваши URL-адреса просматриваются вне контекста веб-страницы. Например, сообщение электронной почты, сидящее в почтовом клиенте (например, Outlook), фактически не имеет URL-адреса, и когда вы просматриваете сообщение, содержащее URL-адрес, относящийся к протоколу, вообще нет очевидного контекста протокола (само сообщение является независимым протокола, используемого для его получения, будь то POP3, IMAP, Exchange, uucp или что-то еще), поэтому у URL-адреса нет протокола относительно. Я не исследовал совместимость с почтовыми клиентами, чтобы увидеть, что они делают, когда им предоставлен недостающий обработчик протокола. Я предполагаю, что большинство из них угадает, что у него есть http. Apple Mail отказывается вводить URL-адрес без протокола. Это аналогично тому, как относительные URL-адреса не работают в электронной почте из-за аналогично отсутствующего контекста.
Аналогичные проблемы могут возникать и в других не-HTTP-контекстах, таких как твиты, SMS-сообщения, документы Word и т.д.
Более общее объяснение заключается в том, что анонимные URL-адреса протокола не могут работать изолированно; там должен быть соответствующим контекстом. В типичной веб-странице это так прекрасно, что в библиотеке script таким образом, но любые внешние ссылки должны всегда указывать протокол. Я попробовал один простой тест: //stackoverflow.com отображает file:///stackoverflow.com во всех браузерах, в которых я его пробовал, поэтому они действительно не работают сами по себе.
Причина может заключаться в предоставлении портативных веб-страниц. Если внешняя страница не переносится зашифрованной (http), зачем шифровать связанные скрипты? Это, по-видимому, является ненужной потерей производительности. В случае, если внешняя страница надежно транспортируется зашифрованной (https), то связанный контент также должен быть зашифрован. Если страница зашифрована, связанный контент отсутствует, IE, похоже, выдает предупреждение Смешанное содержимое. Причина в том, что злоумышленник может манипулировать сценариями на этом пути. См. http://ie.microsoft.com/testdrive/Browser/MixedContent/Default.html?o=1 для более продолжительного обсуждения.
Кампания HTTPS Everywhere из EFF предлагает использовать https, когда это возможно. У нас есть емкость сервера в эти дни, чтобы обслуживать веб-страницы, всегда зашифрованные.
Просто для полноты. Это было упомянуто в другом потоке:
'Две косые черты - это общая сокращенная версия любого протокола используется правильно "
if (plain http environment) {
use 'http://example.com/my-resource.js'
} else {
use 'https://example.com/my-resource.js'
}
Пожалуйста, проверьте полную версию.
Кажется, это довольно распространенная техника. Нет недостатков, это только помогает унифицировать протокол для всех активов на странице, поэтому следует использовать там, где это возможно.