UNIVERSAL RESSOURCE IDENTIFIER
Pour rechercher des fichiers sur
le World Wide Web, on utilise des adresses particulières.Ces adresses sont des " Universal Resouce Identifier ".
Elles contiennent une grande quantité d'information.
Après le langage HTML de description de page, le concept des URI est le second pilier sur lequel s'est bâti le succès du WEB.
Bien entendu, pour formuler les URI, des règles de syntaxe très précises sont nécessaires (voir RFC1630).
Lors de la mise au point de ces règles, les objectifs étaient les suivants.
La syntaxe doit être extensible, afin que l'on puisse l'adapter aux applications à venir.
Elle doit être complète et ouverte.
Autrement dit, elle doit pouvoir intégrer tous les modes de désignation existant.
Enfin, la syntaxe des URI doit permettre à chacun d'entre eux être formulé correctement en texte ASCII 7 bits.
Un URI se compose d'un mot-clé définissant le schéma syntaxique qu'il faut utiliser afin d'exploiter l'adresse, puis cette dernière.
Ce mot-clé est souvent indiqué au nom du protocole Internet correspondant.
Retour à la table des matières.
Uniform Resouce Locator (URL)
Au sein d'un documents HTML, les adresses sont indiqués sous formes d'attributs, SRC et HREF par exemple.
Ces attributs sont des chaînes de caractères représentant les URI.
Généralement, il faut utiliser les URI spécifiques majeurs que sont les " Uniform Ressource Locators " (URL voir RFC1738).
Un URL se compose de plusieurs parties, dont l'agencement au sein des adresses diffère selon les protocoles d'application concernés.
En principe un URL contient au maximum quatre éléments distincts.
Tous ces éléments doivent être séparés par des suites de caractères ou des signes déterminés.
Le second élément de l'URL (l'adresse du système distant) peut prendre la forme d'une adresse IP, tout comme celle d'un nom de domaine.
Il est parfois nécessaire d'ajouter à cette adresse un numéro de port et un nom d'utilisateur accompagné de son mot de passe.
Retour à la table des matières.
Uniform Resouce Name (URN)
L'attribution d'URN doit garantir aux utilisateurs la possibilité de retrouver un document, même lorsque son adresse physique (URL), a changé.
La gestion de ces noms doit être centralisée, ce qui peut poser un certain nombre de problèmes.
L'univocité des URL est assez facile à garantir.
L'adresse IP (ou le nom de domaine) devant permettre l'identification du document à partir de son URL est unique.
En principe, l'univocité d'un nom de fichier est garantie par le système d'exploitation.
Si plusieurs versions d'un fichier sont présents dans un même répertoire (ce qui, comme chacun le sait , impossible sous Ms-Dos), le version la plus récente sera activé, à moins que l'un des autres fichiers ne soient explicitement réclamé.
Un URL est donc constitué d'éléments d'adresse univoques, dont la réunion produit une adresse excluant toute confusion.
Dans le cas des URN, il est bien sûr impossible de s'appuyer sur l'univocité des noms de serveurs, puisqu'il s'agit précisément de garantir que le document requis pourra également être repéré sur un autre serveur.
C'est pourquoi il est nécessaire de mettre en place un système informatique capable, au même titre que les Names Servers, de convertir les URN en adresses proprement dites.
La mise en œuvre de tels projets est aujourd'hui encore à l'etude.
Retour à la table des matières.
URL HTTP
Un URL, désignant un document proposé par un serveur HTTP, débute par l'indication du protocole HTTP qui doit être utilisé.
Les caractères " :// "séparent cette information de l'adresse du système distant.
Dans le cadre de HTTP, vous ne devez inscrire ni non d'utilisateur, ni mot de passe.
L'adresse du système distant est donc simplement constituée de son adresse IP ou de son nom de domaine.
Vous pouvez y adjoindre un numéro de port, que vous devez séparer de l'adresse proprement dite à l'aide de deux points.
Si vous n'inscrivez pas d'indication, le numéro de port utilisé sera le port 80 qui est le port standard de HTTP.
Indiquez ensuite le chemin et le nom du fichier correspondant à votre demande HTTP.
Le chemin doit être séparé de l'adresse du système par une barre oblique " / ".
Chaque nom de répertoire doit être également ponctué d'une barre oblique '/', et non d'un " Backslash " ordinairement utilisé sous Ms-Dos.
Si vous n'anscrivez aq'un cjÅMio, la ráponse à votre requête vous parviendra sous forme de document standard.
Vous pourrez finalement compléter votre URL HTTP par des données, qui seront transmises à l'adresse distante.
Il peut s'agir notamment d'un nom d'un point d'ancrage placé au sein du document requis.
Un tel nom doit être séparé du reste de l'URL par le signe " # ".
N'étant pas déterminant pour le choix du document qui doit être affiché par le navigateur, ce nom n est pas transmis au serveur.
Vous pouvez également inscrire des données destinées à un programme CGI fonctionnant sur le serveur.
Ces informations doivent être séparés du reste de l'URL par un point d'interrogation.
Retour à la table des matières.
Les autres type d'URL
En utilisant un navigateur Web, vous pouvez egalement accéder à des informations dont la transmission fait appel à des protocoles distincts de HTTP.
|
MOT-CLE |
DESCRIPTION |
EXEMPLE D'URL |
|
Protocole utilisé dans la transmission de fichiers |
FTP ://users :password@ftp.serv.fr/dir/prog.exe |
|
|
FILE
|
Transmission de fichier semblable à FTP, s'applique également aux fichiers d'un système local |
FILE ://serv.fr/dir/prog.exe |
|
Système d'information orienté menu |
GOPHER ://goph.edu |
|
|
MAILTO |
Appel un client E-Mail intégré au navigateur |
MAILTO ://users@host.fr |
|
Appel d'un newsgroup usenet |
NEWS :groupe.article |
|
|
NMTP |
Idem à News |
NMTP ://host.fr/groupe |
|
Mise en place d'une session TELNET |
TELNET ://users :password@host.fr |
Bien d'autres protocoles comme LDAP, IMAP4, etc. sont disponibles et la liste est longue.
Retour à la table des matières.
Créé par Hagard Yannick
le 03/10/97 19:20
