httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Howard Fear <>
Subject Re: Let's get rid of .htaccess files :-)
Date Thu, 18 Jul 1996 18:28:37 GMT
Here's my 2 cents worth (although given my level of contribution it
may only be worth 1/2 cents).

Randy Terbush writes:
> One of my goals in this was to move the .htaccess files out of the
> webspace to improve security and prevent corruption of these files.
> Secondly, by creating a standard format like this, it would make it
> very easy to write configuration interfaces. By creating a separate
> conf/ tree, we reduce the depth of directories we need to search.

But, this is exactly the problem.  There are at least two general
philosophies to 'webspace': the web as a filesystem, and the web
as an interface to files in the underlying file system.  For the
internet, the first view is prevelant, but for intranets, I suspect
the second is.  I've worked on a couple of servers where almost
nothing is in the htodcs directories.  Most (if not all) of the
data is accessed through ~user.  (Many of which are actually automounted
from somewhere else.)

We also should preserve the distinction between server configuration
and 'file' configuration.  The former should not only have limited
access, but also limited visibility.  It also, probably, causes
a server restart.  The second should be available to all users
(for their files) and shouldn't (mustn't) cause server restarts.

To address speed issues, I'd second rasmus's suggestion of caching
possibly processed configuration files.

> You would only need to parse the tree at startup and SIGHUP.
> It would be very easy to have a separate daemon watching the
> conf/ for changes and sending a SIGHUP when needed.

I don't see the need for this.  And, I think this is a real problem
if you're going to let your users control the configuration of their
own files.  (This may not generally be the case for commercial
web servers, but is certainly desireable for intranets.)

> My suggestion that you could point conf/ at the DocumentRoot was
> really only for backward compatibility and perhaps a mode that
> would allow you to easily build a conf/ from the existing webspace.

If you're going to provide an interface for managing file attributes,
it should be available for ~user urls as well.  Perhaps even more
so, given that server admins are likely to be much more comfortable
with configuration files than normal users.

Here's how I perceive the requirements:
    1) interface to the server configuration for admin.
        - causes restarts when necessary
        - limited accessability which can be provided by a server-wide
          <LOCATION> or .htaccess in the root directory.

    2) general interface for directory/file attributes
        - accessability managed within itself
        - accessed through, perhaps, a magic file name or type

    3) data presentation
        - user sees the local configuration and the inherited
          configuration as separate items.
        - Items are presented in a natural format, i.e choices
          show up as a menu, on/off choices show up as checkboxes,
        - User input is validated before being installed with
          feedback as appropriate
        - Some form of configurable template should be supported.

I think this does have some implications:
    - Configuration data is accumulated into a single ascii table
      in order to be easily accessable to a conf module.
    - It will be easier to use some form of file specific configuration
      file instead of the directories .htaccess.  Otherwise, you raise
      all sorts of information about keeping the .htaccess correctly.
    - The configuration information is generated by reading the 
      file specific configuration file.
    - Validation gets separated from merge.
    - The module interface is changed to support returning some form
      of possible values.  You might even add some magic regular
      expression things like filenames, urls, and so forth.
    - The module interface also must return whether a single value
      or multiple values are valid.  (And may also have to support
      some indication of whether the values are merged with the
      environment or replace them.)
    - You may want to support some form of hide directive that
      hides certain configuration directives from lower level

Overall, I think that this kind of strategy would result in a much
more capable (and flexible) configuration facility.

Howard Fear      email1:

View raw message