When implementing reverse proxy setups in Apache, one common frustration occurs with relative URL paths. The scenario described - where resources like CSS files are being requested from the root domain instead of the proxied subpath - is a classic symptom of this issue.

The current configuration:

<Location /folder>
    ProxyPass  http://test.madeupurl.com
    ProxyPassReverse http://test.madeupurl.com
</Location>

correctly proxies requests to the backend server, but doesn't handle URL rewriting for resources referenced in the HTML response. This causes browsers to request assets from the wrong location.

We need to modify both the HTML responses and HTTP headers. Here's the enhanced configuration:

<Location /folder>
    ProxyPass http://test.madeupurl.com
    ProxyPassReverse http://test.madeupurl.com
    ProxyPassReverseCookiePath / /folder/
    RequestHeader set X-Forwarded-Prefix "/folder"
</Location>

For HTML content, you might need additional processing:

<Location /folder>
    # Previous proxy directives
    AddOutputFilterByType SUBSTITUTE text/html
    Substitute "s|href=\"/|href=\"/folder/|i"
    Substitute "s|src=\"/|src=\"/folder/|i"
</Location>

For more complex scenarios, install mod_proxy_html:

<Location /folder>
    ProxyPass http://test.madeupurl.com
    ProxyHTMLEnable On
    ProxyHTMLURLMap / /folder/
    RequestHeader unset Accept-Encoding
</Location>

• JavaScript-generated URLs may need special handling
• WebSocket connections might require additional configuration
• Always test with various content types (JSON, XML, binary files)

When setting up reverse proxies in Apache, one of the most common frustrations occurs when relative URLs from the backend server don't respect the proxy path. Your backend application at test.madeupurl.com might work perfectly when accessed directly, but once proxied through www.example.com/folder, all those relative URLs (/css/styles.css, /js/app.js) suddenly point to the wrong location.

The core issue lies in how web servers handle relative paths. When your backend server generates HTML with relative URLs (like href="/style.css"), these paths are resolved relative to the document root, not the proxy path. The browser sees these as absolute paths from the domain root.

Apache's mod_proxy_html module provides the tools to rewrite these URLs on the fly. Here's how to implement it:

<Location /folder>
    ProxyPass http://test.madeupurl.com/
    ProxyPassReverse http://test.madeupurl.com/
    ProxyHTMLURLMap / /folder/
    SetOutputFilter proxy-html
    ProxyHTMLEnable On
</Location>

This configuration tells Apache to:

• Proxy requests to your backend server
• Rewrite URLs in the response headers (via ProxyPassReverse)
• Rewrite URLs in the HTML content (via ProxyHTMLURLMap)

For more complex scenarios, you might need additional directives:

<Location /folder>
    ProxyPass http://test.madeupurl.com/
    ProxyPassReverse http://test.madeupurl.com/
    ProxyHTMLURLMap / /folder/
    ProxyHTMLURLMap http://test.madeupurl.com /folder
    ProxyHTMLExtended On
    ProxyHTMLMeta On
    RequestHeader unset Accept-Encoding
    SetOutputFilter proxy-html
    ProxyHTMLEnable On
</Location>

Modern applications often generate URLs in JavaScript or CSS. For these cases, you might need additional processing:

ProxyHTMLURLMap (\/static\/) /folder$1 js
ProxyHTMLURLMap url\(['"]?/([^'")]*) ['"]?\) url('/folder/$1') css

While URL rewriting solves the problem, it does add processing overhead. Where possible, consider these alternatives:

• Configure your application to use root-relative URLs (/folder/style.css)
• Use the HTML tag in your application's templates
• Serve static assets directly from the frontend server

If you're still encountering problems, check these common pitfalls:

• Ensure mod_proxy_html is installed and loaded
• Verify the RequestHeader unset Accept-Encoding directive is present
• Check for mixed content (HTTP/HTTPS) issues
• Confirm there are no caching layers interfering