Pourquoi les URL sont-elles sensibles à la casse?

Pourquoi ne « t lURL doit-elle être sensible à la casse?

Je comprends que cela peut ressembler à un type de question rhétorique provocante (et « lavocat du diable »), mais je pense que cest utile à considérer. La conception de HTTP est quun « client », que nous appelons communément un « navigateur Web », demande des données au « serveur Web ».

Il existe de très nombreux serveurs Web différents. Microsoft a publié IIS avec Windows Systèmes dexploitation serveur (et 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 dOpenBSD, ou thttpd, ou lighttpd. De plus, de nombreux appareils compatibles réseau ont des serveurs Web intégrés qui peuvent être utilisés pour configurer lappareil, y compris des appareils à des fins spécifiques aux réseaux, comme les routeurs (y compris de nombreux points daccès Wi-Fi et les modems DSL) et dautres appareils tels que les imprimantes ou Les onduleurs (blocs dalimentation sans interruption alimentés par batterie) qui peuvent avoir une connectivité réseau.

La question « Pourquoi les URL sont-elles sensibles à la casse? », Se demande: « Pourquoi les serveurs Web traitent-ils lURL comme étant sensible à la casse?  » Et la vraie réponse est: ils ne font pas tous cela. Au moins un serveur Web, qui est assez populaire, nest généralement PAS sensible à la casse. (Le serveur Web est IIS.)

Une des principales raisons de un comportement différent entre différents serveurs Web se résume probablement à une question de simplicité. La façon simple de créer un serveur Web est de faire les choses de la même manière que la façon dont le système dexploitation de lordinateur / du périphérique localise les fichiers. Plusieurs fois, les serveurs Web localisent un fichier afin de fournir une réponse. Unix a été conçu autour dordinateurs haut de gamme, et donc Unix a fourni la fonctionnalité souhaitable dautoriser les lettres majuscules et minuscules. Unix a décidé de traiter les majuscules et les minuscules comme étant différents parce que, eh bien, ils sont différents. Cest la chose simple et naturelle à faire. Windows a lhabitude dêtre insensible à la casse en raison dun désir de prendre en charge les logiciels déjà créés, et cette histoire remonte à DOS qui ne prenait tout simplement pas en charge les lettres minuscules, peut-être dans un effort pour simplifier les choses avec des ordinateurs moins puissants qui utilisent moins de mémoire. Étant donné que ces systèmes dexploitation sont différents, le résultat est que les serveurs Web (les premières versions de) simplement conçus reflètent les mêmes différences.

Maintenant, avec tout cela En arrière-plan, voici quelques réponses spécifiques aux questions spécifiques:

Lorsque les URL ont été conçues pour la première fois, pourquoi le respect de la casse a-t-il été intégré?

Pourquoi pas? Si tous les serveurs Web standard étaient insensibles à la casse, cela indiquerait que les serveurs Web suivaient un ensemble de règles spécifiées par la norme. Il ny avait tout simplement pas règle qui dit que ce cas doit être ignoré. La raison pour laquelle il ny a pas de règle est simplement quil ny avait aucune raison il doit y avoir une telle règle. Pourquoi se donner la peine dinventer des règles inutiles?

Je pose cette question parce quil me semble (i.e., un profane) que linsensibilité à la casse serait préférable pour éviter des erreurs inutiles et simplifier une chaîne de texte déjà compliquée.

Les URL ont été conçues pour les machines à traiter . Bien quune personne puisse taper une URL complète dans une barre dadresse, ce nétait pas une partie importante de la conception prévue. La conception prévue est que les gens suivraient (« cliquez sur ») les liens hypertexte. Si les profanes moyens le font, alors ils ne vous souciez pas de savoir si lURL invisible est simple ou compliquée.

De plus, y a-t-il un réel objectif / avantage à avoir une URL sensible à la casse (comme opposé à la grande majorité des URL qui pointent vers la même page, quelle que soit la casse)?

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 denvoyer un peu dinformations à un serveur Web, et plus dinformations peuvent être incluses sil y en a moins restrictions, donc une restriction de sensibilité à la casse réduirait la quantité dinformations pouvant être incluses.

Cependant, dans de nombreux cas, la sensibilité à la casse na pas un avantage très convaincant, qui est prouvé par le fait quIIS ne sen soucie généralement pas.

En résumé, la raison la plus convaincante est probablement juste 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 dUnix, car Unix est nettement plus ancien que HTTP.)

Commentaires

•  » Lune des principales raisons du comportement différent entre les différents navigateurs Web se résume probablement à une question de simplicité.  » – Je suppose que vous signifie  » serveurs Web « , plutôt que  » navigateurs Web  » ici et dans quelques autres endroits?
• Mise à jour. Examen de tous les cas de  » navigateurs  » et effectué plusieurs remplacements. Merci de lavoir signalé afin que la qualité puisse être améliorée.
• Jai reçu plusieurs excellentes réponses à ma question, allant de lhistorique à j’hésite à aller à contre-courant et à accepter une réponse moins bien notée, mais la réponse de @TOOGAM ‘ a été la plus utile pour moi. Cette réponse est complète et détaillée, mais elle explique le concept dune manière simple et conversationnelle que je peux comprendre. Et je pense que cette réponse est une bonne introduction aux explications plus détaillées.
• La raison pour laquelle Windows a un système de fichiers insensible à la casse est due à cela ‘ s Héritage DOS. MS-DOS a vu le jour sur des ordinateurs comme le Tandy TRS-80, qui utilisait un téléviseur comme écran et ne prenait pas à lorigine en charge les lettres minuscules en raison du manque de résolution. Comme il ne pouvait ‘ t afficher des minuscules, les casse mixte n’était pas ‘ pris en charge. MS-DOS a été autorisé par IBM pour devenir le PC-DOS original. Alors que le PC dorigine pouvait afficher des minuscules, le système de fichiers a été porté tel quel depuis MS-DOS.

Les URL ne sont pas sensibles à la casse, seulement certaines dentre elles.
Par exemple, rien nest sensible à la casse dans lURL https://google.com,

En référence à la RFC 3986 – Uniform Resource Identifier (URI): Generic Syntax

Premièrement, à partir de Wikipédia , une URL ressemble à:

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

(Jai « supprimé le user:password partie car elle nest pas intéressante et rarement utilisée)

• scheme :

Les schémas ne sont pas sensibles à la casse

• host :

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

• path :

Le composant de chemin contient des données …

• query :

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

• fragment :

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

Ainsi, les scheme et host ne sont pas sensibles à la casse.
Le reste de lURL est sensible à la casse.

Pourquoi la path est-elle sensible à la casse?

Cela semble être la question principale.
Il est difficile de répondre « pourquoi » quelque chose a été fait sil nétait pas documenté, mais nous pouvons faire une très bonne estimation.
Jai choisi des citations très spécifiques de la spécification, en mettant laccent sur data .
Regardons à nouveau lURL:

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

• Emplacement – Lemplacement a une forme canonique et est insensible à la casse. Pourquoi? Vous pourriez 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 lapplication peut choisir ce que cela signifie . Cela naurait aucun sens de rendre les données insensibles à la casse. Lapplication devrait avoir plus doptions, et la définition de linsensibilité à la casse dans la spécification limitera ces options.
  Cest également une distinction utile pour HTTPS: les données sont chiffrées , mais lhôte est visible.

Est-ce utile?

Cas- la sensibilité a ses pièges en ce qui concerne la mise en cache et les URL canoniques, mais cest certainement utile. Quelques exemples:

• Base64 , qui est utilisé dans les URI de données .
• Les sites peuvent encoder des données Base64 dans lURL, par exemple: http://tryroslyn.azurewebsites.net/#f:r/A4VwRgNglgxgBDCBDAziuBhOBvGB7AOxQBc4SAnKAgczLgF44AiAUQPwBMBTDuKuYgAsucAKoAlADIBCJgG4AvkA
• Les raccourcisseurs dURL utilisent le respect de la casse: /a5B peut être différent de /a5b
• Comme vous « avez mentionné, Wikipedia peut différencier » SIDA « de » Aids « .

Commentaires

•  » Les URL ne sont pas des cas e-sensitive.  » /  » Le reste de lURL est sensible à la casse.  » – Cela semble être une contradiction?
• En vérité, le schéma définit à quoi sattendre dans le reste de lURL. http: et les schémas associés signifient que lURL fait référence à un nom dhôte DNS. Le DNS était insensible à la casse ASCII bien avant linvention des URL. Voir page 55 de ietf.org/rfc/rfc883.txt
• Bien détaillé! Jallais dun point de vue historique. Cétait à lorigine le chemin du fichier qui devait être sensible à la casse uniquement si vous frappiez le système de fichiers. Sinon, ce nétait pas le cas. Mais aujourdhui, les choses ont changé. Par exemple, les paramètres et CGI nexistaient pas à lorigine. Votre réponse prend une perspective actuelle. Jai dû récompenser vos efforts !! Vous avez vraiment creusé dans celui-ci! Qui savait que cela exploserait comme ça? Bravo !!
• @ w3dk: cest ‘ une bizarrerie de terminologie pas très intéressante, mais vous pourriez prendre  » sensible à la casse  » pour signifier,  » changer la casse dun caractère peut changer lensemble « , ou vous pourriez le considérer comme signifiant,  » changer la casse dun caractère toujours change lensemble « . Kobi semble affirmer ce dernier, il préfère que sensible à la casse signifie  » tout changement de casse est significatif « , ce qui bien sûr nest pas vrai pour les URL. Vous préférez le premier. ‘ est juste une question de comment ils sont sensibles à la casse.
• @ rybo111: Si un utilisateur tape example.com/fOObaR , la spécification exige que le serveur de www.example.com reçoive un chemin  » / fOObaR  » comme indiqué; il est silencieux sur la question de savoir si le serveur doit traiter cela différemment de  » / foOBaR « .

Simple. Le système dexploitation est sensible à la casse. Les serveurs Web ne sen soucient généralement pas, sauf sils doivent toucher le système de fichiers à un moment donné. Cest là que Linux et dautres systèmes dexploitation basés sur Unix appliquent les règles du système de fichiers, auquel cas le respect de la casse est un élément majeur. Cest pourquoi IIS na jamais été sensible à la casse; car Windows na jamais été sensible à la casse.

[Mise à jour]

Il y a eu quelques arguments forts dans les commentaires (supprimés depuis) pour savoir si les URL ont une relation avec le système de fichiers comme je lai indiqué. Ces arguments se sont enflammés. Il est extrêmement myope de croire quil ny a pas de relation. Il y en a absolument! Laissez-moi vous expliquer plus en détail.

Les programmeurs dapplications ne sont généralement pas des programmeurs internes aux systèmes. Je ne suis pas insultant. Ce sont deux disciplines distinctes et les connaissances internes du système ne sont pas nécessaires pour écrire des applications lorsque les applications peuvent simplement faire des appels au système dexploitation. Étant donné que les programmeurs dapplications ne sont pas des programmeurs internes aux systèmes, il nest pas possible de contourner les services du système dexploitation.Je dis cela parce que ce sont deux camps séparés et ils se croisent rarement. Les applications sont généralement écrites pour utiliser les services du système dexploitation. Il existe de rares exceptions bien sûr.

À lépoque où les serveurs Web ont commencé à apparaître, les développeurs dapplications navaient pas tenté de contourner les services du système dexploitation. Il y avait plusieurs raisons à cela. Premièrement, ce nétait pas nécessaire. Deuxièmement, les programmeurs dapplications ne savaient généralement pas comment contourner les services du système dexploitation. Troisièmement, la plupart des systèmes dexploitation étaient soit extrêmement stables et robustes, soit extrêmement simples et légers et ne valaient pas le coût.

Gardez à lesprit que les premiers serveurs Web fonctionnaient sur des ordinateurs coûteux tels que le DEC VAX / Serveurs VMS et Unix du jour (Berkeley et Ultrix ainsi que dautres) sur des ordinateurs main-frame ou mid-frame, puis peu après sur des ordinateurs légers tels que les 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 dautres systèmes dexploitation tels que Novell et Linux ont également commencé à exécuter des serveurs Web. Apache était le serveur Web dominant, bien quil y en ait dautres comme IIS et O « Reilly qui étaient également très populaires. Aucun dentre eux à lépoque ne contournait les services du système dexploitation. Il est probable quaucun des serveurs Web ne le fasse même aujourdhui.

Les premiers serveurs Web étaient assez simples. Ils le sont encore aujourdhui. Toute demande faite pour une ressource via une requête HTTP qui existe sur un disque dur était / est faite par le serveur Web via le système de fichiers du système dexploitation.

Les systèmes de fichiers sont des mécanismes assez simples. Lorsquune demande daccès à un fichier est faite, si ce fichier existe, la demande est transmise au sous-système dautorisation et, si elle est accordée, la demande dorigine est satisfaite. Si la ressource existe. nexiste pas ou nest pas autorisée, une exception est levée par le système. Lorsquune application fait une demande, un déclencheur est défini et lapplication attend. Lorsque la demande reçoit une réponse, le déclencheur est lancé et lapplication traite la réponse à la demande. fonctionne toujours de cette façon aujourdhui. Si lapplication constate que la demande a été satisfaite, elle continue, si elle a échoué, l application exécute une condition d erreur dans son code ou meurt si elle nest pas traitée. Simple.

Dans le cas dun serveur Web, en supposant quune demande dURL pour un chemin / fichier est faite, le serveur Web prend la partie chemin / fichier de la demande dURL (URI) et fait une demande au système de fichiers et il 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 laccès accordé par le sous-système dautorisation, le serveur Web traite cette demande dE / S comme dhabitude. Si le système de fichiers lève une exception, alors le serveur Web renvoie une erreur 404 si le fichier est introuvable ou un 403 interdit si le code anomalie nest pas autorisé.

Étant donné que certains systèmes dexploitation sont sensibles à la casse et que les systèmes de fichiers de ce type nécessite 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 y être programmé. Les serveurs Web traitent simplement les demandes au fur et à mesure quils les reçoivent. Si la partie chemin / fichier de la demande dURL transmise directement au système de fichiers ne correspond pas à ce qui se trouve sur le disque dur, le système de fichiers lève une exception et le serveur Web renvoie une erreur 404 Not Found.

Ce sont vraiment des gens simples. Ce nest pas sorcier. Il existe une relation absolue entre la partie chemin / fichier dune URL et le système de fichiers.

Commentaires

• Je pense que votre argument est défectueux. Bien que Berners-Lee n’ait ‘ aucun choix concernant la sensibilité à la casse des URL ftp. Il a pu concevoir des URL http. Il aurait pu les spécifier comme US-ASCII uniquement et insensible à la casse. Si des serveurs Web venaient de transmettre le chemin de lURL au système de fichiers, ils nétaient pas sécurisés et lintroduction du codage dURL a rompu la compatibilité avec eux. Étant donné que le chemin est en cours de traitement avant de passer au cas de destruction du système dexploitation, cela aurait été facile à mettre en œuvre. Par conséquent, je pense que nous devons considérer cela comme une décision de conception et non comme une bizarrerie dimplémentation.
• @WilliamHay Cela na rien à voir avec Berners-Lee ou la conception du Web. Il sagit des limitations et des exigences du système dexploitation. Je suis ingénieur systèmes internes à la retraite. Jai travaillé sur ces systèmes à lépoque. Je vous explique exactement pourquoi les URL sont sensibles à la casse. Ce nest pas une supposition. Ce nest pas une opinion. Cest un fait. Ma réponse a été intentionnellement simplifiée. Bien sûr, il existe des vérifications de fichiers et dautres processus qui peuvent être effectués avant démettre une déclaration ouverte. Et oui (!) Les serveurs Web sont encore partiellement non sécurisés à ce jour.
• Que les URL soient sensibles à la casse na rien à voir avec la conception du Web? Ah bon? Argument dAutorité suivi dargument par Assertion.Le fait que les serveurs Web transmettent le composant de chemin dune URL plus ou moins directement à un appel ouvert est une conséquence de la conception des URL et non une cause de celui-ci. Les serveurs (ou les clients intelligents dans le cas du FTP) auraient pu masquer la sensibilité à la casse des systèmes de fichiers à lutilisateur. Quils ne ‘ t est une décision de conception.
• @WilliamHay Vous devez ralentir la trémie dherbe et relire ce que jai écrit. Je suis un ingénieur système à la retraite qui écrit des composants de système dexploitation, des piles de protocoles et du code de routeur pour lARPA-Net, etc. Jai travaillé avec Apache, O ‘ Reilly et les internes dIIS. Votre argument FTP ne tient pas la route car au moins les principaux serveurs FTP restent sensibles à la casse pour la même raison. A aucun moment je nai rien dit sur la conception dURL / URI. A aucun moment je nai dit que les serveurs Web passaient des valeurs sans traitement. Jai dit que les services du système dexploitation sont couramment utilisés et que le système de fichiers nécessite une correspondance exacte pour réussir.
• @WilliamHay Veuillez comprendre que vous et moi pensons à contre-courant. Tout ce que je disais dans ma réponse, cest que pour certains systèmes dexploitation, les appels de système de fichiers sont sensibles à la casse par conception. Les applications qui utilisent des appels système, et la plupart le font, sont limitées à lapplication des règles du système dexploitation – dans ce cas, le respect de la casse. Il nest pas impossible de contourner cette règle. En fait, cela peut être quelque peu trivial dans certains cas, mais pas pratique. Javais lhabitude de contourner régulièrement le système de fichiers dans mon travail pour déchiffrer les disques durs qui allaient kablooie pour une raison ou une autre ou pour analyser les fichiers internes de la base de données, etc.

1. Les URL prétendent être un localisateur de ressources UNIFORME et peuvent pointer vers des ressources antérieures au Web. Certains dentre eux 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. Linsensibilité à la casse nécessite plus de travail lors de la recherche une correspondance (dans le système dexploitation ou au-dessus).

3. Si vous définissez des URL comme sensibles à la casse, les serveurs individuels peuvent les implémenter en ne respectant pas la casse sils le souhaitent. Linverse nest pas vrai.

4. Linsensibilité à la casse peut être non triviale dans les contextes internationaux: https://en.wikipedia.org/wiki/Dotted_and_dotless_I . La RFC1738 autorisait également lutilisation de caractères en dehors de la plage ASCII à condition quils soient encodés mais ne spécifient pas de jeu de caractères. Ceci est assez important pour quelque chose qui sappelle le WORLD wide web. Définir des URL comme insensibles à la casse ouvrirait beaucoup de possibilités pour bogues.

5. Si vous essayez de regrouper beaucoup de données dans un URI (par exemple, un URI de données ), vous pouvez en emballer davantage si les majuscules et les minuscules sont distinctes.

Commentaires

• I ‘ Je suis presque certain que les URL étaient historiquement limitées à lASCII. Il est donc peu probable que linternationalisation soit une raison originale. Lhistoire dUnix étant sensible à la casse, OTOH, a probablement joué un rôle énorme.
• Alors que seul un sous-ensemble dASCII peut être utilisé non codé dans une URL, RFC1738 indique spécifiquement que les caractères en dehors de la plage ASCII peuvent être utilisés codés. Sans spécifier de jeu de caractères, il est ‘ quil est possible de savoir quels octets représentent le même caractère acteur sauf cas. Mis à jour.
• Re # 4: Cela ‘ est en fait pire que cela. Pointillé et sans point I sont une démonstration du principe plus général selon lequel, même si tout est UTF-8 (ou un autre UTF), vous ne pouvez pas mettre correctement en majuscules ou en minuscules sans connaître les paramètres régionaux auxquels le texte appartient . Dans les paramètres régionaux par défaut, une lettre majuscule latine I minuscule en une lettre latine minuscule i, ce qui est faux en turc car elle ajoute un point (il ny a pas de  » majuscule turque sans point I  » code point; vous ‘ êtes censé utiliser le point de code ASCII). Ajoutez des différences de codage, et cela va de  » vraiment difficile  » à  » complètement insoluble .  »

Jai volé sur le blog un Old New Thing lhabitude daborder les 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? »

Disons que jai configuré un serveur Web pour me servir mes fichiers de documents à partir dun dossier afin que je puisse les lire sur le téléphone quand jétais au bureau. Maintenant, dans mon dossier de documents, jai trois fichiers, todo.txt, ToDo.txt et TODO.TXT (Je sais, mais cela me semblait logique lorsque jai créé 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.

Disons que jai un script qui me permet dajouter un contact à mon carnet dadresses, ce que je peux faire également sur le Web.Comment cela devrait-il prendre ses paramètres? Eh bien, jaimerais lutiliser comme: http://www.example.com/addcontact.php?name=Tom McHenry von der O"Reilly. Mais sil ny avait aucun moyen pour moi de spécifier le nom par cas, comment le ferais-je?

Comment différencierais-je les pages du wiki pour Cat et CAT, Text and TEXT, latex et LaTeX? Disambig pages, je suppose, mais je préfère simplement obtenir ce que jai demandé.

Mais tout cela se sent comme si elle répondait à la mauvaise question, de toute façon.

La question que je pense que vous vous posiez vraiment est « Pourquoi les serveurs Web 404 vous sont-ils simplement pour une différence de cas, quand ce sont des ordinateurs, conçus pour vous simplifier la vie , et ils sont parfaitement capables de trouver au moins les variations de cas les plus évidentes dans lURL que jai tapée qui fonctionneraient? « 

La réponse est que si certains sites ont fait cela (et mieux, ils vérifier les autres fautes de frappe également), personne na jugé utile de modifier la page derreur 404 par défaut dun serveur Web pour le faire … mais peut-être quils devraient le faire?

Commentaires

• Certains sites utilisent une sorte de mécanisme pour convertir un ny requête à tous les minuscules ou quelque chose de cohérent. Dune certaine manière, cest intelligent.
• Non, ils ne devraient pas ‘ t. Cette fonctionnalité peut être, et est souvent, ajoutée lorsque cela est souhaitable (par exemple, par des modules dans apache.) Imposer ce type de changement comme comportement par défaut – ou pire, un comportement immuable – serait plus perturbateur que le comportement relativement rare. occasion où quelquun doit saisir manuellement une URL au-delà du nom dhôte. Pour un bon exemple de pourquoi ne pas faire cela, rappelez-vous le fiasco lorsque Network Solutions  » a corrigé  » des erreurs de domaine inexistantes du DNS public requêtes.
• @SirNickity Personne ne proposait limmuabilité à aucun niveau et les pages derreur du serveur Web sont configurables sur chaque serveur Web que jai ‘ utilisé; personne ne suggérait de remplacer 404 par 30 * codes, mais plutôt dajouter une liste de liens de suggestion cliquables par lhomme à la page derreur; les noms de domaine sont un sujet très différent et un problème insensible à la casse et dans un contexte de sécurité différent; et IIS déjà automatiquement  » corrige  » (en ignorant) les différences de casse dans les parties de chemin ou de nom de fichier des URI.
• Depuis 1996, Apache vous permet de faire cela avec mod_speling . Cela ne semble ‘ pas être une chose très populaire à faire. Les gens dUnix / Linux voient linsensibilité à la casse comme la règle, linsensibilité à la casse comme lexception.

Bien que le La réponse ci-dessus est correcte & bonne. Je voudrais ajouter quelques points supplémentaires.

Pour mieux comprendre, il faut comprendre la différence fondamentale entre le serveur Unix (Linux) et Windows. Unix est sensible à la casse & Windows nest pas un système dexploitation 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 à Les instituts du CERN, la plupart de ces jours, les scientifiques utilisaient des machines Unix et non Windows.

La plupart des scientifiques connaissaient Unix, ils auraient 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 étaient complètes.

Cela pourrait être la raison.

Commentaires

•  » Le serveur Windows est sorti après 2000.  » Léquipe Windows NT 3.1 aurait été en désaccord avec vous en 1993. NT 3.51 en 1995 était probablement le moment où NT a commencé à devenir suffisamment mature et bien établie pour prendre en charge les applications serveur critiques pour l’entreprise.
• NT 3.51 avait l’interface Win 3.1. Windows na pas vraiment décollé avant Windows 95 et il a fallu NT 4.0 pour obtenir la même interface.
• Michael Kj ö rling, daccord. Permettez-moi de le modifier.
• @Thorbj ø rnRavnAndersen Sur le marché des serveurs, NT 3.51 a assez bien réussi. Sur le marché grand public / prosommateur, il a fallu attendre Windows 2000 (NT 5.0) avant que la ligne NT ne commence à gagner du terrain.
• En effet, WorldWideWeb a été initialement développé sur des systèmes Unix, qui sont sensibles à la casse systèmes de fichiers, et la plupart des URL mappées directement aux fichiers du système de fichiers.

Comment lire un « pourquoi a-t-il été conçu de cette façon? » question? Demandez-vous un compte rendu historiquement précis du processus de prise de décision, ou demandez-vous « pourquoi quelquun le concevrait-il de cette façon? »?

Il est très rarement possible dobtenir un historique précis Compte.Parfois, lorsque les décisions sont prises dans les comités de normalisation, il existe une piste documentaire sur la façon dont le débat a été mené, mais au début du Web, les décisions ont été prises à la hâte par quelques personnes – dans ce cas probablement par TimBL lui-même – et la 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

Dans les premiers temps, les URL étaient mappées très directement aux noms de fichiers, et les fichiers étaient généralement sur des machines de type Unix, et les machines de type Unix avaient des noms de fichiers sensibles à la casse. Je suppose donc que cest arrivé de cette façon pour la commodité de la mise en œuvre, et la convivialité (pour les utilisateurs finaux) na même jamais été prise en compte. Encore une fois, au début, les utilisateurs étaient tous des programmeurs Unix de toute façon.

Commentaires

• Les utilisateurs finaux étaient également des utilisateurs Unix (pas nécessairement des programmeurs, mais physiciens des hautes énergies et autres), donc eux aussi étaient habitués à l’insensibilité à la casse.

Ceci na rien à voir avec lendroit où vous avez acheté votre domaine, le DNS nest pas sensible à la casse. Mais, le système de fichiers sur le serveur que vous utilisez pour lhébergement est.

Ce nest pas vraiment un problème et cest assez courant sur les hôtes * nix. Assurez-vous simplement que tous les liens que vous écrivez sur vos pages sont corrects et que vous naurez pas de problème. Pour vous faciliter la tâche, je vous recommande de toujours nommer vos pages en minuscules, vous naurez jamais besoin de vérifier le nom lors de la rédaction dun lien.

Closetnoc a raison à propos du système dexploitation. Certains systèmes de fichiers traitent le même nom avec une casse différente comme des fichiers différents.

De plus, y a-t-il un réel objectif / avantage à avoir une URL sensible à la casse (par opposition à la grande majorité des URL qui pointent vers la même page, peu importe la majuscule)?

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 exactement vers la même page avec exactement le même contenu, alors vous auriez du contenu en double, et je suis sûr que vous avez une console de recherche Google (outils pour les webmasters), Google vous lindiquera.

Ce que je veux Si vous êtes dans cette situation, je suggère dutiliser toutes les URL minuscules, puis de rediriger les URL contenant au moins une majuscule vers la version minuscule. Donc, dans la liste des URL ci-dessus, redirigez toutes les URL vers la première URL.

Commentaires

•  » Oui. pour éviter les problèmes de contenu en double.  » – Mais le contraire semble être vrai? Le fait que les URL peuvent être sensibles à la casse (et cest ainsi que les moteurs de recherche les traitent) cause les problèmes de contenu dupliqué que vous mentionnez. Si les URL étaient universellement insensibles à la casse, il ny aurait aucun problème de contenu en double avec une casse différente. page-1 serait le même que PAGE-1.
• Je pense quune mauvaise configuration de serveur est ce qui peut provoquer un contenu dupliqué en matière de boîtier. Par exemple, linstruction RewriteRule ^request-uri$ /targetscript.php [NC] stockée dans .htaccess correspondrait à http://example.com/request-uri et http://example.com/ReQuEsT-Uri car le [NC] indique que la casse na ‘ pas dimportance lors de lévaluation de cette expression régulière.

La sensibilité à la casse a une valeur.

Sil y a 26 lettres, chacune delles pouvant être mise en majuscule, cest 52 caractères.

4 caractères a la possibilité de 52 * 52 * 52 * 52 combinaisons, équivalant à 7311616 combinaisons.

Si vous ne pouvez pas mettre les caractères en majuscule, le nombre de combinaisons est de 26 * 26 * 26 * 26 = 456976

Il y a plus de 14 fois plus de combinaisons pour 52 caractères que il y en a pour 26. Donc, pour stocker des données, les URL peuvent être plus courtes et plus dinformations peuvent être transmises sur les réseaux avec moins de données transférées.

Cest pourquoi vous voyez YouTube en utilisant des URL comme https://www.youtube.com/watch?v=xXxxXxxX