On Thu, Mar 29, 2001 at 10:12:10PM -0800, Des Dougan <[EMAIL PROTECTED]> wrote:
> I've used the suggestions in this thread (from earlier this month) to set
> up ProxyPass to enable access to Webmail via an e-smith gateway to my
> internal e-smith server (both 4.1 with upgrades applied).
>
> I seem to have a response from the internal server - Webmail is active and
> accessible on the LAN, but the page returned (from external to the e-smith
> LAN) tells me that Webmail over HTTP is disabled, with the "If you have an
> SSL enabled browser and would like to access webmail over an SSL
> connection, please click here." link on the page pointing to the internal
> server (https://192.168.1.2/webmail - with no trailing slash). The
For starters, an invalid URL such as the one above will cause a redirect
header to be sent from the Apache server. This might be the first
indication of trouble. You'll need to ensure that the redirect happens
in the right context -- that is, that the server being proxied handles
the redirect, not the proxying server.
> I assume therefore that I have missed some configuration step additional to
> those outlined in the thread (e.g. for content presentation in Rob Adams'
> message). I would appreciate any assistance from those who've ploughed this
> furrow before.
Rob's ProxyPass directives use a virtual directory as the base URL below
which all requests will be passed on to the proxied server. If the
proxied content contains root-relative URLs (like, say, a reference to
the /images directory) the proxying server will attempt to resolve this
URL in the context of its own resources. If it cannot find the resource,
it will return a 404 header instead.
I'll repeat something I might not have emphasised adequately before:
The simplest way to ProxyPass a resource is to do so via a virtual
server, so that *all* requests from the root directory on down are
proxied. If you don't do this, you'll have to deal with the possibility
of name space collisions -- and you'll have to ensure that any other
URLs at or above that level in the hierarchy are also ProxyPass'ed.
Let's use Rob's case as an example:
> ># Implement ProxyPass to enable to corporate web stuff
> ># to reside on the IIS server (not MY choice) on
> ># 192.168.1.1:80 (Rob Adams 12 Mar 2001
> >#
> >
> ><IfModule mod_proxy.c>
> >ProxyPass /corporate/ http://192.168.1.1/
> >ProxyPassReverse /corporate/ http://192.168.1.1/
> ></IfModule>
In this case, any URL in the proxied content that starts with
/corporate/ will be properly proxied by the proxying server. Any URL at
or above that level in the hierarchy (for example, /cgi-bin/foo.cgi)
will *not* be proxied, unless the proxying server has another set of
ProxyPass Directives:
<IfModule mod_proxy.c>
ProxyPass /corporate/ http://192.168.1.1/
ProxyPassReverse /corporate/ http://192.168.1.1/
# Add proxying for /cgi-bin/ as well
ProxyPass /cgi-bin/ http://192.168.1.1/cgi-bin/
ProxyPassReverse /cgi-bin/ http://192.168.1.1/cgi-bin/
</IfModule>
As you can see from the example, this can create some interesting
name space conflicts. Typically, we'd want to be able to access the
/cgi-bin directory on both servers.
As a solution, you can either use a virtual host as the proxying
resource (see above) or you can create an alias with a unique name on
the proxied server:
ScriptAlias /cgi-bin/ /path/to/scripts/directory/
ScriptAlias /proxied-cgi-bin/ /path/to/scripts/directory/
Then in the proxied content you'd have to use the second alias in all
references to the resources contained therein.
As you can see, it's far easier use the ProxyPass* directives in
conjunction with a virtual server.
Hope this helps,
--
Dan McGarry, e-smith, Inc.
http://www.e-smith.com/ http://www.e-smith.org/
[EMAIL PROTECTED] +1 613-368-4374
