httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoffrey Young <>
Subject Re: [PATCH] catching malformed container directives
Date Tue, 09 Dec 2003 22:49:09 GMT

William A. Rowe, Jr. wrote:
> At 09:36 AM 12/9/2003, Geoffrey Young wrote:
>>>André Malo wrote:
>>>>I'd like to keep <IfDefine > possible. Simply because it's a very efficient
>>>>way to comment a whole part out (reliably, since one cannot specify an
>>>>empty -D argument). And it's in use out there.
>>ok, here is a new patch that excludes <IfDefine >.
> Now you have me thinking.  For Apache 2.1 (perhaps 2.0) I'd like to see that
> particular nonsense go away.  I sympathize with André's observation that it's
> useful, but what he wants to do can be accomplished with
> <IfDefine NEVER>
>     DangerousDirective
> </IfDefine>
> which serves the same purpose, but it much more legible.

not to speak for andre, but he pointed out to me on irc that what he was
after was an <IfDefine> that could not be overridden with -D, and I suppose
-DNEVER would expose the config block.  or are you suggesting a literal
"<IfDefine NEVER>" as a special case?  one thing I suggested was perhaps
using <IfDefine 0>, but he pointed out that -D0 works (but -D"" doesn't).
so maybe we can make -D0 not work as well and keep with something that feels
programmatically familiar.

> You point out that containers that expect args (e.g. not <Perl> blocks) can 
> be very difficult to debug in any sort of dynamic (mod_macro) sort of config
> environment. 

that was part of the rationale, yes.  the other being that it just didn't
seem to make sense that the directive arguments were required in the docs
(and in practice) but that illegally formed configs were allowed to pass
without so much as a warning.

> But also consider that many conf rewriting tools could probably 
> crack under the strain of parsing such <IfFoo> containers, if they specify
> no argument.

it must be that it's post-dinner here and I need a rejolt of coffee, but I
don't understand that :)

> On the balance, for 2.1 forward we should disallow <IfDefine >.  It's a coin
> toss to me if we continue to accept them in 2.0 - so I'd argue the principle
> of least surprise.  Disallow in 2.1, but continue to allow in 2.0 <IfDefine >.

either way, my patches were against 2.1, so if the community agrees to 2.1
inclusion then I suppose 2.0 backport gets voted on afterward.

>>also included is a patch (that applies on top of the other one) that fixes
>>broken <Limit> containers.  currently
>><Limit GET
>>does not throw an error (note the missing final '>').
> That would be goodness!


if you'd like that as a separate issue before the <IfFoo > stuff is resolved
(as it's probably less controversial :) I'll whip up a new patch - just let
me know.


View raw message