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

232

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

Это не совсем легкое чтение, но section 4.2 of 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.

Совместим полностью Совместим с браузером? Есть ли какие-либо другие оговорки?

источник

2011-01-28 a paid nerd

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

ПРЕДУПРЕЖДЕНИЕ: не забудьте НИКОГДА пользовательские безрисковые URI в перенаправлении HTTP 3xx !! Заголовки HTTP не совместимы с этим URL-адресом. Если вам нужно перенаправить в зависимости от схемы, используйте mod_rewrite или аналогичный. – user2596282

@ user2596282 Экспериментирование в современных версиях Chrome и Firefox не согласуется с вами, равно как и модификация (все еще в проекте) HTTP 1.1. spec, определенный рабочей группой HTTPbis (см. https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p2-semantics.html#header.location). Возможно, то, что вы говорите, верно для некоторых браузеров; знаете ли вы, в частности, что сбои в отношении URL-адресов, связанных с протоколом, в заголовках местоположений? –

198

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

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

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

источник

2011-01-28 19:04:27

Спасибо, Дэйв :) –

+32

Хотя IE7/8 обрабатывает относительные URL-адреса протокола (ака.безрисковые URI), в большинстве случаев, когда таблицы стилей задаются с такими URL-адресами, он загружает их _twice_. (Так говорит [Steve Souders] (http://www.stevesouders.com/blog/2010/02/10/5a-missing-schema-double-download/)) – lucasrizoli

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

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

источник

2011-01-28 18:33:17 Gumbo

+11

Он даже рекомендуется и используется в шаблоне HTML5: http://html5boilerplate.com/ –

whit Да, вы не ответьте Да на «Есть ли какие-либо другие оговорки?» ? ;) –

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

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

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

источник

2011-06-16 11:23:44

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

+114

IE 7 и 8 следует избегать для хорошей производительности ... – Cerin

Вопрос о том, является ли один мог изменить все свои ссылки, чтобы быть протокольным родственник может быть спорными, рассматривая вопрос о том, насколько устойчивы РЕКОМЕНДУЕМОГО сделать это. Согласно Paul Irish:

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

источник

2015-01-17 13:10:42

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

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

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

Совместим полностью? Есть ли какие-либо другие оговорки?

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

Microsoft Internet Explorer, кажется, особенно чувствительны к этому, увидеть этот вопрос: Not able to load jQuery in Internet Explorer on localhost (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>

Я отправил этот ответ here а.

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

источник

2016-06-06 09:41:21 bg17aw

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

источник

2017-05-26 18:22:07 user1431784

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

ответ

Смежные вопросы