Могу ли я изменить все мои ссылки http: // просто на //?


240

Дэйв Уорд говорит,

Это не совсем легкое чтение, но в разделе 4.2 RFC 3986 предусмотрены полностью определенные URL-адреса, в которых полностью отсутствует протокол (HTTP или HTTPS). Когда протокол URL-адреса пропущен, браузер использует протокол базового документа.

Проще говоря, эти URL-адреса без протокола позволяют использовать такую ​​ссылку в любом браузере, в котором вы ее попробуете:

//ajax.googleapis.com/ajax/libs/jquery/1.4.4/jquery.min.js

Поначалу это выглядит странно, но этот URL «без протокола» - лучший способ ссылаться на сторонний контент, доступный через HTTP и HTTPS.

Это, безусловно, решит кучу ошибок со смешанным контентом, которые мы видим на страницах HTTP - при условии, что наши ресурсы доступны как через HTTP, так и через HTTPS.

Это полностью совместимо с браузерами? Есть ли другие предостережения?


Я читал об этой технике в блоге IE некоторое время назад. Но когда я попробовал, это не сработало. Если мой сайт обслуживался по протоколу HTTPS, браузер (Chrome) все еще использовал HTTP для URL-адресов без протокола.
Кристофер Рамирес

10
ВНИМАНИЕ: НИКОГДА не забывайте использовать пользовательские схемы без URI в перенаправлениях HTTP 3xx !! Заголовки HTTP не совместимы с этим форматом URL. Если вам нужно перенаправить в зависимости от схемы, используйте mod_rewrite или подобное.
user2596282

1
@ user2596282 Эксперименты в современных версиях Chrome и Firefox не согласны с вами, как и (все еще в черновике) пересмотр HTTP 1.1. спецификация определена рабочей группой HTTPbis (см. svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/… ). Возможно, то, что вы говорите, верно для некоторых браузеров; Знаете ли вы что-нибудь конкретное, что терпит неудачу на относящихся к протоколу URL в заголовках местоположения?
Марк Амери


Не используйте их, они уродливы и излишни.
IllidanS4 хочет вернуть Монику

Ответы:


204

Я тщательно проверил это перед публикацией. Из всех браузеров, доступных для тестирования на Browsershots , я нашел только один, который неправильно обрабатывал относительный URL протокола: скрытый браузер * nix под названием Dillo .

Есть два недостатка, о которых я получил отзыв:

  1. URL без протокола могут работать не так, как ожидалось, когда вы «открываете» локальный файл в браузере, поскольку базовый протокол страницы будет file: ///. Особенно, когда вы используете URL без протокола для внешнего ресурса, такого как ресурс, размещенный на CDN. Однако использование локального веб-сервера, такого как Apache или IIS, для проверки адресов http: // localhost работает нормально.
  2. Очевидно, есть хотя бы одно приложение для чтения каналов iPhone, которое неправильно обрабатывает URL-адреса без протокола. Я не знаю, у кого проблема или насколько она популярна. Для размещения файла JavaScript это не является большой проблемой, так как читатели RSS обычно игнорируют содержимое JavaScript в любом случае. Тем не менее, это может быть проблемой, если вы используете эти URL-адреса для мультимедиа, например изображений внутри контента, который необходимо синдицировать через RSS (хотя одно приложение для чтения на одной платформе, вероятно, обеспечивает очень небольшое количество читателей).

33
В то время как IE7 / 8 хорошо обрабатывает относящиеся к протоколу URL-адреса (так называемые UL-схемы без схемы) в большинстве случаев, когда таблицы стилей указываются с такими URL-адресами, он загружает их дважды . (Так говорит Стив Соудерс )
lucasrizoli

3
Я обнаружил, что IE6 пытается преобразовать URI в относительный (т.е. удалить одну из ведущих косых черт). Это в linkэлементе. Например, при указании //fonts.googleapis.com/css?family=Rokkitt:400,700IE6 пытается загрузить http://mysite.com/fonts.googleapis.com/css/<...>. Не так хорошо, как хотелось бы!
CBono

2
Я обнаружил в своих журналах случаи, когда роботы веб-пауков (источник неизвестен) пытаются использовать ссылки без протокола и не обрабатывают их правильно.
Kzqai

3
Я видел много такого в своих журналах, не связанных с бездокументарными URL. Многие из этих пауков просто невероятно плохо написаны.
Дэйв Уорд

11
Важно понимать , что эти адреса являются не от протокола меньше , но от протокола относительного . Они получают свой протокол из своего контекста, и в отсутствие контекста они будут действовать как URL-адреса файлов в большинстве браузеров, что фактически означает, что они ломаются, не загружая намеченный контент. Хотя они будут работать при доставке по http, вы обнаружите, что если вы сохраните страницу и загрузите точно такой же HTML из локального файла, это не сработает, поскольку контекст другой. Единственный контекст, в котором вы должны их использовать - это http против https.
Синхро

37

Вопрос о том, можно ли изменить все их ссылки на протокол-относительные, может быть спорным, учитывая вопрос о том, следует ли это делать. По словам Пола Айриша :

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


Я думал точно так же. Какой смысл скачивать внешний ресурс через http, если он также доступен через https - даже если основной сайт использует http (чего не должно быть, но это уже другая тема).
joonas.fi

1
@ joonas.fi Единственное, о чем я могу думать, - это избегать смешанных предупреждений HTTP / HTTPS, которые могут генерироваться некоторыми браузерами
Охад Шнайдер

3
Предупреждения @Ohad_Schneider срабатывают только в том случае, если документ загружен по защищенному (https), а ресурсы по незащищенному (http). Я предлагал вам всегда загружать активы более надежно, даже если документ загружен небезопасно. Нет предупреждений и причин не использовать безопасный, что делает ненужным весь «относительный к протоколу URL».
joonas.fi

1
@Ohad_Schneider ой прости, я думаю, что я неправильно истолковал твои слова. Загрузка ресурсов через https, когда ваш документ превышает http, не должно выдавать никаких предупреждений. Но загрузка ресурсов через http, когда ваш документ превышает https, делает (и, вероятно, по умолчанию заблокирована, по крайней мере, в Chrome). Вы имели в виду случай, когда вы обслуживаете свой сайт по https, а внешние ресурсы доступны только по http? Да, это может быть проблемой, но я не думаю, что есть какая-либо серьезная сторонняя служба, которая не обслуживает их контент через https, иначе они все равно должны прекратить свою деятельность. :)
joonas.fi

@ joonas.fi Что? O_o Если у кого-то есть относительные URL-адреса протокола сайта HTTPSed (тогда), это не поможет решить проблему получения сторонних ресурсов через HTTP - никак И в любом случае, лучше иметь не такой чистый зеленый логотип SSL на странице HTTPS, чем вернуть его обратно HTTP только из-за того, что третьи лица еще не поддерживают HTTPS.
Пой

30

Если вы используете URL-адреса без протокола для загрузки таблиц стилей, IE 7 и 8 загрузят их дважды: http://www.stevesouders.com/blog/2010/02/10/5a-missing-schema-double-download/

Так что этого следует избегать для CSS, если вам нравится хорошая производительность.


5
Правда, однако это становится все менее веской причиной избегать использования бессхемных URL, поскольку доля рынка IE 7 и 8 сокращается.
Симон Лишке

15

Да, ссылки на сетевые пути уже были указаны в RFC 1808 и должны работать со всеми браузерами.


11
Это даже рекомендуется и используется в шаблонном коде HTML5: html5boilerplate.com
Фелипе Лима,

1
Да, вы не отвечаете «Да» на «Есть ли какие-либо другие предупреждения?» ? ;)
Каспар Клейн

2
@Caspar Kleijne: Я объяснил Да с остальной частью предложения.
Гамбо

1
Каспер, Гамбо на самом деле отвечал на два вопроса: «Является ли это полностью совместимым с браузером? Да, это ответ на первый вопрос.
Даррен Гриффит

4

Это полностью совместимо с браузерами? Есть ли другие предостережения?

Просто добавьте это в смесь, если вы разрабатываете на локальном сервере, это может не сработать. Вам нужно указать схему, в противном случае браузер может предположить, что src="//cdn.example.com/js_file.js"это так src="file://cdn.example.com/js_file.js"и будет, потому что вы не размещаете этот ресурс локально.

Microsoft Internet Explorer, кажется, особенно чувствителен к этому, посмотрите на этот вопрос: не удается загрузить jQuery в Internet Explorer на локальный хост (WAMP)

Вы, вероятно, всегда пытаетесь найти решение, которое работает во всех ваших средах с наименьшим количеством необходимых изменений.

Решение, используемое HTML5Boilerplate, состоит в том, чтобы иметь запасной вариант, когда ресурс загружен неправильно, но это работает, только если вы включите проверку:

<script src="//ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js"></script>
<!-- If jQuery is not defined, something went wrong and we'll load the local file -->
<script>window.jQuery || document.write('<script src="js/vendor/jquery-1.10.2.min.js"><\/script>')</script>

Я разместил этот ответ и здесь .

ОБНОВЛЕНИЕ: HTML5Boilerplate теперь использует <script src="https://ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js">после принятия решения об устаревании относительных URL-адресов протокола, см. Здесь .


1

У меня не было этих проблем при использовании: //domain.com - но вам нужно добавить двоеточие в начале. Йост хорошо написал об этом некоторое время назад. Но это потеряно в его куче сообщений в блоге.


проголосуйте за то, чтобы не указывать, где дополнительное: полезно. Везде я случайно оставил «:», сломал ссылку
грабить

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