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

J'ai remarqué ça

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 a du sens pour l'utilisateur.

Si je regarde Google, cette URL fonctionne bien:

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 " HTML et 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 leur identification peut ne pas être facile. Les utilisateurs doivent toujours considérer que les URL sont sensibles à la casse.

Tous les « insensibles » sont mis en gras pour plus de lisibilité.

Les noms de domaine ne respectent pas la casse selon la RFC 4343 . Le reste de l'URL est envoyé au serveur via la méthode GET. Cela peut être sensible à la casse ou non.

Prenez cette page par exemple, stackoverflow.com reçoit la chaîne GET / questions / 7996919 / devrait être sensible à la casse , 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 .

D'autre part, 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 conduisent au même article, mais https://en.wikipedia.org/wiki/CASE_SENSITIVITY renvoie 404.

Dépend de l'hébergeur. Les sites hébergés sur Windows ont tendance à ne pas respecter 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 du nom d'hôte de l'URL est toujours insensible à la casse, c'est le reste du chemin qui varie.

La partie du nom de domaine d'une URL n'est pas sensible à la casse car DNS ignore la casse: http://en.example.org/et les HTTP://EN.EXAMPLE.ORG/deux 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 http://en.example.org/wiki/URLest correct, alors http://en.example.org/WIKI/URLou http://en.example.org/wiki/urlaffichera une page d'erreur HTTP 404, à moins que ces URL pointent vers des ressources valides elles-mêmes.

Je ne suis pas un fan de l'ancien article, 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 @Bhavin Shah répond que la partie domaine de l'url est insensible à la casse, donc

http://google.com 

et

http://GOOGLE.COM 

et

http://GoOgLe.CoM 

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

alors...

http://GOOGLE.COM/ABOUT

et

http://GOOGLE.COM/about

sont différents.

Remarque: je parle "techniquement" et non "littéralement" dans de nombreux cas, la plupart du temps, les serveurs sont configurés pour gérer ces éléments de la même manière, mais il est possible de les configurer afin 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 encodées en Base64 qui sont transmises en tant que valeur de chaîne de requête).

Donc, pour répondre à la question, "si" les serveurs doivent être sensibles à la casse dans la capture de 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 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 du crédit là où c'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 ne respectent pas la casse et sont normalement fournis en minuscules; tous les autres composants sont comparés de manière sensible à la casse.

Considérer ce qui suit:

https://www.example.com/createuser.php?name=Paul%20McCartney

Dans cet exemple hypothétique, un formulaire HTML - utilisant la méthode GET - envoie le paramètre "name" à un script PHP qui crée un nouveau compte utilisateur.

Et le point que je fais avec cet exemple est que ce paramètre GET doit être sensible à la casse pour préserver la capitalisation de "McCartney" (ou, comme un autre exemple, pour préserver "Walter d'Isney", car il existe d'autres façons pour que les noms enfreignent les règles de capitalisation habituelles).

Ce sont des cas comme ceux-ci qui guident la recommandation du W3C selon laquelle le schéma et l'hôte ne respectent pas la casse, mais tout ce qui suit est potentiellement sensible à la casse - et est laissé au serveur. Forcer l'insensibilité à la casse par la norme rendrait l'exemple ci-dessus incapable de conserver la casse de l'entrée utilisateur passée en tant que paramètre de requête GET.

Mais ce que je dirais, c'est que bien que ce soit nécessairement la lettre de la loi pour tenir compte de tels cas, l'esprit de la loi est que, lorsque l'affaire n'est pas pertinente, elle se comporte d'une manière insensible à la casse. Les normes, cependant, ne peuvent pas vous dire où le cas n'est pas pertinent parce que, comme les exemples que j'ai donnés, c'est une chose dépendante du contexte.

(Par exemple, il est préférable de forcer un nom d'utilisateur de compte à ne pas respecter la casse - car "User123" et "user123" étant des comptes différents, cela peut prêter à confusion - même si leur vrai nom, comme ci-dessus, est préférable de respecter la casse.)

Parfois, c'est pertinent, la plupart du temps ce n'est pas le cas. Mais il faut laisser au serveur / développeur Web le soin de décider de ces choses - et cela ne peut pas être prescrit par la norme - car ce n'est qu'à ce niveau que le contexte peut être connu.

Le schéma et l'hôte ne respectent pas la casse (ce qui montre la préférence de la norme pour l'insensibilité à la casse, où elle peut être universellement prescrite). Le reste est à vous de décider, car vous comprenez mieux le contexte. Mais, comme cela a été discuté, vous devriez probablement, dans l'esprit de la loi, ne pas respecter l'insensibilité à la casse, sauf si vous avez une bonne raison de ne pas le faire.

Les URL doivent être insensibles à la casse, sauf s'il y a une bonne raison pour qu'elles ne le soient pas.

Ce n'est pas obligatoire (il ne fait partie d'aucune RFC) mais cela 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

En quoi devraient-ils différer? Peut-être que l'un est écrit «style de cri» (majuscules) - mais d'un point de vue IA, la distinction ne devrait jamais être faite par un changement dans le cas de l'URL.

De plus, il est facile de l'implémenter dans Apache - utilisez simplement CheckSpelling Onmod_Speling.

Vieille question, mais j'ai trébuché ici, alors pourquoi ne pas y jeter un coup d'œil, car la question cherche une perspective différente et non une réponse définitive.

Le w3c a peut-être ses recommandations - ce qui m'importe beaucoup - mais je veux y repenser puisque la question est ici.

Pourquoi le w3c considère-t-il que les noms de domaine sont insensibles à la casse et laisse quoi que ce soit après la casse?

Je pense que la raison est que la partie domaine de l'URL est tapée à la main par un utilisateur. Tout après avoir été hyper texte sera résolu par la machine (navigateur et serveur à l'arrière).

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

Mais la question est juste parce que les machines PEUVENT gérer cela devrait-il être fait de cette façon?

Je veux dire quels sont les avantages de nommer et d'accéder à une ressource assise à hereIsTheResourcevs hereistheresource?

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

Voici donc mes points: -

Le chemin des ressources 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 le toucher ou le taper, etc. Vous devez développer votre application pour ÉVITER que les utilisateurs tapent le chemin autant que possible.

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

Conclusion

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

Les caractères d'URL sont convertis en code hexadécimal (si vous avez déjà remarqué des espaces dans les URL affichés en tant que% 20, etc.), et comme les minuscules et les majuscules ont des valeurs hexadécimales différentes, il est parfaitement logique que les URL soient très certainement sensibles à la casse. Cependant, l'esprit de la question semble être DEVRAIT être la norme et je dis non, mais ils le sont. Il appartient au développeur / fournisseur d'en tenir compte dans leur code s'il souhaite que cela fonctionne indépendamment pour un utilisateur final.

Je pense que cela et beaucoup de réponses sur ce que la spécification dit ou ne dit pas, c'est le point de la question. Doivent- ils être sensibles à la casse? C'est vraiment une question délicate. Du point de vue d'un utilisateur, la sensibilité à la casse est un point douloureux, tous ne savent pas faire la différence. La question de savoir si les URI doivent ou non être, dépend du contexte de la question. Pour la flexibilité technique, oui, ils devraient l'être. Pour la convivialité, non, ils ne devraient pas l'être.

Conservation des cas

Les URL respectent la casse , entre le client et le serveur. Mais certaines parties des URL peuvent ou non être sensibles à la casse , selon le serveur, pour deux raisons.

Sensibilité à la casse

Les parties en gras suivantes des URL peuvent être sensibles à la casse, selon le site et / ou la configuration du serveur.

    http: // www. example.com /abc/def.ghi?jkl=mno#pqr

    utilisateur @ exemple.com

Raisonnement

La casse dans les URL peut avoir plusieurs utilisations. Principalement:

1. Compatibilité native avec les systèmes de fichiers sensibles à la casse.
2. Encodage de données plus compact dans les URL, comme pour la sérialisation, le hachage, les ID, les permaliens et les raccourcisseurs d'URL.

En tant que développeur, je pense que ce qui précède peut souvent être géré de meilleures façons, mais je comprends également qu'il y a des cas où une situation peut ne pas le permettre.

Par exemple, imaginez un produit existant qui nécessite beaucoup de données placées dans l'URL "GET", mais il doit être compatible avec les longueurs d'URL maximales de tous les principaux serveurs, navigateurs et mécanismes de mise en cache / proxy. Pour s'adapter même à une chaîne de commande de longueur modérée (moins de 1 024 caractères pour certains navigateurs plus anciens), vous devez utiliser tous les caractères uniques sûrs pour les URL que vous pourriez (ce qui est fondamentalement le codage base64url).

Dans un monde idéal

La question de savoir si les URL doivent être sensibles à la casse est discutable. Personnellement, je pense qu'ils ne devraient pas l'être, pour plus de simplicité (bien que cela puisse créer des URL plus longues, nous avons des échappements en pourcentage pour gérer facilement les cas où nous devons garantir la préservation des caractères exacts, et il existe des moyens de transférer des données autres que directement dans l'URL) .

Beaucoup semblent être d'accord sur le fait que les URL insensibles à la casse sont explicitement activées pour de nombreux sites et services populaires, afin d'augmenter la convivialité. L'exemple le plus important est la partie nom d'utilisateur des adresses e-mail. La plupart des fournisseurs de messagerie ignoreront la casse et parfois même les points et autres symboles (comme "j.smith@example.com" étant le même que "JSMITH@example.com"). Même si les noms d'utilisateur de messagerie sont sensibles à la casse par défaut, selon les spécifications.

Cependant, le fait est que malgré ce que moi ou d'autres voudrions, c'est l'état de fonctionnement actuel. Et bien qu'une éventuelle transition mondiale vers une norme d'URL insensible à la casse soit certainement possible, cela prendrait probablement beaucoup de temps car la sensibilité à la casse est actuellement largement utilisée sur le Web à diverses fins.

Les meilleures pratiques

En ce qui concerne les meilleures pratiques, en tant qu'utilisateur, vous pouvez raisonnablement vous limiter aux minuscules pour la plupart des situations et vous attendre à ce que les choses fonctionnent. Les principales exceptions seraient les URL qui utilisent un codage basé sur la casse ou des chemins de document avec des équivalents directs de système de fichiers. Cependant, ces URL complexes sont généralement copiées-collées (ou simplement cliquées) plutôt que tapées manuellement.

En tant que développeur Web, vous devriez envisager de garder les URL aussi sensibles à la casse que possible. Bien qu'il existe clairement des situations difficiles à éviter, selon le contexte, comme indiqué ci-dessus.

la question est de savoir si l'url doit ê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 doit être évité à tout moment.

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

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 emplacements. Dans un serveur Windows, l'URL est insensible à la casse, comme pour nommer un DOSSIER et sera redirigé vers le même emplacement.

Il est possible de créer des URL non sensibles à la casse

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

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