uri(7)

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]

This format allows you to optionally insert a username, a user plus password, and/or a port number. The host is the name of the host computer, either its name as determined by DNS or an IP address (numbers separated by periods). Thus the URI <http://fred:fredpassword@example.com:8080/> logs into a web server on host example.com as fred (using fredpassword) using port 8080. Avoid including a password in a URI if possible because of the many security risks of having a password written down. If the URL supplies a username but no password, and the remote server requests a password, the program interpreting the URL should request one from the user.

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
http://serveur_ip/chemin?requête

Il s'agit d'une URL accédant à un serveur web (HTTP). Le port par défaut est 80. Si le chemin référence un répertoire, le serveur choisira ce qu'il renverra. Habituellement, si un fichier nommé « index.html » ou « index.htm » est présent, son contenu est renvoyé. Sinon, il crée et renvoie une liste des fichiers dans le répertoire en cours avec les liens appropriés. Un exemple : <http://lwn.net>.

Une requête peut être formulée dans le format archaïque « isindex », consistant en mot ou phrase sans signe égal « = ». Une requête peut aussi être dans le format « GET » plus long, qui a une ou plusieurs entrées de requêtes de la forme clé=valeur séparées par un caractère « et commercial » « & ». Notez que la clé peut être répétée plusieurs fois, et c'est au serveur web et ses programmes applicatifs de déterminer s'il y a une signification pour cela. Il y a une interaction malheureuse avec HTML/XML/SGML et le format de requête GET. Quand une telle requête avec plusieurs clés est incluse dans un document SGML/XML (y compris HTML), le « et commercial » « & » doit être réécrit sous forme « &amp; ». Notez que toutes les requêtes n'utilisent pas ce format ; elles peuvent être trop longues pour être stockée en URL et utilisent un mécanisme d'interaction différent (appelé POST) sans inclure les données dans l'URI. Consultez la spécification Common Gateway Interface (CGI) à l'adresse http://www.w3.org/CGI pour plus de détails.

ftp - File Transfer Protocol (FTP)

ftp://serveur_ip/chemin

Cette URL accède à un fichier à travers le protocole FTP. Le port par défaut (pour les commandes) est 21. Si aucun nom d'utilisateur n'est inclus, l'utilisateur « anonymous » est employé, et dans ce cas de nombreux clients fournissent l'adresse courriel du requérant en guise de mot de passe. Un exemple est <ftp://ftp.is.co.za/rfc/rfc1808.txt>.

gopher - Serveur Gopher

gopher://serveur_ip/type_gopher sélecteur
gopher://serveur_ip/type_gopher sélecteur%09recherche
gopher://serveur_ip/type_gopher sélecteur%09recherche%09chaine_gopher+

Le port gopher par défaut est 70. Le type_gopher est un champ composé d'un unique caractère indiquant le type de ressource Gopher à laquelle l'URL fait référence. Le chemin entier paut aussi être vide, auquel cas le délimiteur « / » est aussi optionnel et le type_gopher prend la valeur par défaut « 1 ».

selecteur est une chaîne de sélecteur Gopher. Dans le protocole Gopher, la chaîne de sélecteur est une séquence d'octets pouvant contenir tous les octets sauf 09 hexadécimal (HT ACSII ou Tabulation), 0A hexadécimal (LF ACSII), et 0D (CR ACSII).

mailto - Adresse courriel

mailto:adresse-courriel

Il s'agit d'une adresse courriel, en principe de la forme nom@nom_hôte. Consultez mailaddr(7) pour plus d'informations sur le format correct d'une adresse courriel. Notez que les caractères % doivent être transformés en %25. Un exemple : <mailto:dwheeler@dwheeler.com>.

news - Groupe ou message des news

news:nom-groupe-news
news:id-message

Un nom-groupe-news est un nom hiérarchique délimité par des points, comme « comp.infosystems.www.misc ». Si nom-groupe-news est « * » (comme dans <news:*>), l'URL référence tous les groupes news disponibles. Un exemple : <news:comp.lang.ada>.

Un id-message correspond au champ identificant Message-ID de IETF RFC 1036, sans les chevrons « < » et « > » ; il prend la forme unique@nom-domaine-complet. Un identificateur de message peut être distingué d'un nom de groupe de news par la présence du caractère « @ ».

telnet - Connexion telnet

telnet://serveur_ip/

Le mécanisme d'URL Telnet est utilisé pour afficher un service interactif accessible par le protocole Telnet. Le caractère « / » final peut être omis. Le port par défaut est 23. Un exemple : <telnet://melvyl.ucop.edu/>.

file - Fichier normal

file://serveur_ip/segments_chemins
file:segments_chemins

Ceci représente un fichier ou un répertoire accessible localement. En particulier, ip_server peut être la chaîne « localhost » ou une chaîne vide ; elle est interprétée comme « la machine sur laquelle l'URL est en cours d'interprétation ». Si le chemin conduit à un répertoire, le navigateur devrait afficher le contenu du répertoire avec des liens pour chaque élément. Tous les navigateurs ne le font pas encore. KDE prend en charge les fichiers générés par l'URL <file:/cgi-bin>. Si le fichier n'est pas trouvé, l'analyseur du navigateur peut essayer de développer le nom du fichier (consultez glob(7) et glob(3)).

The second format (e.g., <file:/etc/passwd>) is a correct format for referring to a local file. However, older standards did not permit this format, and some programs don't recognize this as a URI. A more portable syntax is to use an empty string as the server name, for example, <file:///etc/passwd>; this form does the same thing and is easily recognized by pattern matchers and older programs as a URI. Note that if you really mean to say "start from the current location", don't specify the scheme at all; use a relative address like <../test.txt>, which has the side-effect of being scheme-independent. An example of this scheme is <file:///etc/passwd>.

man - Pages de manuel

man:nom-commande
man:nom-commande(section)

Ceci référence les pages de documentation en ligne (man) locales. Le nom de la commande peut être suivi éventuellement de parenthèses et d'un numéro de section. Consultez man(7) pour plus de renseignements sur la signification du numéro de section. Ce mécanisme d'URI est unique aux systèmes UNIX (comme Linux) et n'est pas encore enregistré par l'IETF. Un exemple : <man:ls(1)>.

info - Page de documentation Info

info:nom-de-fichier-virtuel
info:nom-de-fichier-virtuel#nom-de-nœud
info:(nom-de-fichier-virtuel)
info:(nom-de-fichier-virtuel)nom-de-nœud

Ce mécanisme référence les pages de documentation en ligne info (créées par les fichiers texinfo), un format utilisé par les outils GNU. Ce mécanisme est spécifique aux systèmes UNIX (comme Linux) et n'est pas encore enregistré par l'IETF. Actuellement, Gnome et Kde divergent dans la syntaxe d'URI et chacun rejette la syntaxe de l'autre. Les deux premiers formats sont ceux de Gnome ; dans le nom de nœud, tous les espaces sont remplacés par des soulignés. Les deux formats suivants sont ceux de Kde ; les espaces doivent rester tels quels, même si c'est interdit dans les standards d'URI. On peut espérer que dans l'avenir la plupart des outils comprendront les deux formats et accepteront des soulignés en remplacement des espaces. Dans tous les cas, le format sans nom de nœud est supposé viser le nœud « Top »". Exemples de format Gnome : <info:gcc> et <info:gcc#G++_and_GCC>. Exemples de format Kde : <info:(gcc)> et <info:(gcc)G++ and GCC>.

whatis - Recherche de documentation

whatis:chaîne

Ce mécanisme parcourt une base de données de courtes (une ligne) descriptions des commandes et renvoie une liste des descriptions contenant la chaîne. Seules les correspondances de mots complets sont renvoyées. Consultez whatis(1). Ce mécanisme est unique aux systèmes UNIX (comme Linux) et n'est pas encore enregistré par l'IETF.

ghelp - Documentation d'aide Gnome

ghelp:nom-application

Ceci charge la documentation d'aide Gnome pour l'application indiquée. Notez qu'il n'y a pas encore beaucoup de documentation dans ce format.

ldap - Lightweight Directory Access Protocol

ldap://hostport
ldap://hostport/
ldap://hostport/dn
ldap://hostport/dn?attributs
ldap://hostport/dn?attributs?portée
ldap://hostport/dn?attributs?portée?filtre
ldap://hostport/dn?attributs?portée?filtre?extensions

Ce mécanisme prend en charge les requêtes utilisant le protocole Lightweight Directory Access Protocol (LDAP), pour interroger un ensemble de serveurs à propos d'informations organisées hiérarchiquement (comme des gens ou des ressources de calcul). Consultez RFC 2255 pour plus d'informations sur la forme des URL LDAP. Les composantes de cette URL sont :

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 RFC 2253 section 3).

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 RFC 2254 section 4.

extensions

a comma-separated list of type=value pairs, where the =value portion may be omitted for options not requiring it. An extension prefixed with a '!' is critical (must be supported to be valid), otherwise it is noncritical (optional).

Les requêtes LDAP sont plus faciles à comprendre par l'exemple. Voici une requête demandant à ldap.itd.umich.edu des informations à propos de l'Université du Michigan aux U.S. :

ldap://ldap.itd.umich.edu/o=University%20of%20Michigan,c=US

Pour n'obtenir que l'attribut Adresse Postale, on demanderait :

ldap://ldap.itd.umich.edu/o=University%20of%20Michigan,c=US?postalAddress

Pour 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
wais://hostport/base?recherche
wais://hostport/base/wtype/wpath

Ce mécanisme désigne une base de données WAIS, une recherche ou un document (voir IETF RFC 1625 pour plus de renseignements sur WAIS). Hostport est le nom d'hôte, suivi éventuellement d'un deux-points et d'un numéro de port (par défaut 210).

La première forme désigne une base de données WAIS pour les recherches. La seconde désigne une recherche particulière dans la base WAIS indiquée. La troisième forme désigne un document particulier à retrouver dans la base de données WAIS. wtype est la désignation WAIS du type d'objet et wpath est l'identificateur WAIS du document.

Autres mécanismes

Il existe d'autres mécanismes URI. La plupart des outils traitant les URI acceptent un jeu d'URI internes (par exemple, Mozilla a un mécanisme about: pour les informations internes, et le navigateur d'aide Gnome a un mécanisme toc: pour diverses opérations). Il y a de nombreux mécanismes qui ont été définis mais pas très utilisés pour l'instant (par exemple, prospero). Le mécanisme nntp: est déconseillé en faveur de celui news:. Les URN seront prises en charge par le mécanisme urn: avec des espaces de noms hiérarchique (p.ex. : urn:ietf:... pour les documents IETF). Pour le moment, les URN ne sont pas très largement implémentés. Tous les outils ne gèrent pas tous les mécanismes.

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) :

; / ? : @ & = + $ ,
    

Unreserved characters may be included in a URI. Unreserved characters include uppercase and lowercase Latin letters, decimal digits, and the following limited set of punctuation marks and symbols:

- _ . ! ~ * ' ( )
    

Tous les autres caractères doivent être protégés. Un octet protégé est encodé sous forme d'un triplet de caractères, consistant en un signe pourcent « % » suivi de deux chiffres hexadécimaux représentant le code de l'octet (les lettres hexadécimales peuvent être en majuscules ou en minuscules). Par exemple un espace blanc doit être protégé sous forme « %20 », une tabulation « %09 » et le « & » en « %26 ». Comme le caractère "% »" a toujours un rôle réservé pour protéger les autres caractères, il faut le protéger sous forme « %25 ». Il est courant de protéger le caractère espace en symbole plus « + » dans les requêtes. Cette pratique n'est pas défini uniformément dans les RFC correspondantes (qui recommandent %20 plutôt) mais tous les outils acceptant les URI avec des requêtes préparées ainsi. Une URI est toujours montrée dans sa forme protégée.

Unreserved characters can be escaped without changing the semantics of the URI, but this should not be done unless the URI is being used in a context that does not allow the unescaped character to appear. For example, "%7e" is sometimes used instead of "~" in an HTTP URL path, but the two are equivalent for an HTTP URL.

For URIs which must handle characters outside the US ASCII character set, the HTML 4.01 specification (section B.2) and IETF RFC 3986 (last paragraph of section 2.5) recommend the following approach:

(1)

translate the character sequences into UTF-8 (IETF RFC 3629)—see utf-8(7)—and then

(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

When written, URIs should be placed inside double quotes (e.g., "http://www.kernel.org"), enclosed in angle brackets (e.g., <http://lwn.net>), or placed on a line by themselves. A warning for those who use double-quotes: never move extraneous punctuation (such as the period ending a sentence or the comma in a list) inside a URI, since this will change the value of the URI. Instead, use angle brackets instead, or switch to a quoting system that never includes extraneous characters inside quotation marks. This latter system, called the 'new' or 'logical' quoting system by "Hart's Rules" and the "Oxford Dictionary for Writers and Editors", is preferred practice in Great Britain and in various European languages. Older documents suggested inserting the prefix "URL:" just before the URI, but this form has never caught on.

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.

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.