it-roy-ru.com

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

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

hTML например:

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

css ex:

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

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

84
Remy Lebeau

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

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

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

64
meder omuraliev

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

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

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

59
Synchro

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

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

3
koppor

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

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

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

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

0
escapedcat