Абсолютные и относительные URL

Я хотел бы знать различия между этими двумя типами URL-адресов: относительными URL-адресами (для изображений, CSS-файлами, файлами JS и т. Д.) И абсолютными URL-адресами.

Кроме того, какой из них лучше использовать?

Как правило, рекомендуется использовать относительные URL-адреса, чтобы ваш веб-сайт не был привязан к базовому URL-адресу, по которому он развернут в настоящее время. Например, он сможет работать на локальном хосте, а также на вашем публичном домене, без изменений.

Должен ли я использовать абсолютные или относительные URL?

Если под абсолютными URL-адресами вы подразумеваете URL-адреса, включающие схему (например, http / https) и имя хоста (например, yourdomain.com), никогда не делайте этого (для локальных ресурсов), потому что это будет ужасно поддерживать и отлаживать.

Допустим, вы использовали абсолютный URL везде в вашем коде, как <img src="http://yourdomain.com/images/example.png">. Теперь, что произойдет, когда вы собираетесь:

• переключиться на другую схему (например, http -> https)
• поменять доменные имена (test.yourdomain.com -> yourdomain.com)

В первом примере будет получено предупреждение о том, что на странице запрашивается небезопасный контент. Потому что все ваши URL-адреса жестко запрограммированы для использования http (: //yourdomain.com/images/example.png). А при запуске ваших страниц через https браузер ожидает загрузки всех ресурсов через https, чтобы предотвратить утечку информации.

Во втором примере, когда ваш сайт работает из тестовой среды, это будет означать, что все ресурсы по-прежнему указывают на ваш тестовый домен, а не на действующий домен.

Поэтому, чтобы ответить на ваш вопрос о том, использовать ли абсолютные или относительные URL-адреса: всегда используйте относительные URL-адреса (для локальных ресурсов).

Каковы различия между различными URL-адресами?

Сначала давайте взглянем на различные типы URL, которые мы можем использовать:

• http://yourdomain.com/images/example.png
• //yourdomain.com/images/example.png
• /images/example.png
• images/example.png

Какие ресурсы эти URL-адреса пытаются получить на сервере?

В приведенных ниже примерах я предполагаю, что веб-сайт работает из следующего местоположения на сервере /var/www/mywebsite.

http://yourdomain.com/images/example.png

Приведенный выше (абсолютный) URL пытается получить доступ к ресурсу /var/www/website/images/example.png. Этот тип URL - это то, что вы всегда хотели бы избегать при запросе ресурсов с вашего собственного сайта по причинам, изложенным выше. Однако это имеет свое место. Например, если у вас есть веб-сайт, http://yourdomain.comи вы хотите запросить ресурс из внешнего домена через https, вы должны использовать это. Например https://externalsite.com/path/to/image.png.

//yourdomain.com/images/example.png

Этот URL-адрес является относительным на основе текущей используемой схемы и должен почти всегда использоваться при включении внешних ресурсов (изображений, javascripts и т. Д.).

Этот тип URL использует текущую схему страницы, на которой он находится. Это означает, что вы находитесь на странице, http://yourdomain.comи на этой странице находится тег <img src="//yourdomain.com/images/example.png">изображения, в котором будет разрешен URL-адрес изображения http://yourdomain.com/images/example.png.
Когда вы были бы на странице http**s**://yourdomain.comи на этой странице есть тег изображения, <img src="//yourdomain.com/images/example.png">URL-адрес изображения будет разрешен в https://yourdomain.com/images/example.png.

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

Приведенный выше URL-адрес разрешается таким же образом на стороне сервера, что и предыдущий URL-адрес:

Приведенный выше (абсолютный) URL пытается получить доступ к ресурсу /var/www/website/images/example.png.

/images/example.png

Для локальных ресурсов это предпочтительный способ ссылки на них. Это относительный URL, основанный на корне документа ( /var/www/mywebsite) вашего сайта. Это означает, что когда у вас есть, <img src="/images/example.png">он всегда будет разрешен /var/www/mywebsite/images/example.png.

Если в какой-то момент вы решите сменить домен, он все равно будет работать, потому что он относительный.

images/example.png

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

Например, когда вы находитесь на странице http://yourdomain.comи используете <img src="images/example.png">ее, она будет разрешаться на сервере, /var/www/mywebsite/images/example.pngкак и ожидалось, однако, когда вы находитесь на странице http://yourdomain.com/some/pathи используете точно такой же тег изображения, он внезапно разрешится /var/www/mywebsite/some/path/images/example.png.

Когда использовать что?

При запросе внешних ресурсов вы, скорее всего, захотите использовать URL-адрес относительно схемы (если вы не хотите использовать другую схему), а при работе с локальными ресурсами вы хотите использовать относительные URL-адреса на основе корня документа.

Пример документа:

<!DOCTYPE html>
<html>
    <head>
        <title>Example</title>
        <link href='//fonts.googleapis.com/css?family=Lato:300italic,700italic,300,700' rel='stylesheet' type='text/css'>
        <link href="/style/style.css" rel="stylesheet" type="text/css" media="screen"></style>
    </head>
    <body>
        <img src="/images/some/localimage.png" alt="">
        <script src="//ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js" ></script>
    </body>
</html>

Некоторые (своего рода) дубликаты

• Безопасный способ писать URL-адреса, которые передаются между средами
• Как правильно разместить изображение на сайте?

Смотрите это: http://en.wikipedia.org/wiki/URI_scheme#Generic_syntax

foo://username:password@example.com:8042/over/there/index.dtb;type=animal?name=ferret#nose
\ /   \________________/\_________/ \__/            \___/ \_/ \_________/ \_________/ \__/
 |           |               |       |                |    |       |           |       |
 |       userinfo         hostname  port              |    |       parameter query  fragment
 |    \_______________________________/ \_____________|____|____________/
scheme                  |                               | |  |
 |                authority                           |path|
 |                                                    |    |
 |            path                       interpretable as filename
 |   ___________|____________                              |
/ \ /                        \                             |
urn:example:animal:ferret:nose               interpretable as extension

Абсолютный URL-адрес включает в себя части перед частью «path» - другими словами, он включает в себя схему ( httpin http://foo/bar/baz) и имя хоста ( fooinhttp://foo/bar/baz ) (и , возможно , порт, UserInfo и порт).

Относительные URL начинаются с пути.

Абсолютные URL-адреса, ну, в общем-то, абсолютные: местоположение ресурса можно определить, глядя только на сам URL-адрес. Относительный URL-адрес является в некотором смысле неполным: для его разрешения вам понадобятся схема и имя хоста, которые обычно берутся из текущего контекста. Например, на веб-странице по адресу

http://myhost/mypath/myresource1.html

Вы могли бы поставить ссылку так

<a href="pages/page1">click me</a>

В hrefатрибуте ссылки используется относительный URL-адрес, и если по нему щелкнуть, его необходимо разрешить, чтобы перейти по нему. В этом случае текущий контекст

http://myhost/mypath/myresource1.html

таким образом, схема, имя хоста и начальный путь к ним взяты и добавлены pages/page1, получая

http://myhost/mypath/pages/page1

Если бы ссылка была:

<a href="/pages/page1">click me</a>

(обратите внимание на /появление в начале URL), тогда это было бы решено как

http://myhost/pages/page1

потому что ведущий /указывает на корень хоста.

В веб-приложении я бы советовал использовать относительные URL для всех ресурсов, которые принадлежат вашему приложению. Таким образом, если вы измените расположение страниц, все будет продолжать работать. Любые внешние ресурсы (это могут быть страницы полностью за пределами вашего приложения, но также и статический контент, который вы доставляете через сеть доставки контента), всегда следует указывать с использованием абсолютных URL-адресов: если вы этого не сделаете, просто невозможно найти их, потому что они проживать на другом сервере.

Предположим, мы создаем дочерний сайт, файлы которого находятся в папке http://site.ru/shop .

1. Абсолютный URL

Link to home page
href="http://sites.ru/shop/"

Link to the product page
href="http://sites.ru/shop/t-shirts/t-shirt-life-is-good/"

2. Относительный URL

Link from home page to product page
href="t-shirts/t-shirt-life-is-good/"

Link from product page to home page
href="../../"

Хотя относительный URL-адрес выглядит короче абсолютного, но абсолютные URL-адреса предпочтительнее, поскольку ссылку можно использовать без изменений на любой странице сайта.

Промежуточные случаи

Мы рассмотрели два крайних случая: «абсолютно» абсолютные и «абсолютно» относительные URL. Но в этом мире все относительно. Это также относится к URL-адресам. Каждый раз, когда вы говорите об абсолютном URL, вы всегда должны указывать относительно чего.

3. Протокол относительно URL

Link to home page
href="//sites.ru/shop/"

Link to product page
href="//sites.ru/shop/t-shirts/t-shirt-life-is-good/"

Google рекомендует такой URL. Однако теперь считается, что http: // и https: // - это разные сайты.

4. Корневой URL

Т.е. относительно корневой папки домена.

Link to home page
href="/shop/"

Link to product page
href="/shop/t-shirts/t-shirt-life-is-good/"

Это хороший выбор, если все страницы находятся в одном домене. Когда вы перемещаете свой сайт в другой домен, вам не нужно делать массовые замены доменного имени в URL.

5. Базовый относительный URL (относительный к домашней странице)

Тег <base> указывает базовый URL, который автоматически добавляется ко всем относительным ссылкам и привязкам. Базовый тег не влияет на абсолютные ссылки. В качестве базового URL мы будем указывать домашнюю страницу: <base href = "http://sites.ru/shop/">.

Link to home page
href=""

Link to product page
href="t-shirts/t-shirt-life-is-good/"

Теперь вы можете перенести свой сайт не только в любой домен, но и в любую подпапку. Просто имейте в виду, что, хотя URL-адреса выглядят как относительные, на самом деле они являются абсолютными. Особенно обратите внимание на якоря. Для навигации по текущей странице мы должны написать href = "t-shirts / t-shirt-life-is-good / # comments" not href = "# comments". Последний выкинет на домашнюю страницу.

Вывод

Для внутренних ссылок я использую базовые URL (5). Для внешних ссылок и информационных бюллетеней я использую абсолютные URL (1).

Есть действительно три типа, которые следует обсудить в явном виде. На практике, хотя URL-адреса были абстрагированы для обработки на более низком уровне, и я бы сказал, что разработчики могут прожить всю свою жизнь, не написав ни одного URL-адреса вручную.

абсолют

Абсолютные URL привязывают ваш код к протоколу и домену. Это можно преодолеть с помощью динамических URL.

<a href=“https://dev.example.com/a.html?q=”>https://dev.example.com/a.html?q=</a>

Абсолютные плюсы:

1. Контроль . Субдомен и протокол можно контролировать. Люди, которые входят через неясный поддомен, будут направлены в соответствующий поддомен. Вы можете переключаться между безопасным и небезопасным в зависимости от ситуации.

2. Конфигурируемый - разработчики любят вещи, чтобы быть абсолютным. Вы можете разработать аккуратные алгоритмы при использовании абсолютных URL. URL-адреса можно настроить так, чтобы URL-адрес можно было обновлять по всему сайту с помощью одного изменения в одном файле конфигурации.

3. Ясновидение - Вы можете искать людей, которые очищают ваш сайт, или, возможно, получить дополнительные внешние ссылки.

Корень Относительный

Корневые относительные URL привязывают ваш код к базовому URL. Это можно преодолеть с помощью динамических URL-адресов и / или базовых тегов .

<a href=“/index.php?q=”>.example.com/index.php?q=</a>

Root Относительные плюсы:

1. Настраиваемый - базовый тег делает их относительными к любому выбранному вами корню, упрощая переключение доменов и внедрение шаблонов.

Родственник

Относительные URL связывают ваш код со структурой каталогов. Нет способа преодолеть это. Относительные URL-адреса полезны только в файловых системах для обхода каталогов или в качестве ярлыка для простой задачи.

<a href=“index.php?q=”>index.php?q=</a>
<link src=“../.././../css/default.css” />

Относительные минусы:

1. КОНФУЗИНГ - Сколько это точек? сколько папок это? Где файл? Почему это не работает?

2. ТЕХНИЧЕСКОЕ ОБСЛУЖИВАНИЕ - Если файл случайно перемещен, ресурсы перестают загружаться, ссылки отправляют пользователя на неправильные страницы, данные формы могут быть отправлены на неправильную страницу. Если файл НУЖДАЕТСЯ в перемещении, все ресурсы, которые собираются прекратить загрузку, и все ссылки, которые будут некорректными, должны быть обновлены.

3. НЕ МАСШТАБИРУЕТСЯ. Когда веб-страницы становятся более сложными и представления начинают повторно использоваться на нескольких страницах, относительные ссылки будут относиться к файлу, в который они были включены. Если у вас есть навигационный фрагмент HTML, который будет на каждой странице, то относительный будет относительным ко многим различным местам. Первое, что люди понимают, когда начинают создавать шаблон, это то, что им нужен способ управления URL-адресами.

4. ВЫЧИСЛЕНО - они реализованы вашим браузером (надеюсь, в соответствии с RFC). См. Главу 5 в RFC3986 .

5. OOPS! - Ошибки или опечатки могут привести к ловушке паука.

Эволюция маршрутов

Разработчики прекратили писать URL-адреса в том смысле, который здесь обсуждается. Все запросы относятся к индексному файлу веб-сайта и содержат строку запроса, то есть маршрут. Маршрут можно представить как мини-URL, который сообщает вашему приложению контент, который будет сгенерирован.

<a href="<?=Route::url('named_url', array('first' => 'my', 'last' => 'whacky'))?>">
    http://dev.example.com/index.php/my:whacky:url
</a>

Маршруты Плюсы:

1. Все преимущества абсолютных URL.
2. Использование любого символа в URL.
3. Больше контроля (хорошо для SEO).
4. Возможность алгоритмически генерировать URL. Это позволяет настраивать URL-адреса. Изменение URL-адреса - это одно изменение в одном файле.
5. Не нужно за 404 не основывать. Резервные маршруты могут отображать карту сайта или страницу ошибки.
6. Удобная защита косвенного доступа к файлам приложения. Охранные заявления могут убедиться, что все прибывают по соответствующим каналам.
7. Практичность в подходе MVC.

Мой дубль

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

Если он предназначен для использования на вашем веб-сайте, лучше использовать относительный URL-адрес, например, если вам нужно переместить веб-сайт на другое доменное имя или просто выполнить локальную отладку, вы можете это сделать.

Посмотрите, что делает stackoverflow (ctrl + U в Firefox):

<a href="/users/recent/90691"> // Link to an internal element

В некоторых случаях они используют абсолютные URL:

<link rel="stylesheet" href="http://sstatic.net/so/all.css?v=5934">

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

Я собираюсь не согласиться с большинством здесь.

Я думаю, что схема относительных URL-адресов «хороша», когда вы хотите быстро запустить и запустить что-то, а не мыслить нестандартно, особенно если ваш проект мал, с несколькими разработчиками (или только вами).

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

Когда вы сравниваете абсолютные и относительные URL по существу, Абсолют побеждает. Зачем? Потому что это никогда не сломается. Когда-либо. Абсолютный URL это именно то, что он говорит. Загвоздка в том, когда вам нужно поддерживать абсолютные URL.

Слабый подход к абсолютной ссылке на URL - это жесткое кодирование всего URL. Не очень хорошая идея и, вероятно, виновник того, почему люди считают их опасными / злыми / раздражающими в обслуживании. Лучший подход - написать простой в использовании генератор URL. Это легко написать, и может быть невероятно мощными: они автоматически определяют ваш протокол, легко настраиваются (буквально устанавливают URL-адрес для всего приложения) и т. Д., И он самостоятельно внедряет ваш домен. Хорошая вещь об этом: вы продолжаете кодировать, используя относительные URL, и во время выполнения приложение вставляет ваши URL как полные абсолюты на лету. Потрясающие.

Учитывая, что практически все современные сайты используют какой-то динамический бэкэнд, в интересах указанного сайта сделать это таким образом. Абсолютные URL-адреса делают больше, чем просто дают вам уверенность в том, на что они указывают, они также могут повысить эффективность SEO.

Я мог бы добавить, что аргумент, что абсолютные URL-адреса каким-то образом изменят время загрузки страницы, является мифом. Если ваш домен весит больше нескольких байтов и вы используете модем в 1980-х годах, конечно. Но это просто не тот случай. https://stackoverflow.com/ имеет размер 25 байт, а файл "topbar-sprite.png", который они используют для области навигации сайта, весит 9+ кб. Это означает, что дополнительные данные URL составляют 0,2% от загруженных данных по сравнению со спрайтовым файлом, и этот файл даже не считается значительным ударом по производительности.

Это большое неоптимизированное полностраничное фоновое изображение с большей вероятностью замедлит время загрузки.

Интересный пост о том, почему относительные URL не следует использовать, находится здесь: http://yoast.com/relative-urls-issues/

Например, проблема, которая может возникнуть у родственников, заключается в том, что иногда сопоставления серверов (обратите внимание на большие, испорченные проекты) не совпадают с именами файлов, и разработчик может сделать предположение об относительном URL, который просто не соответствует правда. Я только что видел это сегодня в проекте, в котором я участвую, и он принес мне целую страницу.

Или, возможно, разработчик забыл переключить указатель и внезапно Google проиндексировал всю вашу тестовую среду. Ой - дублированный контент (плохо для SEO!).

Абсолюты могут быть опасными, но при правильном использовании таким образом, который не может нарушить вашу сборку, они оказываются более надежными. Посмотрите на статью выше, которая дает множество причин, почему генератор URL-адресов Wordpress супер.

:)

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

Есть довольно приличная статья об абсолютных и относительных URL , посмотрите ее.

URL - адрес , который начинается с URL - схемы и схемы определенной части ( http://, https://, ftp://и т.д.) является абсолютным URL - адрес.

Любой другой URL-адрес является относительным URL-адресом и нуждается в базовом URL-адресе, из которого разрешается относительный URL-адрес (и, следовательно, зависит от него), то есть в URL-адресе ресурса, в котором используется ссылка, если не объявлено иначе.

Взгляните на RFC 2396 - Приложение C, где приведены примеры разрешения относительных URL.

Допустим, у вас есть сайт www.yourserver.com. В корневой директории для веб-документов у вас есть поддиректория изображений, в которой у вас есть myimage.jpg.

Абсолютный URL-адрес определяет точное местоположение документа, например:

http://www.yourserver.com/images/myimage.jpg

Относительный URL-адрес определяет местоположение относительно текущего каталога , например, если вы находитесь в корневом веб-каталоге, в котором находится ваше изображение:

images/myimage.jpg

(относительно этого корневого каталога)

Вы должны всегда использовать относительные URL, где это возможно. Если вы переместите сайт на www.anotherserver.com, вам придется обновить все абсолютные URL-адреса, которые указывали на www.yourserver.com, относительные будут продолжать работать как есть.

Для каждой системы, поддерживающей относительное разрешение URI, относительные и абсолютные URI служат одной и той же цели: ссылкам. И они могут быть использованы взаимозаменяемо. Таким образом, вы могли бы решить в каждом случае по-разному. Технически они предоставляют одинаковые ссылки.

Чтобы быть точным, с каждым относительным URI уже есть абсолютный URI. И это базовый URI, против которого разрешается относительный URI. Таким образом, относительный URI на самом деле является функцией поверх абсолютных URI.

И именно поэтому с относительными URI вы можете сделать больше, чем с одним абсолютным URI - это особенно важно для статических веб-сайтов, которые в противном случае не могли бы быть настолько гибкими в обслуживании по сравнению с абсолютными URI.

Эти положительные эффекты относительного разрешения URI могут также использоваться для динамической разработки веб-приложений. Абсолютные URI с негибкостью вводить также проще в динамической среде, поэтому некоторые разработчики, которые не уверены в разрешении URI и о том, как правильно его реализовать и управлять им (не всегда легко), часто выбирают использование абсолютного URI в динамической части веб-сайта, поскольку они могут вводить другие динамические функции (например, переменную конфигурации, содержащую префикс URI), чтобы обойти эту негибкость.

Так в чем же польза от использования абсолютных URI? Технически нет, но я бы сказал, что относительные URI являются более сложными, потому что их необходимо сопоставить с так называемым абсолютным базовым URI. Даже разрешение строго определено с годами, вы можете столкнуться с клиентом, у которого есть ошибка в разрешении URI. Поскольку абсолютные URI не нуждаются в каком-либо разрешении, использование абсолютных URI не имеет риска столкнуться с ошибочным поведением клиента при относительном разрешении URI. Так насколько велик этот риск на самом деле? Ну, это очень редко. Я знаю только об одном интернет-браузере, у которого была проблема с относительным разрешением URI. И это было не вообще, а только в очень (неясном) случае.

Рядом с HTTP-клиентом (браузером), возможно, сложнее и для автора гипертекстовых документов или кода. Здесь абсолютный URI имеет то преимущество, что его проще тестировать, так как вы можете просто ввести его как есть в адресную строку браузера. Однако, если это не просто ваша часовая работа, вам чаще всего полезно понять абсолютную и относительную обработку URI, чтобы вы могли использовать преимущества относительного связывания.

Я бы искренне рекомендовал относительные URL для указания битов того же сайта на другие биты того же сайта.

Не забывайте, что для изменения HTTPS - даже если на том же сайте - понадобится абсолютный URL.