On Mon, Mar 05, 2001 at 09:34:45AM +1000, David Boccabella
<[EMAIL PROTECTED]> wrote:
> Last night I got my E-Smith machine up and going, and was very happy with
> it's responsiveness and the fact that the Dynamic DNS subsection is working.
>
> I read an article on Apache's ProxyPass and was wondering how to use that
> with the server.
For those who aren't aware of it, Apache's ProxyPass and
ProxyPassReverse directives allow an Apache web server with mod_proxy
enabled to transparently proxy the content of another web resource. This
can allow such things as:
* The presentation of content on an otherwise inaccessible server
via a web gateway.
* The ability to mask the originating server's URL. For example, a
server named foo.bar.tld could be used to proxy the content of
bar.baz.tld, so that the user is not aware that the content
they're requesting is coming from anywhere but foo.bar.tld.
e-smith investigated using this capability to redirect requests to
http://server-name/e-smith-manager/ to http://localhost:980/, all
the while displaying only the first URL to the user.
More information can be found at:
http://httpd.apache.org/docs/mod/mod_proxy.html#proxypass
Note that mod_proxy *must* be available on the server, but does not have
to be running. Typical usage is to place your ProxyPass* directives
inside a conditional statement:
<IfModule mod_proxy.c>
ProxyPass /some-dir/ http://foo.bar.tld/some-dir/
ProxyPassreverse /some-dir/ http://foo.bar.tld/some-dir/
</IfModule>
>
> Its's perfect for what I want as I will need to allow access to certain test
> sites on my internal network, and just adding them as a link to my home page
> would be great.
>
> A couple of Q though..
> Has anyone done this.. and if so how..
I mocked up some ProxyPass stuff during the 4.1 development cycle, and
found a few things of interest:
* Namespace is important. If, for example, you're using
http://www.mydomain.com/foo/ as the root for the ProxyPass
directive, pointing it to http://internal-machine/foo/, then make
sure to use URLs within the proxied content that are:
a) relative -- browsers will attempt to resolve any fully
qualified URLs on their own, which can cause no end of grief,
if the URLs use internal network references;
or
b) fully qualified to the *proxied* namespace (i.e.
<a href="http://www.mydomain.com/foo/resource/>some link</a>)
and
c) unique -- This is the most important, if the server thinks it
can resolve an URL without using the proxied namespace, it
will try to, and return either 404 or the wrong content. A
reference in internal-machine's content to /cgi-bin, for
example, will result in the proxying server looking for the
requested resource in its own /cgi-bin directory. Ungood.
* You should use the ProxyPass and ProxyPassReverse directives in
tandem. Although the apache docs suggest that ProxyPassReverse
does everything that ProxyPass does, and handles redirect result
headers as well, I've found that this is not the case. A typical
set of directives would therefore look like this:
# using ProxyPass* directives to proxy content from
# http://internal-machine/foo/*
# through
# http://www.foo.bar.com/foo/
ProxyPass /foo/ http://internal-machine/foo/
ProxyPassReverse /foo/ http://internal-machine/foo/
* Use *valid* URLs. In particular, note the trailing slashes in the
example above. When a server receives an URL without the trailing
slash and if no file or script matches that exact URL, it assumes
that the client has been lazy and ommitted the trailing slash. It
then issues a 301 (moved permanently) response header, and the
client sends a second request, this time with the trailing slash
in place. This can confuse Apache when
mod_proxy is running -- especially if it's the server providing
the source content that sends the redirect -- and sometimes
results in 404 errors where none should exist.
>
> And when an internal webserver is access via this methon - what server would
> be processing the web pages as I am using 2 different and incompatable
> technologies..
The server on which the ProxyPass* directives are placed sends a request
to the server providing the proxied content. It then forwards the output
to the client. This means that if an external server running Apache on,
say, e-smith is configured to proxy content for an internal server
running IIS and ASP, the internal server will have to process the
script, then send the resulting HTML to the external server. The
external server does *not* process the script; it simply forwards the
internal server's response to the client making the original requester.
Hope this helps,
--
Dan McGarry, e-smith, Inc.
http://www.e-smith.com/ http://www.e-smith.org/
[EMAIL PROTECTED] +1 613-368-4374
