httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Laurie <>
Subject Re: more wacky A2 ideas
Date Sun, 03 Jan 1999 19:43:48 GMT
Alexei Kosut wrote:
> On Sun, 3 Jan 1999, Ben Laurie wrote:
> > Hmmm ... perhaps I'm missing the point here, but wouldn't the point of
> > an LRI be that it actually identified a resource, including, of course,
> > a file. So I'd imagine that an LRI that referred to a file would looks
> > something like "file:/a/b/c". Then a <Directory /x/y/z> directive maps
> > neatly on to the (new) <LRI file:/x/y/z/.*> directive... and so on.
> Probably. The problem I was thinking of was specifically htaccess files,
> and a few others, which can't be solved in a generic manner.

I don't understand why htaccess can't be solved in a generic manner? I
suppose you mean it can't be solved for non-hierarchical resources?
However, files are not the only example of hierarchical resources.
Access control can be solved for non-hierarchical resources, of course,
but not in a way that relies on hierarchy. So, I contend that htaccess
as we know it is something that only makes sense on a hierarchical
resource. So it isn't a problem (but it does imply that we need to know
whether a resource is hierarchical).

> > So "file:" LRIs do have some special properties (e.g. they know about
> > symlinks) but they also have general ones ("directories").
> Right. What I was referring to is that the same properties that the file
> data store has to deal with, the CGI data store does as well, etc...; how
> to produce all current Apache functionality with a model that knows
> nothing about files does present some issues.

I'm obviously missing something - clearly _something_ knows about files.
All we need to do (All? Hah!) is push the file-dependent stuff down into
the file module (which is where it belongs anyway, right?).

> Especially if you want to promote other backing systems to the same level
> as filesystems. i.e., if several data store modules are based on access to
> an Oracle database, and that database is set up with certain properties,
> e.g., the equivilent of file permissions, htaccess files, whichever, there
> should be some way of sharing that code between data stores. The obvious
> way to do that is just to have them both call the same functions, in a
> library or something. Which is why I suggested doing it the same way for a
> filesystem.

There are two aspects to htaccess which need to be separated, IMO - what
they contain (i.e. configuration stuff) and which ones we use (see
above). Clearly configuration stuff can be handled by the general
configuration machinery. Which ones we use is an (the?) interesting

> > Now the thing that exercises me is that LRIs may, in theory, map on to
> > each other in mysterious ways. For example, URI:/x/y maps to
> > LRI:sandwich:/a/b/y which maps to the concatenation of
> > LRI:file:/a/b/header, LRI:file:/a/b/y, LRI:file:/a/b/footer. So what's
> > the problem? Perhaps none, but at what points do the configuration rules
> > apply in all this? Will configuring/debugging something like this drive
> > everyone mad? Or will some kind of beautiful elegance drop out of the
> > bottom?
> I hope so. Simon was claiming he had some brilliant ideas on how to do
> configuration for all this, but we haven't heard from him recently :)
> I would say that "maps to the concatenation of" is probably not a function
> of the server, but of a data store. i.e., a 'cat' data store module might
> take a list of other LRIs, which it included (via a sub-request-like
> mechanism).

Yes, that's what I meant, too (at least, I did by the end of my mail).

> An LRI, as I envision it, is the name of a data store module, an opaque
> string to pass to that module, and a list of filters (with opaque strings
> on those two) to apply to the output of the data store. That's
> possibly simple enough to configure:
> URI-to-LRI ^/imagemaps/(.*) file-data-store("$1") imap-filter("CERN")
> URI-to-LRI ^/html(.*) file-data-store("/usr/www/htdocs$1")

I find the lack of slashes here disconcerting. Was it deliberate?

> <LRI file-data-store *>
> AddHandler server-side-includes shtml

Bong! shtml is an extension, but * matches an opaque string, no? Or is
it sufficiently unopaque that we are going to believe in "extensions"?

> AddFilterToLRIByHandler server-side-includes includes-filter()
> </LRI>
> Or something.




"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
     - Indira Ghandi

View raw message