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

29
<code>http://example.com/something/somewhere//somehow/script.js
</code>

Двойная косая черта ломает что-нибудь на стороне сервера? У меня есть сценарий, который анализирует URL-адреса, и мне было интересно, если он сломает что-нибудь (или изменить путь), если я заменил несколько косых черт с одним слеш Особенно на стороне сервера, некоторые платформы, такие как CodeIgniter и Joomla, используют схемы сегментированных URL и маршрутизацию. Я просто хотел бы знать, если это что-нибудь сломает.

Ваш Ответ

8   ответов
29

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

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

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

Вы должны взглянуть на раздел 3.3 документа, который вы цитировали (или RFC3986, который устарел, но соглашается с обсуждаемым здесь поведением), в котором через ABNF указано, какpath_segments состоит как минимум из одногоsegment токен, который сам может быть пустой длины. Это означает, что последовательности символов, такие как// полностью действительны в URI. amn
@ AricFowler lol;) poncha
@ amn Это действительно, здесь нет проблем. Но вопрос был в том, может ли это что-то сломать. И это может произойти - если вы используете перезапись URL (например) poncha
Это отличный ответ! Жаль, что это дубликат https: ///stackoverflow.com////////a/////10161264/////6618577 хотя ... Aric
Re " если вы не используете какое-то переписывание URL ", Это также имеет значение для относительных URL.http://host/a/b/c/d + ../../e = http://host/a/e, в то время какhttp://host/a/b/c//d + ../../e = http://host/a/b/e ikegami
11

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

0

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

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

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

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

1

Рассмотрите декларацию соответствующего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-адреса. Вопрос состоит в том, нарушают ли что-либо URL с несколькими прямыми косыми чертами, на что я ответил в основном «на практике, они могут, но теоретически они не должны, поскольку множественные прямые косые черты действительны в отношении канонической спецификации URL amn
Весь твой ответ говорит, чтоhttp://host/a////b является действительным URI, но это не то, что спросил OP. Дело в том, чтоhttp://host/a////b действителен, не делает его эквивалентнымhttp://host/a/b. На самом деле, тот самый RFC, который вы цитируете, говорит, что они Не эквивалент. ikegami
Снова, факт, что это действительный URI, не имеет значения. Foo также является действительным URI, но он обязательно сломает вещи, если вы используете его вместо @ Stackoverflow.c. Поскольку все, что вам нужно сделать, это показать, что URI действителен, он не отвечает на вопрос ikegami
8

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

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

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

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

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

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

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

1

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

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

Пример, который они использую

example.com/path/path/path/

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

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

1

Спецификация учитывает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
-1

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

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

Уточненный ответ на конкретное, что есть, а что нет. William Entriken
Qualifier «обычные случаи предоставления статического содержимого, например, вашего примера», исключает особый случай двойной косой черты с.. в твоем примере. William Entriken
Re " это все равно получит правильное содержание ", Нет, не будет если обслуживаемая страница содержит относительные ссылки на скрипты, изображения и т. д. ikegami
В статических страницах с относительными ссылками нет ничего особенного; они довольно распространены. Вы могли бы читать один прямо сейчас для всех, что вы знаете ikegami
Хорошо. Кто сказал, что ссылка../xyz противhttp://url/a//b получитьhttp://url/a/xyz не было намеченного поведения? William Entriken

Похожие вопросы