http://example.com/something/somewhere//somehow/script.js
Сглаживает ли двойная косая черта на стороне сервера? У меня есть script, который анализирует URL-адреса, и мне было интересно, не сломает ли он что-либо (или изменит путь), если я заменил несколько слэшей одной косой чертой. Особенно на стороне сервера некоторые структуры, такие как CodeIgniter и Joomla, используют сегментированные схемы URL и маршрутизацию. Я просто хотел бы знать, не сломает ли что-нибудь.
HTTP RFC 2396 определяет разделитель путей как единую косую черту.
Однако, если вы не используете какую-либо переписывание URL-адресов (в этом случае на правила перезаписи может влиять количество косой черты), uri сопоставляет путь на диске, но в (большинстве?) современных операционных системах (Linux/Unix, Windows), несколько разделителей путей в строке не имеют никакого особого значения, поэтому /path/to/foo и/path//в////foo в конечном итоге будут отображаться в один и тот же файл.
Еще одна вещь, которая может быть затронута, - кеширование. Поскольку ваш браузер и сервер кэшируют отдельные страницы (в соответствии с их настройками кэширования), запрос одного и того же файла несколько раз с помощью немного разных URI может повлиять на кеширование (в зависимости от реализации сервера и клиента).
URL-адреса не должны отображаться на пути к файловой системе. Поэтому, даже если//в пути файловой системы эквивалентен /, вы не можете гарантировать, что то же самое верно для всех URL-адресов.
Правильный ответ на этот вопрос зависит от реализации сервера!
Предисловие: Двойная косая черта синтаксически допустима в соответствии с RFC 2396, который определяет синтаксис пути URL. Как объясняет amn, следовательно, он подразумевает пустой сегмент URI. Однако обратите внимание, что RFC 2396 определяет только синтаксис, а не семантику путей, включая пустые сегменты пути, поэтому ваш сервер должен решить семантику пустого пути.
Вы не упомянули, какой стек серверного программного обеспечения вы используете, возможно, вы даже используете свой собственный? Поэтому, пожалуйста, используйте свое воображение относительно того, какой может быть семантика!
На практике я хотел бы указать на некоторые повседневные семантические причины, которые означают, что вам следует избегать двойных слешей, даже если они синтаксически допустимы:
Поскольку пустое значение является действительным, как-то не ожидается всеми, это может вызвать ошибки. И хотя ваша серверная технология сегодня может быть совместима с ней, либо ваша серверная технология завтрашнего дня, либо следующая версия вашей серверной технологии сегодня может решить не поддерживать ее больше. Пример: библиотека ASP.NET MVC Web API выдает ошибку при попытке указать шаблон маршрута с двойной косой чертой.
Некоторые серверы могут интерпретировать//как указание корневого пути. Это может быть либо намеренная ошибка, либо ошибка, и, скорее всего, это ошибка безопасности, то есть уязвимость, связанная с обходом каталога.
Поскольку это иногда ошибка и ошибка безопасности, некоторые умные серверные стеки и брандмауэры будут видеть подстроку "//", что вы можете сделать попытку использования такой ошибки, и поэтому они вернут 403 Forbidden или 400 Bad Request т.д. И отказ от какой-либо дальнейшей обработки URI.
Рассмотрим объявление соответствующего нетерминала 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 и все виды программного обеспечения, которые устанавливаются поверх них, когда такие угловые случаи ломают большие системы.
Можно подумать, что это может повлиять на индексацию страницы в поисковой системе. Согласно этой веб-странице,
URL с тем же путем, который повторяется 3 раза, не будет проиндексирован в Google
Пример использования:
example.com/path/path/path/
Я не подтвердил, что это также было бы правдой, если бы вы использовали example.com///, но я определенно хотел бы узнать, важна ли оптимизация SEO для моего сайта.
Они упоминают, что "это потому, что Google считает, что он попал в ловушку URL". Если кто-то еще точно знает ответ, добавьте комментарий к этому ответу; в противном случае я счел нужным включить этот случай для рассмотрения.
Да, это может определенно сломать вещи.
Спецификация рассматривает http://host/pages/foo.html и http://host/pages//foo.html как разные URI, и серверы могут назначать им разные значения. Однако большинство серверов будут обрабатывать пути /pages/foo.html и /pages//foo.html одинаково (потому что базовая файловая система тоже). Но даже когда имеешь дело с такими серверами, дополнительная косая черта легко может сломать вещи. Рассмотрим ситуацию, когда сервер возвращает относительный URI.
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
Позвольте мне объяснить, что это значит. Скажем, ваш сервер возвращает HTML-документ, который содержит следующее:
<img src="../images/foo.png">
Если ваш браузер получил эту страницу, используя
http://host/pages/foo.html # Path has 2 segments: "pages" and "foo.html"
Ваш браузер попытается загрузить
http://host/images/foo.png # ok
Однако, если ваш браузер получил эту страницу, используя
http://host/pages//foo.html # Path has 3 segments: "pages", "" and "foo.html"
вы, вероятно, получите ту же страницу (потому что сервер, вероятно, не отличает /pages//foo.html от /pages/foo.html), но ваш браузер по ошибке попытается загрузить
http://host/pages/images/foo.png # XXX
Вы можете быть удивлены, например, при создании ссылок для ресурсов в вашем приложении.
<script src="mysite.com/resources/jquery//../angular/script.js"></script>
не решит mysite.com/resources/angular/script.js , но < mysite.com/resources/jquery/angular/script.js , что вы, вероятно, не хотели
Двойные косые черты злы, старайтесь избегать их.
Я только что обнаружил эту структуру URL на сайте клиента. Это проявляется в SEO-аудитах с использованием SEMrush. Все варианты URL, будь то///,//или/////, все переходят на один/вариант страницы.
Есть ли способ остановить это? Чтобы выключить это? Я не разработчик, и мой разработчик не знает, как это происходит (да, я знаю... возможно, пришло время найти нового разработчика). Я пытаюсь найти ответы самостоятельно и нашел эту ветку. Если вы можете дать какие-либо рекомендации о том, как устранить эту непреднамеренную (я думаю) проблему, я благодарен.
Ваш вопрос "это что-нибудь сломает". С точки зрения спецификации URL допускаются дополнительные косые черты. Не читайте RFC, вот быстрый эксперимент, который вы можете попытаться увидеть, если ваш браузер молча меняет URL:
echo '<?= $_SERVER['REQUEST_URI'];' > tmp.php
php -S localhost:4000 tmp.php
Я протестировал macOS 10.14 (18A391) с Safari 12.0 (14606.1.36.1.9) и Chrome 69.0.3497.100, и оба получили результат:
/Привет, мир
Это указывало на то, что использование дополнительной косой черты является видимым для веб-приложения.
Определенные варианты использования будут нарушены при использовании двойной косой черты. Это включает в себя перенаправления/маршрутизацию URL-адресов, которые ожидают однослойный URL-адрес, или другие приложения CGI, которые анализируют URI напрямую.
Но для обычных случаев подачи статического контента, например, для вашего примера, он все равно будет получать правильный контент. Но клиент получит пропуск кеша для одного и того же контента, доступ к которому осуществляется разными слэшами.