Quand dois-je utiliser une barre oblique dans mon URL?

Quand une barre oblique doit-elle être utilisée dans une URL? Par exemple, mon URL doit-elle ressembler à /about-us/ ou être /about-us ?

Je suis pleinement conscient des problèmes liés au référencement – contenu dupliqué et chose canonique; J’essaie de déterminer lequel je devrais utiliser dans le contexte de servir des pages correctement seul.

Par exemple, mon collègue pense qu’une barre oblique à la fin signifie que c’est un “dossier” – un “répertoire”, ce n’est donc pas un style correct. Mais je pense que sans slash à la fin – ce n’est pas tout à fait correct non plus, car cela ressemble presque à un dossier, mais ce n’est pas le cas et ce n’est pas un fichier normal, mais un nom de fichier sans extension.

Y a-t-il une manière appropriée de savoir qui utiliser?

    À mon avis, les barres obliques sont mal utilisées.

    Fondamentalement, le format de l’URL provenait du même format UNIX de fichiers et de dossiers, plus tard, sur les systèmes DOS, et enfin, adapté au Web.

    Une URL typique de ce livre sur un système d’exploitation de type Unix serait un chemin de fichier tel que file: ///home/username/RomeoAndJuliet.pdf, identifiant le livre électronique enregistré dans un fichier sur un disque dur local.

    Source: Wikipedia: Identificateur de ressource uniforme

    Une autre bonne source à lire: Wikipedia: Schéma URI

    Selon la RFC 1738, qui définissait les URL en 1994, lorsque les ressources contiennent des références à d’autres ressources, elles peuvent utiliser des liens relatifs pour définir l’emplacement de la deuxième ressource comme si elles étaient “au même endroit chemin”. Il a poursuivi en disant que ces URL relatives dépendent de l’URL originale contenant une structure hiérarchique par rapport à laquelle le lien relatif est basé, et que les schémas ftp, http, et URL de fichier sont des exemples qui peuvent être considérés comme hiérarchiques, avec le les composants de la hiérarchie étant séparés par “/”.

    Source: Wikipedia Uniform Resource Locator (URL)

    Aussi:

    C’est la question que nous entendons souvent. En avant pour les réponses! Historiquement, il est fréquent que les URL avec une barre oblique finale indiquent un répertoire et que celles sans barre oblique finale indiquent un fichier:

    http://example.com/foo/ (avec barre oblique, classiquement un répertoire)

    http://example.com/foo (sans barre oblique, classiquement un fichier)

    Source: Blog central de Google WebMaster – Couper ou ne pas couper

    Finalement:

    1. Une barre oblique à la fin de l’URL rend l’adresse “jolie”.

    2. Une URL sans barre oblique à la fin et sans extension semble quelque peu “bizarre”.

    3. Vous ne nommerez jamais votre fichier CSS (par exemple) http://www.sample.com/stylesheet/

    MAIS je suis un partisan des meilleures pratiques du Web, quel que soit l’environnement. Il peut être difficile et peu clair, comme vous l’avez dit à propos de l’URL sans ext.

    Ce n’est pas une question de préférence. /base et /base/ ont une sémantique différente. Dans de nombreux cas, la différence est sans importance. Mais c’est important quand il y a des URL relatives.

    • child rapport à /base/ is /base/child .
    • child rapport à /base est (peut-être étonnamment) /child .

    Je suis toujours surpris par le recours fréquent à des barres obliques sur les URL non-répertoires (WordPress entre autres). Cela ne devrait vraiment pas être un débat, car mettre une barre oblique après une ressource est sémantiquement erroné. Le Web a été conçu pour fournir des ressources adressables, et ces adresses – les URL – ont été conçues pour émuler une hiérarchie de systèmes de fichiers de style * nix. Dans ce contexte:

    • Les barres obliques indiquent toujours les répertoires, jamais les fichiers.
    • Les fichiers peuvent être nommés n’importe quoi (avec ou sans extensions), mais ne peuvent pas contenir ou se terminer par des barres obliques.

    En utilisant ces directives, il est faux de placer une barre oblique après une ressource non-répertoire.

    Ce n’est pas vraiment une question d’esthétique, mais bien une différence technique. Le répertoire en y pensant est totalement correct et explique à peu près tout. Travaillons sur:

    Vous êtes de retour à l’âge de pierre maintenant ou ne servez que des pages statiques

    Vous avez une structure de répertoires fixe sur votre serveur Web et uniquement des fichiers statiques tels que des images, du HTML, etc. – pas de scripts côté serveur ou autre.

    Un navigateur demande /index.htm , il existe et est livré au client. Plus tard, vous avez beaucoup de DVD, par exemple, et une page HTML pour chacun d’eux dans le répertoire /dvd/ . Maintenant, quelqu’un demande /dvd/adams_apples.htm et il est livré car il est là.

    Un jour, quelqu’un demande juste /dvd/qui est un répertoire et le serveur essaie de comprendre ce qu’il faut livrer. Outre les ressortingctions d’access et ainsi de suite, il existe deux possibilités: Afficher le contenu du répertoire (je parie que vous l’avez déjà vu quelque part) ou afficher un fichier par défaut (dans Apache: DirectoryIndex: sets the file that Apache will serve if a directory is requested. )

    Jusqu’ici tout va bien, c’est le cas attendu. Cela montre déjà la différence de manipulation, alors allons-y:

    A 5h34, vous avez commis une erreur lors du téléchargement de vos fichiers

    (Ce qui est d’ailleurs tout à fait compréhensible.) Donc, vous avez fait quelque chose de complètement faux et au lieu de télécharger /dvd/the_big_lebowski.htm vous avez téléchargé ce fichier en tant que dvd (sans extension) dans / .

    Quelqu’un a mis en favori votre liste de répertoires /dvd/ (bien sûr, vous ne vouliez pas créer et toujours mettre à jour cet index.htm ) et visitez votre site Web. Le contenu du répertoire est livré – tout va bien.

    Quelqu’un a entendu parler de votre liste et tape /dvd . Et maintenant c’est foutu. Au lieu de votre répertoire de DVD listant le serveur trouve un fichier avec ce nom et livre votre fichier Big Lebowski.

    Donc, vous supprimez ce fichier et dites au gars de recharger la page. Votre serveur recherche le fichier /dvd , mais il est parti. La plupart des serveurs remarqueront alors qu’il existe un répertoire portant ce nom et indiquent au client que ce qu’il cherchait est bien ailleurs. La réponse sera probablement:

    Status Code:301 Moved Permanently avec l’ Location: http://[...]/dvd/

    Donc, en ignorant totalement ce que vous pensez des répertoires ou des fichiers, le serveur ne peut gérer que ce genre de choses et – sauf indication contraire – décide pour vous de la signification de “slash” ou non.

    Finalement, après avoir reçu cette réponse, le client charge /dvd/ et tout va bien.

    Est-ce bien? Non.

    “Très bien” n’est pas suffisant pour vous

    Vous avez une page dynamic où tout est passé à /index.php et est traité. Tout a bien fonctionné jusqu’à maintenant, mais tout commence à ralentir et vous enquêtez.

    Bientôt, vous remarquerez que /dvd/list fait exactement la même chose: redirect vers /dvd/list/ qui est ensuite traduit en interne dans index.php?controller=dvd&action=list . Une demande supplémentaire – mais pire encore! customer/login redirige vers le customer/login/ qui à son tour redirige vers l’URL HTTPS du customer/login/ . Vous finissez par avoir des tonnes de redirections HTTP inutiles (= requêtes supplémentaires) qui rendent l’expérience utilisateur plus lente.

    Vous avez probablement un index de répertoire par défaut ici aussi: index.php?controller=dvd sans action charge simplement en interne index.php?controller=dvd&action=list .

    Résumé:

    • S’il se termine par / il ne peut jamais être un fichier. Aucun serveur ne devine.

    • Slash ou no slash sont des significations complètement différentes. Il existe une différence technique / de ressources entre “slash” ou “slash”, et vous devez en être conscient et l’utiliser en conséquence. Juste parce que le serveur charge le plus souvent /dvd/index.htm – ou charge les scripts appropriés – lorsque vous dites /dvd : Il le fait, mais pas parce que vous avez fait la bonne demande. Qui aurait été /dvd/ .

    • Omettre la barre oblique même si vous voulez dire que la version avec barre oblique vous donne une pénalité de requête HTTP supplémentaire. Ce qui est toujours mauvais (pensez à la latence mobile) et a plus de poids qu’une “jolie URL” – d’autant plus que les robots ne sont pas aussi stupides que les SEO le pensent ou le souhaitent ()

    Lorsque vous créez votre URL /about-us/ (avec la barre oblique finale), il est facile de démarrer avec un seul fichier index.html , puis de le développer et d’append d’autres fichiers (par exemple, our-CEO-john-doe.jpg ) ou même construire une hiérarchie sous-jacente (par exemple /about-us/company/ , /about-us/products/ , etc.) selon les besoins, sans changer l’URL publiée . Cela vous donne une grande flexibilité.

    Qui a dit qu’un nom de fichier nécessitait une extension? jetez un oeil sur une machine * nix parfois …
    Je suis d’accord avec ton ami, pas de slash traînant.

    D’autres réponses semblent favoriser l’omission de la barre oblique. Il y a un cas dans lequel une barre oblique finale aidera à l’optimisation des moteurs de recherche (SEO). C’est le cas que votre document a ce qui semble être une extension de fichier qui n’est pas .html . Cela devient un problème avec les sites qui évaluent les sites Web. Ils pourraient choisir entre ces deux URL:

    • http://mysite.example.com/rated.example.com
    • http://mysite.example.com/rated.example.com/

    Dans un tel cas, je choisirais celui avec la barre oblique . En effet, l’extension .com est une extension pour les fichiers de commandes exécutables Windows. Les moteurs de recherche et les vérificateurs de virus détestent souvent les URL qui semblent contenir des logiciels malveillants dissortingbués via de tels mécanismes. La barre oblique semble atténuer les problèmes, permettant à la page de se classer dans les moteurs de recherche et d’obtenir des vérificateurs de virus.

    Si vos URL n’ont pas dans la partie fichier, je vous recommande d’omettre la barre oblique pour simplifier.