httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <>
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 00:18:58 GMT
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.

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.

> 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.


View raw message