Quand une URI désigne un document web on parle d'URL. Par exemple,

http://www.univ-poitiers.fr/formation/domaines.html

désigne un document accessible par le protocole web (HTTP) sur la machine serveuse www.univ-poitiers.fr, dans le fichier de chemin /formation/domaines.html. Sauf cas particulier, ce chemin se comprend relativement à un dossier particulier, appelé racine web du serveur, où sont regroupés les documents web disponibles sur cette machine. L'emplacement de la racine dépend de l'installation du serveur. Les chemins sont indiqués de la façon usuelle sous UNIX : une succession de dossiers, du plus large au plus précis, puis le nom de fichier, le tout séparé par des obliques (/). Attention à ne pas confondre avec les contre-obliques (\) de Microsoft.

Un cas particulier de dossier qui ne se trouve pas sous cette racine est celui où chaque utilisateur peut installer ses propres documents web, ces utilisateurs étant des individus, des groupes de travail, des départements, etc. Il s'agit de la racine web de l'utilisateur, qui se trouve généralement dans son dossier personnel (pour les systèmes de type UNIX). Le chemin exact de cette racine au sein des dossiers personnels dépend de la configuration du serveur. Il est généralement le même pour tous les utilisateurs (c'est souvent public_html ou www). Chaque racine d'utilisateur apparaît comme un répertoire ~compte à la racine du serveur. Par exemple (exemple fictif),

http://www.exemple.fr/~yd/animaux/abeille.html

désigne le fichier de chemin animaux/abeille.html relativement à la racine web de l'utilisateur yd.

Comme les URL servent à désigner des documents à partir de documents, il n'est pas toujours souhaitable de désigner un documents dans l'absolu, par rapport à tout Internet. Quand il s'agit de désigner une image à faire apparaître dans une page de texte, la désigner dans l'absolu rendrait fort compliqué le déplacement dans l'arborescence des fichiers de la page et de ses illustrations. Pour cela, il est convenu que quand une ressource R est désignée à partir d'un document D, on peut utiliser pour R une URI relative à la position de D. Cette URI ne précise ni le schéma d'accès ni le serveur, R sera alors récupéré de la même façon et sur le même serveur que D. L'URI contient directement un chemin relatif au dossier contenant D. Ainsi,

../images/apis_mellifera.jpg

quand il est indiqué dans le document abeille.html de l'exemple précédent, désigne le fichier apis_mellifera.jpg dans le dossier ~yd/images. Le nom de dossier spécial .. (deux fois un point) désigne, comme sous UNIX et Windows, le dossier contenant le dossier courrant.

Il est également possible, même si l'usage en est généralement fortement déconseillé, de produire des URI relatives à la racine du serveur web du document courant. Dans ce cas, comme sous Unix, l'URI commence simplement par une oblique (/). Exemple : /animaux/fourmi.html.

Rappelons que les URI ne peuvent pas contenir n'importe quel caractères. Sont admis : les lettres (a à z et A à Z, sans accent ni cédille, ni ligature, etc.), les chiffres (0 à 9), le tiret (-), le point (.) et le souligné (_). Les caractères non admis, sont remplacés, normalement par le client, soit en plus (+) pour l'espace soit en un code consistant en un signe pourcent (%) suivi du code hexadécimal à deux chiffres du signe remplacé (ex.: %2B pour +). Par ailleurs, la casse (différence majuscule/minuscule) compte, contrairement à ce qui est en usage sous Windows ou MacOS. Ainsi renard.html et Renard.html désignent a priori des fichiers différents.

Signalons enfin deux extensions du système d'URI précédent : la sécurisation et le changement de port.

Les serveurs web constituent un service qui travaille généralement sur le port TCP/IP 80 d'une machine. Ceci n'est pas obligatoire et il advient parfois qu'un serveur soit mis en service sur un autre port. Ceci est fréquent pour les petits serveurs mis en place par des utilisateurs ou spécifiques à des usages donnés comme, par exemple, la maintenance système. Pour s'adresser au serveur sur le port numéro nnn, on indique ce numéro à la suite du nom de serveur, précédé par le signe deux-points (:). Exemple (historique) :

http://www-eleves.ens.fr:8080/~delmas

Dans cet exemple, le serveur visé est sur le port 8080.

Certains serveurs travaillent pour tout ou partie en mode sécurisé. Dans ce cas les données sont cryptées entre le client et le serveur, ce qui diminue considérablement les risques d'écoute et d'interception. Dans ce cas le sélecteur de service n'est plus http mais https. Les URL ont alors la forme suivante :

https://www.banquexxx.fr/identification.html

Il est important de noter que, dans ce cas, non seulement http://xy/z et https://xy/z ne désignent pas la même méthode d'acheminement des données, mais encore, ces URL ne désignent simplement pas la même donnée. Même sur un même serveur, l'URI https://www.exemple.fr peuvent parler de légumes là où http://www.exemple.fr parle de produits d'entretien (exemple fictif).

Tout élément^[5] à l'intérieur d'une page web (HTML, XML, WML...), on parle de fragment (web), peut être nommé, au moment de la conception. Il devient alors identifiable depuis l'ensemble du web et, donc, dispose d'une URI (ici, on ne parle pas d'URL).

Pour désigner un fragment nommé fff à l'intérieur d'un document d'URL ddd, on accolle l'URL et le nom séparés par un symbole dièse (#) : ddd#fff. Typiquement, si le document est désigné de façon absolue, une telle URI aura l'allure suivante (fictif) :

http://www.poitou-charentes.iufm.fr/~delmas/animaux/mollusques.html#escargot

Si le document est désigné de façon relative à partir du document contenant le lien vers le fragment, l'URI résultante aura l'allure suivante (fictif) :

../animaux/mollusques.html#escargot

Enfin, si le document contenant le fragment et le document contenant le lien vers le fragment ne font qu'un, l'URI sera simplement :

#escargot

Ce type de constructions est particulièrement fréquente pour mettre en place des renvois, comme dans l'exemple précédent. Il est alors de bonne pratique de choisir des noms significatif et non des désignations génériques et/ou susceptible de varier, telles que titre2 ou section3.

Pour cet usage, il est fréquent qu'on ne veuille pas vraiment désigner une portion de texte, mais juste un point du texte. Dans ce cas, on dispose au point considéré une ancre (balise <A>) vide portant le nom de référence voulu.

Une URI peut aussi désigner d'autres éléments d'un document, qu'il s'agisse d'une image, d'un champ de formulaire, d'une carte cliquable ou d'une feuille de style. Dans tous les cas, la référence utilisée sera le nom donné au fragment en question (se reporter à la documentation du logiciel de composition de pages). En HTML, ce nom est donné par l'attribut ID ou l'attribut NAME.

Les documents du web ne sont pas de contenu constant et les URI servent aussi à transmettre de l'information à des serveurs. Par exemple, quand on a rempli un formulaire, l'envoi des données peut se faire à travers une URI. Ces données sont généralement susceptibles de changer le contenu du document renvoyé. Bien sûr, toutes les pages dynamiques ne dépendent pas nécessairement d'un envoi de données ; l'origine de la variété des pages peut se trouver sur le serveur ou être intrinsèque (indication de la date, inclusion d'un fichier, actualités etc.).

Le transfert de données dans l'URI s'effectue en ajoutant une liste d'informations à la suite de l'URI d'envoi des données. Cette liste d'informations est précédée d'un point d'interrogation (?). Il s'agit généralement d'une série de nom=valeur séparées par des esperluètes (ou perluètes, &, prononcer « éperluaite »). Voici un exemple typique (fictif) :

http://www.mairie-poitiers.fr/orientation/carte.cgi?x=100&y=67&lang=fr

Comme nous l'avons vu les URI ne peuvent contenir qu'un nombre restreint de caractères. Si nécessaire, les données de l'URI seront donc encodées pour ne pas déroger à la règle (l'espace est remplacé par un plus (+) et les autres caractères interdits par un signe pourcent (%) suivi du code hexadécimal des caractères). Attention : il est impératif, dans ce cas, que client et serveur utilisent le même encodage pour les caractères accentués ou non latins.

Si l'on veut désigner un objet (un fragment) à l'intérieur d'une page calculée à partir d'informations, la partie d'URI désignant l'objet s'ajoute à la suite des indications de requètes éventuelles. Voici un exemple (fictif) :

http://www.mairie-poitiers.fr/orientation/carte.cgi?x=100&y=67#logo_ville

Pour information, les données envoyées à une URI sont généralement traitées de deux grands types de manières : soit le serveur fait appel à un programme externe, souvent selon un mode appelé CGI, soit le serveur analyse (ou fait analyser) le document à la recherches d'opérations à effectuer avant l'envoi. Ce second mode, largement dominant, est généralement mis en oeuvre sous la forme de pages PHP (serveurs Apache ou IIS), de pages ASP (serveurs IIS et Apache), ou d'inclusions Java, pages JSP (principalement sur des serveurs UNIX, dont Apache).

Pour être complet signalons que certaines données, audio ou video, par exemple, peuvent demander un mode de diffusion particulier. Le protocole n'est plus alors HTTP sur TCP sur IP et demande donc un schéma d'URI spécifique. Pour la diffusion en temps réel sur Internet, un standard s'est maintenant imposé : RTSP [Real Time Streaming Protocol, protocole de diffusion continue en temps-réel] sur UDP (ou TCP) sur IP. Pour TCP les URI auront l'allure [RFC2326] :

rtsp://hôte/chemin

et pour UDP :

rtspu://hôte/chemin

Comme toujours, un numéro de port peut être précisé si nécessaire. Exemple :

rtsp://media.example.com:554/twister/audiotrack