httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From (Ralf S. Engelschall)
Subject Re: \[contrib\] mod_mmap_static.c v0.03
Date Mon, 09 Feb 1998 09:47:59 GMT

In article <> 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

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?

                                       Ralf S. Engelschall

View raw message