Эта директива изменяет правила, применяемые к строке HTTP-запроса (RFC 7230 §3.1.1) и полям заголовка HTTP-запроса (RFC 7230 §3.2), которые теперь применяются по умолчанию или с использованием параметра Strict . Из-за устаревших модулей, приложений или пользовательских агентов, которые должны быть объявлены устаревшими, Unsafe была добавлена опция для возврата к устаревшему поведению.

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

Директива принимает три параметра из следующего списка вариантов, применяя значения по умолчанию к тем, которые не указаны:

Строгий|Небезопасный

До введения этой директивы синтаксические анализаторы сообщений запроса HTTP-сервера Apache были терпимы к ряду форм ввода, которые не соответствовали протоколу. RFC 7230 §9.4 Разделение запроса и §9.5 Контрабанда ответов указывают только на два потенциальных риска, связанных с приемом несовместимых сообщений запроса, в то время как RFC 7230 §3.5 «Надежность синтаксического анализа сообщений» определяет риски принятия неясных пробелов и форматирования сообщения запроса. С момента введения этой директивы все грамматические правила спецификации применяются в Strict рабочем режиме по умолчанию, а строгие пробелы, предложенные в разделе 3.5, применяются и не могут быть смягчены.

Риски безопасности Unsafe

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

Пример запроса, ведущего к HTTP 400 со строгим режимом

# Missing CRLF
GET / HTTP/1.0\n\n

Инструменты командной строки и CRLF

Некоторые инструменты необходимо принудительно использовать CRLF, иначе httpd вернет ответ HTTP 400, как описано в приведенном выше примере использования. Например, для правильной работы OpenSSL s_client требуется параметр -crlf .

Директива DumpIOInput может помочь при просмотре HTTP-запроса для выявления таких проблем, как отсутствие CRLF.

Зарегистрированные методы | Мягкие методы

RFC 7231 §4.1 «Методы запроса» «Обзор» требует, чтобы исходные серверы отвечали кодом состояния HTTP 501, когда в строке запроса встречается неподдерживаемый метод. Это уже происходит при LenientMethods использовании параметра, но администраторы могут захотеть переключить RegisteredMethods параметр и зарегистрировать любые нестандартные методы с помощью RegisterHttpMethod директивы, особенно если Unsafe параметр был переключен.

Совместимость с прямым прокси

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

Пример запроса, приводящего к HTTP 501 в режиме LenientMethods

# Unknown HTTP method
WOW / HTTP/1.0\r\n\r\n

# Lowercase HTTP method
get / HTTP/1.0\r\n\r\n


Разрешить0.9|Требовать1.0

RFC 2616 §19.6 «Совместимость с предыдущими версиями» рекомендовал HTTP-серверам поддерживать устаревшие запросы HTTP/0.9. RFC 7230 заменяет это «Ожидание поддержки запросов HTTP/0.9 было удалено» и предлагает дополнительные комментарии в RFC 7230, Приложение A. Параметр Require1.0 позволяет пользователю удалить поддержку Allow0.9 поведения параметра по умолчанию.

Пример запроса, ведущего к HTTP 400 с режимом Require1.0

# Unsupported HTTP version
GET /\r\n\r\n

Просмотр сообщений ErrorLog , зарегистрированных на LogLevel debug уровне , может помочь идентифицировать такие ошибочные запросы вместе с их источником. Пользователи должны обратить особое внимание на 400 ответов в журнале доступа для недействительных запросов, которые были неожиданно отклонены.