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


148

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

html ex:

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

css ex:

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

1
это замедляет сайт ???
TheBlackBenzKid

2
нет причин, по которым это должно влиять на производительность, за исключением случаев, которые Медер перечислил ниже в своем ответе.
Роб Волк

Похоже, я был на что-то. Несколько месяцев назад разработчики Google начали использовать это соглашение на своей странице библиотек размещенного Javascript developers.google.com/speed/libraries/devguide
Роб Волк

10
Что если такой HTML-файл загружается локально (открывается непосредственно в браузере)? Похоже, Firefox (в нашем случае 28) не загружает удаленный ресурс. Имеет смысл, потому что тогда HTTP не является родительским протоколом. Но это было бы недостатком, по моему мнению.
Доктор Ян-Филипп Герке

Ответы:


86

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


8
это поддерживается во всех основных браузерах? (IE7, IE8, FF, Chrome, Safari)
Роб Волк

22
Учитывая, что первый RFC, описывающий его, RFC 1808, был написан 15 лет назад, а ссылки на URL являются ключом к функциональности веб-сайта, я думаю, можно с уверенностью сказать, что почти все основные браузеры уже поддерживают его. Но единственный способ узнать наверняка - просто попробовать самим и посмотреть, что получится.
Реми Лебо

2
Этот вопрос был связан с кем-то, кто задавал аналогичный вопрос, и я нашел его в RFC 1630 годом ранее (он был сформулирован по-другому, но все еще допускает рассматриваемый формат). Это вполне могло быть в той или иной форме документа, который был в ftp://info.cern.ch/pub/www/doc/http-spec.txtначале 1991 года, если бы у кого-то была архивная копия.
Джон Ханна

4
«2014.12.17: Теперь, когда SSL приветствуется для всех и не имеет проблем с производительностью, этот метод теперь является анти-шаблоном. Если нужный вам актив доступен по SSL, всегда используйте https: // asset». (цитата цитируется stackoverflow.com/a/27999789 )
joonas.fi

@ joonas.fi Это рассуждение второкурсное. SSL по-прежнему влияет на производительность и не требуется во многих приложениях. Я предпочитаю использовать его, конечно, но я бы не хотел, чтобы это применялось, например, в коде, который я развернул.
Отей

64

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

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

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


18
Исправлено в IE9, FWIW.
EricLaw

@EricLaw это исправлено в IE9 независимо от режима рендеринга или только в режиме стандартов и все еще не работает в режиме Quirks?
Scunliffe

Я почти уверен, что это было исправлено во всех режимах сканера. Вы видели где-нибудь иначе?
EricLaw

SSL , конечно же имеет влияние на производительность. EFF не пишет сервер-серверные интерфейсы, и этот другой сайт не имеет большого технического опыта. Кроме того, нельзя утверждать, что поставщик веб-сайта будет применять такие ограничения. Таким образом, люди, пишущие приложения на CSS и javascript, не должны полагаться на вопрос протокола.
Отей

63

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

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

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


5
Это действительно хороший момент, я действительно думал об этом, когда заснул прошлой ночью. Другая проблема заключается в том, что версия httpsили httpможет быть на самом деле не доступна, вы не всегда можете предположить, что это так.
Уэсли Мёрч

1
За пределами браузера вы, так сказать, сами по себе. Нельзя сказать, знает ли электронная почта или другой клиент о javascript, css и т. Д. Так что это довольно спорный вопрос об относительных URL?
Крис

Не спорный вопрос. Многие почтовые клиенты поддерживают JS, и браузеры, безусловно, могут при загрузке с file://. Это небольшой случай, но когда он подходит, это важно.
Jun-Dai Bates-Kobashigawa

Мне бы очень хотелось, чтобы был способ указать использование http, если текущим URL-адресом не является https, и в этом случае использовать https , а не указывать использование того же протокола, с которого были загружены текущие страницы , что фактически //является тем, что есть.
Jun-Dai Bates-Kobashigawa

2
Если вы укажете, например <base href="https://www.google.com">, вы можете просматривать контент за пределами веб-сайта. либо <img src="//www.google.com/images/srpr/logo11w.png">или<img src="images/srpr/logo11w.png">
зиг

3

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

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



-2

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.