You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Brad Fitzpatrick <br...@bradfitz.com> on 1999/07/01 19:06:17 UTC
REMOTE_* w/ ProxyPass
Perhaps this is the inapproriate forum, and I suspect it is, but I can't
find reference to this elsewhere.
I'm curious whether or not there is a way to pass the REMOTE_* environment
variables to the webserver from another one, that's pulling the request on
command from a ProxyPass directive.
In other words, I want the real server to see the environment as if it
were hit directly from the client, instead of seeing the REMOTE_HOST and
_PORT of the proxy machine.
If this functionality is not already available, would it be something
to consider adding? Or, is this a security hole? I assume these settings
would have to be passed in HTTP headers from the proxy to the other
server, so the server would probably have to have a directive as to which
mirroring proxies to "trust" passing environments.
Thanks!
Brad
Re: REMOTE_* w/ ProxyPass
Posted by Tony Finch <do...@dotat.at>.
Dean Gaudet <dg...@arctic.org> wrote:
>
>It's almost like we want a hook (and I'm sure this is something EAPI/KEAPI
>solves) which says "please resolve this variable for me", which modules
>can hook into... and the first module to resolve it wins. The core would
>resolve it from the usual location.
>
>It's not that simple though, is it? You need to be able to get the list
>of variables... oh, and if they're truly "variable", rather than "a value
>which is fixed for the length of one request" then you can't cache them...
The REMOTE_foo stuff is doable via some sort of EAPI without much
difficulty, I think -- you have to make sure that access controls work
properly (probably the main reason for doing this), but that just means
that there should be an accessor function for the client's address [1]
or some underhanded fiddling with r->connection->remote_addr when a
request arrives. The value would be fixed for each request but not
necessarily for a whole connection.
The SERVER_foo end is harder if you want to use it as the basis for
virtual hosting decisions. It's not so bad if you are willing to
settle for mass vhosting only, but for fully-featured configs
something really gnarly is needed -- for a start the pre-computed
vhost information hanging off the conn_rec is useless.
[1] I have been thinking about binary compatibility recently. If
Apache wanted to have a very high degree of compatibility after 2.0,
would it be necessary to hide all core structure members behind
accessor functions or is a more lightweight solution possible?
Tony.
--
f.a.n.finch dot@dotat.at fanf@demon.net
Winner, International Obfuscated C Code Competition 1998
Re: REMOTE_* w/ ProxyPass
Posted by Brad Fitzpatrick <br...@bradfitz.com>.
> Something similar just came up on the Linux-PAM mailing list.
>
> http://perl.apache.org/tuning/#SQUID_ACCELERATOR
>
Very cool. This might just give me reason to try out mod_perl. Last time
I did it, I was in no way prepared for its memory requirements and I ended
up tripping all over myself.
However, what they describe in the above URL is, like I said, very cool.
I'll have to try that out.
Thanks!
Brad
Re: REMOTE_* w/ ProxyPass
Posted by tv...@aventail.com.
Tony Finch <do...@dotat.at> writes:
> Dean Gaudet <dg...@arctic.org> wrote:
> >
> >Yeah squid works with any server; I just think it has some extra headers
> >it can insert when forwarding requests in a "reverse proxy" situation.
>
> Squid already produces an X-Forwarded-For: header which contains the
> client's IP address (unless you turn it off). (If the request is piped
> through a chain of more than one Squid then the X-Forwarded-For:
> header will contain a record of the chain -- see posts to Usenet from
> DejaNews which uses Squid accelerators.) [ snip ]
Something similar just came up on the Linux-PAM mailing list.
http://perl.apache.org/tuning/#SQUID_ACCELERATOR
-Tom
--
Tom Vaughan <tvaughan at aventail dot com>
Re: REMOTE_* w/ ProxyPass
Posted by Ask Bjoern Hansen <as...@valueclick.com>.
On Thu, 1 Jul 1999, Dean Gaudet wrote:
...
> > DejaNews which uses Squid accelerators.) All Apache needs is an option
> > to make it fake up REMOTE_* from this header. Accelerated virtual
> > hosting would also benefit from modifying Squid to add an
> > X-Server-Addr: header from which Apache can fake up SERVER_*.
>
> Yeah, sounds like a simple job for mod_rewrite or a custom module.
I'm doing with a small module:
ftp://ftp.netcetera.dk/pub/apache/mod_proxy_add_forward.c
And in my "backend" apaches (with mod_perl) I have a few lines to set the
remote ip address again (if the request comes from a trusted source (ip
address of the proxy)). Works very well.
- ask
--
ask bjoern hansen - <http://www.netcetera.dk/~ask/>
more than 14M impressions per day, <http://valueclick.com>
Re: REMOTE_* w/ ProxyPass
Posted by Dean Gaudet <dg...@arctic.org>.
On Thu, 1 Jul 1999, Tony Finch wrote:
> Dean Gaudet <dg...@arctic.org> wrote:
> >
> >Yeah squid works with any server; I just think it has some extra headers
> >it can insert when forwarding requests in a "reverse proxy" situation.
>
> Squid already produces an X-Forwarded-For: header which contains the
> client's IP address (unless you turn it off). (If the request is piped
> through a chain of more than one Squid then the X-Forwarded-For:
> header will contain a record of the chain -- see posts to Usenet from
> DejaNews which uses Squid accelerators.) All Apache needs is an option
> to make it fake up REMOTE_* from this header. Accelerated virtual
> hosting would also benefit from modifying Squid to add an
> X-Server-Addr: header from which Apache can fake up SERVER_*.
Yeah, sounds like a simple job for mod_rewrite or a custom module.
> There is a slight problem, though: accelerators are allowed to pipe
> requests from multiple clients down the same connection, but Apache
> assumes that the client information is static for a given connection.
> Confusion between request_rec and conn_rec raises its ugly head again.
But aren't these headers present on each request going down the pipe?
Oh I see your point -- if we insist on using REMOTE_foo and SERVER_foo
rather than HTTP_X_FORWARDED_FOR then you get into the confusion between
conn_rec and request_rec...
Interesting.
It's almost like we want a hook (and I'm sure this is something EAPI/KEAPI
solves) which says "please resolve this variable for me", which modules
can hook into... and the first module to resolve it wins. The core would
resolve it from the usual location.
It's not that simple though, is it? You need to be able to get the list
of variables... oh, and if they're truly "variable", rather than "a value
which is fixed for the length of one request" then you can't cache them...
oh joy.
mumble.
Dean
>
> This is on my list of things to do when it needs to be done, but I doubt
> that time will come for a few months yet unless someone else wants the
> same thing.
>
> Tony.
> --
> f.a.n.finch dot@dotat.at fanf@demon.net
> Winner, International Obfuscated C Code Competition 1998
>
Re: REMOTE_* w/ ProxyPass
Posted by Tony Finch <do...@dotat.at>.
Dean Gaudet <dg...@arctic.org> wrote:
>
>Yeah squid works with any server; I just think it has some extra headers
>it can insert when forwarding requests in a "reverse proxy" situation.
Squid already produces an X-Forwarded-For: header which contains the
client's IP address (unless you turn it off). (If the request is piped
through a chain of more than one Squid then the X-Forwarded-For:
header will contain a record of the chain -- see posts to Usenet from
DejaNews which uses Squid accelerators.) All Apache needs is an option
to make it fake up REMOTE_* from this header. Accelerated virtual
hosting would also benefit from modifying Squid to add an
X-Server-Addr: header from which Apache can fake up SERVER_*.
There is a slight problem, though: accelerators are allowed to pipe
requests from multiple clients down the same connection, but Apache
assumes that the client information is static for a given connection.
Confusion between request_rec and conn_rec raises its ugly head again.
This is on my list of things to do when it needs to be done, but I
doubt that time will come for a few months yet unless someone else
wants the same thing.
Tony.
--
f.a.n.finch dot@dotat.at fanf@demon.net
Winner, International Obfuscated C Code Competition 1998
Re: REMOTE_* w/ ProxyPass
Posted by Dean Gaudet <dg...@arctic.org>.
Well you'd need the proxy to insert headers into the outgoing request...
and then you'd get those headers on the destination server. They wouldn't
be called REMOTE_*, they'd be HTTP_SOMETHING. But you'd get them at
least.
Yeah squid works with any server; I just think it has some extra headers
it can insert when forwarding requests in a "reverse proxy" situation.
Dean
On Thu, 1 Jul 1999, Brad Fitzpatrick wrote:
> I'm not too deeply familiar with Squid, but I browsed over the docs real
> quick. Didn't see anything obvious, or not in language that I
> understand. (maybe they call this something else?)
>
> In any case, this seems like something that must, in part at least, be
> implemented inside the Apache server, or inside a module, in able to alter
> the environment that logging and CGI requests and such see. I mean, there
> are two parties involved in the protocol even if Squid does define it,
> right? Is there a mod_squid? I thought Squid worked with any HTTP
> server, or are there Apache-specific optimizations/tricks?
>
>
> On Thu, 1 Jul 1999, Dean Gaudet wrote:
>
> > I don't think there is currently any way to do this.
> >
> > Before you go invent a new protocol for it, check with the squid docs to
> > see if they handle it already (ISTR there's something like this in squid).
> >
> > Dean
> >
> > On Thu, 1 Jul 1999, Brad Fitzpatrick wrote:
> >
> > > Perhaps this is the inapproriate forum, and I suspect it is, but I can't
> > > find reference to this elsewhere.
> > >
> > > I'm curious whether or not there is a way to pass the REMOTE_* environment
> > > variables to the webserver from another one, that's pulling the request on
> > > command from a ProxyPass directive.
> > >
> > > In other words, I want the real server to see the environment as if it
> > > were hit directly from the client, instead of seeing the REMOTE_HOST and
> > > _PORT of the proxy machine.
> > >
> > > If this functionality is not already available, would it be something
> > > to consider adding? Or, is this a security hole? I assume these settings
> > > would have to be passed in HTTP headers from the proxy to the other
> > > server, so the server would probably have to have a directive as to which
> > > mirroring proxies to "trust" passing environments.
> > >
> > >
> > > Thanks!
> > > Brad
> > >
> > >
> > >
> >
> >
>
>
Re: REMOTE_* w/ ProxyPass
Posted by Brad Fitzpatrick <br...@bradfitz.com>.
I'm not too deeply familiar with Squid, but I browsed over the docs real
quick. Didn't see anything obvious, or not in language that I
understand. (maybe they call this something else?)
In any case, this seems like something that must, in part at least, be
implemented inside the Apache server, or inside a module, in able to alter
the environment that logging and CGI requests and such see. I mean, there
are two parties involved in the protocol even if Squid does define it,
right? Is there a mod_squid? I thought Squid worked with any HTTP
server, or are there Apache-specific optimizations/tricks?
On Thu, 1 Jul 1999, Dean Gaudet wrote:
> I don't think there is currently any way to do this.
>
> Before you go invent a new protocol for it, check with the squid docs to
> see if they handle it already (ISTR there's something like this in squid).
>
> Dean
>
> On Thu, 1 Jul 1999, Brad Fitzpatrick wrote:
>
> > Perhaps this is the inapproriate forum, and I suspect it is, but I can't
> > find reference to this elsewhere.
> >
> > I'm curious whether or not there is a way to pass the REMOTE_* environment
> > variables to the webserver from another one, that's pulling the request on
> > command from a ProxyPass directive.
> >
> > In other words, I want the real server to see the environment as if it
> > were hit directly from the client, instead of seeing the REMOTE_HOST and
> > _PORT of the proxy machine.
> >
> > If this functionality is not already available, would it be something
> > to consider adding? Or, is this a security hole? I assume these settings
> > would have to be passed in HTTP headers from the proxy to the other
> > server, so the server would probably have to have a directive as to which
> > mirroring proxies to "trust" passing environments.
> >
> >
> > Thanks!
> > Brad
> >
> >
> >
>
>
Re: REMOTE_* w/ ProxyPass
Posted by Dean Gaudet <dg...@arctic.org>.
I don't think there is currently any way to do this.
Before you go invent a new protocol for it, check with the squid docs to
see if they handle it already (ISTR there's something like this in squid).
Dean
On Thu, 1 Jul 1999, Brad Fitzpatrick wrote:
> Perhaps this is the inapproriate forum, and I suspect it is, but I can't
> find reference to this elsewhere.
>
> I'm curious whether or not there is a way to pass the REMOTE_* environment
> variables to the webserver from another one, that's pulling the request on
> command from a ProxyPass directive.
>
> In other words, I want the real server to see the environment as if it
> were hit directly from the client, instead of seeing the REMOTE_HOST and
> _PORT of the proxy machine.
>
> If this functionality is not already available, would it be something
> to consider adding? Or, is this a security hole? I assume these settings
> would have to be passed in HTTP headers from the proxy to the other
> server, so the server would probably have to have a directive as to which
> mirroring proxies to "trust" passing environments.
>
>
> Thanks!
> Brad
>
>
>