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

j’ai remarqué que

HTTP://STACKOVERFLOW.COM/QUESTIONS/ASK 

et

 http://stackoverflow.com/questions/ask 

les deux fonctionnent correctement – en fait, le précédent est converti en minuscules.

Je pense que cela a du sens pour l’utilisateur.

Si je regarde Google, cette URL fonctionne correctement:

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

mais celui-ci avec “ABOUT” ne fonctionne pas:

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

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

Selon le ” HTML et les URL ” de W3, ils devraient:

Il peut y avoir des URL, ou des parties d’URL, où la casse n’a pas d’importance, mais l’identification de celles-ci peut ne pas être facile. Les utilisateurs doivent toujours considérer que les URL sont sensibles à la casse.

Tous les « insensibles » sont en gras pour la lisibilité.

Les noms de domaine sont insensibles à la casse conformément à la RFC 4343 . Le rest de l’URL est envoyé au serveur via la méthode GET. Cela peut être sensible à la casse ou non.

Prenez par exemple cette page, stackoverflow.com reçoit les chaînes GET / questions / 7996919 / should-url-be-sensitive , en envoyant un document HTML à votre navigateur. Stackoverflow.com n’est pas sensible à la casse car il produit le même résultat pour / QUEStions / 7996919 / Should-url-be-case-sensitive .

En revanche, Wikipedia est sensible à la casse, sauf le premier caractère du titre. Les URL https://en.wikipedia.org/wiki/Case_sensitivity et https://en.wikipedia.org/wiki/case_sensitivity mènent au même article, mais https://en.wikipedia.org/wiki/CASE_SENSITIVITY renvoie 404.

Dépend de l’OS d’hébergement. Les sites hébergés sous Windows ont tendance à être insensibles à la casse car le système de fichiers sous-jacent est insensible à la casse. 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 nom d’hôte de l’URL est toujours insensible à la casse, c’est le rest du chemin qui varie.

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

Le chemin est utilisé pour spécifier et peut-être trouver la ressource demandée. Il est sensible à la casse, bien qu’il puisse être traité comme insensible à la casse par certains serveurs, en particulier ceux basés sur Microsoft Windows.

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

Je ne suis pas un fan des anciens articles, mais parce que c’était l’une des premières réponses à ce problème particulier, j’ai ressenti le besoin de clarifier quelque chose.

Comme la réponse de @Bhavin Shah indique que la partie domaine de l’URL est insensible à la casse,

 http://google.com 

et

 http://GOOGLE.COM 

et

 http://GoOgLe.CoM 

sont tous identiques mais tout ce qui suit la partie nom de domaine est considéré comme sensible à la casse.

alors…

 http://GOOGLE.COM/ABOUT 

et

 http://GOOGLE.COM/about 

sont différents.

Note: Je parle “techniquement” et non “littéralement” dans la plupart des cas. En réalité, les serveurs sont configurés pour gérer 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.

Différents serveurs gèrent cela différemment et dans certains cas, ils doivent être sensibles à la casse. Dans de nombreux cas, les valeurs de chaîne de requête sont codées (telles que les identifiants de session ou les données codées en Base64 transmises en tant que valeur de chaîne de requête). Ces éléments sont donc sensibles à la casse pour que le serveur les traite.

Donc, pour répondre à la question, “les serveurs” devraient-ils être sensibles à la casse en saisissant ces données, la réponse est “oui, certainement”.

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


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

Regardez la spécification ici: section 2.7.3 http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-25#page-19

Le schéma et l’hôte sont insensibles à la casse et normalement fournis en minuscules; tous les autres composants sont comparés d’une manière sensible à la casse.

Les URL doivent être insensibles à la casse, sauf s’il existe une bonne raison pour laquelle elles ne le devraient pas.

Ceci n’est pas obligatoire (il ne fait pas partie d’une RFC) mais rend la communication et le stockage des URL beaucoup plus fiables.

Si j’ai deux pages sur un site Web:

 http://stackoverflow.com/ABOUT.html 

et

 http://stackoverflow.com/about.html 

Comment devraient-ils différer? On peut peut-être écrire «style de cris» (en majuscules) – mais du sharepoint vue de l’IA, la distinction ne devrait jamais être faite par un changement du cas de l’URL.

De plus, il est facile de l’implémenter dans Apache – utilisez simplement CheckSpelling On depuis mod_Speling.

Ancienne question, mais je suis tombé ici, alors pourquoi ne pas tenter le coup car la question cherche des outlook différentes et non une réponse définitive.

w3c a peut-être ses recommandations – ce qui me tient à cœur – mais souhaite repenser depuis la question.

Pourquoi w3c considère-t-il que les noms de domaine sont insensibles à la casse et ne laisse alors aucune insensible à la casse?

Je pense que la raison en est que la partie domaine de l’URL est saisie à la main par un utilisateur. Tout ce qui après avoir été hyper textuel sera résolu par la machine (navigateur et serveur à l’arrière).

Les machines peuvent gérer l’insensibilité à la casse mieux que les humains (pas le genre technique :)).

Mais la question est juste parce que les machines peuvent gérer cela si cela devait être fait de cette façon?

Je veux dire, quels sont les avantages de nommer et d’accéder à une ressource hereIsTheResource hereistheresource ? hereIsTheResource vs hereistheresource ?

Le latéral est très illisible que le cas du chameau, qui est plus lisible. Lisible pour les humains (y compris le type technique)

Alors voici mes points: –

Le chemin de ressource se situe quelque part au milieu de la structure de programmation et est parfois proche d’un utilisateur final derrière le navigateur.

Votre URL (à l’exclusion du nom de domaine) doit être insensible à la casse si vos utilisateurs sont censés la toucher ou la taper, etc. Vous devez développer votre application pour ÉVITER que les utilisateurs saisissent le chemin autant que possible.

Votre URL (à l’exclusion du nom de domaine) doit être sensible à la casse si vos utilisateurs ne la taperont jamais à la main.

Conclusion

Le chemin doit être sensible à la casse. Mes points pèsent sur les chemins sensibles à la casse.

Les caractères URL sont convertis en code hexadécimal (si vous avez déjà remarqué que des espaces dans les URL sont affichés sous la forme% 20, etc.) et que les majuscules et les minuscules ont des valeurs hexadécimales différentes. Cependant, l’esprit de la question semble être que ce soit la norme et je dis non, mais ils le sont. Il appartient au développeur / fournisseur de rendre compte de cela dans leur code s’ils veulent qu’il fonctionne indépendamment de l’utilisateur final.

Je pense que cela et beaucoup de réponses autour de ce que la spécification dit ou ne dit pas manque le sharepoint la question. Devraient- ils être sensibles à la casse? C’est vraiment une question chargée. Du sharepoint vue de l’utilisateur, la sensibilité à la casse est un point sensible, tous ne savent pas faire la différence. La question de savoir si les adresses URI doivent ou non être, dépend du contexte de la question. Pour la flexibilité technique, oui, ils devraient l’être. Pour la facilité d’utilisation, non, ils ne devraient pas l’être.

Pour les sites Web hébergés sur un serveur Linux, l’URL est sensible à la casse. http://www.google.com/about et http://www.google.com/About seront redirigés vers différents sites. Dans un serveur Windows, l’URL ne fait pas la distinction entre les majuscules et les minuscules, comme pour nommer un dossier et sera redirigé vers le même emplacement.

la question est la suivante: l’URL doit-elle être sensible à la casse?

Je ne vois aucune utilisation ou bonne pratique derrière les URL sensibles à la casse. C’est stupide, ça craint et devrait être évité à tout moment.

Juste pour sauvegarder mon opinion, quand quelqu’un demande quelle URL, comment pourriez-vous expliquer quels caractères de l’URL sont en majuscules ou en minuscules? C’est absurde et personne ne devrait jamais vous dire le contraire.

Il est possible de créer des URL sensibles non-cas

 RewriteEngine on rewritemap lowercase int:tolower RewriteCond $1 [AZ] RewriteRule ^/(.*)$ /${lowercase:$1} [R=301,L] 

Rendre Google.com..GOOGLE.com etc directement à google.com