httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexei Kosut <ako...@organic.com>
Subject Re: URI->filename and mod_alias
Date Mon, 29 Jul 1996 21:09:12 GMT
On Mon, 29 Jul 1996, Ralf S. Engelschall wrote:

> > No, mod_alias operates correctly.
> 
> Corectly, yes. But not if we want more than one URI-to-filename translator to
> work together to make the URI-to-filename transistion together!

Hmm. Well, it's a URI to filename translating phase. What you're talking
about is more of a filename to filename phase, or a URI to URI phase.
Maybe we need to extend the API to allow such a thing. But having the
modules use r->filename as the "URI" seems to me defenitely the wrong
solution.

> > mod_rewrite currently looks at the filename it translates, and tries to
> > figure out if it's a real file or not. It shouldn't do this, IMO. Not only
> > does it do a lot of stats (which can slow a server down, sometimes
> > drastically), it can also cause confusing behavior. If it finds a match,
> > it should return OK - it shouldn't check to see if the file exists, that's
> > the handler's job. Remember that a module later on down the line could
> > actually create those missing directories and files (a PUT handler, for
> > example), or may do something else entirely, like a database lookup or who
> > knows what. mod_rewrite should operate on blind faith that it did the
> > right thing. If it finds a match; any match; it should return OK,
> > otherwise DECLINED.
> 
> Hmmm.. yes and no! It earlier versions of mod_rewrite I just did that!  I
> rewrite it and returned OK or DECLINED. But this didn't work. The server
> dumped core. Ok, this was 1.1b0 or such a beast, but I think is still there.

Hmm. This sounds odd. I suggest you try it again. It should most
defenitely work.

> After discovering this problem I looked at the other modules and found that
> r->finfo and r->filename really need some very carefully choosen value to get
> the other stuff of Apache working clean. Ok, if I'm wrong, then there are
> some questions open:

Well, look at core_translate(), or mod_alias. They don't do any stats,
they don't touch r->finfo, they just tack on r->filename and return OK.
The code in http_request.c is responsible for determining if the filename
is valid, and performing stats.

> 1. If any URI-to-filename translator only should look at r->uri and
>    set r->filename if something matched for him, this prevents more than one
>    URI-to-filename translator working. Because this assumes that all
>    URI-to-filename translators really translate the URI to filename once and
>    finally. There is then no chance to do some Rewritings via mod_rewrite,
>    then a final rewrite by mod_alias, etc. If another module, which wants to
>    use the URI-to-filename hook, arrives, It either has to do the whole
>    URI-to-filename transistion itself or cannot do anything.  THIS IS THE
>    POINT!

See above. That's what the phase is intended to do. A filename-to-filename
translation phase might not be a bad idea. Someone should put it in the
2.0 pile.

> 2. With the current operation (i.e. everys URI-to-filename translator either
>    does the transistion from r->uri to r->filename or does nothing) we are
>    never be able to do anything like RewriteRule ^/someurl  somenewurl Alias
>    somenewurl someofile or any other combination of directives from two
>    URI-to-filename- hook-based modules.

Yes.

> 3. Why does mod_userdir do a stat() to r->finfo in its URI-to-filename hook.
>    According to your description, this is also wrong!

Um... er... yeah. It does. However, that's a "feature". Namely, if you put
in more than one entry, it will look to see if they exist, i.e.

UserDir public_html /home/web

will first look for a ~username/public_html directory, then look in
/home/web/username. But it always returns OK with the final value, even if
it didn't match.

I suppose I wouldn't mind, for example, an "E" flag in RewriteRule that
means "only use this if the directory exists". But it shouldn't be the
default.

[...]

> I don't see why this should cause some configs to break, because 

Watch:

UserDir /home/*/www
Alias /home /www/Home

This very obviously causes a request for /~user/foo to go to
/home/user/www/foo, and a request for /home/foo to go to /www/Home/foo.

Now, pretend mod_userdir and mod_alias work as you claim they "should".
Then suddenly a request for /~user/foo would go to /www/Home/user/www/foo.
Not good.

-- Alexei Kosut <akosut@organic.com>            The Apache HTTP Server 
   http://www.nueva.pvt.k12.ca.us/~akosut/      http://www.apache.org/


Mime
View raw message