Chris Darroch wrote:
I've been working with the 2.4 authn/z stuff a bit lately and
what I keep tripping over is that the default authorization merge rule
uses OR logic. For example, if I enable mod_access_compat and
put in a traditional:
I wonder if anyone would offer a fastfeather talk
William A. Rowe, Jr. wrote:
I've been working with the 2.4 authn/z stuff a bit lately and
what I keep tripping over is that the default authorization merge rule
uses OR logic. For example, if I enable mod_access_compat and
put in a traditional:
I wonder if anyone would offer a fastfeather
... if we had a config finalize, modules who were prepared to declare
their config (e.g. mod_vhost declaring the per-host directory merges
completed) then as-root, we can finish these out, opening logs with
full privileges. Other merges will happen at run time (or be optimized
when we
Jorge Schrauwen wrote:
... if we had a config finalize, modules who were prepared to declare
their config (e.g. mod_vhost declaring the per-host directory merges
completed) then as-root, we can finish these out, opening logs with
full privileges. Other merges will happen at run time (or be
On 4/3/2008 at 8:06 AM, in message
[EMAIL PROTECTED], Jim Jagielski
[EMAIL PROTECTED] wrote:
Another good topic of discussion:
Time for a 2.4 release? I wouldn't mind pushing that along
and get some of the feature-set of 2.4 out before we do too
much ripping with the inevitable delays
-Ursprüngliche Nachricht-
Von: Jim Jagielski
Gesendet: Donnerstag, 3. April 2008 16:07
An: dev@httpd.apache.org
Betreff: 2.4 (Was: Re: Configuration Issues to Address [was
Re: Dynamic configuration for the hackathon?])
Another good topic of discussion:
Time for a 2.4
Another good topic of discussion:
Time for a 2.4 release? I wouldn't mind pushing that along
and get some of the feature-set of 2.4 out before we do too
much ripping with the inevitable delays associated with that :)
On Thu, Apr 03, 2008 at 10:06:50AM -0400, Jim Jagielski wrote:
Time for a 2.4 release? I wouldn't mind pushing that along
and get some of the feature-set of 2.4 out before we do too
much ripping with the inevitable delays associated with that :)
Is there really enough news in trunk to warrant
Plüm wrote:
2. My feeling regarding the usage of 2.2 is that since about 6 month we are
getting
track as commercial 3rd parties now supply modules for httpd 2.2. This means
that
will have to maintain one more stable branch for quite some time and to be
honest
currently we
On 4/2/08 5:50 PM, William A. Rowe, Jr. [EMAIL PROTECTED] wrote:
ixnay on the run-time intensive, slow down the server sorts of changes.
httpd continues to become slower as it becomes more powerful. I know you
are the first one to raise your hand and point out when we are doing too
much
On 4/2/08 5:56 PM, William A. Rowe, Jr. [EMAIL PROTECTED] wrote:
I'm pondering this... if we drop per-server ... yet retain the ability
for authors to factor their config info into related config sections...
Yes... Bcs what IO am imagining is something like what I've posted before:
If
On 4/2/08 6:07 PM, William A. Rowe, Jr. [EMAIL PROTECTED] wrote:
we can finish these out, opening logs with
full privileges. Other merges will happen at run time (or be optimized
when we can accomplish this) per-request.
We already fake per-dir logs with the env stuff in mod_log_config.
--
On 4/3/08 10:47 AM, William A. Rowe, Jr. [EMAIL PROTECTED] wrote:
I'll commit the Method
If HTTP_Method == GET
...
/If
;)
--
Brian Akins
Chief Operations Engineer
Turner Digital Media Technologies
Akins, Brian wrote:
On 4/2/08 5:56 PM, William A. Rowe, Jr. [EMAIL PROTECTED] wrote:
I'm pondering this... if we drop per-server ... yet retain the ability
for authors to factor their config info into related config sections...
Yes... Bcs what IO am imagining is something like what I've
Akins, Brian wrote:
On 4/3/08 10:47 AM, William A. Rowe, Jr. [EMAIL PROTECTED] wrote:
I'll commit the Method
If HTTP_Method == GET
...
/If
Slow
On 4/3/08 11:38 AM, William A. Rowe, Jr. [EMAIL PROTECTED] wrote:
If HTTP_Method == GET
...
/If
Slow
Not if the parsing is done at config time and HTTP_Method is handle by a
provider. Some pseudo code:
At config time, the parser would do something like:
On Thu, 03 Apr 2008 11:22:00 -0400
Akins, Brian [EMAIL PROTECTED] wrote:
If HTTP_HEADER{'Host'} == www.cnn.com and Port == 8080
DocumentRoot /www/cnn
ServerAdmin [EMAIL PROTECTED]
etc
That basically comes out of what I committed this morning.
Well, up to a point: it only
On 4/3/08 11:38 AM, William A. Rowe, Jr. [EMAIL PROTECTED] wrote:
But that *doesn't* mean I don't want it... simply not to replace directory,
file, location or method. Keep in mind you wouldn't have your ErrorLog
opened at startup time, as this is too variant
Unless I'm mistaken, there is
On Thu, Apr 3, 2008 at 8:53 AM, Akins, Brian [EMAIL PROTECTED] wrote:
Very rough draft. But this is not necessarily slow... ;)
Right.
Even then, the user/admin may be willing to burn CPU cycles anyway to
get a simpler config. Plus, if they were to use mod_rewrite, they've
already blown a
On Thu, Apr 3, 2008 at 4:31 PM, Mads Toftum [EMAIL PROTECTED] wrote:
On Thu, Apr 03, 2008 at 10:06:50AM -0400, Jim Jagielski wrote:
Time for a 2.4 release? I wouldn't mind pushing that along
and get some of the feature-set of 2.4 out before we do too
much ripping with the inevitable
Nick Kew wrote:
Limit is of course a crusty old relative.
Limit is unrelated, it's fundamentally borked (directive must know
it is participating in a limit-ed section, cannot overly multiple
limit-ed sections because that directive has never created a conf
section, and there is no exception
Akins, Brian wrote:
On 4/3/08 11:38 AM, William A. Rowe, Jr. [EMAIL PROTECTED] wrote:
But that *doesn't* mean I don't want it... simply not to replace directory,
file, location or method. Keep in mind you wouldn't have your ErrorLog
opened at startup time, as this is too variant
Unless I'm
Justin Erenkrantz wrote:
On Thu, Apr 3, 2008 at 8:53 AM, Akins, Brian [EMAIL PROTECTED] wrote:
Very rough draft. But this is not necessarily slow... ;)
Right.
Even then, the user/admin may be willing to burn CPU cycles anyway to
get a simpler config. Plus, if they were to use
On Thu, 03 Apr 2008 11:13:31 -0500
William A. Rowe, Jr. [EMAIL PROTECTED] wrote:
The If logic doesn't even apply when that module isn't loaded, I'd
hope. Those admins who refuse to let their junior admins use that
directive should have a level of control over their outward facing
[was
Re: Dynamic configuration for the hackathon?])
Another good topic of discussion:
Time for a 2.4 release? I wouldn't mind pushing that along
and get some of the feature-set of 2.4 out before we do too
much ripping with the inevitable delays associated with that :)
I know that I am always
Nick Kew wrote:
But before that, we need a vision of where we're going,
and how to get there without breaking what we've got.
* server_conf goes away. Modules have zero or more conf sections,
essentially today's misnamed dir_conf, which are initialized and
merged as they are today.
William A. Rowe, Jr. wrote:
I'd -1 a 2.4.0 release today, because nobody has even bothered to make
a candidate for 2.3-dev. Auth logic changes break most if not all third
party auth modules (broke an auth feature in mod_ftp). Not talking about
commercial modules but every third party
On Apr 3, 2008, at 12:32 PM, Brad Nicholes wrote:
It wouldn't surprise me, which is why we need to get a 2.3-beta out
there for testing.
That would be good as well... that way we can determine
how solid the existing impl is, so when the new stuff is
added we know the old stuff is still good
On Mar 31, 2008, at 13:31, Paul Querna wrote:
Just look at SSLRequire, Rewrite*, MPM Process/Thread Management,
Filter chaining, large Auth{N,Z} chains, and more.
Imagine them not sucking.
That would be lovely. Truly.
--
Happiness isn't something you experience; it's something you
On Mar 31, 2008, at 13:46, Issac Goldstand wrote:
Make mod_wombat a standard module and part of the default moduleset
May I request, if mod_wombat becomes a standard module, that it be
given a name not quite so calculated to make the newbie disable it
without a second glance. I mean,
On 4/2/08 8:44 AM, Rich Bowen [EMAIL PROTECTED] wrote:
May I request, if mod_wombat becomes a standard module, that it be given a
name not quite so calculated to make the newbie disable it without a second
glance.
I think the reason wombat was chosen is because mod_lua was taken. In
There's a couple of conflicting demands by our users, and spending
time on the users mailing list and on the IRC channel is a great way
to see this first-hand.
They don't want to learn a new syntax. And they want a new syntax
that lets them do what they mean.
And they're very frustrated
Issac Goldstand wrote:
We're not talking about fresh users, we're talking about existing
users. Fresh users have to deal with one learning curve or another
anyway.
I'm not talking about fresh users either.
Matt
Akins, Brian wrote:
The biggest problems I have with current system are:
-Every module does things differently
Within limits this will remain true. But we are missing a host of very
trivial simplifications for the casual module developer, and reinvent the
same wheel module after module.
I'm
Graham Leggett wrote:
Jim Jagielski wrote:
This reminds me: a serf BOF or session would, I think, go over
quite well :)
A question that has been on my mind for a bit, is what does serf intend
to replace, and why is it better?.
The impression I have so far is that somehow what we have now
William A. Rowe, Jr. wrote:
-I have to write a good bit of code before a module is configurable. (I'm
lazy. Very lazy.)
Agreed - see my first point.
One interesting point; why do we keep per-server and per-dir sections?
Perhaps it's time for a single simpler-to-use mechanic which can
William A. Rowe, Jr. wrote:
William A. Rowe, Jr. wrote:
-I have to write a good bit of code before a module is configurable.
(I'm
lazy. Very lazy.)
Agreed - see my first point.
One interesting point; why do we keep per-server and per-dir sections?
Perhaps it's time for a single
On Mon, Mar 31, 2008 at 11:15 AM, Roy T. Fielding [EMAIL PROTECTED] wrote:
Unfortunately, after last year's experience of being the only server
person around who wasn't working on a Joost release,
*hides*
I decided to delay
my arrival until Tuesday rather than attend the hackathon.
On Mon, Mar 31, 2008 at 7:41 PM, William A. Rowe, Jr.
[EMAIL PROTECTED] wrote:
I sympathize, but this doesn't reflect the addition of lua blocks...
those blocks can be trivially implemented as a loadable module ;-)
As I grok it, the point would be throw out our ridiculous config
syntax
On Mon, 31 Mar 2008 11:15:38 -0700
Roy T. Fielding [EMAIL PROTECTED] wrote:
On Mar 31, 2008, at 10:39 AM, Paul Querna wrote:
Just read the mod_rewrite docs:
http://httpd.apache.org/docs/2.2/rewrite/rewrite_tech.html#InternalAPI
They are already exposing internals to users'.
Not, erm,
William A. Rowe, Jr. wrote:
-0.5 PLEASE not in the core. Make mod_wombat a standard module and
part of the default moduleset, whatever, but let's not make more core
dependencies, please?!?
-0.99 - agreed. Perl is perfectly happy having perl blocks as modular
behaviors... I've noticed a
On Tue 01 Apr 2008, Paul Querna wrote:
William A. Rowe, Jr. wrote:
-0.99 - agreed. Perl is perfectly happy having perl blocks as modular
behaviors... I've noticed a trend in the last few years of building on
the core (and folks rightfully accused me of growing mod_proxy core when
new
Torsten Foertsch wrote:
On Tue 01 Apr 2008, Paul Querna wrote:
William A. Rowe, Jr. wrote:
-0.99 - agreed. Perl is perfectly happy having perl blocks as modular
behaviors... I've noticed a trend in the last few years of building on
the core (and folks rightfully accused me of growing
Can we 1st determine exactly what pain-point we're trying to solve here?
Or, at least, prioritize them?
It seems to me that if the main issue is runtime re-configuration
during the request/response phases, then that really forces us into
something which must be very lean, mean and FAST. By
On 4/1/08 5:35 AM, Issac Goldstand [EMAIL PROTECTED] wrote:
I don't think we're even talking about on-the-fly stuff for the Lua
parser engine, so Perl can do everything that Lua can.
I am.
The biggest problems I have with current system are:
-Every module does things differently
-No real
On Apr 1, 2008, at 2:17 AM, Justin Erenkrantz wrote:
On Mon, Mar 31, 2008 at 7:41 PM, William A. Rowe, Jr.
[EMAIL PROTECTED] wrote:
I sympathize, but this doesn't reflect the addition of lua
blocks...
those blocks can be trivially implemented as a loadable module ;-)
As I grok it, the
IMO, we work best when we feel empowered to scratch our itches...
As we've also seen, sometimes all it takes is someone to create
a rough framework of an implementation for people to get excited
by it and jump right on in, adding, extending and tuning it.
This reminds me: a serf BOF or session
On Apr 1, 2008, at 5:21 AM, Torsten Foertsch wrote:
You cannot add virtual servers on the fly
Hmmm let's see now. If we have a default Vhost that all non-matched
name-based hosts get directed to configured, then a mod_perl based
handler can be adjusted to look at the Server header and do
On Mar 31, 2008, at 2:15 PM, Roy T. Fielding wrote:
Users like mod_rewrite for many reasons, but I think mostly because it
does so many things that almost every Apache hosting provider needs to
have it installed and usable in .htaccess
Except for web hosting companies, and some special
Akins, Brian wrote:
My opinion (which is worthless, I know) is to pick one way and do it. Lua
is easy to learn and satisfies most (all?) of our requirements. And if
Brian M. and I can learn it, anyone can ;)
The trouble is, if I want to solve problem A (configure the server),
and I find
Let me try and summarize this then:
Problem:
The httpd configuration is to static for some users (e.g. large host
providers) they want to have a more dynamic system.
Where they can configure things on a request basis and add vhosts and
such without restarting httpd.
Solutions propose:
- lua in
On Apr 1, 2008, at 9:34 AM, Graham Leggett wrote:
Jim Jagielski wrote:
This reminds me: a serf BOF or session would, I think, go over
quite well :)
A question that has been on my mind for a bit, is what does serf
intend to replace, and why is it better?.
The impression I have so far is
On 4/1/08 9:40 AM, Torsten Foertsch [EMAIL PROTECTED] wrote:
I know one can do that. But a VHost has a server_rec, maybe a separate
error_log and access_log, etc. Those cannot be created at request time. That
is what I meant.
Well
I was hacking around with the idea that the selection of
On Tue 01 Apr 2008, Jim Jagielski wrote:
On Apr 1, 2008, at 5:21 AM, Torsten Foertsch wrote:
You cannot add virtual servers on the fly
Hmmm let's see now. If we have a default Vhost that all non-matched
name-based hosts get directed to configured, then a mod_perl based
handler can be
Jim Jagielski wrote:
This reminds me: a serf BOF or session would, I think, go over
quite well :)
A question that has been on my mind for a bit, is what does serf intend
to replace, and why is it better?.
The impression I have so far is that somehow what we have now is
suboptimal, and
On Apr 1, 2008, at 9:40 AM, Torsten Foertsch wrote:
On Tue 01 Apr 2008, Jim Jagielski wrote:
On Apr 1, 2008, at 5:21 AM, Torsten Foertsch wrote:
You cannot add virtual servers on the fly
Hmmm let's see now. If we have a default Vhost that all non-
matched
name-based hosts get directed
Jorge Schrauwen wrote:
Solutions propose:
- lua in the core or atleast in a module
- mod_perl
mod_perl exists already. We're looking to replace it because... (see below)
Downside:
- perl isn't very easy and userfriendly
I think that the downside is the fact that perl interpreters suck
On Tue, Apr 1, 2008 at 4:13 PM, Issac Goldstand [EMAIL PROTECTED] wrote:
Jorge Schrauwen wrote:
Solutions propose:
- lua in the core or atleast in a module
- mod_perl
mod_perl exists already. We're looking to replace it because... (see below)
I'm quite aware that it exists, I
Jorge Schrauwen wrote:
On Tue, Apr 1, 2008 at 4:13 PM, Issac Goldstand [EMAIL PROTECTED] wrote:
Downside:
- perl isn't very easy and userfriendly
I think that the downside is the fact that perl interpreters suck up
RAM, not the easiness factor. It's probably not significantly
On Apr 1, 2008, at 9:36 AM, Jorge Schrauwen wrote:
Let me try and summarize this then:
Problem:
The httpd configuration is to static for some users (e.g. large host
providers) they want to have a more dynamic system.
IMO, based on feedback from people I've dealt with with my
Jim Jagielski wrote:
On Apr 1, 2008, at 9:36 AM, Jorge Schrauwen wrote:
Let me try and summarize this then:
Problem:
The httpd configuration is to static for some users (e.g. large host
providers) they want to have a more dynamic system.
IMO, based on feedback from people I've dealt with
On Apr 1, 2008, at 10:32 AM, Matthew M. Burke wrote:
Graham Leggett wrote:
The trouble is, if I want to solve problem A (configure the
server), and I find out that before I can solve problem A
(configure the server) I need to first solve problem B (learn a
new language), that is a big
Matthew M. Burke wrote:
Graham Leggett wrote:
The trouble is, if I want to solve problem A (configure the server),
and I find out that before I can solve problem A (configure the
server) I need to first solve problem B (learn a new language),
that is a big incentive to just ignore the
Graham Leggett wrote:
The trouble is, if I want to solve problem A (configure the server),
and I find out that before I can solve problem A (configure the
server) I need to first solve problem B (learn a new language),
that is a big incentive to just ignore the new server and stick with
On Tue 01 Apr 2008, Akins, Brian wrote:
In pseudo config, like niq is suggesting, you could have something like:
If HTTP_HEADER{Host} =~ cnn\.com$ || TCPPort == 8080
#cnn specific stuff here...
DocumentRoot /htdocs/cnn
CutomLog |/usr/bin/logger cnn my_format
ErrorLog
On 4/1/08 11:21 AM, Torsten Foertsch [EMAIL PROTECTED] wrote:
On Tue 01 Apr 2008, Akins, Brian wrote:
In pseudo config, like niq is suggesting, you could have something like:
If HTTP_HEADER{Host} =~ cnn\.com$ || TCPPort == 8080
#cnn specific stuff here...
DocumentRoot /htdocs/cnn
Jim Jagielski wrote:
I'd prefer optimum runtime and let that drive how it gets exposed to
the admin, rather than the reverse... And then we can see if that
pain is worth it :)
+1 to this as a guiding principle.
I know our administrators would, above all else, like a standard
way to build
On Tue, Apr 1, 2008 at 6:20 AM, Jim Jagielski [EMAIL PROTECTED] wrote:
IMO, we work best when we feel empowered to scratch our itches...
As we've also seen, sometimes all it takes is someone to create
a rough framework of an implementation for people to get excited
by it and jump right on
Akins, Brian wrote:
On 3/26/08 9:06 AM, Nick Kew [EMAIL PROTECTED] wrote:
There seems to be a demand for dynamic per-request configuration,
as evidenced by the number of users hacking it with mod_rewrite,
and the other very limited tools available. Modern mod_rewrite
usage commonly looks like
Nick Kew wrote:
On Thu, 27 Mar 2008 08:17:01 -0400
Akins, Brian [EMAIL PROTECTED] wrote:
On 3/27/08 3:58 AM, Torsten Foertsch [EMAIL PROTECTED]
wrote:
So I was going to reimplement it based on mod_wombat some
time this year.
The nice thing about lua, in addition to being lightweight, is
Paul Querna wrote:
Akins, Brian wrote:
On 3/26/08 9:06 AM, Nick Kew [EMAIL PROTECTED] wrote:
There seems to be a demand for dynamic per-request configuration,
as evidenced by the number of users hacking it with mod_rewrite,
and the other very limited tools available. Modern mod_rewrite
On 3/31/08 1:46 PM, Issac Goldstand [EMAIL PROTECTED] wrote:
if possible (to
remove completely unnecessary bloating)
Lua != perl
Lua perl (size wise by an order of magnitude)
And in
addition, the learning curve to learn to use these powerful directives
is still optional
I disagree.
On 3/31/08 1:39 PM, Paul Querna [EMAIL PROTECTED] wrote:
We should just do it right, and stop hacking around the central problem.
Expose the structures.
Embed Lua.
+1, but you already knew that...
Also, mod_wombat, as such, goes away if Lua is embedded. We may have a
module that sits
Issac Goldstand wrote:
Paul Querna wrote:
Akins, Brian wrote:
On 3/26/08 9:06 AM, Nick Kew [EMAIL PROTECTED] wrote:
There seems to be a demand for dynamic per-request configuration,
as evidenced by the number of users hacking it with mod_rewrite,
and the other very limited tools available.
Paul Querna wrote:
Issac Goldstand wrote:
I think the right approach is to first change the internal configuration
API.
Make it a real API, not a series of callbacks with filepointers and
strings in them.
Once we have that, we can write language bindings for all of them, and
all
On Mar 31, 2008, at 10:39 AM, Paul Querna wrote:
Just read the mod_rewrite docs:
http://httpd.apache.org/docs/2.2/rewrite/rewrite_tech.html#InternalAPI
They are already exposing internals to users'.
Users want customization.
We should just do it right, and stop hacking around the central
Issac Goldstand wrote:
Paul Querna wrote:
Akins, Brian wrote:
On 3/26/08 9:06 AM, Nick Kew [EMAIL PROTECTED] wrote:
There seems to be a demand for dynamic per-request configuration,
as evidenced by the number of users hacking it with mod_rewrite,
and the other very limited tools available.
William A. Rowe, Jr. wrote:
Issac Goldstand wrote:
Paul Querna wrote:
Akins, Brian wrote:
On 3/26/08 9:06 AM, Nick Kew [EMAIL PROTECTED] wrote:
There seems to be a demand for dynamic per-request configuration,
as evidenced by the number of users hacking it with mod_rewrite,
and the other
Paul Querna wrote:
Then the existing configuration file, a new lua system, or anything
else, could be written in terms of that, rather than the current system
where each language reinvents the modules it wants to control.
I sympathize, but this doesn't reflect the addition of lua blocks...
Paul Querna wrote:
William A. Rowe, Jr. wrote:
Issac Goldstand wrote:
Paul Querna wrote:
Akins, Brian wrote:
On 3/26/08 9:06 AM, Nick Kew [EMAIL PROTECTED] wrote:
There seems to be a demand for dynamic per-request configuration,
as evidenced by the number of users hacking it with
On Wed 26 Mar 2008, Akins, Brian wrote:
There seems to be a demand for dynamic per-request configuration,
as evidenced by the number of users hacking it with mod_rewrite,
and the other very limited tools available. Modern mod_rewrite
usage commonly looks like programming, but it's not
I used to use mod_macro, then I moved to mod_perl but like you said.
mod_perl is great (well, more okay than great) for dynamic configurations
that change/get generated on start and not per request.
A new more flexible alternative would be awsome.
Jorge (on vacation)
On Thu, Mar 27, 2008 at
On Thu, 27 Mar 2008 08:17:01 -0400
Akins, Brian [EMAIL PROTECTED] wrote:
On 3/27/08 3:58 AM, Torsten Foertsch [EMAIL PROTECTED]
wrote:
So I was going to reimplement it based on mod_wombat some
time this year.
The nice thing about lua, in addition to being lightweight, is that
most
On 3/27/08 9:00 AM, Nick Kew [EMAIL PROTECTED] wrote:
/Lua
Fine for users who want to hack their own server. Like Perl.
Every play with lighttpd? It's almost the same way... Of course typical
lighthttpd user is a hacker.
But r.filename is the kind of innards we really don't want
to
There seems to be a demand for dynamic per-request configuration,
as evidenced by the number of users hacking it with mod_rewrite,
and the other very limited tools available. Modern mod_rewrite
usage commonly looks like programming, but it's not designed as
a programming language. Result:
On 3/26/08 9:06 AM, Nick Kew [EMAIL PROTECTED] wrote:
There seems to be a demand for dynamic per-request configuration,
as evidenced by the number of users hacking it with mod_rewrite,
and the other very limited tools available. Modern mod_rewrite
usage commonly looks like programming, but
Akins, Brian wrote:
On 3/26/08 9:06 AM, Nick Kew [EMAIL PROTECTED] wrote:
There seems to be a demand for dynamic per-request configuration,
as evidenced by the number of users hacking it with mod_rewrite,
and the other very limited tools available. Modern mod_rewrite
usage commonly looks
On Wed, 26 Mar 2008 15:39:53 +0200
Issac Goldstand [EMAIL PROTECTED] wrote:
Akins, Brian wrote:
On 3/26/08 9:06 AM, Nick Kew [EMAIL PROTECTED] wrote:
There seems to be a demand for dynamic per-request configuration,
as evidenced by the number of users hacking it with mod_rewrite,
On 3/26/08 9:53 AM, Nick Kew [EMAIL PROTECTED] wrote:
I'm not talking about inventing a new language. Those who want one
have some options already, as noted below ...
Right. I was just throwing it out there, so to speak. I'm not opposed to
what you are saying, just wondering if we
On Wed, 26 Mar 2008 10:15:05 -0400
Akins, Brian [EMAIL PROTECTED] wrote:
As to your suggestion:
So basically, the per_dir merge would use this mechanism instead of
what it does now (file walk, location walk) (or in addition to??)
Something like:
If Directory == /www/stuff and Remote_IP
On 3/26/08 10:31 AM, Nick Kew [EMAIL PROTECTED] wrote:
Straightforward: conditions on headers, method (obsoletes Limit),
request line, env, CGI vars. With the option to disable conditional
stuff for speed.
In mod_include, we parse into a tree on every request. For the
configuration, we
On 3/26/08 12:42 PM, Akins, Brian [EMAIL PROTECTED] wrote:
Thoughts?
Of course, it will not work exactly as I have said because we have to take
stuff like variable substitution into account, etc. Was just thinking out
loud...
--
Brian Akins
Chief Operations Engineer
Turner Digital Media
On Wed, 26 Mar 2008 12:42:51 -0400
Akins, Brian [EMAIL PROTECTED] wrote:
On 3/26/08 10:31 AM, Nick Kew [EMAIL PROTECTED] wrote:
Straightforward: conditions on headers, method (obsoletes Limit),
request line, env, CGI vars. With the option to disable conditional
stuff for speed.
In
On 3/26/08 1:14 PM, Nick Kew [EMAIL PROTECTED] wrote:
we have to parse a string before we have Remote_IP.
Once we have that, sure, our evaluation function can dispatch
to the Remote_IP handler.
Of course. I was getting ahead of my self...
You seem to be looking a little further than my
94 matches
Mail list logo
