Pourquoi les URL sont-elles sensibles à la casse?
Ma question: lors de la conception initiale des URL, pourquoi la sensibilité à la casse est-elle devenue une fonctionnalité? Je pose cette question car il me semble (c’est-à-dire un non-initié) que l’insensibilité à la casse serait préférable pour éviter les erreurs inutiles et simplifier une chaîne de texte déjà compliquée.
En outre, existe-t-il un objectif/avantage réel à avoir une URL sensible à la casse (par opposition à la grande majorité des URL pointant sur la même page, quelle que soit la casse)?
Wikipédia, par exemple, est un site Web sensible à la casse des lettres (à l'exception du premier caractère):
Pourquoi l'URL ne serait-il pas sensible à la casse?
Je comprends que cela puisse ressembler à un type de question rhétorique de type provocateur (et "avocat du diable"), mais j'estime qu'il est utile de l'examiner. La conception de HTTP est telle qu'un "client", que nous appelons communément un "navigateur Web", demande des données au "serveur Web".
De nombreux serveurs Web différents sont disponibles. Microsoft a publié IIS avec les systèmes d'exploitation Windows Server (et autres, y compris Windows XP Professional). Unix a des poids lourds comme nginx et Apache, sans parler des offres plus petites comme le httpd interne, ou thttpd, ou lighttpd d'OpenBSD. De plus, de nombreux périphériques réseau sont dotés de serveurs Web intégrés pouvant être utilisés pour configurer le périphérique, y compris des périphériques ayant des fonctions spécifiques aux réseaux, tels que les routeurs (y compris de nombreux points d’accès Wi-Fi et les modems DSL) et d’autres périphériques tels que des imprimantes ou UPS (unités d'alimentation sans coupure sauvegardées par batterie) pouvant avoir une connectivité réseau.
La question "Pourquoi les URL sont-elles sensibles à la casse?" Est la suivante: "Pourquoi les serveurs Web considèrent-ils l'URL comme étant sensible à la casse?" Et la réponse est: ils ne le font pas tous. Au moins un serveur Web, qui est assez populaire, ne respecte généralement pas la casse. (Le serveur Web est IIS.)
L'une des principales raisons du comportement différent d'un serveur Web à l'autre est sans doute une question de simplicité. Le moyen le plus simple de créer un serveur Web consiste à procéder de la même manière que le système d’exploitation de l’ordinateur/du périphérique pour localiser les fichiers. Plusieurs fois, les serveurs Web localisent un fichier afin de fournir une réponse. Unix a été conçu autour d'ordinateurs haut de gamme. Unix a donc fourni la fonctionnalité désirable consistant à autoriser les lettres majuscules et minuscules. Unix a décidé de traiter les majuscules et les minuscules comme différentes car, eh bien, elles sont différentes. C'est la chose simple et naturelle à faire. Windows a toujours été insensible à la casse du fait de son désir de prendre en charge les logiciels déjà créés. Cet historique remonte à DOS et ne prend tout simplement pas en charge les lettres minuscules, éventuellement dans le but de simplifier les choses avec des ordinateurs moins puissants, utilisant moins de mémoire. . Ces systèmes d'exploitation étant différents, il en résulte que les serveurs Web simplement conçus (les premières versions de) reflètent les mêmes différences.
Maintenant, avec tout ce fond, voici quelques réponses spécifiques aux questions spécifiques:
Quand les URL ont été conçues pour la première fois, pourquoi la sensibilité à la casse est-elle devenue une fonctionnalité?
Pourquoi pas? Si tous les serveurs Web standard étaient insensibles à la casse, cela indiquerait qu'ils suivaient un ensemble de règles spécifiées par la norme. Il n'y avait tout simplement aucune règle indiquant que cette affaire devait être ignorée. La raison pour laquelle il n'y a pas de règle est simplement qu'il n'y avait aucune raison pour qu'il en soit ainsi. Pourquoi s'embarrasser de règles inutiles?
Je pose cette question car il me semble (c’est-à-dire un non-initié) que l’insensibilité à la casse serait préférable pour éviter les erreurs inutiles et simplifier une chaîne de texte déjà compliquée.
Les URL ont été conçues pour être traitées par des machines. Bien qu'une personne puisse taper une URL complète dans une barre d'adresse, cela ne faisait pas partie intégrante de la conception envisagée. Le but recherché est que les gens suivent les hyperliens ("cliquent sur"). Si des non-initiés font cela, ils se moquent bien de savoir si l'URL invisible est simple ou compliquée.
En outre, existe-t-il un objectif/avantage réel à avoir une URL sensible à la casse (par opposition à la grande majorité des URL pointant sur la même page, quelle que soit la casse)?
Le cinquième point numéroté de réponse de William Hay mentionne un avantage technique: les URL peuvent être un moyen efficace pour un navigateur Web d'envoyer un brin d'information à un serveur Web, et davantage d'informations peuvent être incluses s'il y en a. moins de restrictions, donc une restriction de sensibilité à la casse réduirait la quantité d'informations pouvant être incluses.
Cependant, dans de nombreux cas, la sensibilité à la casse ne présente pas un avantage incontestable, comme en témoigne le fait que IIS ne s'en préoccupe généralement pas.
En résumé, la raison la plus convaincante est probablement la simplicité pour ceux qui ont conçu le logiciel de serveur Web, en particulier sur une plate-forme sensible à la casse comme Unix. (HTTP n'était pas quelque chose qui a influencé la conception originale de Unix, car Unix est nettement plus ancien que HTTP.)
Simple. Le système d'exploitation est sensible à la casse. Les serveurs Web ne s’inquiètent généralement pas à moins de devoir frapper le système de fichiers à un moment donné. C’est là que Linux et d’autres systèmes d’exploitation basés sur Unix appliquent les règles du système de fichiers, auquel cas la sensibilité est un élément majeur. C'est pourquoi IIS n'a jamais été sensible à la casse; parce que Windows n'a jamais été sensible à la casse.
[Mettre à jour]
Certains commentaires ont été avancés dans les commentaires (depuis leur suppression) sur le fait que les URL ont une relation quelconque avec le système de fichiers, comme je l’ai indiqué. Ces arguments sont devenus chauffants. Il est extrêmement imprévoyant de penser qu’il n’ya pas de relation. Il y en a absolument! Permettez-moi d'expliquer plus loin.
Les programmeurs d'applications ne sont généralement pas des programmeurs internes aux systèmes. Je ne suis pas insultant. Il s’agit de deux disciplines distinctes et la connaissance interne du système n’est pas nécessaire pour écrire des applications lorsque celles-ci peuvent simplement appeler le système d’exploitation. Étant donné que les programmeurs d'application ne sont pas des programmeurs internes au système, il est impossible de contourner les services du système d'exploitation. Je dis cela parce que ce sont deux camps séparés et ils se croisent rarement. Les applications sont écrites pour utiliser les services de système d'exploitation en règle générale. Il y a de rares exceptions, bien sûr.
À l'époque où les serveurs Web ont commencé à apparaître, les développeurs d'applications n'ont pas tenté de contourner les services du système d'exploitation. Il y avait plusieurs raisons à cela. Un, ce n'était pas nécessaire. Deuxièmement, les programmeurs d'applications ne savaient généralement pas comment contourner les services de système d'exploitation. Troisièmement, la plupart des systèmes d’exploitation étaient extrêmement stables et robustes, ou extrêmement simples et légers et ne valaient pas le coût.
N'oubliez pas que les premiers serveurs Web fonctionnaient soit sur des ordinateurs coûteux, tels que les serveurs DEC VAX/VMS et sur l'Unix du jour (Berkeley et Ultrix, entre autres), sur des ordinateurs à châssis principal ou intermédiaire, puis peu de temps après. ordinateurs légers tels que PC et Windows 3.1. Lorsque des moteurs de recherche plus modernes ont commencé à apparaître, tels que Google en 1997/8, Windows est passé à Windows NT et d’autres systèmes d’exploitation tels que Novell et Linux ont également commencé à utiliser des serveurs Web. Apache était le serveur Web dominant, bien que d'autres, tels que IIS et O'Reilly, fussent également très populaires. Aucun d'entre eux à l'époque ne contournait les services du système d'exploitation. Il est probable qu'aucun des serveurs Web ne le soit encore aujourd'hui.
Les premiers serveurs Web étaient assez simples. Ils sont toujours aujourd'hui. Toute demande faite pour une ressource via une demande HTTP qui existe sur un disque dur a été/est faite par le serveur Web via le système de fichiers du système d'exploitation.
Les systèmes de fichiers sont des mécanismes plutôt simples. Lorsqu'une demande d'accès à un fichier est faite, si ce fichier existe, la demande est transmise au sous-système d'autorisation et, si elle est accordée, la demande d'origine est satisfaite. Si la ressource n'existe pas ou n'est pas autorisée, une exception est levée par le système. Lorsqu'une application fait une demande, un déclencheur est défini et l'application attend. Lorsque la demande reçoit une réponse, le déclencheur est déclenché et l'application traite la réponse à la demande. Cela fonctionne toujours comme ça aujourd'hui. Si l'application constate que la demande est satisfaite, elle continue, si elle a échoué, elle exécute une condition d'erreur dans son code ou meurt si elle n'est pas traitée. Simple.
Dans le cas d'un serveur Web, en supposant qu'une demande d'URL pour un chemin/fichier soit effectuée, le serveur Web prend la partie chemin/fichier de la demande d'URL (URI) et envoie une demande au système de fichiers et celui-ci est satisfait. ou lève une exception. Le serveur Web traite ensuite la réponse. Si, par exemple, le chemin et le fichier demandés sont trouvés et que l'accès est accordé par le sous-système d'autorisation, le serveur Web traite alors cette demande d'E/S normalement. Si le système de fichiers génère une exception, le serveur Web renvoie une erreur 404 si le fichier est introuvable ou 403 interdit si le code anomalie n'est pas autorisé.
Étant donné que certains systèmes d'exploitation sont sensibles à la casse et que les systèmes de fichiers de ce type exigent des correspondances exactes, le chemin/fichier demandé au serveur Web doit correspondre exactement à ce qui existe sur le disque dur. La raison en est simple. Les serveurs Web ne devinent pas ce que vous voulez dire. Aucun ordinateur ne le fait sans être programmé pour. Les serveurs Web traitent simplement les demandes au fur et à mesure de leur réception. Si la partie chemin/fichier de la demande d'URL transmise directement au système de fichiers ne correspond pas à celle présente sur le disque dur, le système de fichiers lève une exception et le serveur Web renvoie une erreur 404 Introuvable.
C'est vraiment aussi simple que ça. Ce n'est pas sorcier. Il existe une relation absolue entre la portion chemin/fichier d'une URL et le système de fichiers.
Les URL prétendent être un localisateur de ressources UNIFORM et peuvent pointer vers des ressources antérieures au Web. Certaines d'entre elles sont sensibles à la casse (par exemple, de nombreux serveurs ftp) et les URL doivent pouvoir représenter ces ressources de manière raisonnablement intuitive.
L'insensibilité à la casse nécessite plus de travail lorsque vous recherchez une correspondance (dans le système d'exploitation ou au-dessus de celui-ci).
Si vous définissez des URL en tant que serveurs individuels sensibles à la casse, vous pouvez les implémenter sans tenir compte de la casse s'ils le souhaitent. L'inverse n'est pas vrai.
L'insensibilité à la casse peut être non triviale dans les contextes internationaux: https://en.wikipedia.org/wiki/Dotted_and_dotless_I . La RFC1738 autorisait également l'utilisation de caractères en dehors de la plage ASCII, à condition qu'ils soient codés sans spécifier de jeu de caractères. C'est assez important pour quelque chose qui s'appelle le WORLD Wide Web. Définir les URL sans tenir compte de la casse ouvrirait beaucoup de possibilités de bogues.
Si vous essayez de regrouper de nombreuses données dans un URI (par exemple, un RI de données ), vous pouvez en stocker davantage si les majuscules et les minuscules sont distinctes.
J'ai volé sur le blog une vieille nouvelle chose l'habitude d'aborder des questions de la forme "pourquoi est-ce que quelque chose est le cas?" avec la contre-question "à quoi ressemblerait le monde, si ce n'était pas le cas?"
Supposons que je mette en place un serveur Web pour me servir moi-même mes fichiers de documents à partir d'un dossier afin que je puisse les lire au téléphone lorsque je suis sorti du bureau. Maintenant, dans mon dossier de documents, j'ai trois fichiers, todo.txt, ToDo.txt et TODO.TXT (je sais, mais cela m’a semblé logique de créer les fichiers).
Quelle URL voudrais-je pouvoir utiliser pour accéder à ces fichiers? Je voudrais y accéder de manière intuitive, en utilisant http://www.example.com/docs/filename.
Supposons que j'ai un script qui me permet d'ajouter un contact à mon carnet d'adresses, ce que je peux également faire sur le Web. Comment cela devrait-il prendre ses paramètres? Eh bien, j'aimerais l'utiliser comme: http://www.example.com/addcontact.php?name=Tom McHenry von der O'Reilly. Mais s'il n'y avait aucun moyen pour moi de spécifier le nom par cas, comment pourrais-je le faire?
Comment pourrais-je différencier les pages de wiki pour Cat et CAT, Text et TEXT, latex et LaTeX? Dégagez les pages, je suppose, mais je préfère simplement obtenir la chose que j'ai demandée.
Mais tout cela donne l'impression de répondre à la mauvaise question, de toute façon.
La question que je vous demandais vraiment est: "Pourquoi les serveurs Web 404 vous considèrent-ils comme une différence de casse, alors qu’ils sont des ordinateurs, conçus pour simplifier la vie, et qu’ils sont parfaitement capables de détecter au moins les différences de cas les URL j'ai tapé cela fonctionnerait? "
La réponse à cette question est que, même si certains sites l'ont fait (et mieux, ils vérifient également d'autres fautes de frappe), personne n'a pensé qu'il valait la peine de modifier la page d'erreur 404 par défaut d'un serveur Web pour le faire ... mais peut-être qu'ils le devraient?
Comment faut-il lire "pourquoi a-t-il été conçu de cette façon?" question? Demandez-vous un compte rendu historiquement exact du processus de prise de décision ou demandez-vous "pourquoi quelqu'un le concevrait-il de cette façon?"?
Il est très rarement possible d'obtenir un compte historiquement exact. Parfois, lorsque les comités de normalisation prennent des décisions, le déroulement du débat est documenté, mais au début du Web, les décisions étaient prises à la hâte par quelques personnes - dans ce cas probablement par TimBL lui-même - et la raison est peu probable. avoir été écrit. Mais TimBL a admis avoir commis des erreurs dans la conception des URL - voir http://www.dailymail.co.uk/sciencetech/article-1220286/Sir-Tim-Berners-Lee-admits-forward-slashes) -web-address-error.html
Au début, les URL mappaient très directement sur les noms de fichiers, et les fichiers se trouvaient généralement sur des machines de type Unix, et les machines de type Unix avaient des noms de fichier sensibles à la casse. Donc, je suppose que c'est ce qui s'est passé de cette façon pour la commodité de la mise en œuvre, et la facilité d'utilisation (pour les utilisateurs finaux) n'a même jamais été envisagée. Encore une fois, dans les premiers temps, les utilisateurs étaient tous des programmeurs Unix.
Bien que la réponse ci-dessus soit correcte et bonne. Je voudrais ajouter quelques points supplémentaires.
Pour mieux comprendre, il faut comprendre la différence fondamentale entre le serveur Unix (Linux) et le serveur Windows. Unix est sensible à la casse & Windows n'est pas un système d'exploitation sensible à la casse.
Le protocole HTTP a évolué ou a commencé à être mis en œuvre vers 1990. Le protocole HTTP a été conçu par des ingénieurs travaillant pour des instituts du CERN. Les scientifiques de cette époque utilisaient pour la plupart des machines Unix et non pas Windows.
La plupart des scientifiques connaissaient Unix, ils ont donc pu être influencés par le système de fichiers de style Unix.
Le serveur Windows est sorti après 2000. Beaucoup avant que le serveur Windows ne devienne populaire, le protocole HTTP était bien mûri et les spécifications complètes.
Cela pourrait être la raison.
Cela n'a rien à voir avec l'endroit où vous avez acheté votre domaine, le DNS n'est pas sensible à la casse. Mais le système de fichiers sur le serveur que vous utilisez pour l'hébergement est.
Ce n'est pas vraiment un problème et c'est assez commun sur les hôtes * nix. Assurez-vous simplement que tous les liens que vous écrivez sur vos pages sont corrects et vous n'aurez pas de problème. Pour faciliter les choses, je vous recommande de toujours nommer vos pages en minuscules, vous n'avez donc jamais besoin de vérifier le nom lorsque vous écrivez un lien.
Closetnoc a raison sur le système d'exploitation. Certains systèmes de fichiers traitent le même nom avec une casse différente comme des fichiers différents.
En outre, existe-t-il un objectif/avantage réel à avoir une URL sensible à la casse (par opposition à la grande majorité des URL pointant sur la même page, quelle que soit la casse)?
Oui. pour éviter les problèmes de contenu en double.
Si vous aviez par exemple les URL suivantes:
http://example.com/page-1
http://example.com/Page-1
http://example.com/paGe-1
http://example.com/PAGE-1
http://example.com/pAGE-1
et ils pointaient tous sur la même page avec le même contenu, vous auriez alors un contenu en double et je suis sûr que si vous avez un compte sur la console de recherche Google (outils pour les webmasters), Google vous l'indiquera.
Si vous vous trouvez dans cette situation, je vous suggérerais d’utiliser toutes les URL minuscules, puis de rediriger les URL contenant au moins une lettre majuscule dans la version minuscule. Donc, dans la liste des URL ci-dessus, redirigez toutes les URL vers la première URL.
La sensibilité à la casse a de la valeur.
S'il y a 26 lettres, chacune avec une capacité de majuscule, cela fait 52 caractères.
4 caractères ont la possiblité de 52 * 52 * 52 * 52 combinaisons, soit 7311616 combinaisons.
Si vous ne pouvez pas mettre les caractères en majuscule, le nombre de combinaisons est 26 * 26 * 26 * 26 = 456976
Il y a 14 fois plus de combinaisons pour 52 caractères que pour 26. Ainsi, pour stocker des données, les URL peuvent être plus courtes et plus d'informations peuvent être transmises sur des réseaux avec moins de données transférées.
C’est pourquoi YouTube est utilisé avec des URL telles que https://www.youtube.com/watch?v=xXxxxxxx