Решение для обратного проксирования URL-адресов, которые нельзя переместить в подкаталог

Короткий рассказ
Ага! Я бы хотел, чтобы разработчики, которые создавали интерфейсы администратора, выставляли параметр «webroot = / myAppAppearsHere» или делали все ссылки относительными.

Длинная история

У меня есть административный портал для клиента, который в основном представляет собой логин apache mod_auth, а затем ряд ссылок на такие внутренние административные страницы;

https://portal.mysite.com/login    
https://portal.mysite.com/

а затем кучу таких ссылок

https://portal.mysite.com/monitoring   -> https://nagios.localdomain/nagios
https://portal.mysite.com/munin     -> https://munin.localdomain/nagios
https://portal.mysite.com/bacukups     -> https://backups.localdomain/backups

Однако есть несколько приложений, которым действительно не нравится обратное проксирование в подкаталог, например chef-server-webui и веб-интерфейс logstash.

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

Очевидная тактика - создать поддомены или поддомены с подстановочными знаками для сопоставления с этими приложениями следующим образом;

https://chef.mysite.com/   -> https://chefserver.localdomain:4040/
https://logstash.mysite.com/   -> https://logstash.localdomain/
https://*.mysite.com/   -> https://($1).localdomain/

Но, к сожалению, я не контролирую администрирование домена, и получение этих дополнений возможно, но очень сложно. (но я бы предпочел решение, которое не требует участия какой-либо третьей стороны для каждой новой ссылки) (я знаю, что это решит подстановочный знак, но мне интересно узнать, какие существуют альтернативы на основе HTTP и apache. .. для обучения и т.д .;-)

Поэтому я перешел к использованию Apache2 :: ModProxyPerlHtml который похож на mod_proxy_html и позволяет динамически переназначать строки в документах. Это действительно работает с некоторой комбинацией LocationMatch и ProxyHTMLRewrite, я даже могу заставить javascript играть хорошо. Однако делать каждое из них - огромная боль, особенно для любых приложений, отличных от веб-1.0.

Например, следующее почти исправляет корректную работу logstash в / logstash;

<LocationMatch "^/logstash/">

    RequestHeader   unset   Accept-Encoding
    PerlSetVar ProxyHTMLVerbose "On"
    PerlInputFilterHandler Apache2::ModProxyPerlHtml
    PerlOutputFilterHandler Apache2::ModProxyPerlHtml
    SetHandler perl-script
    PerlAddVar ProxyHTMLRewrite "/style.css /logstash/style.css"
    PerlAddVar ProxyHTMLRewrite "/css/smoothness/jquery-ui-1.8.5.custom.css /logstash/css/smoothness/jquery-ui-1.8.5.custom.css"
    PerlAddVar ProxyHTMLRewrite "/js/jquery-1.6.1.min.js /logstash/js/jquery-1.6.1.min.js"
    PerlAddVar ProxyHTMLRewrite "action='/search' action='/logstash/search'"
    PerlAddVar ProxyHTMLRewrite "/js/jquery-ui-1.8.13.min.js /logstash/js/jquery-ui-1.8.13.min.js"
    PerlAddVar ProxyHTMLRewrite "/media/throbber.gif /logstash/media/throbber.gif"

    PerlAddVar ProxyHTMLRewrite "/api/search /logstash/api/search"
    PerlAddVar ProxyHTMLRewrite "/api/histogram /logstash/api/histogram"

</LocationMatch>

Но это очень хитроумно, и вы не можете просто использовать подстановку подстановки URL-адресов, потому что существует множество JSON и javascript, которые искажаются.

Я думал о каком-то куки или запросе var, который отслеживал текущий прокси-сервер, чтобы apache мог динамически перенаправить запрос на правильный сервер .. Что-то вроде этого;

https://admin.mysite.com/?request-proxy=chef -> https://chefserver.localdomain:4040/
https://admin.mysite.com/?request-proxy=logstash  -> https://logstash.localdomain/

И в основном, поскольку apache в последний раз просматривает весь HTTP-контент сервера, он может динамически помечать URL-адреса с помощью дополнительных переменных запроса & request-proxy = logstash. Однако я думаю, что это столкнется с той же проблемой, что и решение ModProxyPerlHtml / mod_proxy_html, поскольку оно никогда не будет работать везде, особенно в приложениях, в которых использовался некоторый javascript, чтобы сбивать с толку клиентскую сторону параметров QUERY.

Я предполагаю, что cookie будет почти работать, поскольку вы можете прокси на основе некоторого переданного значения cookie сказать «request-proxy = logstash», однако это будет проблемой, если у вас есть две вкладки, открытые на сайте, поскольку они, вероятно, будут писать поверх каждой другие файлы cookie.

Я знаю, что некоторые приложения просто используют какой-то метод грубой силы и оборачивают весь прокси-запрос в повторно запеченный html, например Netscreen SA-3000.

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

1. ps. Мне известно о lemonldap, но я не продвинулся далеко без погружения в код Perl. Хотя выглядит круто, и я посмотрю еще раз.
2. Я начинаю подозревать, что с таким же успехом я мог бы просто потратить время на переназначение этих HTML-страниц с помощью ModProxyPerlHtml, потому что универсального решения не будет.