httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tony Finch <...@dotat.at>
Subject Re: REMOTE_* w/ ProxyPass
Date Thu, 01 Jul 1999 22:01:53 GMT
Dean Gaudet <dgaudet@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

Mime
View raw message