Відповіді:
Загалом, найкращою практикою є використання відносних URL-адрес, щоб ваш веб-сайт не був прив’язаний до базової URL-адреси, де він зараз розміщений. Наприклад, він зможе працювати на localhost, а також на вашому відкритому доступі, без змін.
Якщо під абсолютними URL-адресами ви маєте на увазі URL-адреси, включаючи схему (наприклад, http / https) та ім'я хоста (наприклад, yourdomain.com), цього ніколи не роблять (для місцевих ресурсів), оскільки це буде жахливо підтримувати та налагоджувати.
Скажімо, ви використовували абсолютну URL-адресу скрізь у коді <img src="http://yourdomain.com/images/example.png">
. Тепер, що буде, коли ви збираєтесь:
У першому прикладі, що станеться, ви отримаєте попередження про небезпечний вміст, який запитується на сторінці. Оскільки всі ваші URL-адреси важко кодуються для використання http (: //yourdomain.com/images/example.png). А під час запуску ваших сторінок через https браузер очікує, що всі ресурси будуть завантажені через https, щоб уникнути витоку інформації.
У другому прикладі, коли ви розміщуєте свій веб-сайт у прямому ефірі з тестового середовища, це означає, що всі ресурси все ще вказують на ваш тестовий домен, а не на живий домен.
Отже, щоб відповісти на ваше запитання щодо використання абсолютних чи відносних URL-адрес: завжди використовуйте відносні URL-адреси (для місцевих ресурсів).
Спочатку давайте ознайомимося з різними типами URL-адрес, якими ми можемо користуватися:
http://yourdomain.com/images/example.png
//yourdomain.com/images/example.png
/images/example.png
images/example.png
У наведених нижче прикладах я припускаю, що веб-сайт працює з наступного місця на сервері /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>
Дивіться це: 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-адреса включає частини перед частиною "шлях" - іншими словами, вона включає схему ( http
in http://foo/bar/baz
) та ім'я хоста ( foo
in http://foo/bar/baz
) (і необов'язково порт, користувальницьку інформацію та порт).
Відносні 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-адрес: якщо у вас немає, просто немає способу їх знайти, оскільки вони проживати на іншому сервері.
//example.com/…
, ?foobar
а #foobar
також є відносними URL-адресами і не починаються з шляху до URL-адреси (добре, адже ?foobar
можна сказати, що він починається з порожнього шляху).
//example.com/…
URL-адреси типу називаються відносними? це для мене нове.
Припустимо, ми створюємо підрозділ, файли якого знаходяться у папці http://site.ru/shop .
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/"
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-адресу, ви завжди повинні вказувати відносно того, що.
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: // - це різні сайти.
Тобто відносно кореневої папки домену.
Link to home page
href="/shop/"
Link to product page
href="/shop/t-shirts/t-shirt-life-is-good/"
Це хороший вибір, якщо всі сторінки знаходяться в одному домені. Переміщуючи свій веб-сайт на інший домен, вам не доведеться робити масову заміну доменного імені в 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 = "футболки / футболка-життя-це-добре / # коментарі" не href = "# коментарі". Останній закине на домашню сторінку.
Для внутрішніх посилань я використовую базові 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>
Абсолютні плюси:
Контроль - субдоменом та протоколом можна керувати. Люди, які входять через незрозумілий субдомен, будуть переведені у відповідний субдомен. Ви можете переходити вперед і назад між безпечним і незахищеним, якщо це доречно.
Настроюється - розробники люблять, щоб речі були абсолютними. Ви можете створити чіткі алгоритми, використовуючи абсолютні URL-адреси. URL-адреси можна налаштувати так, щоб URL-адресу можна було оновити на всьому сайті за допомогою однієї зміни в одному файлі конфігурації.
Виразність - Ви можете шукати людей, які скреблі ваш сайт, або, можливо, підбирати додаткові зовнішні посилання.
Кореневі URL-адреси відносять ваш код до базової URL-адреси. Це можна подолати за допомогою динамічних URL-адрес та / або базових тегів .
<a href=“/index.php?q=”>.example.com/index.php?q=</a>
Кореневі відносні плюси:
Відносні URL-адреси прив'язують ваш код до структури каталогу. Неможливо цього подолати. Відносні URL-адреси корисні лише у файлових системах для проходження каталогів або як ярлик для найголовнішого завдання.
<a href=“index.php?q=”>index.php?q=</a>
<link src=“../.././../css/default.css” />
Відносні мінуси:
ПЛІШИТИ - Скільки це крапок? скільки папок це? Де файл? Чому це не працює?
ОБСЛУГОВУВАННЯ - Якщо файл випадково переміщений, ресурси припиняють завантаження, посилання надсилають користувача на неправильні сторінки, дані форми можуть бути надіслані на неправильну сторінку. Якщо файл НЕОБХІДНО перенести всі ресурси, які збираються припинити завантаження, і всі посилання, які будуть неправильними, потрібно оновити.
НЕ МАЄТЬСЯ - Коли веб-сторінки стають складнішими і перегляди починають повторно використовуватись на кількох сторінках, відносні посилання будуть відносно файлу, до якого вони були включені. Якщо у вас є фрагмент навігації HTML, який буде розміщений на кожній сторінці, то відносність буде відносно багатьох різних місць. Перше, що люди розуміють, коли вони починають створювати шаблон, - це те, що їм потрібен спосіб управління URL-адресами.
КОМП'ЮТЕРНІ - Вони реалізовані вашим браузером (сподіваємось згідно з RFC). Див. Розділ 5 у RFC3986 .
OOPS! - Помилки або помилки можуть призвести до павукових пасток.
Розробники перестали писати URL-адреси в тому сенсі, про який мова йде тут. Усі запити призначені для індексного файлу веб-сайту і містять рядок запиту, також маршрут. Маршрут можна розглядати як міні-URL, який повідомляє вашій програмі вміст, який потрібно створити.
<a href="<?=Route::url('named_url', array('first' => 'my', 'last' => 'whacky'))?>">
http://dev.example.com/index.php/my:whacky:url
</a>
Плюси плюсів:
Більшість людей так чи інакше використовуватиме всі три форми у своїх проектах. Головне - зрозуміти їх і вибрати той, який найкраще підходить для виконання завдання.
Якщо він використовується для вашого веб-сайту, краще використовувати відносну 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-адреси становлять .2% завантажених даних порівняно з файлом спрайту, і цей файл навіть не вважається великим хітом продуктивності.
Це велике, неоптимізоване, повне зображення фонового зображення набагато частіше сповільнить ваші завантаження.
Цікавий пост про те, чому відносні URL-адреси не слід використовувати тут: http://yoast.com/relative-urls-isissue/
Наприклад, проблема, яка може виникнути у родичів, полягає в тому, що іноді відображення серверів (пам'ятайте про великі, заплутані проекти) не співпадає з іменами файлів, і розробник може зробити припущення щодо відносної URL-адреси, яка просто не є правда. Я щойно це побачив на проекті, над яким я працюю, і він звів всю сторінку.
Або, можливо, розробник забув переключити вказівник і раптом Google проіндексував всю вашу тестову середу. Whoops - дублюючи вміст (погано для SEO!).
Абсолюти можуть бути небезпечними, але при правильному використанні та у спосіб, який не може порушити вашу конструкцію, вони виявляються більш надійними. Подивіться на статтю, в якій наведено купу причин, чому генератор URL-адрес Wordpress є надзвичайним.
:)
/
посилання на базовий шлях? тобто /products/wallets/thing.html
на thing.html
відміну відhttp://www.myshop.com/products/wallets/thing.html
echo Route::url('route_name')
для створення абсолютної URL-адреси, використовуючи URL-адресу сайту та інформацію про маршрути, з можливістю зробити це через HTTPS.
У більшості випадків відносні 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, щоб ви могли реально використовувати переваги відносного зв’язку.