L'URL doit-il être sensible à la casse ?

Question

J'ai remarqué que

HTTP://STACKOVERFLOW.COM/QUESTIONS/ASK

et

http://stackoverflow.com/questions/ask

les deux fonctionnent bien - en fait, le précédent est converti en minuscules.

Je pense que cela est logique pour l'utilisateur.

Si je regarde sur Google, cette URL fonctionne bien :

http://www.google.com/intl/en/about/corporate/index.html  

mais celui-là, avec "ABOUT", ne fonctionne pas :

http://www.google.com/intl/en/ABOUT/corporate/index.html   

L'URL doit-elle être sensible à la casse ?

Answer 1

Selon le rapport du W3 " HTML et URLs ", ils devraient :

Il peut y avoir des URL, ou des parties d'URL, où la casse n'a pas d'importance. mais il n'est pas toujours facile de les identifier. Les utilisateurs doivent toujours considérer que Les URLs sont sensibles à la casse.

Answer 2

Tous " insensible Les "s" sont mis en gras pour plus de lisibilité.

Les noms de domaine sont des cas insensible en fonction de RFC 4343 . Le reste de l'URL est envoyé au serveur via la méthode GET. Cette méthode peut être sensible à la casse ou non.

Prenez cette page par exemple, stackoverflow.com reçoit la chaîne GET /questions/7996919/doivent-ils être sensibles à la casse ? en envoyant un document HTML à votre navigateur. Stackoverflow.com est un cas insensible car il produit le même résultat pour /QUEStions/7996919/Should-url-be-case-sensitive (en anglais) .

En revanche, Wikipédia respecte la casse, sauf pour le premier caractère du titre. Les URLs https://en.wikipedia.org/wiki/Case_sensitivity et https://en.wikipedia.org/wiki/case_sensitivity mène au même article, mais https://en.wikipedia.org/wiki/CASE_SENSITIVITY retourne 404.

Answer 3

Cela dépend de l'OS d'hébergement. Les sites hébergés sous Windows ont tendance à ne pas tenir compte de la casse, car le système de fichiers sous-jacent ne la prend pas en compte. Les sites hébergés sur des systèmes de type Unix ont tendance à être sensibles à la casse car leurs systèmes de fichiers sous-jacents sont généralement sensibles à la casse. La partie du nom d'hôte de l'URL est toujours insensible à la casse, c'est le reste du chemin qui varie.

Answer 4

La partie du nom de domaine d'une URL n'est pas sensible à la casse puisque le DNS ignore la casse : http://en.example.org/ et HTTP://EN.EXAMPLE.ORG/ Les deux ouvrent la même page.

Le chemin est utilisé pour spécifier et éventuellement trouver la ressource demandée. Il est sensible à la casse, bien qu'il puisse être traité comme tel par certains serveurs, notamment ceux basés sur Microsoft Windows.

Si le serveur est sensible à la casse et que http://en.example.org/wiki/URL est correcte, alors http://en.example.org/WIKI/URL ou http://en.example.org/wiki/url affichera une page d'erreur HTTP 404, à moins que ces URL ne pointent elles-mêmes vers des ressources valides.

Answer 5

Je ne suis pas un fan des vieux articles, mais comme il s'agit de l'une des premières réponses à ce problème particulier, j'ai ressenti le besoin de clarifier quelque chose.

Comme l'indique la réponse de @Bhavin Shah, la partie domaine de l'url n'est pas sensible à la casse, donc

http://google.com 

et

http://GOOGLE.COM 

et

http://GoOgLe.CoM 

sont tous les mêmes, mais tout ce qui suit la partie du nom de domaine est considéré comme sensible à la casse.

donc...

http://GOOGLE.COM/ABOUT

et

http://GOOGLE.COM/about

sont différentes.

Remarque : je parle "techniquement" et non "littéralement" dans de nombreux cas, la plupart des serveurs sont configurés pour traiter ces éléments de la même manière, mais il est possible de les configurer pour qu'ils ne soient PAS traités de la même manière.

Les différents serveurs gèrent cela différemment et dans certains cas, ils doivent respecter la casse. Dans de nombreux cas, les valeurs des chaînes de requête sont codées (comme les identifiants de session ou les données codées en Base64 qui sont transmises comme valeur de chaîne de requête). Ces éléments sont sensibles à la casse de par leur nature et le serveur doit donc les traiter en respectant la casse.

Donc, pour répondre à la question "les serveurs doivent-ils" être sensibles à la casse lorsqu'ils saisissent ces données, la réponse est "oui, très certainement".

Bien sûr, tout ne doit pas être sensible à la casse, mais le serveur doit savoir ce qu'il en est et comment gérer ces cas.

---

Le commentaire de @Hart Simha dit en gros la même chose. Je l'ai manqué avant de poster, donc je veux donner le crédit où le crédit est dû.