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 t
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 nex
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 goo
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 auth
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.
>> 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 release? I wouldn't mind pushing that along
>> and get some of the feature-
On Thu, 03 Apr 2008 11:13:31 -0500
"William A. Rowe, Jr." <[EMAIL PROTECTED]> wrote:
> The hope. Those admins who refuse to let their junior admins use that
> directive should have a level of control over their outward facing
> heavily-loaded machines :)
The logic is approximately cloned from ,
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 mod_rew
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
Nick Kew wrote:
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 thrown
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 inevita
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
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
On Thu, 03 Apr 2008 11:22:00 -0400
"Akins, Brian" <[EMAIL PROTECTED]> wrote:
>
> DocumentRoot /www/cnn
> ServerAdmin [EMAIL PROTECTED]
> etc
That basically comes out of what I committed this morning.
Well, up to a point: it only applies to the per-dir config.
> Maybe no need fo
On 4/3/08 11:38 AM, "William A. Rowe, Jr." <[EMAIL PROTECTED]> wrote:
>>
>> ...
>>
>
> 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:
parse_provider *prov;
void
On Thu, 03 Apr 2008 11:25:56 -0400
"Akins, Brian" <[EMAIL PROTECTED]> wrote:
> On 4/3/08 10:47 AM, "William A. Rowe, Jr." <[EMAIL PROTECTED]>
> wrote:
>
> > I'll commit the
>
>
> ...
>
May work already (not tested) if Rewrite is active
(so method is available as an env var). Certainly
on th
Akins, Brian wrote:
On 4/3/08 10:47 AM, "William A. Rowe, Jr." <[EMAIL PROTECTED]> wrote:
I'll commit the
...
Slow
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
On 4/3/08 10:47 AM, "William A. Rowe, Jr." <[EMAIL PROTECTED]> wrote:
> I'll commit the
...
;)
--
Brian Akins
Chief Operations Engineer
Turner Digital Media Technologies
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_conf
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:
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
> mu
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 effectively
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 warran
> -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 dis
>>> 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 d
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
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 :)
> ... 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
> whe
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 simpler-to-
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 represe
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 n
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
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
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 w
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
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, womba
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 rememb
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
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 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:
>>
>>
>> #cnn specific stuff here...
>> DocumentRoot /htdocs/cnn
>> CutomLog "|/usr/bin/logger cnn" my_
On Tue 01 Apr 2008, Akins, Brian wrote:
> In pseudo config, like niq is suggesting, you could have something like:
>
>
> #cnn specific stuff here...
> DocumentRoot /htdocs/cnn
> CutomLog "|/usr/bin/logger cnn" my_format
> ErrorLog /var/log/cnn.error
>
I don't like that. I think there
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
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 t
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
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 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
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
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 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 select
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
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
Covalent/SpringSo
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
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
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 th
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
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 wo
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 cases,
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
blocks...
those blocks can be trivially implemented as a loadable module ;-)
As I grok it, the point
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 o
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
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 extens
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
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 blocks as modular
behaviors... I've noticed a trend i
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'.
Torsten Foertsch wrote:
On Tue 01 Apr 2008, Paul Querna wrote:
William A. Rowe, Jr. wrote:
-0.99 - agreed. Perl is perfectly happy having 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
On Tue 01 Apr 2008, Paul Querna wrote:
> William A. Rowe, Jr. wrote:
> > -0.99 - agreed. Perl is perfectly happy having 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
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 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 entire
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.
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 mod_r
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 blocks...
thos
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 othe
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 availabl
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
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 langua
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 availabl
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 tha
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 disa
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
u
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 lightweigh
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 l
On 3/27/08 9:00 AM, "Nick Kew" <[EMAIL PROTECTED]> wrote:
> /Lua>
>
> Fine for users who want to hack their own server. Like .
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
>
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 lightweigh
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 of
the url mapping/rewriting can be simple lua statements.
if string.match(r
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 8:58
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
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 tha
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 ),
> > request line, env, CGI vars. With the option to disable conditional
> > stuff for speed
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 Med
On 3/26/08 10:31 AM, "Nick Kew" <[EMAIL PROTECTED]> wrote:
> Straightforward: conditions on headers, method (obsoletes ),
> 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 sh
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:
>
>
> SetEnv coolstuff
>
>
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 wo
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
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 look
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
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: confuse
96 matches
Mail list logo
