On 28 Mar 2010, at 9:44 PM, William A. Rowe Jr. wrote:
Right, so something does vary between 2.2, and the patched behavior.
It introduces new mechanisms to introduce typos into a working config,
more complex typos that previously would have failed.
The patch does no such thing - it moves the "fnmatch" loop that in the
past considered files only to now consider directories as well as
files. The patch makes no attempt whatsoever to change the existing
behaviour of fnmatch at all, it respects the behaviour that is already
there. Nor should the patch have attempted to make any change in
behaviour: one patch, one change.
I strongly object to any difference in behaviour between directories
and files (as in, I would -1 it). If a files-no-match returns a
failure, then a directories-no-match must return a failure. If files-
no-match returns ignore, then directories-no-match should too return
ignore. To do otherwise would introduce genuine confusion about the
arbitrary inconsistency: pick one, or the other, not both.
Your technical justification you have provided is as follows:
"No-match of a wildcard must result in an error. If you are arguing
that httpd
should allow the admin to create conf/vhosts/*, only populated if they
are created,
then I'll counter that would be fine, just populate conf/vhosts/
empty.conf with no
lines, the error would go away, and supporting no-matches is never
necessary. This
must be true of both file and directory patterns to prevent users from
experiencing
unnecessary frustration over their own fat fingers."
Given that the risk you've given (unnecessary frustration over their
own fat fingers) exists right now and has for some time, and the fact
that nobody has complained of this risk to date[1], I argue that the
risk you've highlighted doesn't exist, and that therefore the
behaviour you want isn't justified. Trying to veto feature A because
it does not also introduce new-and-unrelated feature B is not a valid
justification for a veto. Argue for feature B on it's own merit, and
patch it separately if necessary.
[1] If this was a genuine problem, we would have been alerted to it,
and we would all have known that no-match is ignored.
Regards,
Graham
--
