URL relatives et barres obliques finales
J'ai déjà regardé sur le web pour cela, et je soupçonne que la réponse est "vous ne pouvez pas", mais comme je n'ai pas encore trouvé de réponse aussi définitive, je pense que cela vaut la peine de demander ici. Le plus proche que j'ai trouvé touchant au problème est le mystère de la barre oblique finale et l'url relative (qui est actuellement en panne, mais Google a une version mise en cache uniquement en texte).
En raison de la conception traditionnelle des URL avec une barre oblique de fin étant interprétée comme répertoire et ceux sans barre oblique finale étant interprété comme une ressource de fichier, et les URL relatives fonctionnant hors du répertoire, alors si la page en cours a un chemin de
/lorem/ipsum/dolor
Un chemin relatif de
not-dolor
Se résoudra comme
/lorem/ipsum/not-dolor
Ce qui est naturellement logique, quand /lorem/ipsum/dolor est considéré comme une ressource de fichier, dolor, assis dans un répertoire, /lorem/ipsum/; conventions typiques et intuitives. Cependant, comme un nombre important de sites Web sont maintenant des applications dynamiques sans mappage du système de fichiers pour chaque URL, cela peut causer des maux de tête, car parfois vous voulez vraiment travailler par rapport au chemin comme si, dans la conception actuelle, il y avait une barre oblique de fin.
Existe-t-il un moyen raisonnable ("n'impliquant pas de traitement côté serveur/variables/autres, ou JavaScript") d'utiliser un chemin relatif basé sur le chemin actuel, et pas le "répertoire" du chemin actuel? De sorte que not-dolor pourrait être relatif à /lorem/ipsum/dolor et produire
/lorem/ipsum/dolor/not-dolor
Il n'y a pas solution de contournement que je connais impliquant quelque chose comme ./not-dolor, puisque . est toujours (/lorem/)ipsum/. Court de rediriger vers une barre oblique finale et de s'assurer que toutes les ressources ont des URL qui correspondent à une nature directory-ish et une nature file-ish, ou de modifier la spécification(!), est-il un moyen de lutter contre cela?
1 réponses
Non.
Le problème n'est pas tellement lié au mappage director/file (qui n'a jamais été attendu que la façon dont les mappages se produiraient, seulement autorisé comme un mappage pratique, qui est encore souvent pratique).
, C'est plus lié au simple fait que dolor n'est pas le même que dolor/ et vous souhaitez donner un nouvel URI à partir d'une référence par rapport à dolor/ lorsqu'il est combiné à un se terminant dans dolor.
Quelle peut être la solution, c'est d'agir avec /lorem/ipsum/dolor/ tout le temps. C'est-à - dites, Ne jamais parler de /lorem/ipsum/dolor du tout, seulement jamais de /lorem/ipsum/dolor/. Après tout, puisque le mappage répertoire/fichier n'est, comme vous le dites, pas la seule façon de faire les choses, il n'y a aucune raison pour que vos noms de ressources ne se terminent pas toujours par des barres obliques.
En effet, cela peut avoir plus de sens de toute façon, car en utilisant de tels liens relatifs, vous impliquez qu'il existe une sorte de relation entre /lorem/ipsum/dolor/not-dolor et /lorem/ipsum/dolor. Maintenant, alors que /lorem/ipsum/dolor/not-dolor n'a peut-être pas beaucoup de relation avec /lorem/ipsum/dolor/, l'implication qu'il pourrait Y Avoir est là dans L'URI (Oui, Les URI sont opaques, mais aussi s'ils doivent être traités comme opaques à certains niveaux, ils sont autorisés à refléter les relations, et c'est précisément pourquoi les références URI relatives ont du sens). Par conséquent, /lorem/ipsum/dolor/ reflète plus clairement votre mappage URI-ressource global (sinon, vous ne voudriez pas passer de dolor à not-dolor de toute façon).
Maintenant, cela revient à rediriger vers une barre oblique finale, que vous dites vouloir éviter (ou mieux encore, ne jamais conduire quelqu'un à dolor en premier lieu), mais ses avantages semblent maintenant meilleurs que la commodité d'URI relatifs plus faciles.