Apache proxypass 不解析图像和 css 等资源的 url

San*_*eep 4 apache mod-rewrite tomcat mod-proxy proxypass

我需要将路径映射到我的 tomcat Web 应用程序。我为此使用了代理通行证。这是 apache2 中的当前配置

<VirtualHost *:80>
        ServerName localhost:80
        ProxyPass /app http://localhost:8088/ui/
        ProxyPassReverse /app http://localhost:8088/ui/


        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>
Run Code Online (Sandbox Code Playgroud)

这从 tomcat 获取 HTML,但形成的 css url 是错误的。而不是http://localhost/app/css/style.cssurl 被映射为http://localhost/ui/css/style.css.

我尝试使用重写,但没有用。

RewriteEngine on
RewriteRule ^/ui/ /app/
Run Code Online (Sandbox Code Playgroud)

我需要找到更正 URL 的正确方法。任何帮助将不胜感激!提前致谢。

San*_*eep 5

经过大量的反复试验,我找到了两种不同的解决方案来解决我的问题。

  1. 使用 mod_rewrite 和对 proxypass 的一些更改:

    <VirtualHost *:80>
        ProxyPreserveHost On
        ProxyPass /app http://localhost:8080/ui/
        ProxyPassReverse /app http://localhost:8080/ui/
    
        #since in java web app the context started with /ui the js src had /ui in the beginning
        #this resulted in 404 so I had to rewrite all request to /ui to forward to /app
    
        RewriteEngine on
        RewriteRule    "^/ui(.+)"  "/app$1"  [R,L]
    
        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined
    </VirtualHost>
    
    Run Code Online (Sandbox Code Playgroud)
  2. 在 webapp 文件夹中创建一个指向已部署应用程序的链接/快捷方式,并将该快捷方式命名为 app 在 linux 中,命令是(来自 webapp 文件夹中) ln -s ui app

现在 apache 配置是:

<VirtualHost *:80>
        ProxyPreserveHost On

        <Location /app>
            ProxyPass  ajp://localhost:8019/app/
            ProxyPassReverse ajp://localhost:8019/app/
            SetOutputFilter  proxy-html
            ProxyHTMLExtended On
            ProxyHTMLURLMap /app /app
            RequestHeader    unset  Accept-Encoding
        </Location>

        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>
Run Code Online (Sandbox Code Playgroud)

在第一个解决方案中,重写 mod 导致请求在重定向到正确的 url 之前返回 304。这就是它默认的工作方式。

在第二个解决方案中,因为两个处理程序都是相同的(/app),所以没有重定向的理由并且 URL 被正确映射。