2010-07-10 18 views
1

Je suis en train de retravailler les formats d'URL de mon projet. Le format de base de nos URL de recherche est la suivante: -Pourquoi n'utilisons-nous pas de tels formats d'URL?

www.projectname/module/search/<search keyword>/<exam filter>/<subject filter>/... other params ... 

sur la recherche sans mot-clé de recherche et filtre examen, l'URL sera: -

www.projectname/module/search///<subject filter>/... other params ... 

Ma question est pourquoi ne pas voir ces URL avec des barres obliques inversées (3 barres obliques après www.projectname/module/search)? Veuillez noter que je n'utilise plus les règles de réécriture .htaccess dans mon projet. Cette URL fonctionne parfaitement fonctionnellement. Alors, devrais-je utiliser ce format?

Pour plus de détails sur la raison pour laquelle nous avons choisi ce format, s'il vous plaît vérifier mon autre question: - Suggest best URL style

Répondre

1

serveurs Web enlèveront généralement plusieurs barres obliques avant l'application arrive à voir la demande, pour un mélange de raisons de compatibilité et de sécurité. Lors du traitement de fichiers simples, il est habituel de permettre à un nombre quelconque de barres obliques entre les segments de chemin de se comporter comme une barre oblique.

segments de chemin d'URL vides ne sont pas invalides dans les URL, mais ils sont généralement évités parce que les URL relatives avec des segments vides peuvent analyser de façon inattendue. Par exemple, dans /module/search, un lien vers //subject/param est pas par rapport au fichier, mais un lien vers le serveur subject avec le chemin /param.

Que vous pouvez voir les séquences multiples barres obliques à partir de l'URL d'origine dépend de votre cadre de serveur et d'application. Dans CGI, par exemple (et d'autres normes de passerelle basées dessus), la variable PATH_INFO généralement utilisée pour implémenter le routage omettra généralement plusieurs barres obliques. Mais sur Apache il y a une variable d'environnement non standard REQUEST_URI qui donne la forme originale de la demande sans avoir des barres obliques élision ou fait de% -unescaping comme PATH_INFO fait. Donc, si vous voulez autoriser des segments de chemin vides, vous le pouvez, mais cela réduira vos options de déploiement.

Il existe d'autres chaînes que la chaîne vide qui ne font pas non plus des segments bons de chemin. L'utilisation d'un codage / (% 2F), \ (% 5C) ou octet nul (% 00) est bloquée par défaut par de nombreux serveurs. Vous ne pouvez donc pas mettre de vieilles chaînes dans un segment; il faudra le traiter pour enlever certains caractères (souvent 'slug'-ified pour enlever tout sauf les lettres et les chiffres). Pendant que vous faites cela, vous pouvez remplacer la chaîne vide par _.

+0

très bonne explication –

0

Probablement parce qu'il est pas clairement défini si oui ou non le supplément/doit être ignoré ou non.

Par exemple: http://news.bbc.co.uk/sport et http://news.bbc.co.uk//////////sport affichent tous les deux la même page dans Firefox et Chrome. Le serveur traite les deux URL comme étant la même chose, alors que ce n'est pas le cas de votre serveur. Je ne suis pas sûr si ce comportement est défini quelque part ou non, mais il semble avoir du sens (au moins pour le site Web de la BBC - si je tape un extra /, il fait ce que je voulais dire.)