URL : dé­fi­ni­tion et domaines d’ap­pli­ca­tion

Chaque URL se compose d’un schéma et d’une partie spé­ci­fique au schéma.

• Schéma : le schéma URL spécifie à la fois le type de ressource et la méthode d’accès, et contient ainsi les in­for­ma­tions sur la manière d’accéder à la ressource. Le schéma d’URL a souvent le même nom que le protocole cor­res­pon­dant à la méthode d’accès au niveau de l’ap­pli­ca­tion d’Internet. Les schémas communs sont HTTP, HTTPS, mailto, file ou ftp.

• Partie spé­ci­fique du schéma : selon le type de schéma, la partie spé­ci­fique au schéma de l’URL contient une série de segments contenant l’em­pla­ce­ment de la ressource cor­res­pon­dante et les pa­ra­mètres de trai­te­ments op­tion­nels.

Un double point est utilisé comme sé­pa­ra­teur entre le schéma et la partie spé­ci­fique au schéma. Selon le schéma, deux slashs peuvent aussi être requis, qui sont basés sur une con­ven­tion des débuts du Web et n’ont aujourd’hui plus de fonction spé­ci­fique.

L’URL est basée sur la syntaxe URI suivante :

Chaque segment de la partie spé­ci­fique apporte une fonction précise. Les sections user, password, host et port sont définis comme Authority (autorité). L’« Authority » désigne l’hôte sur lequel une ressource doit être trouvée et l’espace de noms sur lequel elle doit être affectée.

• user et password : les sections user et password con­tien­nent le nom d’uti­li­sa­teur et le mot de passe d’une personne autorisée à accéder à la ressource et sont séparées par deux points. Les deux spé­ci­fi­ca­tions ne sont requises que si la ressource demande une au­then­ti­fi­ca­tion. Le nom d’uti­li­sa­teur et le mot de passe sont séparés du segment URI host par le symbole @.

• host : le segment URI host comporte gé­né­ra­le­ment un domaine incluant les domaines de premier, second et troisième niveau et spécifie un or­di­na­teur en par­ti­cu­lier (host), sur lequel la ressource désirée doit être récupérée. Vous pouvez aussi spécifier le nom d’hôte sous la forme d’une adresse IP.

• Port : en spé­ci­fiant un numéro de port, il est possible de contrôler un port TCP/IP spé­ci­fique dans le réseau. Comme la plupart des schémas possèdent un port standard, une entrée séparée est op­tion­nelle. Les ports standards sont par exemple 80 pour HTTP, 443 pour HTTPS ou 21 pour FTP. Un numéro de port est seulement né­ces­saire lorsqu’aucun port général n’est défini ou si un port non standard est requis pour les trans­ferts standards. Le numéro de port est séparé de la section host par un double point.

Le domaine dans Authority est gé­né­ra­le­ment spécifié sous une forme lisible pour les personnes. Par contre, les or­di­na­teurs fonc­tion­nent avec des adresses IP ; ainsi, pour appeler une ressource Web, une étape in­ter­mé­diaire est né­ces­saire. Elle est réalisée en arrière-plan de manière inaperçue : c’est la ré­so­lu­tion de nom basée sur le Domain Name System (DNS).

L’Authority de l’URI est suivie par l’in­di­ca­tion de l’em­pla­ce­ment de la ressource sur l’or­di­na­teur, ainsi que des com­po­sants Query String op­tion­nels et l’iden­ti­fi­ca­teur de fragment.

• Path : la séquence de segments path ou chemin est similaire a un ré­per­toire et se réfère à l’em­pla­ce­ment de la ressource sur l’or­di­na­teur cible (host). Il commence toujours par un slash (/).

• Query : certaines res­sources Web con­tien­nent des com­po­sants exé­cu­tables et demandent une chaîne de requête (query string) en plus du fichier chemin (path). La requête (query) contient des pa­ra­mètres (comme la saisie uti­li­sa­teur) qui sont transmis avec l’URL et traités côté serveur. C’est gé­né­ra­le­ment le cas pour les pages Web dy­na­miques qui sont créées à partir d’en­re­gis­tre­ments de base de données au moment de la ré­cu­pé­ra­tion. La requête est toujours précédée d’un point d’in­ter­ro­ga­tion (?).

• Fragment : si une position spé­ci­fique dans une ressource doit être ré­fé­ren­cée (une ressource se­con­daire par exemple), l’URI se termine par un in­di­ca­teur de fragment. Elle est jointe sé­pa­ré­ment avec un dièse (#) et se réfère gé­né­ra­le­ment à un numéro de page dans un document HTML qui est iden­ti­fiée de façon unique par un ID, par exemple une sous-rubrique.

Les éléments de la syntaxe URI qu’une URL contient dépendent du schéma cor­res­pon­dant. La structure URL est donc dé­ter­mi­née par le type de ressource. La liste suivante contient les types d’URL les plus courants.

mailto est un schéma d’URL pour les adresses email qui permet aux opé­ra­teurs de sites Web de mettre en place des hy­per­liens dans le but d’être contacté. Lorsqu’un in­ter­naute clique sur un lien mailto, tous les na­vi­ga­teurs clas­siques ouvrent au­to­ma­ti­que­ment le programme de mes­sa­ge­rie standard du système. Une nouvelle fenêtre de mes­sa­ge­rie s’ouvre alors. L’adresse email qui est indiquée dans la partie spé­ci­fique du schéma est saisie comme adresse de des­ti­na­taire dans la fenêtre de l’email. Ceci permet donc d’ouvrir le programme au­to­ma­ti­que­ment et l’uti­li­sa­teur n’a pas besoin de rentrer l’adresse email ma­nuel­le­ment. 

Le schéma file, permet d’appeler certains fichiers sur votre or­di­na­teur. Si vous saisissez le bon chemin d’accès au fichier comme URL dans la barre d’adresse du na­vi­ga­teur Web, il appelle le ré­per­toire désiré ou un fichier cible.

Les URL avec le schéma FTP (File Transfer Protocol) per­met­tent l’accès aux fichiers situés sur un autre or­di­na­teur (accès à distance). Le protocole de transfert de fichiers FTP du même nom est utilisé pour la trans­mis­sion.

Un uti­li­sa­teur qui souhaite accéder aux fichiers d’un système de fichiers distant via FTP doit gé­né­ra­le­ment s’au­then­ti­fier. Les URL qui font référence à des res­sources FTP con­tien­nent donc gé­né­ra­le­ment des données d’accès (nom d’uti­li­sa­teur et mot de passe).

La norme technique URL ne prend en charge qu’un nombre limité de ca­rac­tères ASCII (American Standard Code for In­for­ma­tion In­ter­change). En outre, divers ca­rac­tères sont déjà réservés à certaines fonctions, comme l’iden­ti­fi­ca­tion de segments in­di­vi­duels et per­met­tent ainsi de dé­com­po­ser et de traiter l’URL.

Les ca­rac­tères suivants ont une fonction clai­re­ment définie dans le standard technique URL :

Par exemple, le point d’in­ter­ro­ga­tion (?) introduit une chaîne de requête. Dif­fé­rents pa­ra­mètres de la chaîne de requête (query string) sont délimités par le caractère (&). Le sé­pa­ra­teur entre le nom du paramètre et la valeur est le signe (=). Le symbole dièse (#) est utilisé pour délimiter des URL d’autres fragments. 

Les ca­rac­tères sans fonctions pré­dé­fi­nies com­pren­nent toutes les lettres, symboles et ca­rac­tères spéciaux suivants :

Les ca­rac­tères autres que les ca­rac­tères ASCII et les ca­rac­tères non ASCII listés ici ne peuvent pas être utilisés dans les URL et doivent être réécrits. Il est également possible de réécrire un des ca­rac­tères réservé pour éviter qu’il ne soit in­ter­prété selon sa sig­ni­fi­ca­tion pré­dé­fi­nie. Pour la réé­cri­ture des ca­rac­tères ASCII, la norme URL utilise le caractère de masquage % (pour­cen­tage) et la table de valeurs ASCII en notation hexa­dé­ci­male. Les ca­rac­tères non ASCII sont également convertis à l’aide de la re­pré­sen­ta­tion en pour­cen­tage. La RFC 3986 re­com­mande un codage com­pa­tible ASCII basé sur l’UTF-8, mais cette re­com­man­da­tion n’est pas con­traig­nante. En fin de compte, c’est le four­nis­seur du service cor­res­pon­dant qui décide quel codage est utilisé. Par exemple, un caractère spécial comme ü pourra être affiché avec %FC (Latin-1) ou %C3%BC (UTF-8). Les ca­rac­tères spéciaux dans les domaines, sont d’autre part convertis en chaînes de ca­rac­tères com­pa­tibles ASCII à l’aide du Punycode. Pour en savoir plus sur la syntaxe de codage Punycode, vous pouvez consulter notre article sur les noms de domaines in­ter­na­tio­naux (IDN).

Il existe deux sortes d’URL : l’URL absolue et l’URL relative. Les URL absolues sont uni­ver­sel­le­ment valables et com­pren­nent tous les segments requis pour le schéma respectif. Les URL relatives, par contre ne sont valables que dans un contexte spé­ci­fique et en héritent certaines pro­prié­tés, de sorte que les sections URL cor­res­pon­dantes peuvent être re­don­dantes et omises. Les in­for­ma­tions qui peuvent provenir du contexte sont par exemples le protocole, le domaine ou le chemin d’accès à la ressource. 

Les URL relatives sont utilisées, entre autres pour les liens internes des pages Web afin de lier dif­fé­rentes pages se­con­daires d’un même site. L’URL du lien hérite de la spé­ci­fi­ca­tion des données de la page Web sur laquelle elle est utilisée.

Les exemples suivants montrent un lien de www.exemple.org/index/page1 à www.exemple.org/index/page2 avec une URL absolue ou relative.

Hyperlien avec une URL absolue :

Hyperlien avec une URL relative :

Les URL relatives ont donc l’avantage d’être beaucoup plus courtes et con­tri­buent ainsi à un code source clair et simple. De plus, les liens hy­per­textes avec les URL relatives fa­ci­li­tent le dé­pla­ce­ment des domaines. Si le domaine du site change, il doit être échangé ma­nuel­le­ment dans chaque lien interne avec une URL absolue ou redirigé vers des re­di­rec­tions. Cet effort n’est pas né­ces­saire pour les URL relatives qui ne re­quiè­rent pas d’autorité et donc une spé­ci­fi­ca­tion de domaine.