Maybe it's best to backup and clarify your goals for IIRF. One main purpose would be to supply a capable URL rewriter ISAPI filter, which IIRF does well. A different goal would be to supply a functional equivalent to Apache's mod_rewrite function,
to which IIRF is about 75-85% there. If you don't care about the latter, a lot of my questions don't matter.
Please don't take that as an opinion that that's what IIRF should be. But I think a lot of people (including myself) are using IIRF to enable porting a web application from Apache to IIS. In my case it's Wordpress MU, which works 99% fine
on IIS except for requiring mod_rewrite and utilizing the missing REQUEST_URI server variable. IIRF can certainly be used to to solve both issues (and it's not even that difficult), but it's not simply install and forget. I don't think most people
would delve into it as far as I have to find a solution. IIS Mod-Rewrite and IIS ISAPI_Rewrite I think more explicitly try to be mod_rewrite functional equivalents (at least the full versions), so require less modifications to a migrated web app when used.
That said, I prefer IIRF because it's more open and transparent. Most of the mod_rewrite equivalencies that I'm pointing out are pretty minor, with one exception:
- Rewritebase - which you've mostly implemented once I can get 188.8.131.52 to work. Only shortcoming at this point is that it doesn't accept arguments, which I completely understand your reasoning for. 99% of the time I think Apache's mod_rewrite
will work exactly as you are saying, which is why I think that it might be useful to accept an argument and just ignore it (i.e. interpret it as equal to "ON"). That would work perfectly for Wordpress MU.
- RedirectRule - I totally get your reasoning here as well, and I think you should leave it as is. However, would it make sense to allow both forms? Strictly for mod_rewrite compatibility? So you could do:
RedirectRule ^/Wookie/(.*)$ http://wookie.example.org/$1 [R=301]
RewriteRule ^/Wookie/(.*)$ http://wookie.example.org/$1 [R=301,L]
and they'd be functionally equivalent. The first would be preferred if you were writing your own rules, but the second would allow for simple apache to IIS migrations
- missing REQUEST_URI - Ok, this is an IIS problem, not IIRF's, but IIRF can help solve it. I'd propose a Global option in GlobalIIRF.ini for a populateOrig_Request ON|OFF (there's probably a better name). If on it would have IIRF *always* populate
HTTP_X_REQUEST_URI with SCRIPT_NAME?QUERY_STRING (or a better equivalent for the originally requested URI). I think it's fairly simple, and it would be useful for those migrating apps from Apache.
- per level rules in .htaccess files - Again I totally agree with your reasoning above. Rules should be set at the vdir level, not at the directory level, it makes sense. However that's not the way mod_rewrite works (most likely simply because
the .htaccess files are typically already there, and they're simply reusing them). In this case though, it's a big change and would take tons of work, and I totally agree it would not be worth the effort just to achieve functional equivalency.
Plus, it's fairly easy to explain to people to just copy and paste the rules out of .htaccess and into iirf.ini. So I would totally agree that you should leave this one alone.
BTW, thanks for the support and your patience, I'm bombarding you with suggestions because I really like the filter, and would like to see it become more popular than ISAPI Rewrite or IIS Mod-Rewrite. I think it easily could be with a little more direct
migration documentation (which I'll be happy to provide, at least for Wordpress). Right now if you search for Wordpress or Wordpress MU on IIS, almost every link points to one of the other two IIS URL rewriter products. Considering the huge popularity
of Wordpress, that's a big area of interest!