httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe Jr." <wr...@rowe-clan.net>
Subject Re: svn commit: r925858 - in /httpd/httpd/branches/2.2.x: CHANGES STATUS docs/manual/mod/core.xml server/config.c
Date Mon, 29 Mar 2010 23:18:18 GMT
On 3/29/2010 5:59 PM, Graham Leggett wrote:
> On 30 Mar 2010, at 12:32 AM, William A. Rowe Jr. wrote:
> 
>> You are persisting in looking at the code.  The problem is not _code_.
>>
>> The _users_ do not expect Include /etc/htppd*/*.conf to succeed,
>> therefore
>> your suggested solution isn't acceptable.  The veto for backporting this
>> broken behavior to 2.2 stands.
> 
> 
> Quoting your own mail:
> 
> "If you believe the feature is necessary, introduce a NEW unambiguous
> feature
> instead of overloading.  E.g. "IncludeOptional /optional/include" for
> allowing
> the include to fail."
> 
> As it turns out that the optional behaviour is the current default
> behaviour, and because you were not aware of this when you made your
> suggestion above, it is necessary for the option to become IncludeStrict
> instead of IncludeOptional.

The default behavior of -trunk-.  Right now, nobody has voted that trunk is
in an appropriate state for general availability.  The default behavior of
2.2 is that only filename wildcards are allowed to not-match.  And by adding
a new IncludeOptional or similarly named directive, experienced users would
be able to relax the requirements to directory names, while we would be able
to enforce the matching of even one filename for the less expert user.

>From a user perspective, this is a better design that would improve the next
httpd release from the 2.2 release, which is always a good thing.  This would
enforce the principal of least surprise.

> Despite your veto being invalid for the reasons already stated, I have
> gone out of my way in good faith to implement your suggestion above and
> give end users the choice of behaviour you believe end users should
> have, in a form that can be backported to v2.2.

No, you haven't; you have inflicted your desire of a new feature in such a way
that the typical user will be confused, and would be disrupted by their own
fat fingers in such a way as they would not be able to decipher the reason for
this failure without re-reading and fully comprehending their configuration
character-by-character, something I watch users fail at on a weekly basis.



Mime
View raw message