Extrait de l'émission CPU release Ex0213 : Disséquons une URL, première partie.
La fin du chemin est (théoriquement) le nom du fichier que vous demandez.
À noter qu'il peut être implicite. Par exemple : si vous demandez une URL qui finit par un /
à un serveur web comme Apache ou IIS, comme vous n'indiquez qu'un répertoire, le serveur peut vous servir un document par défaut dans ce répertoire. En général, il s'appelle index.html
, et donc son nom est implicite si vous ne le précisez pas.
On peut aussi avoir un listing du répertoire par défaut, mais de nos jours, on sait que c'est une très très très très mauvaise idée de laisser un serveur web paramétré comme ça.
Si votre URL n'a ni protocole, ni autorité, mais commence directement par un / donc avec le chemin en premier, votre logiciel client, par exemple votre navigateur web, va considérer que vous faites référence à la racine de l'arborescence dans le contexte du programme client, et très probablement au système de fichier local de l'ordinateur.
D'une manière amusante, si vous ne précisez ni protocole, ni autorité, mais que vous avez une partie de chemin dans l'arborescence sans avoir commencé par un /
, vous avez une URL relative. Et dans ce cas-là, le fichier que vous appelez est censé être dans le même répertoire que là où vous êtes. Ou plus exactement, relativement à ce répertoire, donc vous pouvez écrire votre chemin avec .. pour remonter dans le répertoire précédent.
C'est une propriété vraiment intéressante d'une URL : Si on n'écrit pas tout ce qui est avant, le chemin peut être relatif ou absolu, on retombe alors sur le système de fichier local, ou dans le contexte du répertoire où est votre logiciel.
Si vous faites un lien dans le document où vous êtes, il peut arriver que le navigateur vous renvoie à la vue implicite de son répertoire.
Entre nous, utiliser des liens relatifs peut vous jouer des tours. Quand vous écrivez une page web, ne faites pas l'économie du chemin : je vous recommande de toujours indiquer le chemin absolu dans les liens.
C'est un point [ahaha] anecdotique, mais dans un nom de fichier, le point qui indique l'extension et donc l'usage attendu d'un document n'est que purement conventionnel, sauf chez Microsoft. Et CP/M (les vieux savent). On l'a ni sur le Mac (où historiquement, on utilise un système de fork de ressources), ni vraiment dans Unix.
Et donc l'extension dans le nom d'un fichier est moins utile pour un navigateur web que le type-mime de ce fichier. Par exemple, rien ne vous empêche de renommer un .png
en .jpg
. Ça ne rendra pas l'image plus légère mais votre navigateur web le reconnaitra quand même, tant que le début du type-mime servi commence par image/
. Oui, le navigateur ignore la suite, seul ce premier mot lui suffit.
En 2008, j'avais créé un CMS, un gestionnaire de sites web, où je créais des fichiers de sous-formats avec leur nom de taille après la virgule. En gros, à côté de image.jpg
, j'avais un image.jpg,petit
. Tant que le serveur web était au courant que les noms de fichier avec l'extension .jpg,mot
devaient être servi avec un mime-type image/jpeg
, c'est passé partout sans soucis : même si le fichier était en fait un gif ou un png, il l'affichait proprement. Oui, même Internet Explorer !
Là encore, il est intéressant de connaître ce qui n'est que convention et ce qui est implémentation des standards.
Texte : Da Scritch
Corrections et nombreux conseils : Stéphane Bortzmeyer
Illustration : Arborescence du serveur de CPU, vu dans un explorateur de fichier en mode arboré. CC-By DaScritch