Как декодировать зарезервированный escape-символ в URI запроса на веб-сервере? - PullRequest
5 голосов
/ 04 мая 2011

Совершенно очевидно, что веб-сервер должен декодировать любой экранированный незарезервированный символ (например, алфавиты и т. Д.), Чтобы выполнить сравнение URI. Например, http://www.example.com/~user/index.htm должно быть идентично http://www.example.com/%7Euser/index.htm.

Мой вопрос: что мы будем делать с побегом зарезервированных персонажей?

Примером может быть %2F или /. Если в URI запроса есть %2F, должен ли синтаксический анализатор веб-сервера заменить его на /? В приведенном выше примере это будет означать, что http://www.example.com/~user%2Findex.htm будет таким же, как http://www.example.com/~user/index.htm? Хотя я попробовал это на сервере Apache (2.2.17 Unix), и похоже, что он выдает ошибку «404 Not Found».

Значит ли это, что %2F и другие экранированные зарезервированные символы должны быть оставлены в покое (по крайней мере до сравнения URI)?

Справочная информация:

В RFC 2616 (HTTP 1.1) есть два места, в которых упоминается проблема аварийного декодирования:

Request-URI передается в формате, указанном в разделе 3.2.1. Если Request-URI кодируется с использованием кодирования «% HEX HEX» [42], сервер происхождения ДОЛЖЕН декодировать Request-URI, чтобы правильно интерпретировать запрос. Серверы ДОЛЖНЫ отвечать на недопустимые идентификаторы Request-URI соответствующим кодом состояния.

и

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

(в соответствии с http://trac.tools.ietf.org/wg/httpbis/trac/ticket/2 «небезопасный» является ошибкой и должен быть удален из спецификации. Поэтому мы смотрим только на «зарезервированный» здесь.)

К вашему сведению, определение таких символов в RFC 2396:

забронировано = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" | "$" | ""

незарезервировано = алфавит | знак

mark = "-" | "_" | "" | "!" | "˜" | "*" | "’ "| "(" | ")"

1 Ответ

1 голос
/ 15 апреля 2015

tl; dr:

Декодирование незарезервированных символов в процентах,
сохранение зарезервированных символов в процентах.


Стандарт URI: STD 66 , что в настоящее время составляет RFC 3986 .

Раздел 6 составляет около Нормализация и сравнение , где раздел 6.2.2.2 объясняет, что делать с процентными кодированными октетами:

Эти URI должны быть нормализованы путем декодирования любого процентного кодированного октета, который соответствует незарезервированному символу […]

Как прямо указано в разделе 2 (выделено жирным шрифтом):

  • Незарезервированные символы :

    URI, которые отличаются заменой незарезервированного символа на соответствующий октет US-ASCII в процентах , эквивалентны

  • Зарезервированные символы :

    URI, которые отличаются заменой зарезервированного символа егосоответствующий октет в процентах не эквивалент.

...