httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe Jr." <>
Subject Re: svn commit: r925858 - in /httpd/httpd/branches/2.2.x: CHANGES STATUS docs/manual/mod/core.xml server/config.c
Date Tue, 30 Mar 2010 01:34:44 GMT
On 3/29/2010 7:18 PM, Graham Leggett wrote:
> On 30 Mar 2010, at 1:18 AM, William A. Rowe Jr. wrote:
>>> 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.
> That's because directory wildcards aren't supported in v2.2 at all and
> never were. You cannot claim that functionality that was never there
> somehow affirms a particular behaviour one way or another.

Correct, it doesn't affirm the behavior either way.  It simply says that
no *files* matching the regex pattern are acceptable.  I disagree, but that
is a subject for discussion of trunk, not 2.2, you are absolutely right in
suggesting we won't change this on 2.2, or 2.0 branches.

> The basic fact remains, you thought the default behaviour of the server
> was that a file no-match returned an error, and I too thought that until
> saturday, when I spent a whole lot of time trying to pick apart what was
> going on to resolve your veto. In the light of your original
> understanding, a veto made perfect sense - if a file no-match returned
> failure, then directory no-match should too return failure, to be
> consistent, non confusing for the end user, and to follow the principle
> of least surprise.
> Then it is uncovered that the default behaviour of the server was the
> complete opposite: the default behaviour of v2.2 and trunk is that file
> no-match returns success. And yet you stuck to your guns, even though
> all the reasons that supported your original veto were now reversed. In
> the process, you are now arguing for inconsistent behaviour, that is
> confusing for the end user, and that violates the principle of least
> surprise.

In what universe does the suggestion that path wildcards must correspond
to at least one existing path diverge from the allowance that the path(s)
need not contain one existing file?  Two separate issues, one veto.

I'm sorry you don't support my -1, but am done with your handwaving about
whether the the veto is valid, or not.  It is, and your protestations don't
invalidate it.

>> 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.
> The original patch was contributed to solve a significant amount of real
> actual pain for a large amount of real actual people caused by a hack
> that was put in place on one of the UK's largest web platforms, the
> solution being to remove the hack and to just do the job properly in the
> first place. I am sure all these people will be overjoyed to hear your
> solution to this problem is to just not make this capability available
> on v2.2.

Then they are welcome to use a patched version of httpd; this is the
advantage of open source.  Anyone can use whatever code they like whether
they agree with the 'released' version, or not.  There is a solution on
the table which could satisfy everyone, allowing a missing explicit file,
or file pattern, or directory pattern to match nothing - while making no
change in 2.2 to the Include behavior of allowing file patterns to not
match once the directory pattern has matched.

View raw message