httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexei Kosut <>
Subject Re: mod_rewrite v2.2-SNAP
Date Tue, 06 Aug 1996 22:36:31 GMT
On Tue, 6 Aug 1996, Ralf S. Engelschall wrote:

> Alexei: I don't know if you are currently looking for inclusion of
>         mod_rewrite, but if so, please first have a look at the current
>         v2.2-SNAP. Now really _ALL ESSENTIAL_ functionality is incorporated
>         into mod_rewrite. I now will start to only fix bugs and problems
>         which you report while trying to include mod_rewrite into 1.2-dev.
>         And if there are no more problems reported by you then I will release
>         v2.2 officially and then this v2.2 release should be the one which
>         gets finally included into 1.2-dev if the other core members give
>         their "+1" for mod_rewrite. So, please take the flag of mod_rewrite
>         and bring it to the core distribution....

Interesting way of putting it... Maybe we do need flags. Actually, the
Apache Group is more of a big game of chess, except no one really knows
the rules.

Anyhow, I took a look at v2.2-SNAP of mod_rewrite. I had to make a slight
change to mod_rewrite.h to get it to compile:

*** mod_rewrite.h.orig  Tue Aug  6 14:54:05 1996
--- mod_rewrite.h       Tue Aug  6 14:39:27 1996
*** 145,151 ****
--- 145,155 ----
  typedef struct {
      char   *input;                 /* Input string of RewriteCond */
      char   *pattern;               /* the RegExp pattern string */
+     regex_t *regexp;
+ #else
      regexp *regexp;                /* the RegExp pattern compilation */
+ #endif
      int     flags;                 /* Flags which control the match */
  } rewritecond_entry;

Once that change is made, it compiles fine, and seems to work. I only
tested the most basic of functionality; a couple of RewriteRules, but that
seems to work.

A qualifier, though: I find the behavior of RewriteRule in .htaccess
files, while somewhat consistent, rather confusing, and just plain Wrong
in cases. Here's what it does, as near as I can tell (this is based on
behavior, not on the code):

It takes the filename (not the URI, as RewriteRule in server config
files do), and strips off part of it. If the document is with the
documentroot, it strips off just that, else it strips off everything. In
other words, if /www/htdocs is the DocumentRoot, and you have an .htaccess
file in /www/htdocs/abc, it strips of "/www/htdocs/" from the front. If
you have a filename in /abc/def, it strips off "/abc/def/" from the front.

If it then matches, it takes the substituted string, and adds back on what
it took off. It then tries to issue an internal redirect to that string.
in other words, if in /abc/def/.htaccess, I have "RewriteRule ^one two",
it will issue an internal redirect to the URL /abc/def/two. This is
entirely wrong. 100%. Let's say I had "Alias /xyz /abc/def" in my config
files. There is no url /abc/def/two. It should issue an internal redirect
to /xyz/two.

The proper behavior here, as I've said before, is to never look at what
r->filename is. Always look at r->uri. And don't do any stripping. People
should know what their URLs are. So I can put "RewriteRule ^/abc/one
/abc/two", and all will work as expected. Then all you need to do is say
that RewriteRules in .htaccess files resolve to URLs instead of
filenames, and everyone is happy. Or, even better, you could in fact make
the rewritten target a filename. Just run sub_req_lookup_file on the name,
and if it passes, pull out all the pertinent info (filename, args, finfo,
content_*, handler), stick it into the request_rec, and return OK. That
might work. Although it could also cause problems. It might be better to
stick with the internal redirect method.

Regardless, I'm quite sure the current behavior is wrong.


-- Alexei Kosut <>            The Apache HTTP Server

View raw message