web-dev-qa-db-fra.com

Pourquoi les traiter comme des URL avec une capitalisation de chemin différente et une barre oblique différente?

Ce sont toutes des URL strictement différentes:

http://www.example.com/page
http://www.example.com/pAge
http://www.example.com/page/
http://www.example.com/paGE/

Je comprends qu’il est conforme aux règles ISO strictes, mais pourquoi? Combien de sites Web traitent réellement page et page/ comme différentes URL que vous pouvez visiter? Ou utilisez-vous réellement la capitalisation pour différencier le contenu? S'ils le faisaient, je leur dirais qu'ils ne le font probablement pas bien.

Pourquoi devons-nous perdre notre temps à nous conformer à ces règles? N'est-il pas assez simple pour Google de déterminer que page et page/ sont la même page et probablement ne devrait pas être traités comme du contenu en double?

urlurl-rewritingcanonical-urltrailing-slashcase-sensitive
8
Tom Gullen

Je comprends qu’il est conforme aux règles ISO strictes, mais pourquoi?

Il existe différents systèmes d'exploitation derrière les différents serveurs du réseau. Pour certains d'entre eux, un répertoire ou un fichier nommé page n'est pas identique à celui nommé Page. Le résultat est que ce sont vraiment deux emplacements différents et même pas nécessairement le même type d’emplacement (dir/page). Le serveur Web peut être configuré pour tenir compte de la casse, mais vous ne pouvez pas en déduire. Par conséquent, les règles doivent supposer que les choses tiennent compte de la casse et si elles ne le font pas. En réalité, ce n’est probablement pas une bonne idée de de s’appuyer sur les différences de cas, mais la situation existe et doit donc être prise en compte, parfois avec des éléments tels que mod_speling .

Combien de sites Web traitent réellement les pages et les pages/différentes URL?

Ils sont différents. C'est juste presque toujours caché de toi:

  1. Lorsque vous accédez à example.com/foo/, le serveur Web est conscient que vous allez dans un répertoire. Il recherche donc un fichier qui correspond à tout ce qu'il est configuré pour reconnaître comme index de répertoire. Donc vous finissez par vous retrouver à example.com/index.html par exemple.
  2. Si vous accédez à example.com/foo, le serveur recherche un fichier dans le répertoire racine uniquement nommé foo. S'il n'en trouve pas , alors il vérifie s'il existe un répertoire nommé /foo et vous pouvez aller jusqu'à # 1.

Ce que vous semblez considérer comme un comportement "normal" dans # 2 est en fait une solution de rechange pour gérer un cas probable.
Combien de personnes utilisent des noms de fichiers sans extension n’est pas pertinent. Encore une fois: vrai problème; doit être pris en compte.

S'ils le faisaient, je leur dirais qu'ils ne le font probablement pas bien.

C'est un avis.
Vous pouvez le sauvegarder avec divers arguments pratiques sur la non-respect de la casse et sur la gestion des URL sans extension avec lesquelles je ne suis pas nécessairement en désaccord, mais factuellement vous auriez tort de dire cela.

10
Su'

Aucune offense intentionnelle, mais la sensibilité à la casse est VITAL aux urls aujourd'hui - ils sont utilisés des millions de fois journée:

bit.ly

  1. http://bit.ly/ri2LhQ
  2. http://bit.ly/ri2LHq

Deux sites très différents - possible uniquement en raison de la sensibilité à la casse

8
Chris Kluis

Ce n'est pas une politique de Google, ce sont des règles de base.

Du point de vue de l'utilisateur Windows, il est difficile de comprendre les noms de fichiers sensibles à la casse. Cependant, sous les systèmes unix/linux, pAge et page ne sont ni les mêmes fichiers ni les mêmes répertoires, et ainsi de suite sur les serveurs Web.

Le slash final est un problème de configuration (ou de choix). Gardez à l'esprit que sur la plupart des serveurs Web, le serveur émettra une redirection 30x sur/page deux/page /, ce qui nécessitera une seconde requête de votre serveur.

Vous pouvez rendre votre serveur Web insensible à la casse et le configurer de la manière que vous souhaitez vous conformer à vos propres règles.

Mais encore une fois, ce n'est pas du tout lié à Google

5
jflaflamme