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

tous " insensible " s sont en caractères gras pour plus de lisibilité.

les noms de domaine sont des noms de cas insensible selon RFC 4343 . Le reste de L'URL est envoyé au serveur via la méthode GET. Cela peut être sensible à la casse ou non.

profiter de cette page par exemple, stackoverflow.com reçoit OBTENEZ chaîne /questions/7996919/devraient-url-être sensible à la casse , l'envoi d'un Document HTML à votre navigateur. Stackoverflow.com est cas insensible parce qu'elle produit le même résultat pour /QUEStions/7996919/Devraient-url-être sensible à la casse .

D'un autre côté, Wikipedia est sensible à la casse sauf le premier caractère du titre. Les URLs https://en.wikipedia.org/wiki/Case_sensitivity et https://en.wikipedia.org/wiki/case_sensitivity conduit à le même article, mais https://en.wikipedia.org/wiki/CASE_SENSITIVITY renvoie 404.

dépend de l'os d'hébergement. Les Sites qui sont hébergés sur 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 reste du chemin qui varie.

la partie nom de domaine d'une URL N'est pas sensible à la casse puisque DNS ignore case: 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 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, à moins que ces URL ne pointent vers des ressources valides elles-mêmes.

Je ne suis pas un fan de cogner de vieux articles mais parce que c'était l'une des premières réponses pour cette question particulière j'ai senti un besoin de clarifier quelque chose.

comme la réponse de @Bhavin Shah indique 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 suit le nom de domaine est considéré comme sensible à la casse.

so...

http://GOOGLE.COM/ABOUT

et

http://GOOGLE.COM/about

sont différents.

Note: je parle" techniquement "et pas" 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 façon, mais il est possible de les configurer de sorte qu'ils ne sont pas traités de la même manière.

Différents serveurs gérer cela différemment et, dans certains cas, ils doivent être sensible à la casse. Dans de nombreux cas, les valeurs de la chaîne de requête sont encodées (comme les IDS de Session ou les données encodées Base64 qui sont passées en tant que valeur de la chaîne de requête).

donc pour répondre à la question," devrait "serveurs être sensible à la casse en saisissant 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 doivent être conscients de ce que c'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 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 sont normalement fournis en minuscules; tous les autres composants sont comparés dans un système sensible à la casse. manière.

devraient être insensibles à la casse, à moins qu'il n'y ait une bonne raison pour qu'elles ne le soient pas.

ce N'est pas obligatoire (il ne fait pas partie d'un RFC) mais il rend la communication et le stockage des URL beaucoup plus fiable.

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 d'eux est écrit "crying style" (caps) - mais du point de vue de L'analyse D'impact de vue, 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 - il suffit d'utiliser CheckSpelling On de mod_Speling.

question ancienne mais je suis tombé ici alors pourquoi ne pas prendre un coup de feu à elle puisque la question est à la recherche de diverses perspectives et non une réponse définitive.

w3c peut avoir ses recommandations - que je me soucie beaucoup - mais veulent repenser puisque la question est ici.

pourquoi le w3c considère-t-il les noms de domaine comme insensibles à la casse et laisse tout ce qui reste insensible à la casse ?

je pense que la raison est que le domaine une partie de L'URL est tapée à la main par un utilisateur. Tout ce qui est hyper texte sera résolu par la machine (navigateur et serveur à l'arrière).

peuvent mieux traiter l'insensibilité à la casse que les humains (pas le type technique:)).

mais la question Est Juste parce que les machines peuvent gérer que devrait-il être fait de cette façon ?

je veux dire quels sont les avantages de nommer et d'accéder à une ressource se trouvant à hereIsTheResource vs hereistheresource ?

Le latéral est très illisible que le chameau cas qui est plus lisible. Lisible pour L'homme (y compris le type technique).)

donc voici mes points: -

Resource Path tombe quelque part dans le milieu de la structure de programmation et d'être près d'un utilisateur final derrière le navigateur parfois.

votre URL (à l'exclusion du nom de domaine) doit être insensible à la casse si vos utilisateurs sont on s'attend à le toucher ou le dactylographier, 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) devrait être sensible à la casse si vos utilisateurs ne la taperaient jamais à la main.

Conclusion

doit être sensible à la casse. Mes points de vue sont en train de peser vers les chemins sensibles à l'affaire.

les caractères D'URL sont convertis en code hexadécimal (si vous avez déjà remarqué que les espaces dans les URLs sont affichés en %20, etc.), et comme les minuscules et les majuscules ont des valeurs hex différentes, il est parfaitement logique que les URLs soient très certainement sensibles à la casse. Toutefois, L'esprit de la question semble être que ce soit la norme et je dis non, mais ils le sont. C'est au développeur/fournisseur de tenir compte de cela dans son code s'il veut que cela fonctionne indépendamment pour un utilisateur final.

je pense que ceci et beaucoup de réponses autour de ce que le spec fait ou ne dit pas manque le point de la question. devraient-ils être sensibles à la casse? C'est une question piège vraiment. Du point de vue de l'utilisateur, la sensibilité à la casse-tête est un point douloureux. La question de savoir si URIs devrait ou non l'ê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.