URL avec plusieurs barres obliques, cela casse-t-il quelque chose?
http://example.com/something/somewhere//somehow/script.js
La double barre oblique casse-t-elle quelque chose du côté serveur? J'ai un script qui analyse les URL et je me demandais si cela casserait quelque chose (ou changerait le chemin) si je remplaçais plusieurs barres obliques par une seule barre oblique. Surtout côté serveur, certains frameworks comme CodeIgniter et Joomla utilisent des schémas d'url segmentés et un routage. Je voudrais juste savoir si ça casse quelque chose.
HTTP RFC 2396 définit le séparateur de chemin comme étant une barre oblique .
Cependant, à moins que vous n'utilisiez une sorte de réécriture d'URL (auquel cas les règles de réécriture peuvent être affectées par le nombre de barres obliques), l'uri est mappé sur un chemin sur le disque, mais dans (la plupart?) Des systèmes d'exploitation modernes (Linux/Unix, Windows), plusieurs séparateurs de chemin dans une rangée n'ont pas de signification particulière, donc/chemin/vers/foo et/chemin // vers //// foo mapperait finalement vers le même fichier.
Une autre chose qui pourrait être affectée est la mise en cache. Étant donné que votre navigateur et le serveur mettent en cache des pages individuelles (en fonction de leurs paramètres de mise en cache), demander plusieurs fois le même fichier via légèrement différents URI peut affecter la mise en cache ( selon l'implémentation du serveur et du client).
Il n'est pas nécessaire que les URL soient mappées aux chemins de système de fichiers. Ainsi, même si // dans un chemin de système de fichiers est équivalent à /, vous ne pouvez pas garantir que la même chose est vraie pour toutes les URL.
La bonne réponse à cette question est cela dépend de l'implémentation du serveur !
Préface: la double barre oblique est syntaxiquement valide selon la RFC 2396, qui définit la syntaxe du chemin URL. Comme amn l'explique, cela implique donc un segment URI vide. Notez cependant que la RFC 2396 définit uniquement la syntaxe , pas la sémantique des chemins, y compris les segments de chemin vides, il appartient donc à votre serveur de décider du sémantique du chemin vide.
Vous n'avez pas mentionné la pile de logiciels serveur que vous utilisez, peut-être même que vous lancez la vôtre? Veuillez donc utiliser votre imagination quant à ce que pourrait être la sémantique!
Pratiquement, je voudrais souligner certaines raisons quotidiennes liées à la sémantique qui signifient que vous devez éviter les doubles barres obliques même si elles sont syntaxiquement valides:
Étant donné que le fait d'être vide n'est pas prévu par tout le monde, cela peut provoquer des bugs. Et même si votre technologie de serveur d'aujourd'hui peut être compatible avec elle, votre technologie de serveur de demain ou la prochaine version de votre technologie de serveur d'aujourd'hui peut décider de ne plus la prendre en charge. Exemple: la bibliothèque d'API Web ASP.NET MVC génère une erreur lorsque vous essayez de spécifier un modèle de route avec une double barre oblique.
Certains serveurs peuvent interpréter // comme indiquant le chemin racine. Cela peut être intentionnel ou un bogue - et il s'agit probablement d'un bogue de sécurité, c'est-à-dire une vulnérabilité de traversée de répertoire.
Parce qu'il s'agit parfois d'un bogue et d'un bogue de sécurité, certaines piles de serveurs et pare-feu intelligents verront la sous-chaîne "//", déduisez que vous essayez peut-être d'exploiter un tel bogue , et donc ils renverront
403 Forbiddenou400 Bad Requestetc, et refusez d'effectuer tout autre traitement de l'URI.
Considérez la déclaration du path-absolutenon-terminal in "RFC3986: Uniform Resource Identifier (URI): Generic Syntax" (spécifié, comme d'habitude, dans ABNF syntaxe):
path-absolute = "/" [ segment-nz *( "/" segment ) ]
Considérez ensuite la déclaration segment quelques lignes plus loin dans le même document:
segment = *pchar
Si vous pouvez lire ABNF, l'astérisque (*) spécifie que l'élément suivant pchar peut être répété plusieurs fois pour constituer un segment, y compris zéro fois . Apprendre cela et relire le path-absolute ci-dessus, vous pouvez voir qu'un segment potentiellement vide implique que le second "/" peut se répéter indéfiniment , permettant ainsi des combinaisons valides comme ////// (longueur arbitraire d'au moins un /) dans le cadre de path-absolute (qui lui-même est utilisé pour spécifier la règle décrivant un URI).
Comme toutes les URL sont des URI, nous pouvons conclure que oui, les URL sont autorisées plusieurs barres obliques consécutives, par RFC cité.
Mais ce n'est pas comme si tout le monde suit ou implémente les analyseurs d'URI par spécification, donc je suis assez sûr qu'il existe des analyseurs d'URI/URL non conformes et toutes sortes de logiciels qui se superposent en plus lorsque de tels cas de coin cassent des systèmes plus importants.
Une chose que vous voudrez peut-être considérer est que cela pourrait affecter votre indexation de page dans un moteur de recherche. Selon cette page Web,
Une URL avec le même chemin répété 3 fois ne sera pas indexée dans Google
L'exemple qu'ils utilisent est:
example.com/path/path/path/
Je n'ai pas confirmé que cela serait également vrai si vous utilisiez example.com///, mais je voudrais certainement savoir si l'optimisation du référencement était essentielle pour mon site Web.
Ils mentionnent que "c'est parce que Google pense qu'il a atteint un piège d'URL." Si quelqu'un d'autre connaît la réponse avec certitude, veuillez ajouter un commentaire à cette réponse; sinon, j'estimais pertinent d'inclure cette affaire pour examen.
Oui, cela peut définitivement casser des choses.
La spécification considère http://Host/pages/foo.html et http://Host/pages//foo.html pour être des URI différents, et les serveurs sont libres de leur attribuer différentes significations. Cependant, la plupart des serveurs traiteront les chemins /pages/foo.html et /pages//foo.html à l'identique (car le système de fichiers sous-jacent aussi). Mais même lorsqu'il s'agit de tels serveurs, il est facilement possible qu'une barre oblique supplémentaire casse les choses. Considérez la situation où un URI relatif est retourné par le serveur.
http://Host/pages/foo.html + ../images/foo.png = http://Host/images/foo.png
http://Host/pages//foo.html + ../images/foo.png = http://Host/pages/images/foo.png
Permettez-moi d'expliquer ce que cela signifie. Supposons que votre serveur renvoie un document HTML contenant les éléments suivants:
<img src="../images/foo.png">
Si votre navigateur a obtenu cette page en utilisant
http://Host/pages/foo.html # Path has 2 segments: "pages" and "foo.html"
votre navigateur tentera de charger
http://Host/images/foo.png # ok
Cependant, si votre navigateur a obtenu cette page en utilisant
http://Host/pages//foo.html # Path has 3 segments: "pages", "" and "foo.html"
vous obtiendrez probablement la même page (car le serveur ne distingue probablement pas /pages//foo.html de /pages/foo.html), mais votre navigateur essaiera par erreur de se charger
http://Host/pages/images/foo.png # XXX
Vous pouvez être surpris, par exemple, lors de la création de liens vers des ressources dans votre application.
<script src="mysite.com/resources/jquery//../angular/script.js"></script>
ne résoudra pasmysite.com/resources/angular/script.jsmais àmysite.com/resources/jquery/angular/script.jsce que vous ne vouliez probablement pas
Les doubles barres obliques sont mauvaises, essayez de les éviter.
Votre question est "ça casse quelque chose". En termes de spécification d'URL, des barres obliques supplémentaires sont autorisées. Ne lisez pas la RFC, voici une rapide expérience que vous pouvez essayer de voir si votre navigateur modifie silencieusement l'URL:
echo '<?= $_SERVER['REQUEST_URI'];' > tmp.php
php -S localhost:4000 tmp.php
J'ai testé macOS 10.14 (18A391) avec Safari 12.0 (14606.1.36.1.9) et Chrome 69.0.3497.100 et les deux obtiennent le résultat:
/Bonjour le monde
Cela indique que l'utilisation d'une barre oblique supplémentaire est visible pour l'application Web.
Certains cas d'utilisation seront rompus lors de l'utilisation d'une double barre oblique. Cela inclut les redirections/routages d'URL qui attendent une URL simple barre oblique ou d'autres applications CGI qui analysent directement l'URI.
Mais pour les cas normaux de diffusion de contenu statique, comme votre exemple, cela obtiendra toujours le contenu correct. Mais le client obtiendra un cache manquant contre le même contenu accessible avec différentes barres obliques.