URLs absolus et relatifs

Question

Je voudrais connaître les différences entre ces deux types d'URL : les URL relatives (pour les images, les fichiers CSS, les fichiers JS, etc.) et les URL absolues.

En outre, laquelle est la meilleure à utiliser ?

Answer 1

Dois-je utiliser des URL absolues ou relatives ?

Si par "URL absolues" vous entendez des URL comprenant le schéma (par exemple http / https) et le nom d'hôte (par exemple yourdomain.com), ne le faites jamais (pour les ressources locales) car la maintenance et le débogage seront terribles.

Disons que vous avez utilisé l'URL absolue partout dans votre code, par exemple <img src="http://yourdomain.com/images/example.png"> . Maintenant, que va-t-il se passer quand tu vas.. :

• passer à un autre schéma (par exemple http -> https)
• changer de nom de domaine (test.votredomaine.com -> votredomaine.com)

Dans le premier exemple, vous obtiendrez des avertissements concernant le contenu dangereux demandé sur la page. Parce que toutes vos URL sont codées en dur pour utiliser http(://votredomaine.com/images/exemple.png). Et lorsque vous exécutez vos pages en https, le navigateur s'attend à ce que toutes les ressources soient chargées en https pour éviter les fuites d'informations.

Dans le second exemple, lorsque vous mettez votre site en ligne à partir de l'environnement de test, cela signifie que toutes les ressources pointent toujours vers votre domaine de test au lieu de votre domaine réel.

Donc, pour répondre à votre question sur l'utilisation des URL absolues ou relatives : utilisez toujours les URL relatives (pour les ressources locales).

Quelles sont les différences entre les différentes URL ?

Voyons d'abord les différents types d'url que nous pouvons utiliser :

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

À quelles ressources ces URLs tentent-ils d'accéder sur le serveur ?

Dans les exemples ci-dessous, je suppose que le site web fonctionne à partir de l'emplacement suivant sur le serveur /var/www/mywebsite .

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

L'URL ci-dessus (absolue) tente d'accéder à la ressource /var/www/website/images/example.png . Ce type d'URL est quelque chose que vous pourriez toujours à éviter pour demander des ressources à partir de votre propre site web pour les raisons exposées ci-dessus. Cependant, elle a sa place. Par exemple, si vous avez un site web http://yourdomain.com et que vous voulez demander une ressource à partir d'un domaine externe via https, vous devez utiliser ceci. Par exemple https://externalsite.com/path/to/image.png .

//yourdomain.com/images/example.png

Cette URL est relative en fonction du schéma actuel utilisé et devrait presque toujours être utilisée pour inclure des ressources externes (images, javascripts, etc.).

Ce type d'URL utilise le schéma actuel de la page sur laquelle il se trouve. Cela signifie que vous êtes sur la page http://yourdomain.com et sur cette page se trouve une balise d'image <img src="//yourdomain.com/images/example.png"> l'URL de l'image serait résolue dans http://yourdomain.com/images/example.png .
Quand vous auriez été sur la page http**s**://yourdomain.com et sur cette page se trouve une balise d'image <img src="//yourdomain.com/images/example.png"> l'URL de l'image serait résolue dans https://yourdomain.com/images/example.png .

Cela permet d'éviter de charger des ressources via https lorsque cela n'est pas nécessaire et de s'assurer automatiquement que la ressource est demandée via https lorsque cela est nécessaire. est nécessaire.

L'URL ci-dessus se résout de la même manière côté serveur que l'URL précédente :

L'URL (absolue) ci-dessus tente d'accéder à la ressource /var/www/website/images/example.png .

/images/example.png

Pour les ressources locales, c'est la manière préférée de les référencer. Il s'agit d'une URL relative basée sur la racine du document ( /var/www/mywebsite ) de votre site web. Cela signifie que lorsque vous avez <img src="/images/example.png"> elle le fera toujours décider de /var/www/mywebsite/images/example.png .

Si, à un moment donné, vous décidez de changer de domaine, le système fonctionnera toujours, car il est relatif.

images/example.png

Il s'agit également d'une URL relative, mais un peu différente de la précédente. Cette URL est relative au chemin d'accès actuel. Cela signifie qu'elle sera résolue par des chemins différents selon l'endroit où vous vous trouvez dans le site.

Par exemple, lorsque vous êtes sur la page http://yourdomain.com et vous utilisez <img src="images/example.png"> il se résoudrait sur le serveur en /var/www/mywebsite/images/example.png comme prévu, cependant lorsque vous êtes sur la page http://yourdomain.com/some/path et que vous utilisez exactement la même balise d'image, elle se résout soudainement en /var/www/mywebsite/some/path/images/example.png .

Quand utiliser quoi ?

Lorsque vous demandez des ressources externes, vous voulez probablement utiliser une URL relative au schéma (à moins que vous ne vouliez forcer un schéma différent) et lorsque vous traitez des ressources locales, vous voulez utiliser des URL relatives basées sur le Root du document.

Un document d'exemple :

<!DOCTYPE html>
<html>
    <head>
        <title>Example</title>
        <link href='http://stackoverflow.com//fonts.googleapis.com/css?family=Lato:300italic,700italic,300,700' rel='stylesheet' type='text/css'>
        <link href="http://stackoverflow.com/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>

Quelques doublons (ou presque)

• Un moyen sûr d'écrire des URLs qui se transfèrent d'un environnement à l'autre.
• Quelle est la manière correcte de lier une image à un site web ?

Answer 2

En général, il est considéré comme une bonne pratique d'utiliser des URL relatives, afin que votre site web ne soit pas lié à l'URL de base de l'endroit où il est actuellement déployé. Par exemple, il pourra fonctionner sur localhost, ainsi que sur votre domaine public, sans modifications.

Answer 3

Voir ça : 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

Une URL absolue comprend les parties situées avant la partie "path" - en d'autres termes, elle comprend le schéma (l'élément http en http://foo/bar/baz ) et le nom d'hôte (le foo en http://foo/bar/baz ) (et optionnellement port, userinfo et port).

Les URL relatives commencent par un chemin.

Les URL absolues sont, en fait, absolues : l'emplacement de la ressource peut être déterminé en regardant uniquement l'URL elle-même. Une URL relative est en quelque sorte incomplète : pour la résoudre, vous avez besoin du schéma et du nom d'hôte, et ceux-ci sont généralement tirés du contexte actuel. Par exemple, dans une page web à

http://myhost/mypath/myresource1.html

vous pourriez mettre un lien comme suit

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

Dans le href de l'attribut du lien, une URL relative est utilisée, et si l'on clique dessus, il faut la résoudre pour pouvoir la suivre. Dans ce cas, le contexte actuel est

http://myhost/mypath/myresource1.html

Ainsi, le schéma, le nom de l'hôte et le chemin principal de ces derniers sont pris et ajoutés en préambule au fichier pages/page1 ce qui donne

http://myhost/mypath/pages/page1

Si le lien aurait été :

<a href="http://stackoverflow.com/pages/page1">click me</a>

(notez le / apparaissant au début de l'URL), il aurait été résolu comme suit

http://myhost/pages/page1

parce que le premier / indique la racine de l'hôte.

Dans une application web, je conseille d'utiliser des URL relatives pour toutes les ressources qui appartiennent à votre application. De cette façon, si vous changez l'emplacement des pages, tout continuera à fonctionner. Toute ressource externe (qu'il s'agisse de pages complètement extérieures à votre application ou de contenu statique que vous diffusez par le biais d'un réseau de diffusion de contenu) doit toujours être désignée par des URL absolues : si vous ne le faites pas, il n'y a tout simplement aucun moyen de les localiser, car elles résident sur un autre serveur.

Answer 4

Il existe réellement trois types qui devraient être discutés explicitement. En pratique, les URL ont été abstraites pour être gérées à un niveau inférieur et je dirais même que les développeurs pourraient passer leur vie entière sans écrire une seule URL à la main.

Absolument

Les URL absolues lient votre code au protocole et au domaine. Ce problème peut être résolu grâce aux URL dynamiques.

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

Les pros absolus :

1. Contrôle - Le sous-domaine et le protocole peuvent être contrôlés. Les personnes qui entrent par un sous-domaine obscur seront dirigées vers le sous-domaine approprié. Vous pouvez passer d'un système sécurisé à un système non sécurisé, selon les besoins.

2. Configurable - Les développeurs aiment que les choses soient absolues. L'utilisation d'URL absolues permet de concevoir des algorithmes soignés. Les URL peuvent être configurées de manière à ce qu'une URL puisse être mise à jour sur l'ensemble du site par un seul changement dans un seul fichier de configuration.

3. Clairvoyance - Vous pouvez rechercher les personnes qui grattent votre site ou peut-être trouver des liens externes supplémentaires.

---

Relatif à la racine

Les URL relatives à la racine relient votre code à l'URL de base. Ce problème peut être résolu avec des URL dynamiques et/ou des balises de base .

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

Root Relative Pros :

1. Configurable - La balise base les rend relatives à n'importe quelle racine que vous choisissez, ce qui facilite le changement de domaine et la mise en œuvre de modèles.

---

Relative

Les URL relatives lient votre code à la structure du répertoire. Il n'y a aucun moyen de surmonter cela. Les URL relatives ne sont utiles que dans les systèmes de fichiers pour parcourir les répertoires ou comme raccourci pour une tâche subalterne.

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

Cons relatif :

1. CONFUSING - Combien de points cela fait-il ? Combien de dossiers cela fait-il ? Où est le fichier ? Pourquoi cela ne fonctionne-t-il pas ?

2. MAINTENANCE - Si un fichier est accidentellement déplacé, les ressources cessent de se charger, les liens envoient l'utilisateur vers les mauvaises pages, les données du formulaire peuvent être envoyées vers la mauvaise page. Si un fichier DOIT être déplacé, toutes les ressources qui cessent de se charger et tous les liens qui sont incorrects doivent être mis à jour.

3. NE S'ÉCHELONNE PAS - Lorsque les pages Web deviennent plus complexes et que les vues commencent à être réutilisées sur plusieurs pages, les liens relatifs seront relatifs au fichier dans lequel ils ont été inclus. Si vous avez un extrait de navigation en HTML qui va se trouver sur chaque page, les liens relatifs seront relatifs à beaucoup d'endroits différents. La première chose que les gens réalisent lorsqu'ils commencent à créer un modèle est qu'ils ont besoin d'un moyen de gérer les URL.

4. COMPUTER - Ils sont mis en œuvre par votre navigateur (si possible conformément à la RFC). Voir le chapitre 5 dans RFC3986 .

5. OOPS ! - Les erreurs ou les fautes de frappe peuvent entraîner des pièges à araignées.

---

L'évolution des routes

Les développeurs ont cessé d'écrire des URL dans le sens dont il est question ici. Toutes les requêtes sont destinées au fichier d'index d'un site Web et contiennent une chaîne de requête, appelée "route". La route peut être considérée comme une mini-URL qui indique à votre application le contenu à générer.

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

Routes Pros :

1. Tous les avantages des urls absolues.
2. Utilisation de n'importe quel caractère dans l'URL.
3. Plus de contrôle (bon pour le référencement).
4. Possibilité de générer des URL de manière algorithmique. Cela permet aux URL d'être configurables. La modification de l'URL est un changement unique dans un fichier unique.
5. Pas besoin de 404 not founds. Les routes de repli peuvent afficher un plan du site ou une page d'erreur.
6. Sécurité pratique de l'accès indirect aux fichiers de l'application. Les états de garde peuvent s'assurer que tout le monde arrive par les voies appropriées.
7. L'aspect pratique de l'approche MVC.

---

Mon point de vue

La plupart des gens utiliseront ces trois formes d'une manière ou d'une autre dans leurs projets. L'essentiel est de les comprendre et de choisir celle qui convient le mieux à la tâche.

Answer 5

Je vais devoir être en désaccord avec la majorité ici.

Je pense que le schéma d'URL relatif est "bien" lorsque vous voulez mettre quelque chose en place rapidement et ne pas penser en dehors de la boîte, en particulier si votre projet est petit avec peu de développeurs (ou juste vous-même).

Cependant, dès que l'on commence à travailler sur de gros systèmes gras où l'on change de domaine et de protocole en permanence, je pense qu'une approche plus élégante s'impose.

Lorsque vous comparez les URL absolues et relatives par essence, l'absolue l'emporte. Pourquoi ? Parce qu'elle ne se casse jamais. Jamais. Une URL absolue est exactement ce qu'elle dit être. Le problème est que vous devez MAINTENIR vos URL absolues.

L'approche la plus faible en matière de liens URL absolus consiste en fait à coder en dur l'intégralité de l'URL. Ce n'est pas une bonne idée, et c'est probablement la raison pour laquelle les gens les considèrent comme dangereux/diaboliques/ennuyeux à maintenir. Une meilleure approche consiste à écrire vous-même un générateur d'URL facile à utiliser. Ceux-ci sont faciles à écrire, et peuvent être incroyablement puissant - il détecte automatiquement votre protocole, est facile à configurer (il suffit de définir l'url une fois pour toute l'application), etc. et il injecte votre domaine tout seul. Ce qui est bien avec ça : Vous continuez à coder en utilisant des URL relatives, et au moment de l'exécution, l'application insère vos URL comme des absolus complets à la volée. Génial.

Étant donné que pratiquement tous les sites modernes utilisent une sorte de back-end dynamique, il est dans le meilleur intérêt dudit site de le faire de cette façon. Les URL absolues ne font pas que vous rendre certain de l'endroit où elles pointent - elles peuvent également améliorer les performances de référencement.

J'ajouterai que l'argument selon lequel les URL absolues vont en quelque sorte modifier le temps de chargement de la page est un mythe. Si votre domaine pèse plus de quelques octets et que vous utilisez un modem téléphonique des années 1980, c'est possible. Mais ce n'est plus le cas aujourd'hui. https://stackoverflow.com/ est de 25 octets, alors que le fichier "topbar-sprite.png" qu'ils utilisent pour la zone de navigation du site pèse plus de 9 kb. Cela signifie que les données URL supplémentaires représentent 0,2 % des données chargées par rapport au fichier sprite, et ce fichier n'est même pas considéré comme un gros problème de performances.

Cette grande image d'arrière-plan pleine page, non optimisée, est beaucoup plus susceptible de ralentir vos temps de chargement.

Un article intéressant sur les raisons pour lesquelles les URL relatives ne devraient pas être utilisées est ici : Pourquoi les URL relatives devraient être interdites aux développeurs web

Un problème qui peut survenir avec les relatives, par exemple, est que parfois les mappages de serveurs (attention aux gros projets en pagaille) ne correspondent pas aux noms de fichiers et le développeur peut faire une supposition sur une URL relative qui n'est pas vraie. J'ai vu cela aujourd'hui sur un projet sur lequel je travaille et cela a fait tomber une page entière.

Ou peut-être qu'un développeur a oublié de changer un pointeur et que, tout à coup, Google a indexé tout votre environnement de test. Oups - contenu dupliqué (mauvais pour le référencement !).

Les absolus peuvent être dangereux, mais quand ils sont utilisés correctement et d'une manière qui ne peut pas casser votre construction il est prouvé qu'ils sont plus fiables. Regardez l'article ci-dessus qui donne un tas de raisons pour lesquelles le générateur d'url de Wordpress est super génial.

)