У Apache Accept LF против CRLF в заголовках запросов

Question

У меня есть устаревший продукт, который я пытаюсь поддерживать на сервере Apache и на сервере только после того, как недавнее обновление начало отклонять заголовки запросов, которые использовали только LF для новых строк, и это сложный приказ перестроить его из-за возраста базы кода, Есть ли где-то параметр, который можно использовать, или команда mod_rewrite, которую можно использовать для разрешения заголовков запросов, которые используют LF вместо CRLF или которые перезаписывают LF как CRLF в заголовках запросов?

Пример заголовка из приложения:

Host: www.ourhostname.com:80\n
Accept-language: en\n
user_agent: Our Old Application\n
\n

Если я в шестнадцатеричном виде отредактирую файл, чтобы изменить \n в \r\nэто работает, но шестнадцатеричное редактирование файла для выпуска как обновления нежелательно, и я пытаюсь найти что-то на стороне сервера, чтобы Apache прекратил задыхаться от LF самостоятельно. Заранее спасибо за любую помощь по этой проблеме!

Answer 1

У нас была та же проблема, и мы обнаружили исправленную уязвимость Apache:

важно: Apache HTTP-запрос разбирает пробелы в пробелах CVE-2016-8743 https://httpd.apache.org/security/vulnerabilities_24.html

Эти дефекты устраняются с выпуском Apache HTTP Server 2.4.25 и координируются новой директивой;

HttpProtocolOptions Strict

который является поведением по умолчанию 2.4.25 и позже. При переключении с режима "Строгий" на режим "Небезопасный" некоторые ограничения могут быть смягчены, чтобы позволить некоторым недопустимым клиентам HTTP/1.1 обмениваться данными с сервером, но это вновь представит возможность возникновения проблем, описанных в этой оценке. Обратите внимание, что приведение к небезопасному поведению по-прежнему не разрешает использование необработанных CTL, кроме HTAB (где это разрешено), но не позволяет применять другие требования RFC, например ровно два символа SP в строке запроса.

Так, HttpProtocolOptions Unsafe директива может быть вашим решением. Мы решили не использовать его.

Answer 2

Вы могли бы установить обратный прокси-сервер перед Apache, и этот дескриптор преобразовывал бы запрос в нечто, удобное для Apache. Возможно, будет работать Varnish Cache, который также может работать как HTTP-процессор или NGINX. Другим вариантом может быть маленькое приложение Node.js, которое принимает вводные данные и конвертирует их во что-то более подходящее для вас, при этом передавая их на сервер.