Pourquoi les URL sont-elles sensibles à la casse?

54

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.

Kyle
la source
11
Vous n'exécutez évidemment pas IIS sous Windows
John Conde
53
J'imagine que itscrap.com, expertsexchange et whorepresents.com préféreraient que davantage de personnes utilisent des noms sensibles à la casse. Pour plus d'informations, consultez boredpanda.com/worst-domain-names .
Eric Towers
22
Les URL ont été conçues lorsque des dinosaures rendus sur des systèmes Unix parcouraient la Terre et qu'Unix était sensible à la casse.
Thorbjørn Ravn Andersen
11
Wikipedia essaie d'utiliser la capitalisation correcte pour le titre du sujet et utilise des redirections pour les différences communes. par exemple. html, htmet Htmltous redirigent vers HTML. Mais surtout, en raison de l’énorme contenu, il est possible d’avoir plusieurs pages dont l’URL diffère d’une cas à l’autre. Par exemple: Latex et LaTeX
MrWhite,
7
@ edc65 Mais Kobi déclare que certaines parties de l'URL (notamment le chemin ) sont sensibles à la casse. Cela ne rend-il donc pas l'URL (dans son ensemble) sensible à la casse?
MrWhite

Réponses:

8

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

TOOGAM
la source
"L'une des principales raisons de la différence de comportement entre les différents navigateurs Web se résume probablement à une question de simplicité." - Je suppose que vous voulez dire "serveurs Web", plutôt que "navigateurs Web" ici et dans quelques autres endroits?
MrWhite
2
Mis à jour. Nous avons examiné tous les cas de "navigateurs" et effectué plusieurs remplacements. Merci de nous l'avoir signalé afin d'améliorer la qualité.
TOOGAM
1
J'ai reçu plusieurs excellentes réponses à ma question, allant de l'historique à la technique. Je suis hésitant à aller à contre-courant et à accepter une réponse moins bien notée, mais la réponse de @ TOOGAM m'a été la plus utile. Cette réponse est complète et complète, mais elle explique le concept d'une 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.
Kyle
74

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)

les régimes sont insensibles à la casse

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

Le composant path contient des données ...

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

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:

Kobi
la source
1
"Les URL ne sont pas sensibles à la casse." / "Le reste de l'URL est sensible à la casse." - Cela semblerait être une contradiction?
MrWhite
8
En vérité, le schéma définit ce à quoi s'attendre dans le reste de l'URL. http:et les schémas associés signifient que l'URL fait référence à un nom d'hôte DNS. Le DNS était insensible à la casse bien avant l’invention des URL. Voir page 55 de ietf.org/rfc/rfc883.txt
O. Jones
3
Joliment détaillé! Je partais d'un point de vue historique. C'était à l'origine le chemin du fichier qui devait être sensible à la casse uniquement si vous frappiez le système de fichiers. Sinon, ce n'était pas. Mais aujourd'hui, les choses ont changé. Par exemple, les paramètres et CGI n'existaient pas à l'origine. Votre réponse prend la perspective du jour en cours. Je devais récompenser vos efforts !! Vous avez vraiment creusé dans celui-ci! Qui savait que cela exploserait de cette façon ?? À votre santé!!
closetnoc
2
@ w3dk: c'est une bizarrerie de terminologie pas très intéressante, mais vous pouvez prendre le terme "sensible à la casse" comme signifiant, "changer la casse d'un personnage peut changer le tout", ou vous dire "changer la casse" le cas d'un personnage change toujours le tout ". Kobi semble affirmer ce dernier point, il préfère que la distinction entre les majuscules et les minuscules veuille dire "tout changement de cas est important", ce qui n'est bien sûr pas le cas des URL. Vous préférez l'ancien. C'est juste une question de leur sensibilité à l'affaire.
Steve Jessop
2
@ rybo111: Si un utilisateur tape exemple.com/fOObaR , la spécification nécessite que le serveur de www.example.com reçoive le chemin "/ fOObaR" tel qu'il est indiqué. il ne dit rien sur la question de savoir si le serveur doit traiter cela différemment de "/ foOBaR".
Supercat
59

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.

placard
la source
1
Je pense que votre argument est imparfait. Tandis que Berners-Lee n’avait aucun choix quant à la sensibilité à la casse des URL ftp. Il a dû concevoir des URL http. Il aurait pu les spécifier uniquement en US-ASCII et sans distinction de casse. Si des serveurs Web venaient de passer le chemin de l'URL au système de fichiers, ils n'étaient pas sécurisés et l'introduction du codage d'URL ne leur permettait pas d'être compatible. Etant donné que le chemin est en cours de traitement avant de passer au système d'exploitation, le cas d'un crash 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 un problème d'implémentation.
William Hay
@ WilliamHay Cela n'a rien à voir avec Berners-Lee ou la conception du Web. Il s'agit de limitations et d'exigences du système d'exploitation. Je suis un ingénieur en systèmes internes à la retraite. J'ai travaillé sur ces systèmes à l'époque. Je vous dis exactement pourquoi les URL sont sensibles à la casse. Ce n'est pas une supposition. Ce n'est pas un avis. C'est un fait. Ma réponse a été intentionnellement simplifiée. Bien sûr, il y a des vérifications de fichiers et d'autres processus qui peuvent être effectués avant d'émettre une instruction ouverte. Et oui (!) Les serveurs Web sont encore partiellement non sécurisés à ce jour.
closetnoc
Que les URL soient sensibles à la casse n'a rien à voir avec la conception du Web? Vraiment? Argument de l'autorité suivi de l'argument de l'assertion. Le fait que les serveurs Web transmettent plus ou moins directement le composant de chemin d’une URL à un appel ouvert est une conséquence de la conception des URL et non une cause de celle-ci. Les serveurs (ou les clients intelligents dans le cas de FTP) auraient pu masquer la sensibilité à la casse des systèmes de fichiers de l'utilisateur. Qu'ils ne le fassent pas est une décision de conception.
William Hay
@ WilliamHay Vous devez ralentir la trémie et relire ce que j'ai écrit. Je suis un ingénieur en systèmes internes à la retraite qui écrit des composants de système d'exploitation, des piles de protocoles et du code de routeur pour ARPA-Net, etc. J'ai travaillé avec les internes d'Apache, O'Reilly et IIS. Votre argument FTP ne tient pas debout car au moins les principaux serveurs FTP restent sensibles à la casse pour la même raison. À aucun moment je n'ai rien dit à propos de la conception d'URL / URI. Je n'ai jamais dit que les serveurs Web transmettaient des valeurs sans traitement. J'ai dit que les services du système d'exploitation sont couramment utilisés et que le système de fichiers nécessite une correspondance exacte pour réussir.
closetnoc
@ WilliamHay S'il vous plaît, comprenez que vous et moi pensons à contre-sens. Tout ce que je disais dans ma réponse, c'est que pour certains systèmes d'exploitation, les appels de système de fichiers sont sensibles à la casse par nature. Les applications qui utilisent des appels système, et la plupart le font, sont limitées à l'application des règles du système d'exploitation - dans ce cas, la sensibilité à la casse. Il n'est pas impossible de contourner cette règle. En fait, cela peut être quelque peu trivial dans certains cas mais pas pratique. J'avais l'habitude de contourner systématiquement le système de fichiers dans mon travail pour déchiffrer les disques durs qui avaient été kablooie pour une raison ou une autre ou pour analyser les éléments internes d'un fichier de base de données, etc.
closetnoc
21
  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.

William Hay
la source
1
Je suis à peu près sûr que les URL étaient historiquement limitées à ASCII. Il est donc peu probable que l'internationalisation soit une raison originale. L’histoire d’Unix étant sensible à la casse, OTOH a probablement joué un rôle important.
derobert
Bien que seul un sous-ensemble d'ASCII puisse être utilisé non codé dans une URL, le RFC1738 précise que les caractères situés en dehors de la plage ASCII peuvent être codés. Sans spécifier un jeu de caractères, il n'est pas possible de savoir quels octets représentent le même caractère, sauf cas. Mis à jour.
William Hay
1
Re # 4: C'est en fait pire que ça. En pointillé et sans point I illustrent le principe plus général selon lequel, même si tout est en UTF-8 (ou en un autre), vous ne pouvez pas mettre les majuscules ou les minuscules correctement sans connaître les paramètres régionaux auxquels le texte appartient. Dans la langue par défaut, une lettre latine majuscule I se met en minuscule en une lettre minuscule latine i, ce qui est faux en turc car elle ajoute un point (il n'y a pas de point de code "majuscule turque I"; vous êtes censé utiliser le code ASCII. point). Ajoutez des différences d'encodage, et cela passe de "très difficile" à "complètement insoluble".
Kevin
5

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?

Dewi Morgan
la source
1
Certains sites utilisent une sorte de mécanisme pour convertir toute requête en minuscule ou en quelque chose de cohérent. D'une certaine manière, c'est intelligent.
closetnoc
Non, ils ne devraient pas. Cette fonctionnalité peut être, et est souvent, ajoutée quand il 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 perturbant que le relativement rare occasion où une personne doit saisir manuellement une adresse URL au-delà du nom d'hôte. Pour un bon exemple de cette opération, rappelez le fiasco lorsque Network Solutions "corrigeait" les erreurs de domaine inexistantes à partir de requêtes DNS publiques.
SirNickity
@SirNickity Personne ne proposait l'immuabilité à quelque niveau que ce soit et les pages d'erreur du serveur Web sont configurables sur tous les serveurs Web que j'ai utilisés. personne ne suggérait de remplacer 404 par 30 * codes, mais plutôt d'ajouter une liste de liens de suggestion cliquables par l'homme à la page d'erreur; les noms de domaine sont un sujet et un problème très différents, étant insensibles à la casse et dans un contexte de sécurité différent; et IIS "corrige" déjà automatiquement (en ignorant) les différences de casse dans les parties de chemin ou de nom de fichier des adresses URI.
Dewi Morgan
Depuis 1996, Apache vous permet de le faire avec mod_speling . Cela ne semble tout simplement pas être une chose très populaire à faire. Les personnes sous Unix / Linux considèrent l'insensibilité à la casse comme la règle et l'insensibilité à la casse comme l'exception.
Reinierpost
4

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.

Mani
la source
2
"Le serveur Windows est sorti après 2000." L'équipe Windows NT 3.1 serait peut-être 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 établi pour prendre en charge des applications serveur critiques.
un CVn
NT 3.51 avait l'interface Win 3.1. Windows n'a pas vraiment décollé avant Windows 95 et il a fallu NT 4.0 pour obtenir la même interface.
Thorbjørn Ravn Andersen
Michael Kjörling, d'accord. Laissez-moi le modifier.
Mani
1
@ ThorbjørnRavnAndersen Sur le marché des serveurs, NT 3.51 a été relativement performant. Sur le marché des consommateurs / prosommateurs, il a fallu attendre Windows 2000 (NT 5.0) pour que la gamme NT commence à gagner du terrain.
un CVn
En effet, le WorldWideWeb a été initialement développé sur des systèmes Unix, qui ont des systèmes de fichiers sensibles à la casse, et la plupart des URL sont directement mappées sur des fichiers du système de fichiers.
Reinierpost
4

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.

Michael Kay
la source
Les utilisateurs finaux étaient également des utilisateurs d’Unix (pas nécessairement des programmeurs, mais des physiciens des hautes énergies, etc.), de sorte qu’ils étaient également habitués à l’insensibilité à la casse.
Reinierpost
3

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.

adnan3344
la source
2

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.

Mike
la source
"Oui. Pour éviter les problèmes de contenu en double." - Mais l'inverse semblerait être vrai? Le fait que les URL puissent être sensibles à la casse (et c'est ainsi que les moteurs de recherche les traitent) entraîne les problèmes de contenu en double que vous avez mentionnés. Si les URL étaient insensibles à la casse de manière universelle, il n'y aurait aucun problème de contenu en double avec une casse différente. page-1serait le même que PAGE-1.
MrWhite
Je pense qu'une mauvaise configuration de serveur peut entraîner la duplication de contenu en matière de boîtier. Par exemple, l'instruction RewriteRule ^request-uri$ /targetscript.php [NC]stockée dans .htaccess correspondrait http://example.com/request-uriet http://example.com/ReQuEsT-Uriparce [NC]que cela indique que la casse n'a pas d'importance lors de l'évaluation de cette expression régulière.
Mike
1

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.

Michael d
la source