Есть ли недостаток в использовании двойной косой черты для наследования протокола в URL?т.е. src = "// domain.com" - PullRequest
145 голосов
/ 11 января 2011

У меня есть таблица стилей, которая загружает изображения из внешнего домена, и мне нужно, чтобы она загружалась с https: // со страниц безопасного заказа и http: // с других страниц на основе текущего URL. Я обнаружил, что запуск URL с двойной косой чертой наследует текущий протокол. Все ли браузеры поддерживают эту технику?

HTML например:

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

css ex:

.class { background: url(//cdn.domain.com/logo.png); }

Ответы [ 6 ]

85 голосов
/ 11 января 2011

Если браузер поддерживает RFC 1808 Раздел 4 , RFC 2396 Раздел 5.2 или RFC 3986 Раздел 5.2 , то он действительно будет использовать схему URL страницы.для ссылок, которые начинаются с "//".

64 голосов
/ 11 января 2011

При использовании на link или @import IE7 / IE8 будет загружать файл дважды за http://paulirish.com/2010/the-protocol-relative-url/

Обновление с 2014 года:

Теперь, когда SSL рекомендуется для всех и не имеет проблем с производительностью , этот метод теперь является анти-паттерном .Если нужный вам актив доступен по SSL, то всегда использует актив https://.

60 голосов
/ 15 октября 2012

Один недостаток возникает, если ваши URL-адреса просматриваются вне контекста веб-страницы. Например, почтовое сообщение, находящееся в почтовом клиенте (скажем, Outlook), по сути, не имеет URL-адреса, а при просмотре сообщения, содержащего относящийся к протоколу URL-адрес, вообще отсутствует очевидный контекст протокола (само сообщение является независимым). протокола, используемого для его извлечения, будь то POP3, IMAP, Exchange, uucp или что-то еще), поэтому в URL-адресе нет протокола, относительно которого он должен быть. Я не исследовал совместимость с почтовыми клиентами, чтобы увидеть, что они делают, когда представлены с отсутствующим обработчиком протокола - я предполагаю, что большинство из них примет http. Apple Mail отказывается вводить URL-адрес без протокола. Это аналогично тому, как относительные URL не работают в электронной почте из-за аналогичного отсутствия контекста.

Подобные проблемы могут возникнуть в других не HTTP-контекстах, таких как твиты, SMS-сообщения, документы Word и т. Д.

Более общее объяснение состоит в том, что анонимные URL-адреса протоколов не могут работать изолированно; должен быть соответствующим контекстом. Таким образом, на типичной веб-странице нормально использовать библиотеку сценариев, но любые внешние ссылки всегда должны указывать протокол. Я попробовал один простой тест: //stackoverflow.com отображается на file:///stackoverflow.com во всех браузерах, в которых я его пробовал, чтобы они действительно не работали сами по себе.

3 голосов
/ 15 декабря 2013

Причина может заключаться в предоставлении портативных веб-страниц. Если внешняя страница не передается в зашифрованном виде (http), почему связанные сценарии должны быть зашифрованы? Это кажется ненужной потерей производительности. В случае, если внешняя страница надежно транспортируется в зашифрованном виде (https), то связанный контент также должен быть зашифрован. Если страница зашифрована, связанный контент отсутствует, IE, похоже, выдает предупреждение Mixed Content . Причина в том, что злоумышленник может манипулировать сценариями в пути. См. http://ie.microsoft.com/testdrive/Browser/MixedContent/Default.html?o=1 для более подробного обсуждения.

Кампания HTTPS Everywhere от EFF предлагает по возможности использовать https. В наши дни у нас есть возможности сервера обслуживать веб-страницы всегда в зашифрованном виде.

0 голосов
/ 21 февраля 2014

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

0 голосов
/ 13 января 2014

Просто для полноты.Это было упомянуто в другой ветке:

'Две прямые косые черты - это обычное сокращение для любого протокола, который используется правильно'

if (plain http environment) {
use 'http://example.com/my-resource.js'
} else {
    use 'https://example.com/my-resource.js'
}

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

...