On 2011-08-15 16:37, Pete Houston wrote:
On Mon, Aug 15, 2011 at 10:16:29AM -0400, Ben Timby wrote:In the above way, the administrator could delegate control of portions of the configuration to a user without the overhead of an .htaccess file. Also, you could include a file which in turn includes other files. Thus, the administrator could delegate via httpd.conf a config file to the user which in turn could delegate to a set of files. This would give you localized management in a set of files.There are two problems with this which I can see. Firstly, from the web server manager's point of view this is a bad idea, because all it would take would be for the user to construct a conf file with a syntax error and the whole server is taken down. Too much of a risk on a shared server. Secondly, from the user's point of view, they make their change to the conf file, but it will only become active when the server is restarted to pick up the changes, so probably daily or worse weekly. With a .htaccess file the changes are instantaneous.
True, as far as it goes.However, while there is no way to limit what an Include file contains, you can restrict what users are allowed to put in htaccess files. This coincides with what you're describing in that changes to Include files should be tested before restarting apache with apachectl configtest, and disabling or (re)moving offending Include files.
This would be the responsibility of the server admin.The use of htaccess files can be quite wide-ranging but it doesn't have to be, and the depth of manipulation the OP wanted to achieve is best split up between these two mechanisms.
Moreover, he obviously wasn't allowing end-users to manipulate htaccess files at all, as he explicitly stated this was a fix for an "inconvenience" in configuration differences between development and production. Both of these are the server admin's responsibility, and one assumes that the server admin is paying attention when deploying new configurations to production.
So, while it's nice in theory, there are practicalities which mean that it is unlikely to happen in a shared server scenario.
In a shared HOSTING environment, you're absolutely correct.The OPs stated goal had nothing to do with shared hosting, although he generalized the request to extend that far.
Perhaps I should have made more plain that I am in no way claiming this feature - or any feature - should not be implemented, or discussed; I am not an apache developer so I wouldn't have much to say about it one way or the other. That's not at all my point - my point was that HIS goal does not need any kind of new feature implementation.
-- J. --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|