Есть ли недостаток в использовании двойной косой черты для наследования протокола в URL? т.е. src = «// domain.com»

У меня есть таблица стилей, которая загружает изображения из внешнего домена, и мне нужно, чтобы она загружалась с 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или @importIE7 / 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-адреса протокола не могут работать изолированно; там должен быть соответствующий контекст. Таким образом, на типичной веб-странице нормально использовать библиотеку сценариев, но любые внешние ссылки всегда должны указывать протокол. Я попробовал один простой тест: //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'
}

Пожалуйста, проверьте всю ветку.

Кажется, сейчас это довольно распространенная техника. Недостатков нет, это только помогает унифицировать протокол для всех ресурсов на странице, поэтому его следует использовать везде, где это возможно.