Les adresses URI sont-elles insensibles à la casse?
Lorsque l'on compare les deux Uri pour décider si elles correspondent ou non, un client
DOIVENT utiliser un casse octet-par-octet comparaison de l'ensemble de l'
Uri, avec les exceptions suivantes:
Je lire la Phrase ci-dessus en Http Rfc je pense que l'Url est de la casse, mais je n'ai pas de undrestand ce que cela signifie
?
source d'informationauteur Shahrooz Jafari
Vous devez vous connecter pour publier un commentaire.
Dans la réalité, cela dépend du serveur web.
IIS n'est pas sensible à la casse.
Apache.
Je soupçonne que la décision concernant IIS est enracinée dans le fait que le système de fichiers de Windows n'est pas sensible à la casse.
IIS est toujours conforme à la partie de la spec parce que est une recommandation, pas une obligation.
RFC 3986 états:
La RFC 2616 définit la comparaison suivante de la règle pour la
HTTPrégime:Cependant, RFC 7230 il verrouille plus loin en indiquant:
Ces règles s'appliquent généralement à côté client comparaisons. Il n'y a pas de règles spécifiquement conçu pour côté serveur comparaisons. Une fois un serveur sauts de une URI dans ses composants, il doit les traiter selon les mêmes règles, mais je ne vois pas qu'appliquée dans les Rfc. Certains serveurs web, comme Apache, faire respecter les règles. IIS n'est pas, pour la compatibilité avec Windows insensibles à la casse du système de fichiers.
La partie hôte de l'URI n'est pas sensible à la casse:
De l'une au-dessus de vous rendre sur ce site.
Le reste de l'URI après la partie hôte peut être sensible à la casse. Cela dépend du serveur.
De savoir si ou de ne pas les Url sont traités comme des casse dépend aussi du serveur web. Par exemple, Microsoft IIS serveurs ne pas traiter les Url comme sensible à la casse.
Les Url suivantes (hébergé sur un serveur IIS de Microsoft) sont à la fois considérées comme équivalentes:
Cependant, les serveurs Apache ne traiter les Url comme sensible à la casse sont classés comme les deux ressources différentes:
Techniquement, Apache est le suivant correctement les normes ici, et Microsoft va à l'encontre de la spécification... eh bien – “les vieilles habitudes ont la vie dure”, disent-ils!
Comme mentionné dans la réponse par Remy Lebeau, les règles sont fixées pour le côté client. En fait, cela signifie que logiciel client ne devrait pas essayer de faire arbitraire cas de modifications à toutes les parties d'Uri, sauf expressément indiqué pièces. Donc, quand un navigateur par exemple, voit une URL relative à une page d'ancrage, est ne doit pas convertir en minuscules avant de vérifier s'il est déjà mis en cache dans le cache; elle ne devrait utiliser l'URI lowercase de poste de serveur. Aussi, il ne devrait pas décider que deux URIs qui diffèrent dans le cas où seul point à la même ressource (donc peut-être à tort, à sauter d'une transaction et le retour de résultat mis en cache à la place).
Cela signifie que client ne doit pas supposer la façon dont les serveurs traiter les Uri. Il n'a besoin de serveurs pour traiter certains pièces insensible à la casse: par exemple, le régime et l'hôte. Mais sinon, c'est jusqu'au serveur de décider si deux URIs qui diffèrent en cas de point à la même ressource, ou pas. La norme n'impose aucune restriction sur les serveurs à cet égard, il n'y a rien "serveur" ou "serveur" n'a pas d'ailleurs directement prescrit. Si le serveur décide que son Uri sont insensibles à la casse, c'est absolument parfait. Si elles sont sensibles à la casse, c'est parfait aussi.
Pour un fichier de la base de URI, en cas de sensibilité dépend de plus sur le sous-jacent du système de fichiers, pas tellement le serveur web. Apache heureux retour
index.htmlpourINDEX.htmlsur Windows (FAT, NTFS) et mac (HFS), mais pas pour les fichiers sensible à la casse des systèmes tels que ceux habituellement utilisés dans Linux (extx et ainsi de suite).