I'm currently looking into reverse proxies and don't have a specific one in mind yet.

I am trying to forward my requests from a reverse proxy through another proxy on the web with authentication. The main reason for a reverse proxy is to have the urls rewritten so when the user clicks on it, it will be forwarded through my reverse proxy. However, it also needs to go through an actual proxy with authentication.

So basically what I am trying to achieve is, the user navigates to a site, the request is captured by a reverse proxy, the reverse proxy then makes another request through another proxy (with a proxy authentication). When the reverse proxy gets a response back, it rewrites the urls from the content inside the response and deliver it back to the user.

My question is, is this possible at all? If so, where could I start looking to implement this?

Any help is appreciated, thank you!

edit:
I found a way to rewrite urls in mod proxy using mod_replace. But still haven't found a way to forward the webrequests through another proxy

This is from Apache's Documentation

ProxyPass Directive

Description: Maps remote servers into the local server URL-space

Syntax: ProxyPass [path] !|url [key=value [key=value ...]] [nocanon] [interpolate] [noquery]

Context: server config, virtual host, directory

Status: Extension

Module: mod_proxy

This directive allows remote servers to be mapped into the space of the local server; the local server does not act as a proxy in the conventional sense, but appears to be a mirror of the remote server. The local server is often called a reverse proxy or gateway. The path is the name of a local virtual path; url is a partial URL for the remote server and cannot include a query string.

Note: This directive cannot be used within a context.

The ProxyRequests directive should usually be set off when using
ProxyPass.

Suppose the local server has address http://example.com/; then

ProxyPass http://backend.example.com/

will cause a local request for http://example.com/mirror/foo/bar to be internally converted into a proxy request to http://backend.example.com/bar.

The following alternative syntax is possible, however it can carry a performance penalty when present in very large numbers. The advantage of the below syntax is that it allows for dynamic control via the Balancer Manager interface:

ProxyPass /mirror/foo/ http://backend.example.com/

If the first argument ends with a trailing /, the second argument
should also end with a trailing / and vice versa. Otherwise the
resulting requests to the backend may miss some needed slashes and do
not deliver the expected results.

The ! directive is useful in situations where you don't want to reverse-proxy a subdirectory, e.g.

<Location /mirror/foo/>
ProxyPass http://backend.example.com/
</Location>

<Location /mirror/foo/i>
ProxyPass !
</Location>

ProxyPass /mirror/foo/i ! ProxyPass /mirror/foo
http://backend.example.com

will proxy all requests to /mirror/foo to backend.example.com except requests made to /mirror/foo/i.

Ordering ProxyPass Directives

The configured ProxyPass and ProxyPassMatch rules are checked in the
order of configuration. The first rule that matches wins. So usually
you should sort conflicting ProxyPass rules starting with the longest
URLs first. Otherwise later rules for longer URLS will be hidden by
any earlier rule which uses a leading substring of the URL. Note that
there is some relation with worker sharing. In contrast, only one
ProxyPass directive can be placed in a Location block, and the most
specific location will take precedence. For the same reasons
exclusions must come before the general ProxyPass directives.

In Apache HTTP Server 2.1 and later, mod_proxy supports pooled connections to a backend server. Connections created on demand can be retained in a pool for future use. Limits on the pool size and other settings can be coded on the ProxyPass directive using key=value parameters, described in the table below.

By default, mod_proxy will allow and retain the maximum number of connections that could be used simultaneously by that web server child process. Use the max parameter to reduce the number from the default. Use the ttl parameter to set an optional time to live; connections which have been unused for at least ttl seconds will be closed. ttl can be used to avoid using a connection which is subject to closing because of the backend server's keep-alive timeout.

The pool of connections is maintained per web server child process, and max and other settings are not coordinated among all child processes, except when only one child process is allowed by configuration or MPM design.

Example

ProxyPass /example http://backend.example.com max=20 ttl=120 retry=300