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 Tue, 23 Mar 2010 22:33:40 GMT
On 3/23/2010 5:10 PM, Graham Leggett wrote:
> On 21 Mar 2010, at 10:14 PM, William A. Rowe Jr. wrote:
> 
>> 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.
> 
> In the wild I see that pattern all the time, a configuration directory
> containing some equivalent of empty.conf, to work around this
> limitation. Without this empty.conf file, you run the opposite risk -
> someone removing the last config file from a directory, and the server
> suddenly stops working without warning.

Whoa.  There is a warning.  ./apachectl yells, ./apachectl -t yells, even
bootup service logs yell  (Starting httpd... [FAILED] or similar).  That
is not a description of 'without warning'.

Without warning means things start up, without their config changes, and
zero hint why their config changes are not taking effect.  They are given
no reason to suspect that their miskeyed Include ... pattern is not working.

Explain to me where the warning is for missing configuration files in the
current backport?  [Yes, accepting it was never there for conf/host-*.conf
style patterns, not accepting this was a good thing.]

So there is an opposite risk, one which clearly identifies the line number
and config file which has a newly introduced flaw.  I won't accept that
the last file magically 'disappearing' is an acceptable thing to permit,
if something has disappeared I then expect httpd to alert!!!

> In our case, web applications
> are packaged as RPMs, so it's entirely possible for a directory to
> become empty without warning when an RPM is uninstalled.

and that is entirely correct because, I would presume, that config template
is of the package that consumed the empty directory, e.g. some binaries,
modules or other scripts that depended on the config in such a tree.  Right?

RPM must have a some 'hands of' mechanism to deposit a file for good, no?
You wouldn't remove such a directory (along with its 'empty' file?) if you
mean for it to go away?

And if an installer has gone and mucked with a config file, it aught to
be un-mucking that config on the way out the door.

Essentially, you are asking for this feature to make one case, package
installers, work in a brainless fashion; I'm pointing out you can't be
hacking httpd in such a way to cripple the feature present for those who
are using httpd with a brain (or half-brained, where they've introduced
a typo into their path name).

> As a result, enforcing no-match == fail doesn't buy you anything at all.

What?  Yes, it buys confirmation that a file was processed when httpd is
explicitly told to process a file.

> I don't have strong opinions either way, the empty.conf directorie in
> our case are already present, so changing this isn't too much of a
> problem - I just need to get some sleep first.

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.


Mime
View raw message