У меня есть следующий элемент:
<script type="text/javascript" src="https://cdn.example.com/js_file.js"></script>
В этом случае сайт HTTPS, но сайт также может быть только HTTP. (Файл JS находится в другом домене.) Мне интересно, допустимо ли для удобства сделать следующее:
<script type="text/javascript" src="//cdn.example.com/js_file.js"></script>
Мне интересно, если это действительно, чтобы удалить http:
или https:
?
Кажется, это работает везде, где я тестировал, но есть ли случаи, когда это не работает?
Ответы:
Относительный URL-адрес без схемы (http: или https :) действителен для RFC 3986: «Универсальный идентификатор ресурса (URI): общий синтаксис», раздел 4.2 . Если клиент его подавляет, то это вина клиента, поскольку он не соответствует синтаксису URI, указанному в RFC.
Ваш пример действителен и должен работать. Я сам использовал этот метод относительных URL на сайтах с интенсивным трафиком и у меня не было жалоб. Также мы тестируем наши сайты в Firefox, Safari, IE6, IE7 и Opera. Все эти браузеры понимают этот формат URL.
источник
Он гарантированно работает в любом основном браузере (я не беру браузеры с долей рынка менее 0,05%). Черт возьми, это работает в Internet Explorer 3.0.
RFC 3986 определяет URI, состоящий из следующих частей:
При определении относительных URI ( раздел 5.2 ) вы можете пропустить любой из этих разделов, всегда начиная слева. В псевдокоде это выглядит так:
URI, который вы описываете, является относительным URI без схемы.
источник
Если родительская страница была загружена
file://
, то, вероятно, она не работает (она попытается получитьfile://cdn.example.com/js_file.js
, что, конечно, вы также можете предоставить локально).источник
script src="//..."
не работал! Я открывал HTML-файл локально!Многие люди называют этот протокол относительным URL.
Это вызывает двойную загрузку файлов CSS в IE 7 и 8 .
источник
Здесь я дублирую ответ в Скрытые возможности HTML :
источник
Это совершенно справедливо, чтобы оставить протокол. Спецификация URL была очень ясной в течение многих лет, и мне еще предстоит найти браузер, который этого не понимает. Я не знаю, почему эта техника не более известна; Это идеальное решение сложной проблемы пересечения границ HTTP / HTTPS. Подробнее здесь: переходы Http-https и относительные URL
источник
Просто добавьте это в смесь, если вы разрабатываете на локальном сервере, это может не сработать. Вам нужно указать схему, в противном случае браузер может предположить, что
src="//cdn.example.com/js_file.js"
это такsrc="file://cdn.example.com/js_file.js"
и будет, потому что вы не размещаете этот ресурс локально.Microsoft Internet Explorer, кажется, особенно чувствителен к этому, посмотрите на этот вопрос: не удается загрузить jQuery в Internet Explorer на локальный хост (WAMP)
Вероятно, вы всегда будете пытаться найти решение, которое работает во всех ваших средах с наименьшим количеством необходимых изменений.
Решение, используемое HTML5Boilerplate, заключается в том, чтобы иметь запасной вариант, когда ресурс загружен неправильно, но это работает, только если вы включите проверку:
ОБНОВЛЕНИЕ: HTML5Boilerplate теперь использует
<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js
после принятия решения об устаревании относительных URL протокола, см. [Здесь] [3].источник
Следуя указаниям gnud, в разделе 5.2 RFC 3986 говорится:
Так
//
правильно :-)источник
Да, это описано в RFC 3986 , раздел 5.2:
(редактировать: Ой, моя ссылка на RFC устарела).
источник
Это действительно правильно, как утверждают другие ответы. Однако вы должны заметить, что некоторые веб-сканеры установят для них значение 404, запрашивая их на своем сервере, как если бы они были локальными. (Они игнорируют двойную косую черту и рассматривают ее как одну косую черту).
Вы можете настроить правило на своем веб-сервере, чтобы перехватывать их и перенаправлять.
Например, с Nginx вы бы добавили что-то вроде:
Однако учтите, что если вы используете точки в своих URI, вам нужно будет повысить специфичность, иначе это приведет к перенаправлению этих страниц на несуществующие домены.
Кроме того, это довольно массивное регулярное выражение для каждого запроса - на мой взгляд, стоит наказывать несовместимые браузеры с 404-ыми по сравнению с (незначительным) ударом по производительности в большинстве совместимых браузеров.
источник
Мы видим 404 ошибки в наших журналах при использовании //somedomain.com в качестве ссылок на файлы JS.
Ссылки, которые вызывают 404-е годы, выглядят так: ref:
404 запроса:
Когда они регулярно появляются в журналах нашего веб-сервера, можно с уверенностью сказать, что: Все браузеры и боты НЕ соблюдают RFC 3986, раздел 4.2. Самым безопасным вариантом является включение протокола, когда это возможно.
источник
1. Резюме
Ответ за 2019 год: вы все еще можете использовать URL-адреса, относящиеся к протоколу, но этот метод является анти-паттерном .
Также:
Переход с URL-адресов, относящихся к протоколу,
https://
был бы неплох.2. Актуальность
Этот ответ актуален для января 2019 года. В дальнейшем данные этого ответа могут устареть.
3. Анти-шаблон
3.1. аргументация
Пол Ириш (Paul Irish) - инженер-фронтовик и адвокат разработчика для Google Chrome - напишите в декабре 2014 года :
3.2. Другие ссылки
3.3. Примеры
https
4. Процесс разработки
Например, я пытаюсь использовать clean-console .
KiraCleanConsole__cdn_links_demo.html
:Ссылка
//cdn.jsdelivr.net/npm/jquery@3.3.1/dist/jquery.min.js
действительна, но я получаю ошибку.Обратите внимание
file://cdn.jsdelivr.net/npm/jquery@3.3.1/dist/jquery.min.js
и прочитайте ответы Тило и bg17aw оfile://
.Я не знал об этом поведении и не мог понять, почему у меня такие проблемы с Pageres .
5. Сторонние инструменты
Я использую кликабельные URL-адреса Sublime Text. Используйте его, я могу просто открыть ссылки из моего текстового редактора в браузере.
Обе ссылки в примере действительны. Но первая ссылка, которую я могу успешно открыть в браузере, использует кликабельные URL, вторая ссылка - нет. Это может быть не очень удобно.
6. Заключение
Да:
Developing process
пункте, вы можете установить рабочий процесс разработки.Third-party tools
пункте, вы можете внести инструменты.Но вам не нужны эти дополнительные проблемы. Читайте информацию по ссылкам в
Anti-pattern
элементе: относящиеся к протоколу URL устарели.источник
Шаблон, который я вижу на html5-шаблоне :
Она проходит гладко на различных схемах , таких как
http
,https
,file
.источник
https://
для всегоhttps://
везде заключается в том, что вам необходимо постоянно проверять все внешние ссылки, чтобы увидеть, действительно ли они его поддерживают, и изменить их на,http://
если они этого не делают (иначе они не будут работать). Это может быть проблематично с большим количеством ссылок.https://
следует (или можно) использовать во всех ссылках, что неправильно.Так как ваш пример связан с внешним доменом, если вы используете HTTPS, вы должны проверить, что внешний домен также настроен для SSL. В противном случае ваши пользователи могут увидеть ошибки SSL и / или ошибки 404 (например, старые версии Plesk хранят HTTP и HTTPS в отдельных папках). Для CDN это не должно быть проблемой, но для любого другого сайта это может быть.
С другой стороны, проверено при обновлении старого сайта, а также работает в части url = META REFRESH.
источник