Назад | Перейти на главную страницу

Apache 500 при проксировании URL-адресов с% 20 через mod_proxy

Мы получаем 500 из Apache при проксировании вызовов tomcat, когда в URL-адресе есть закодированное пространство.

Мы переносим приложение, которое нормально работало в контейнере J2EE, в котором была более старая интегрированная версия Apache (1.x), но как только мы переместили приложение на Tomcat + Apache 2 + mod_proxy, мы начали видеть ошибку.

Например:

http://foo.org/app/rest/no_spaces/  works fine
http://foo.org/app/rest/no%20spaces fails with a 500

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

Конфигурация прокси для сервера на foo.org выглядит следующим образом:

ProxyPass /app ajp://127.0.0.1:8080/app
ProxyPassReverse /app ajp://127.0.0.1:8080/app

Мы попытались переключиться на HTTP, а не на AJP, но ошибка не изменилась.

Ведущая теория заключается в том, что mod_proxy декодирует% 20, а затем ожидает увидеть другую информацию заголовка HTTP, а не оставшуюся подстроку URL-адреса, что приводит к 500. Если это так, есть ли у кого-нибудь обходной путь, который не предполагает перезаписи приложение. Если причина не в этом, есть ли у кого-нибудь предположение, что это могло быть?

Я не видел документации или отчетов об ошибках этого точного симптома во время моих поисков.

Заранее спасибо.

Работает ли добавление nocanon в правило ProxyPass?

то есть ProxyPass / app ajp: //127.0.0.1: 8080 / app nocanon

Из документов:

Обычно mod_proxy канонизирует URL-адреса ProxyPassed. Но это может быть несовместимо с некоторыми бэкэндами, особенно теми, которые используют PATH_INFO. Необязательное ключевое слово nocanon подавляет это и передает "необработанный" URL-путь на бэкэнд. Обратите внимание, что это может повлиять на безопасность вашего бэкэнда, поскольку он удаляет обычную ограниченную защиту от атак на основе URL-адресов, предоставляемую прокси.