Чи є якісь недоліки використання провідного подвійного косого кута для успадкування протоколу в 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'
}

Перевірте повну нитку.

Здається, зараз це досить поширена техніка. Недоліків немає, він лише допомагає уніфікувати протокол усіх активів на сторінці, тому його слід використовувати, де це можливо.