On Fri, Jan 07, 2000 at 03:05:58AM +0200, Eli Marmor wrote:
> > > need to load and parse htaccess files (sometimes even per request),
> >
> > I'm no expert in web servers, but this looks strange to me. Could
> > you explain why there isn't some way for a user to signal the server
> > that he had changed his .htaccess file?
>
> This is not the only problem. The main problem is the inability to
> guess what directories to read. Sometimes, there are 10 levels of
> directories under htdocs and 20 sub-directories per each directory;
> Should we read 20^10 directories, just because somebody may want to
> access them later? And what if there are hundreds of users with home
> directories (or sub-directories, more exactly) which are accessible by
> the web server?
Are we better off reading one extra file per request? I guess this
question may only be answered if we can estimate how often users
edit their .htaccess files.
> > If this is really such a
> > bottleneck, we can (it seems to me) change the semantics a bit and
> > put the responsibility on the users' side.
>
> It is already done. All the Apache books recommend the users to avoid
> htaccess, for better performance, unless there is no other way (for
> example, in virtual web hosting, it's usually impossible to let
> anybody access the main httpd.conf).
But this kind of solution is saying "we've got this feature, but
don't use it". What happens if we _do_ need this feature (as in
virtual hosting)?
My question is whether functionality may be maintained for this
feature - but at the same time, with less cost. My *guess* is that
it can, but (as I said) I'm no expert in this field, so I may be
missing something important.
> > (In case I haven't made myself clear, I mean something like asking
> > users to kill -1 the server after every time they modify their
> > htaccess. I realize they can't do that themselves, but surely there
> > is some sort of mechanism to deploy here that's cheaper than
> > what you describe above.)
>
> Apache already supports the "kill -HUP" for re-reading the
> configuration files, but as I already wrote, it can't solve the
> problem of htaccess.
I know - I said that, too. (Not only can users not edit the main
conf file: they can't send signals to apache, as well.)
What about a utility for updating the apache configuration? What
I have in mind is something that can be asked to recompile .htaccess
for an explicitly given subdirectory, OR for the whole site. This
proposed utility builds all the information into some binary
representation, and then shoves the new configuration (shared mem,
pipes, whatever) down to the server process(es).
This increases complexity of Apache, granted, but *if* the
bottlenecks are indeed large (and again, I plead ignorance about
this bit) it might be worth it. I think that for the user, it
won't be too difficult to learn, either.
--
believing is seeing
[EMAIL PROTECTED]
http://www.forum2.org/gaal/
=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
