url avec plusieurs barres obliques, ne rien casser?

http://example.com/something/somewhere//somehow/script.js

La double barre oblique casser quoi que ce soit sur le serveur? J'ai un script qui analyse les Url et je me demandais si elle allait se briser quoi que ce soit (ou de modifier le chemin d'accès) si j'ai remplacé plusieurs obliques à un seul. Surtout du côté du serveur, certains cadres comme CodeIgniter et Joomla utilisation sectorielle schémas d'url et de routage. Je veux juste savoir si ça casse quoi que ce soit.

InformationsquelleAutor Joseph | 2012-04-15
  1. 32

    HTTP La RFC 2396 définit le séparateur de chemin à seule barre oblique.

    Cependant, sauf si vous êtes en utilisant un certain type de réécriture d'URL (dans ce cas, les règles de réécriture peut être affectée par le nombre de barres obliques), les uri correspond à un chemin d'accès sur le disque, mais dans (la plupart?) moderne des systèmes d'exploitation (Linux/Unix, Windows), plusieurs séparateurs de chemin dans une ligne n'a pas de signification particulière, de sorte que /chemin/vers/foo et /chemin//à//////foo serait finalement la carte pour le même fichier.

    Une chose supplémentaire qui pourrait être concernée est mise en cache. Depuis deux votre navigateur et le serveur de cache des pages individuelles (en fonction de leurs paramètres de mise en cache), demandant même fichier plusieurs fois par légèrement différents Uri pourrait affecter la mise en cache (en fonction sur le serveur et le client de la mise en œuvre).

    • Vous avez à regarder la section 3.3 du document que vous avez cité (ou RFC3986 qui obsoletes, mais s'engage sur discutés comportement ici), qui a précisé par ABNF comment path_segments comprend au moins un segment jeton, qui lui-même peut être de vide de longueur. Cela signifie que les séquences de caractères comme // sont parfaitement valables en Uri.
    • Il est valide, pas de problème ici. Mais la question est de savoir si ou non il peut rien casser. Et c'est peut - si Vous utiliser la réécriture d'URL (par exemple)
    • C'est une excellente réponse! La honte c'est un doublon de https:///stackoverflow.com////////a/////10161264/////6618577 bien que...
    • lol 😉
    • Re "sauf si vous utilisez une sorte de réécriture d'URL", Il est également importante pour les Url relatives. http://host/a/b/c/d + ../../e = http://host/a/e, tandis que http://host/a/b/c//d + ../../e = http://host/a/b/e
    • vrai 😉 belle prise

    InformationsquelleAutor poncha
  2. 11

    Url n'avez pas de carte de système de fichiers chemins. Donc, même si //dans un chemin du système de fichiers est équivalent à /, vous ne pouvez pas garantir le même est vrai pour toutes les URLs.

    InformationsquelleAutor RedGrittyBrick
  3. 9

    La bonne réponse à cette question est , il dépend de la mise en œuvre du serveur!

    Préface: la Double barre oblique est syntaxiquement valide conformément à la RFC 2396, qui définit le chemin d'accès d'URL de la syntaxe. Comme amn explique qu'il implique donc un vide URI segment. Notez cependant que la RFC 2396 définit seulement le syntaxe, pas la sémantique de chemins, vides compris les segments du chemin, il est donc à votre serveur pour décider de la sémantique du vide chemin.

    Vous n'avez pas mentionné le logiciel de serveur de la pile que vous utilisez, vous êtes peut-être même de roulement de votre propre? Alors utilisez votre imagination quant à ce que la sémantique pourrait être!

    Pratiquement, je tiens à souligner un peu tous les jours sémantique des raisons liées à la ce qui signifie que vous devez éviter les doubles barres obliques, même si elles sont syntaxiquement valide:

    1. Depuis vide valide est en quelque sorte pas attendu par tout le monde, il peut causer des bugs. Et même si votre serveur de la technologie d'aujourd'hui peut être compatible avec elle, soit votre serveur de la technologie de demain ou de la prochaine version de votre serveur de la technologie d'aujourd'hui peut décider de ne pas le supportent plus. Exemple: ASP.NET MVC, Web API de la bibliothèque renvoie une erreur lorsque vous essayez de spécifier un template de route avec une double barre oblique.

    2. Certains serveurs peuvent l'interpréter //en indiquant le chemin d'accès racine. Cela peut être soit à usage, ou d'un bug - et alors c'est un bug de sécurité, c'est à dire une traversée de répertoire de la vulnérabilité.

    3. Car c'est parfois un bug, et d'un bogue de sécurité, quelques petits malins serveur piles et les pare-feu, voir la sous-chaîne '//', en déduire que vous êtes peut-être faire une tentative à d'exploitation d'un bug, et, par conséquent, ils seront de retour 403 Forbidden ou 400 Bad Request etc, et de refuser de le faire réellement tout autre traitement de l'URI.

    InformationsquelleAutor Tim Lovell-Smith
  4. 2

    De considérer la déclaration de la path-absolute non-terminal dans "RFC3986: Identificateur de Ressource Uniforme (URI): Syntaxe Générique" (spécifié, comme cela est habituel, dans ABNF syntaxe):

    path-absolute = "/" [ segment-nz *( "/" segment ) ]

    Alors compte de la segment déclaration quelques lignes plus bas 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ée plusieurs fois pour faire un segment, y compris zéro fois. L'apprentissage de cette et re-lecture de la path-absolute déclaration ci-dessus, vous pouvez voir que potentiellement vide segment imples que la deuxième "/" peut répéter indéfiniment, et donc d'avoir des combinaisons valides comme ////// (longueur arbitraire d'au moins un /) dans le cadre de path-absolute (qui lui-même est utilisé dans la spécification de la règle décrivant une URI).

    Comme toutes les Url sont des Uri, nous pouvons conclure que oui, les Url sont autorisés multiples consécutifs obliques, cité par la RFC.

    Mais ce n'est pas comme tout le monde les suit ou met en œuvre URI analyseurs par la spécification, donc je suis assez sûr qu'il y a non-conforme URI/URL analyseurs et tous les types de logiciels que les piles sur le dessus de ces où un tel angle cas de rupture des systèmes plus grands.

    • Toutes vos réponse dit, c'est que http://host/a////b est une URI valide, mais ce n'est pas ce que l'OP a demandé. Le fait que http://host/a////b est valable de ne pas la rendre équivalente à http://host/a/b. En fait, le RFC que vous citez dit qu'ils ne sont pas équivalent.
    • La question n'est pas de savoir si les deux Url que vous avez cité sont équivalentes. La question demande si les Url avec plusieurs barres obliques rien casser, auxquelles j'ai répondu avec en gros "dans la pratique, ils pourraient, en théorie, ils ne devraient pas, comme plusieurs barres obliques sont valables à l'égard de l'URL canonique de la spécification".
    • Encore une fois, le fait que c'est une uri valide n'est pas pertinent. foo est aussi l'une uri valide, mais c'est sûr elle va casser des choses, si vous utilisez à la place de stackoverflow.com. Car tout ce que votre réponse n'est montrer que l'uri est valide, il ne répond pas à la question
    InformationsquelleAutor amn
  5. 1

    Une chose que vous pourriez envisager est qu'il pourrait affecter votre page d'indexation dans les moteurs de recherche. Selon cette page web,

    Une URL avec le même chemin répété 3 fois ne sera pas indexé dans Google

    L'exemple qu'ils utilisent est:

    example.com/path/path/path/

    Je n'ai pas confirmé l'existence de ce serait également vrai si vous avez utilisé example.com///, mais je serais certainement envie de savoir si l'optimisation SEO est essentiel pour mon site web.

    Ils mentionnent que "C'est parce que Google pense qu'il a frappé une URL piège." Si quelqu'un connait la réponse, merci d'ajouter un commentaire à cette réponse; sinon, j'ai pensé qu'il pertinent d'inclure cette affaire à l'examen.

    InformationsquelleAutor Sablefoste
  6. 1

    Oui, il peut très certainement casser des choses.

    La spec considère http://host/pages/foo.html et http://host/pages//foo.html être différents Uri, et les serveurs sont libres d'attribuer des significations différentes pour eux. Cependant, la plupart des serveurs traiter des chemins /pages/foo.html et /pages//foo.html à l'identique (parce que le sous-jacent système de fichiers n'est de trop). Mais même lorsque l'on traite avec les serveurs, il est facilement possible pour plus de slash à casser des choses. Considérons une situation où un URI relatif est renvoyé 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

    Laissez-moi vous expliquer ce que cela signifie. Dire votre serveur renvoie un document HTML qui contient les éléments suivants:

    <img src="../images/foo.png">

    Si votre navigateur a obtenu que la page à l'aide de

    http://host/pages/foo.html          # Path has 2 segments: "pages" and "foo.html"

    votre navigateur va essayer de charger

    http://host/images/foo.png          # ok

    Toutefois, si votre navigateur a obtenu que la page à l'aide de

    http://host/pages//foo.html         # Path has 3 segments: "pages", "" and "foo.html"

    vous aurez probablement la même page (parce que le serveur n'a probablement pas de différence /pages//foo.html de /pages/foo.html), mais votre navigateur à tort d'essayer de charger

    http://host/pages/images/foo.png    # XXX
    InformationsquelleAutor ikegami
  7. 0

    Vous pourriez être surpris par exemple lors de la construction de liens pour les ressources de votre application.

    <script src="mysite.com/resources/jquery//../angular/script.js"></script>

    ne permettra pas de résoudre à mysite.com/resources/angular/script.js mais à mysite.com/resources/jquery/angular/script.js ce que vous n'avez probablement pas envie

    Doubles barres obliques sont le mal, essayez de les éviter.

    InformationsquelleAutor lukyer
  8. 0

    Votre question est "est-il casser quelque chose". En termes de l'URL de la spécification, en sus des barres obliques sont autorisés. Ne pas lire les RFC, ici, c'est une expérience rapide, vous pouvez essayer de voir si votre navigateur silencieusement mangles 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 à la fois obtenir le résultat:

    /bonjour//monde

    Ce qui indiquait que l'utilisation d'un supplément de slash est visible à l'application web.

    Certains cas d'utilisation seront brisés lors de l'utilisation d'une double barre oblique. Cela inclut les redirections d'URL/routage qui s'attendent à recevoir un seul encolures URL ou d'autres applications CGI qui sont l'analyse de l'URI directement.

    Mais pour les cas normaux de servir du contenu statique, comme votre exemple, ce sera toujours obtenir le bon contenu. Mais le client devra obtenir un cache miss contre le même contenu accessible avec différentes barres obliques.

    • Précisé réponse spécifique de ce qui est et n'est pas cassé.
    • Re "ce sera toujours obtenir le bon contenu", non, ça N'a pas si la servi en de la page contient les url relatives pour les scripts, les images, etc
    • Qualificatif de "les cas normaux de servir du contenu statique, comme votre exemple" exclut le cas particulier d'une double barre oblique avec un .. dans votre exemple.
    • Il n'y a rien de spécial à propos des pages statiques avec des références relatives à l'intérieur; ils sont tout à fait commun. Vous pourriez être la lecture d'un droit maintenant, pour tout ce que vous savez
    • Ok. Qui a dit que le référencement ../xyz contre http://url/a//b pour obtenir http://url/a/xyz n'était pas le comportement voulu?
    • Ça ne change rien. Si http://url/a//b est l'URL attendu, puis en ajoutant des barres obliques (par exemple http://url/a///b) ou leur suppression (par exemple,http://url/a/b) pourrait casser des choses
    • Résumé: un URI avec des pistes de slash est différente de celle d'une URL avec ceux slash s'exécute, s'est effondré (s|/+|/|g). Il est probable que votre serveur va servir le même fichier. Vous êtes responsable de l'effet sur les Url relatives.
    • C'est une horrible résumé. Le résumé, à l'instar de votre réponse, ne répond pas à la question! Résumé: un URI avec des pistes de slash est différente de celle d'une URL avec ceux slash s'exécute, s'est effondré (s|/+|/|g). Il est probable que votre serveur va servir les différents fichiers dans le cadre de chargement du document référencé (parce qu'il sera probablement charger la page de droite, mais de briser les url relatives à l'intérieur), donc la rupture des choses.

    InformationsquelleAutor William Entriken