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 qui pointent vers la même page, quelle que soit la capitalisation)?

Wikipédia, par exemple, est un site Web sensible à la casse des lettres (à l'exception du premier caractère):

https://en.wikipedia.org/wiki/St Un ck_Exchange est DOA.

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 je pense qu’il est utile de l’envisager. 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 d'autres, y compris Windows XP Professionnel). 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 qui peuvent être utilisés pour configurer le périphérique, notamment les 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 les imprimantes ou les imprimantes. 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?" Demande: "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. C'est pourquoi Unix a fourni les fonctionnalités souhaitables 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, qui ne prend tout simplement pas en charge les lettres minuscules. peut-être dans le but de simplifier les choses avec des ordinateurs moins puissants qui utilisent moins de mémoire. Ces systèmes d'exploitation étant différents, il en résulte que les serveurs Web de conception simple (versions antérieures 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. La conception prévue 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 qui pointent vers la même page, quelle que soit la capitalisation)?

Le cinquième point numéroté de la réponse de William Hay mentionne un avantage technique: les URL peuvent être un moyen efficace pour un navigateur Web d’envoyer un peu d’informations à un serveur Web, et davantage d’informations peuvent être incluses s’il ya moins de restrictions, ce qui rend la casse sensible Une restriction réduirait la quantité d'informations pouvant être incluses.

Cependant, dans de nombreux cas, la sensibilité à la casse ne présente aucun avantage incontestable, comme le prouve le fait qu'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.)

Les URL ne sont pas sensibles à la casse, elles n'en représentent qu'une partie.
Par exemple, rien n’est sensible à la casse dans l’URL https://google.com,

En référence à RFC 3986 - Identifiant de ressource uniforme (URI): Syntaxe générique

D'abord, sur Wikipedia , une URL ressemble à ceci:

 scheme:[//host[:port]][/]path[?query][#fragment]

(J'ai enlevé la user:passwordpartie parce qu'elle n'est pas intéressante et rarement utilisée)

• scheme:

les régimes sont insensibles à la casse

• host:

Le sous-composant hôte est sensible à la casse.

• path:

Le composant path contient des données ...

• query:

Le composant de requête contient des données non hiérarchiques ...

• fragment:

Les types de supports individuels peuvent définir leurs propres restrictions ou structures dans la syntaxe d'identificateur de fragment pour spécifier différents types de sous-ensembles, vues ou références externes.

Ainsi, les schemeet hostsont insensibles à la casse.
Le reste de l'URL est sensible à la casse.

Pourquoi la pathcasse est-elle sensible?

Cela semble être la question principale.
Il est difficile de dire "pourquoi" quelque chose a été fait si ce n’était pas documenté, mais on peut très bien deviner.
J'ai sélectionné des citations très spécifiques de la spécification, en mettant l'accent sur les données .
Regardons à nouveau l'URL:

 scheme:[//host[:port]][/]path[?query][#fragment]
 \____________________/\________________________/
        Location                 Data

• Emplacement - L'emplacement a une forme canonique et est insensible à la casse. Pourquoi? Vous pourriez donc probablement acheter un nom de domaine sans avoir à acheter des milliers de variantes.

• Données - les données sont utilisées par le serveur cible et l'application peut choisir ce que cela signifie . Cela n'aurait aucun sens de rendre les données insensibles à la casse. L'application devrait avoir plus d'options, et la définition d'une insensibilité à la casse dans la spécification limitera ces options.
  C'est également une distinction utile pour HTTPS: les données sont cryptées , mais l'hôte est visible.

Est-ce utile?

La sensibilité à la casse présente des inconvénients en ce qui concerne la mise en cache et les URL canoniques, mais elle est certainement utile. Quelques exemples:

• Base64 , utilisé dans les URI de données .
• Les sites peuvent encoder des données Base64 dans l'URL, par exemple: http://tryroslyn.azurewebsites.net/#f:r/A4VwRgNglgxgBDCBDAziuBhOBvGB7AOxQBc4SAnKAgczLgF44AiAUQwBBTDuKuYG
• Les raccourcisseurs d'URL utilisent la sensibilité à la casse: /a5Bpeuvent être différents de/a5b
• Comme vous l'avez mentionné, Wikipedia peut différencier "SIDA" de "SIDA".

Facile. Le système d'exploitation est sensible à la casse. Les serveurs Web ne s’inquiètent généralement pas à moins d’avoir à 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 essentiel. C'est pourquoi IIS n'a jamais été sensible à la casse. parce que Windows n'a jamais été sensible à la casse.

[Mise à 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 sur des ordinateurs coûteux, tels que les serveurs DEC VAX / VMS et les Unix du jour (Berkeley et Ultrix, entre autres) sur des ordinateurs centraux ou de taille moyenne, 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 initiale 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. Facile.

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 nécessitent 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 comprennent 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.

1. 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.

2. 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).

3. 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.

4. 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 aient été 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.

5. Si vous essayez de regrouper de nombreuses données dans un URI (par exemple, un URI 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.txtet TODO.TXT(je sais, mais il était logique pour moi quand je fait 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, je voudrais 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 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, alors que 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?

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 été mis au point 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. Bien 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.

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 des décisions sont prises par les comités de normalisation, 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 leur justification 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 -mistake.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 des raisons de commodité d'implémentation et que la facilité d'utilisation (pour les utilisateurs finaux) n'a même jamais été envisagée. De nouveau, au début, les utilisateurs étaient tous des programmeurs Unix.

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 qui pointent vers la même page, quelle que soit la capitalisation)?

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=xXxxxxxxX.