Косая черта ("/") эквивалентна косой черте ("% 2F") в части пути URL-адреса HTTP

Question

У меня есть сайт, который обрабатывает "/" и "% 2F" в части пути (не в строке запроса) URL-адреса по-разному. Плохо ли это делать в соответствии с RFC или реальным миром?

Я спрашиваю, потому что я продолжаю сталкиваться с небольшими сюрпризами с веб-фреймворком, который я использую (Ruby on Rails), а также со слоями ниже этого (Passenger, Apache, например, мне пришлось включить «ALLOW_ENCODED_SLASHES» для Apache). Сейчас я склоняюсь к полному избавлению от закодированных слешей, но мне интересно, должен ли я подавать отчеты об ошибках, где я вижу странное поведение, связанное с закодированными слешами.

Что касается того, почему у меня вообще есть закодированные косые черты, в основном у меня есть такие маршруты:

:controller/:foo/:bar

где: foo - это что-то вроде пути, который может содержать косую черту. Я подумал, что самым простым решением будет просто экранировать URL foo, чтобы косая черта игнорировалась механизмом маршрутизации. Теперь у меня есть сомнения, и довольно ясно, что фреймворки на самом деле не поддерживают это, но, согласно RFC, это неправильно делать так?

Вот некоторая информация, которую я собрал:

RFC 1738 (URL):

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

RFC 2396 (URI):

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

(означает ли экранирование здесь что-то кроме кодирования зарезервированного символа?)

RFC 2616 (HTTP / 1.1):

Символы, отличные от символов в зарезервированных и небезопасных наборах (см. RFC 2396 [42]), эквивалентны их кодировке ""% "HEX HEX".

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

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

Он ищет буквальный файл 'foo / bar' в корневом каталоге. Не экранированная версия ищет панель файлов в каталоге foo.

Из RFC ясно, что raw и закодированный эквивалент для незарезервированных символов, но какова история для зарезервированных символов?

Answer 1

Из собранных вами данных я бы сказал, что закодированный "/" в uri снова должен рассматриваться как "/" на уровне application / cgi.

То есть, если вы используете apache с mod_rewrite, например, он не будет сопоставлять шаблон, ожидающий косые черты, с URI с закодированными косыми чертами в нем. Однако, как только соответствующий модуль / cgi / ... вызывается для обработки запроса, он должен выполнить декодирование и, например, извлечь параметр, включающий косые черты, в качестве первого компонента URI.

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

Подводя итог, я считаю совершенно нормальным видеть разницу в поведении в "/" или "% 2F", поскольку их интерпретация будет выполняться на разных уровнях.

Answer 2

История %2F против / заключалась в том, что в соответствии с первоначальными рекомендациями W3C косая черта «должна подразумевать иерархическую структуру» :

Пример 2

URI

http://www.w3.org/albert/bertram/marie-claude

и

http://www.w3.org/albert/bertram%2Fmarie-claude

НЕ идентичны, так как во втором случае закодированная косая черта не имеют иерархическое значение.

Answer 3

У меня также есть сайт с многочисленными URL-адресами с символами urlencoded. Я нахожу, что многие веб-API (включая инструменты Google для веб-мастеров и несколько модулей Drupal) работают с символами urlencoded. Многие API автоматически декодируют URL-адреса в какой-то момент своего процесса, а затем используют результат в качестве URL или HTML. Когда я нахожу одну из этих проблем, я обычно дважды кодирую результаты (что превращает% 2f в% 252f) для этого API. Однако это сломает другие API, которые не ожидают двойного кодирования, так что это не универсальное решение.

Лично я избавляюсь от как можно большего количества специальных символов в моих URL.

Кроме того, я использую идентификаторы в своих URL, которые не зависят от кодировки url:

example.com / блог / мой-удивительный-блог% 2fstory / вчера

становится:

example.com / блог / 12354 / мой-удивительный-блог% 2fstory / вчера

в этом случае мой код использует только 12354 для поиска статьи, а остальная часть URL игнорируется моей системой (но все еще используется для SEO.) Кроме того, этот номер должен появляться ДО неиспользуемых компонентов URL. таким образом, URL будет работать, даже если% 2f будет декодирован неправильно.

Кроме того, обязательно используйте канонические теги, чтобы ошибки в URL-адресах не приводили к дублированию контента.

Answer 4

Если вы используете Tomcat, добавьте '-Dorg.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH = true' в свойствах виртуальной машины.

https://tomcat.apache.org/tomcat-7.0-doc/config/systemprops.html#Security

Answer 5

Что делать, если :foo в натуральном виде содержит косые черты? Вы не хотели бы, чтобы не было различием, которое рекомендация пытается сохранить? Особо отмечает ,

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

Если кто-то создает сетевой интерфейс для программы резервного копирования и хочет выразить путь как часть пути URL, имеет смысл закодировать косые черты в пути к файлу, поскольку это not действительно часть иерархии ресурса - и, что более важно, маршрут . /backups/2016-07-28content//home/dan/ теряет корень файловой системы в двойном слэше. Избежание косой черты - это подходящий способ различить, как я читаю.