Вопрос по – URL с несколькими косыми чертами, это что-нибудь ломает?

RFC 2396 определяет разделитель пути как одиночная косая черта.

Однако, если вы не используете какое-либо переписывание URL (в этом случае на правила перезаписи может влиять количество слешей), URI отображается на путь на диске, но в (большинстве?) Современных операционных системах (Linux) / Unix, Windows), несколько разделителей пути в строке не имеют какого-либо специального значения, поэтому / path / to / foo и / path // to //// foo в конечном итоге отобразятся в один и тот же файл.

Еще одна вещь, которая может повлиять на кеширование. Поскольку и ваш браузер, и сервер кэшируют отдельные страницы (в соответствии с их настройками кэширования), запрашивая один и тот же файл несколько раз через Немного различные 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 то, что ты, вероятно, не хотел

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

Рассмотрите декларацию соответствующего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 и все виды программного обеспечения, которые устанавливаются поверх них, когда такие угловые случаи ломают большие системы.

зависит от реализации сервера!

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

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

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

Так как пустое значение является действительным, как-то не все ожидают, это может привести к ошибкам. И хотя ваша серверная технология сегодня может быть совместима с ней, либо ваша серверная технология завтрашнего дня, либо следующая версия вашей серверной технологии сегодня может решить не поддерживать ее больше. Пример: библиотека ASP.NET MVC Web API выдает ошибку при попытке указать шаблон маршрута с двойной косой чертой.

Некоторые серверы могут интерпретировать // как указание на корневой путь. Это может быть либо преднамеренно, либо ошибка - и, скорее всего, это ошибка безопасности, то есть уязвимость обхода каталога.

Потому что это иногда ошибка, и ошибка безопасности, некоторые хитроумные серверные стеки и брандмауэры будут видеть подстроку «//», что вы можете сделать попытку эксплуатируя такую ошибку, и поэтому они вернутся403 Forbidden или400 Bad Request и т. д., и отказаться от дальнейшей обработки URI.

может быт влияет на индексацию вашей страницы в поисковой системе. Согласно сэт страница в Интернете

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

допускаются дополнительные косые черты. Не читайте 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, и оба получили результат:

/Привет, ми

Это означает, что используется дополнительная косая чертаявляетс видимый для веб-приложения.

Certain варианты использования будут разбиты при использовании двойной косой черты. Это включает в себя перенаправления / маршрутизацию URL-адресов, которые ожидают однослойного URL-адреса, или другие приложения CGI, которые анализируют URI напрямую.

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