Re: \[contrib\] mod_mmap_static.c v0.03

["Ralf S. Engelschall" <rs...@engelschall.com>]

In article <Pi...@twinlark.arctic.org> you wrote:

> Hey Ralf why does mod_rewrite do this?

>     /* if filename was not initially set,
>      * we start with the requested URI
>      */
>     if (r->filename == NULL) {
>         r->filename = pstrdup(r->pool, r->uri);
>         rewritelog(r, 2, "init rewrite engine with requested uri %s",
>                    r->filename);
>     }
> ?

> I didn't expect r->filename to be set at this point, especially when no
> RewriteRule was matched. 

This is because the current API only supports a uri-to-filename phase.  So
mod_rewrite has to rewrite to r->filename even if it does a uri-to-uri
rewriting or nothing. So, in the early discussions on how we can write a
mod_rewrite with the current API we decided to let mod_rewrite operate on
r->filename (because r->uri is totally incorrect and only leads to problems).
And because mod_rewrite has to start with anything it pre-initialised
r->filename. 

The r->filename in the past seemed to us as the best choice for the rewriting.
So the engine is entirely based on it. When we have a uri-to-uri and
filename-to-filename API phase in Apache 2.0 the current mod_rewrite is the
handler for filename-to-filename and for the other two (u2u, u2f) mod_rewrite
has to be expanded.

Or in short: Because of the current API mod_rewrite runs as a u2u, u2f and f2f
handler logically but runs as a u2f handler physically because this was the
best compromise. 

I dislike this, too. But its the best we can do currently, I think to be open
for the future. And we have not discovered any side-effects of this approach,
haven't we?

Greetings,
                                       Ralf S. Engelschall
                                       rse@engelschall.com
                                       www.engelschall.com

Re: \[contrib\] mod_mmap_static.c v0.03

[Dean Gaudet <dg...@arctic.org>]

On Mon, 9 Feb 1998, Ralf S. Engelschall wrote:

> I dislike this, too. But its the best we can do currently, I think to be open
> for the future. And we have not discovered any side-effects of this approach,
> haven't we?

No I was just surprised by it... I was assuming that if r->filename !=
NULL then it was a valid filename... but that's not always the case.  In
all phases after translate_name you can test (r->finfo.st_mode != 0) to
discover if it's a valid filename and the file exists.  But there's no way
to ask "is this supposed to be a filename?"

Doesn't matter, I worked around my need for that.

Dean