Почему & ldquo; google.com/images&rdquo ;, и & ldquo; google.com //////////// images & rdquo; перейдите на ту же страницу? [Дубликат]

Рассмотрите объявление соответствующего path-absolute нетерминала в «RFC3986: Единый идентификатор ресурса (URI): общий синтаксис« (указанный, как обычно, в синтаксисе ABNF :

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

Затем рассмотрите декларацию segment несколько строк дальше в том же документе:

segment       = *pchar

Если вы можете читать ABNF, звездочка (*) указывает, что следующий элемент pchar может повторяться несколько раз, чтобы создать segment, включая нулевое время . Изучив это и перечитав декларацию path-absolute выше, вы увидите, что потенциально пустой segment показывает, что второй "/" может повторять неопределенно , следовательно, допустимые комбинации, такие как ////// ( произвольная длина по крайней мере одного /) как часть path-absolute (которая сама используется при указании правила, описывающего URI).

Поскольку все URL-адреса являются URI, мы можем заключить, что да, URL-адреса разрешено несколько последовательных косых черт в соответствии с цитируемым RFC.

Но это не похоже на то, что каждый следует или реализует парсеры URI для каждой спецификации, поэтому я уверен, что существуют несовместимые анализаторы URI / URL и все виды программного обеспечения, которые стеки поверх них, где такие угловые случаи ломают большие системы.

Вы можете быть удивлены, например, при создании ссылок для ресурсов в вашем приложении.

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

не будет разрешать mysite.com/resources/angular/script.js, но mysite.com/resources/jquery/angular/script.js то, что вы, вероятно, не хотели

Двойные косые черты - это зло, старайтесь избегать их.

URL-адреса не должны отображаться в пути к файловой системе. Поэтому, даже если // в пути к файловой системе эквивалентен /, вы не можете гарантировать, что то же самое верно для всех URL-адресов.

Одна вещь, которую вы, возможно, захотите рассмотреть, это то, что она может повлиять на индексирование страницы в поисковой системе. Согласно этой веб-странице,

URL с тем же путем, который повторяется 3 раза, не будет проиндексирован в Google

. Например, они используют:

example.com/path/path/path/

Я не подтвердил, что это также было бы правдой, если бы вы использовали example.com///, но я бы, конечно же, хотел узнать, важна ли оптимизация SEO для моего сайта.

Они отмечают, что «это потому, что Google считает, что он попал в ловушку URL». Если кто-то еще точно знает ответ, добавьте комментарий к этому ответу; в противном случае я счел нужным включить этот случай для рассмотрения.

Правильный ответ на этот вопрос зависит от реализации сервера !

Предисловие: двойной слэш синтаксически действителен в соответствии с RFC 2396, который определяет синтаксис URL-пути. Как объясняет Амн, поэтому подразумевается пустой сегмент URI. Однако обратите внимание, что RFC 2396 определяет синтаксис , а не семантику путей, включая пустые сегменты пути, поэтому ваш сервер должен решить семантику пустого пути.

Вы не упомянули о стеке серверного программного обеспечения, которое вы используете, возможно, вы даже катаетесь самостоятельно? Поэтому, пожалуйста, используйте свое воображение относительно семантики!

Практически я хотел бы указать на некоторые повседневные смысловые причины, которые означают, что вы должны избегать двойных косых черт, даже если они [синтаксически [3] / g3] valid:

1. Поскольку пустое значение действительно как-то не ожидается всеми, оно может вызвать ошибки. И хотя ваша серверная технология сегодня может быть совместима с ней, либо ваша серверная технология завтрашнего дня, либо следующая версия вашей серверной технологии сегодня могут решить не поддерживать ее больше. Пример. Библиотека ASP.NET MVC Web API выдает ошибку при попытке указать шаблон маршрута с двойной косой чертой.
2. Некоторые серверы могут интерпретировать // как указание корневого пути. Это может быть либо целевым, либо ошибкой - и, скорее всего, это ошибка безопасности, то есть уязвимость обхода каталога.
3. Поскольку иногда это ошибка и ошибка безопасности, некоторые умные серверные стеки и брандмауэры увидят подстроку «//», выведите, возможно, попытку использовать такую ​​ошибку , и поэтому они вернут 403 Forbidden или 400 Bad Request и т. д., и откажутся на самом деле любая дальнейшая обработка URI.

Ваш вопрос: «он что-то сломает». Что касается спецификации URL, то она не работает. Не читайте RFC, вот быстрый эксперимент, который вы можете попробовать:

cat > tmp.php <<'EOF'
<?php
echo $_SERVER['REQUEST_URI'];
EOF
php -S localhost:4000 tmp.php

Теперь откройте свой браузер до http: // localhost: 4000 / hello // world