mod_rewrite v2.2-SNAP

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

I don't know what the official status of inclusion of mod_rewrite into Apache
1.2-dev is. I think Alexei has this task on his side, but their were no "+1"
or "-1" votes for v2.1 to be included into the core distribution. 

Because of this still waiting decision, I couldn't sleep deeply last night
;-), because the currently released mod_rewrite v2.1 is good, yes. Good
enough I think to be included into the core distribution. But it had one(!)
feature (a lot of people wanted in the past) still not included, because I
thought it would be to hard to incorporate it into v2.1. So yesterday I
officially released v2.1 with this feature left on my TODO-List.

Today, I did a brainstorming again and realized that it is actually much
simpler to add as I thought in the past. Ok, long words, tiny semantics:

       mod_rewrite v2.2-SNAP now contains RULE PRECONDITIONS!

Hu? What's that? Let me show you an example of a possible .htaccess file:

  RewriteCond   %{HTTP_USER_AGENT}  ^Mozilla/3.*
  RewriteRule   ^testfile\.html$    testfile.max.html   [L]

  RewriteCond   %{HTTP_USER_AGENT}  ^Lynx.*             
  RewriteRule   ^testfile\.html$    testfile.min.html   [L]

  RewriteRule   ^testfile\.html$    testfile.std.html   [L]

With this (and without any CGI-stuff ;-) you can just rewrite a request to
.../somedir/testfile.html (assuming your .htaccess file was in "somedir" for
this example) depend of the Browser type. This is the standard example which
was wanted a lot by the users of mod_rewrite.

There is another real-world example, which come to my mind while I'm writing
this:

  RewriteCond   %{REMOTE_IDENT}@%{REMOTE_HOST}  ^rse@en2\.engelschall\.com$
  RewriteRule   ^service\.cgi                   service-admin.cgi       [L]

  RewriteRule   ^service\.cgi                   service-user.cgi   [L]

etc. pp.

For more information just read the updated documentation in
http://www.engelschall.com/sw/mod_rewrite/arc/mod_rewrite-SNAP/mod_rewrite.html
There is a wide range of more possible rewriting tricks, because I have
created a lot of %{...} variables. With them you can do a lot of useful and a
lot of silly rewriting stuff...

BTW: v2.2-SNAP has another nice flag for RewriteRule now: skip|S=<n>
     which forces the rewriting engine to skip the next <n> rules if the
     current one matched. With this you can setup pseudo if-then-else clauses
     instead of the above "if match then end" examples. I added this flag to
     make the RewriteCond feature more useful.

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....

Greetings,
                                        Ralf S. Engelschall    
                                        rse@engelschall.com
                                        http://www.engelschall.com/~rse

Re: mod_rewrite v2.2-SNAP

[Alexei Kosut <ak...@organic.com>]

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 */
+ #ifdef HAVE_INTERNAL_REGEX
+     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.

Thanks.

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