[prev in list] [next in list] [prev in thread] [next in thread] 

List:       apache-httpd-dev
Subject:    Re: [PATCH] catching malformed container directives
From:       Geoffrey Young <geoff () modperlcookbook ! org>
Date:       2003-12-21 19:11:58
[Download RAW message or body]

hi all

just following up on this to see if the interested parties have given the
issue any more thought.  if there is still some dis-harmony around the
<IfDefine > case then I'm happy to keep posting alternatives until a
solution is reached that everyone can live with.

otherwise, if there isn't sufficient interest in changing the current
(somewhat broken) core container args parsing, I'll just lop it off of my
todo list.

--Geoff

(current patch viewable from
http://nagoya.apache.org/bugzilla/showattachment.cgi?attach_id=9526)


Geoffrey Young wrote:
>>>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.
> 
> 
> yet another try :)
> 
> this patch makes 'httpd -D0' invalid, thus making <IfDefine 0> a special
> define case that is guaranteed to evaluate to false.  the rest remains as
> before - arguments are enforced across all containers.
> 
> it actually feels a bit strange to fail the command line args without some
> kind of message, so I suppose it might be wiser to implement this in core.c
> instead, tossing an error message to the error_log if "0" is both caught and
> defined.  but for the moment I guess I'm just seeing if the idea is
> appealing, after which the implementation can be adjusted as required.
> 
> --Geoff

[prev in list] [next in list] [prev in thread] [next in thread]