table of contents
other languages
other sections
URI(7) | Manuel du programmeur Linux | URI(7) |
NOM¶
uri, url, urn - Identificateur de ressource uniforme (URI), comprenant URL ou URNSYNOPSIS¶
URI = [ URI_absolu | URI_relatif ] [ "#" fragment ]
URI_absolu = mécanisme ":" ( partie_hiérarchique | partie_opaque )
URI_relatif = ( chemin_réseau | chemin_absolu | chemin_relatif ) [ "?" requête
mécanisme = "http" | "ftp" | "gopher" | "mailto" | "news" | "telnet" | "file" | "man" | "info" | "whatis" | "ldap" | "wais" | ...
partie_hierarchique = ( chemin_réseau | chemin_absolu ) [ "?" requête ]
chemin_réseau = "//" autorité [ chemin_absolu ]
chemin_absolu = "/" segments_chemin
chemin_relatif = segment_relatif [ chemin_relatif ]
DESCRIPTION¶
Un Identificateur de Ressource Uniforme (URI) est une courte chaîne de caractères identifiant une ressource physique ou abstraite (par exemple une page web). Une Localisation de Ressource Uniforme (URL) est un URI qui identifie une ressource à travers son moyen d'accès (sa « position » réseau par exemple), plutôt que par son nom ou un autre attribut de la ressource. Un Nom de Ressource Uniforme (URN) est un URI qui doit rester globalement unique, et persister même si la ressource cesse d'exister ou devient indisponible. Les URI constituent le mécanisme standard pour nommer les destinations des liens hypertextes pour les outils comme les navigateurs web. La chaîne « http://www.kernelnotes.org » est une URL (et donc aussi un URI). Beaucoup de gens utilisent le terme URL comme vague synonyme de URI (bien que techniquement les URL soient un sous-ensemble des URI). Les URI peuvent être absolus ou relatifs. Un identificateur absolu référence une ressource indépendamment du contexte, alors qu'un identificateur relatif référence une ressource en décrivant la différence par rapport au contexte courant. Dans les références de chemins relatifs, les segments complets « . » et « .. » ont des significations particulières : « le niveau actuel dans la hiérarchie » et « le niveau au-dessus dans la hiérarchie », respectivement, tout comme dans les systèmes type UNIX. Un segment de chemin qui contient un caractère deux-points ne peut pas être utilisé comme premier segment du chemin d'un URI (par exemple « ceci:cela »), car on le confondrait avec le mécanisme. Précédez un tel segment avec ./ (par exemple « ./ceci:cela »). Notez que les descendants de MS-DOS (par ex. Windows) remplacent le deux-points du nom de périphérique par une barre verticale dans les URI, ainsi « C: » devient « C| ». Un identificateur de fragment, s'il est présent, référence une portion particulière de la ressource ; le texte après le « # » identifie le fragment. Un URI commençant par « # » référence le fragment dans la ressource courante.Utilisation¶
Il y a plusieurs schémas d'URI différents, chacun ajoutant des règles et des significations spécifiques, mais ils sont volontairement rendus le plus ressemblants possible. Par exemple, plusieurs schémas d'URL permettent le format suivant pour décrire l'autorité d'un chemin réseau, que l'on appellera serveur_ip (les crochets encadrent les parties optionnelles) :serveur_ip = [user [ : password ] @ ]
hôte [ : port]
Ce format permet d'insérer éventuellement un nom d'utilisateur,
suivi éventuellement d'un mot de passe, et/ou un numéro de port.
La partie hôte est le nom de l'ordinateur, soit son nom
déterminé par le DNS, soit son adresse IP (numéros
séparés par des points). Ainsi l'URI
<http://fred:fredpassword@xyz.com:8080/> se connecte dans le serveur web
sur l'ordinateur xyz.com avec l'identité fred (et le mot de passe
fredpassword) en utilisant le port 8080. Évitez d'utiliser les mots de
passe dans les URI à cause des risques liés à la
sécurité sitôt que l'on écrit un mot de passe. Si
l'URL indique un nom d'utilisateur et pas de mot de passe, et si le serveur
distant réclame un mot de passe, alors le programme interprétant
l'URL peut en demander un à l'utilisateur.
Voici les mécanismes les plus courants utilisés sur les
systèmes type UNIX, compris par de nombreux outils. Notez que beaucoup
d'outils gérant les URI ont aussi des mécanismes internes ou
spécialisés ; consultez la documentation de ces outils
pour plus de détails.
http - Serveur Web (HTTP)
http:// serveur_ip/chemin
- hostport
- le serveur LDAP à interroger, écrit comme un nom d'hôte suivi éventuellement par un deux-points et un numéro de port. Le port TCP pour le LDAP est 389. Si le nom est vide, le client détermine le serveur LDAP à utiliser.
- dn
- Le nom complet (Distinguished Name) LDAP, qui identifie l'objet de base de la recherche LDAP (voir
- attributs
- une liste d'attributs à renvoyer séparés par des virgules ; voir la RFC 2251 section 4.1.5. Par défaut tous les attributs sont renvoyés..
- portée
- indique la portée de la recherche qui peut être « base » (recherche d'objet de base), « one » (recherche sur un niveau), ou « sub » (recherche dans un sous-arbre). Par défaut, on considère « base ».
- filtre
- indique le filtre de recherche (sous-ensemble des entrées à renvoyer). Par défaut, toutes les entrées sont renvoyées. Consultez
- extensions
- une liste de paires type=valeur séparées par des virgules, où la portion =valeur peut être omise pour les options ne la nécessitant pas. Une extension préfixée par un « ! » est critique (doit être pris en charge pour être valide), sinon elle est non-critique (facultative).
ldap://ldap.itd.umich.edu/o=University%20of%20Michigan,c=USPour n'obtenir que l'attribut Adresse Postale, on demanderait :
ldap://ldap.itd.umich.edu/o=University%20of%20Michigan,c=US?postalAddressPour demander à host.com, sur le port 6666 des informations sur la personne de nom courant (cn) « Babs Jensen » à l'University du Michigan, demandez :
ldap://host.com:6666/o=University%20of%20Michigan,c=US??sub?(cn=Babs%20Jensen)wais - Wide Area Information Servers wais:// hostport/base
Codage des caractères¶
Les URI utilisent un nombre limité de caractères afin d'être saisis et utilisés dans de nombreuses situations. Les caractères suivants sont réservés ; ils peuvent apparaître dans un URI, mais leurs usages est limités aux fonctionnalités réservées (les données conflictuelles doivent être protégées avant de former l'URI) :-
; / ? : @ & = + $ ,
-
- _ . ! ~ * ' ( )
- 1.
- traduire le caractère en séquence UTF-8 (RFC 2279) — consultez utf-8(7) — puis
- 2.
- utiliser le mécanisme d'échappement d'URI, c'est-à-dire, utiliser les %HH pour coder les octets non-sûrs.
Écrire un URI¶
Lorsqu'il est écrit, un URI doit être placé entre guillemets (« http://www.kernelnotes.org »), encadré par des chevrons (<http://lwn.net>), ou placé sur une ligne indépendante. Un avertissement à propos des guillemets : Ne jamais introduire une ponctuation supplémentaire (comme le point final d'une phrase ou la virgule séparant les éléments d'une liste) à l'intérieur de l'URI, car cela modifierait sa valeur (N.d.T. : cet avertissement vaut surtout pour les anglo-saxons ; en français l'usage veut que les éléments de ponctuations restent à l'extérieur des guillemets). On peut utiliser les chevrons à la place, ou basculer sur un système de notation qui n'incopore aucun caractère supplémentaire à l'intérieur des marques de citation. Ce système (N.d.T. : le nôtre !), appelé « nouveau » ou « logique » par les « Hart's Rules » et le « Oxford Dictionnary for Writes and Editors », est la pratique préférée des hackers dans le monde entier. Consultez la section sur le style d'écriture dans le Jargon File http://www.fwi.uva.nl/~mes/jargon/h/HackerWritingStyle.html pour plus de détails. Les documentations anciennes suggèrent d'insérer le préfixe « URL: » juste avant un URI, mais cette forme n'a jamais été utilisée réellement. La syntaxe des URI a été conçue pour éviter les ambiguïtés. Toutefois, comme les URI sont devenus de plus en plus répandus, les médias traditionnels télévision, radio, journaux et magazines...) ont utilisé de manière croissante des abréviations d'URI, consistant en la seule partie autorité et segments de chemin de la ressource (par exemple <www.w3.org/Addressing>). De tels références sont surtout prévues pour une interprétation humaine, avec la supposition que la compréhension du contexte permet de compléter l'URI (par exemple les noms d'hôtes commençant par « www » se préfixent avec « http:// » et les noms commençant par « ftp » doivent se préfixer avec « ftp:// »). De nombreux clients résolvent ces références avec de telles heuristiques. Elle peuvent toutefois évoluer, particulièrement quand de nouveaux mécanismes sont introduits. Comme les URI abrégés ont la même syntaxe qu'un chemin d'URL relative, les références abrégées ne sont pas utilisables lorsque des URI relatifs sont autorisés. N'utilisez pas d'URI abrégés comme liens hypertexte dans un document ; utilisez le format standard décrit ici.CONFORMITɶ
(IETF RFC 2396) (HTML 4.0)NOTES¶
Un outil acceptant les URI (par exemple un navigateur web) sur un système Linux devrait être capable de traiter (directement ou indirectement) tous les mécanismes décrits ici, y compris man: et info:. Sous-traiter ces éléments à un autre programme est tout à fait acceptable, et même encouragé. Techniquement, la notation d'un fragment ne fait pas partie de l'URI. Pour savoir comment incorporer des URI (y compris des URL) dans un format de données, voir la documentation sur ce format. HTML utilise le format <A HREF=" uri"> text </A>. Les fichiers texinfo utilisent le format @uref{ uri}. Man et mdoc ont une macro UR récemment ajoutée, ou incluent juste l'URI dans le texte (les visualiseurs doivent détecter le :// comme portion d'URI). Les environnements Gnome et Kde divergent actuellement sur les URI qu'ils acceptent, en particulier dans leurs systèmes d'aide. Pour lister les pages de manuel, Gnome utilise <toc:man> alors que Kde utilise <man:(index)>. Pour lister les pages info, Gnome emploie <toc:info> et Kde <info:(dir)> (l'auteur de cette page préfère l'approche Kde, bien qu'un format plus régulier serait encore meilleur). En général, Kde utilise <file:/cgi-bin/> comme préfixe pour les fichiers générés. Kde préfère la documentation en Html, accessible avec <file:/cgi-bin/helpindex>. Gnome préfère le mécanisme ghelp pour stocker et retrouver la documentation. Aucun navigateur ne gère les références file: vers un répertoire à l'heure où j'écris ces lignes, ce qui rend difficile de se référer à un répertoire avec un URI navigable. Comme indiqué plus haut, ces environnements diffèrent sur la gestion du mécanisme info:, probablement leur plus importante divergence. On espère que Gnome et Kde vont converger vers des formats d'URI communs, et la future version de cette page décrira le résultat de cette convergence.Sécurité¶
Un URI ne pose pas de problème de sécurité par lui-même. Il n'y a aucune garantie qu'une URL, qui localise une ressource à un moment donné continuera de le faire. Pas plus qu'il n'y a de garantie qu'une URL ne localisera pas une ressource différente à un autre moment. Les seules garanties peuvent être fournies par les personnes qui gèrent l'espace de noms de la ressource en question. Il est parfois possible de construire une URL de manière qu'une tentative de réaliser une opération apparemment bénigne, comme accéder à la ressource associée, va en réalité produire une action éventuellement dommageable pour le correspondant. Les URL non sûres sont typiquement construites en indiquant un numéro de port différents de ceux réservés pour les protocoles en question. Le client, croyant contacter un site, va en réalité engager un autre protocole. Le contenu de l'URL contient des instructions, qui interprétées par l'autre protocole, produisent des résultats inattendus. Un exemple a été l'emploi d'une URL Gopher pour envoyer un message falsifié et indésiré sur un serveur SMTP. Il faut être prudent en utilisant une URL qui indique un numéro de port différent de celui du protocole, particulièrement si ce numéro est dans l'espace réservé. Il faut s'assurer que lorsque l'URI contient des délimiteurs protégés pour un protocole donné (par exemple CR et LF pour le protocole telnet) qu'ils ne soient pas « déprotégés » avant la transmission. Ceci peut violer le protocole, mais évite le risque que ces caractères servent à simuler une opération dans ce protocole, ce qui peut conduire à des actions distantes éventuellement nocives. Il est clairement déraisonnable d'utiliser un URI qui contient un mot de passe censé être secret. En particulier, l'utilisation du mot de passe dans la partie « info utilisateur » de l'URI est fortement déconseillé, sauf s'il s'agit d'un de ces cas rares où le mot de passe est vraiment public.BOGUES¶
La documentation peut se trouver dans un grand nombre d'endroit, ainsi il n'y a pas encore de bon mécanisme d'URI pour la documentation générale en ligne, dans des formats arbitraires. Les référence de la forme <file:///usr/doc/ZZZ> ne fonctionnent pas, car différentes distributions et installations locales peuvent placer les fichiers dans divers répertoires (cela peut être /usr/doc, ou /usr/local/doc, ou /usr/share, ou autre part). De même, le répertoire ZZZ change en principe avec le numéro de version (bien que le développement des noms de fichiers puisse partiellement couvrir ce problème). Finalement, l'utilisation du mécanisme file: n'est pas recommandée pour les gens qui consultent la documentation dynamiquement depuis Internet plutôt que de la télécharger sur leur système de fichiers local. Un mécanisme d'URI sera peut être ajouté dans l'avenir (p.ex. : « userdoc: ») pour permettre aux programme d'inclure des références vers de la documentation plus détaillées sans avoir à connaître l'emplacement exact de celle-ci. Autrement, une version future des spécifications du système de fichiers peut décrire les emplacements de manière suffisamment précise pour que le mécanisme file: soit capable de situer la documentation. De nombreux programmes et formats de fichiers n'incluent aucune manière d'incorporer ou l'implémenter des liens utilisant les URI. Beaucoup de programmes ne traitent pas tous les formats URI différents ; il devrait y avoir un mécanisme standard pour charger un URI quelconque qui détecte automatiquement l'environnement utilisateur (p.ex. : texte ou graphique, environnement de bureau, préférences de l'utilisateur, outils en cours d'exécution) et invoque le bon outil quelque soit l'URI.VOIR AUSSI¶
lynx(1), man2html(1), mailaddr(7), utf-8(7) IETF RFC 2255COLOPHON¶
Cette page fait partie de la publication 3.65 du projet man-pages Linux. Une description du projet et des instructions pour signaler des anomalies peuvent être trouvées à l'adresse http://www.kernel.org/doc/man-pages/.TRADUCTION¶
Depuis 2010, cette traduction est maintenue à l'aide de l'outil po4a <http://po4a.alioth.debian.org/> par l'équipe de traduction francophone au sein du projet perkamon <http://perkamon.alioth.debian.org/>. Christophe Blaess <http://www.blaess.fr/christophe/> (1996-2003), Alain Portal <http://manpagesfr.free.fr/> (2003-2006). Julien Cristau et l'équipe francophone de traduction de Debian (2006-2009). Veuillez signaler toute erreur de traduction en écrivant à <debian-l10n-french@lists.debian.org> ou par un rapport de bogue sur le paquet manpages-fr. Vous pouvez toujours avoir accès à la version anglaise de ce document en utilisant la commande « man -L C <section> <page_de_man> ».18 mars 2014 | Linux |