RewriteBase plans?

Topics: Developer Forum, User Forum
Apr 3, 2010 at 5:34 PM

I just wanted to ask if there were still plans to add a RewriteBase mod_rewrite equivalent, and what version it might be included in?  It would be useful for migrating mod_rewrite rules by minimizing necessary modifications.

Also, I might suggest that an option to read the IIRF configuration rules from .htaccess files on a per directory basis.  This is how Apache's mod_rewrite works, and it would make it much easier to port applications (like Wordpress) over to IIS.

The necessary changes to Wordpress or Wordpress MU (and likely many other Apache based web apps) with both of these features included would be minimal, involving just a change to the "REQUEST_URI" server variable name (which is IIS's fault), changing one rule from RewriteRule to RedirectRule (mod_rewrite doesn't seem to seperate those 2 directives) and adding the "U" flag to all the RewriteRules (to accomodate the lack of "REQUEST_URI").  Wordpress and Wordpress MU themselves need only a single added line of code to map "REQUEST_URI' to "HTTP_X_REWRITE_URL".

Coordinator
Apr 4, 2010 at 3:41 AM

Hey Randy, thanks for using the forums.

On the RewriteBase directive, I had a relevant workitem open for a while, soliciting input on this.  I didn't get much!  After thinking about it further, I've implemented RewriteBase in v2.1.1.2 of the filter.  It is slightly different than mod_rewrite's RewriteBase because IIRF does not support per-directory ini files, as does Apache.   Rather than explicitly specifying the url base as an argument to RewriteBase, in IIRF you can only turn on the RewriteBase option, and the base is implicitly set to the vdir virtual path.   The reason for this is that in IIS, the vdir root is known, fixed, and it would be a redundancy to have to specify it both in the IIS configuration and in the IIRF configuration. 

You also suggested per-directory ini files.  Right now IIRF has per-vdir ini files, which seems to work well enough for most people.  Prior to today, I haven't heard anyone ask for per-directory ini files.  It is theoretically possible to add it, and I'll open a workitem for the request, but I don't promise any quick action on it.  There is not a large demand for it, and also, it would cause a pretty significant change in the administrative model for the filter.  Significant enough that I would be able to consider adding it, only with a major version upgrade.   Even with a major upgrade, I'm not sure the added flexibility would be justified by the added complexity.  In any case I don't expect this will be a major problem for you or other people who use wordpress.  Typically, people want per-vdir ini files, not per directory.   

As for the REQUEST_URI; setting that variable to the appropriate value is easily done in IIRF with a few additional directives in the ini file: 

RewriteCond %{HTTP_X_REQUEST_URI}  ^HTTP_X_REQUEST_URI$
RewriteHeader X-REQUEST-URI:  .*    %{PATH_INFO}  [QSA]

You need v2.1.1.2 to get that capability.  You don't need the U flag.

You also mentioned changing RewriteRule to RedirectRule.   I'm definitely not gonna do that. The reason for my reluctance is the utter confusion people encounter surrounding redirect versus rewrite.  I fought that battle for a long time, explaining to people that a RewriteRule with an [R] option was really a Redirect, and after the 1000th time explaining it, I decided that it was a stupid way to do things, even if Apache seems to think otherwise. Therefore in IIRF, RedirectRule is for Redirects, RewriteRule is for Rewrites.  It's really easy for people to understand, and it's really easy for me to explain.  And I'd like to keep it that way.

Check out the v2.1.1.2 release, and read the documentation on RewriteBase.  It may be satisfactory for you.

 

 

 

Apr 4, 2010 at 7:06 PM

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 2.1.1.2 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]

OR

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!

Coordinator
Apr 5, 2010 at 4:03 AM

Thanks for the input.

As for the purpose of IIRF - My thinking was that I wanted to provide a pretty good open source rewriter, with similar syntax to mod_rewrite.  I knew from the beginning I was not going to achieve a 100% reproduction of the Apache capability.  There's too much, and it's too mature, and there are too many related modules that sort of get lumped in with mod_rewrite.  People will want ProxyPass (which I provided, then ProxyPassReverse (not yet), setting variables (not possible as far as I know in IIS), and on and on.  To reproduce mod_rewrite completely would be practically unreachable. So I figured IIRF would provide most of the capability, and most of the same syntax.  I figured I would add to it over time, as people asked for things. Which is what I'm trying to do.

I diverged where it was too much work for the payoff, or where it got to be too confusing, as with RedirectRule vs RewriteRule.   Or with per-directory ini files.

I can look into re-enabling the RewriteRule with the [R] modifier.   The code is not the tricky part there.  It's the explanation and support that gets expensive.

 

Coordinator
Apr 5, 2010 at 4:03 AM

oh, and I added the capability to provide an explicit argument to RewriteBase, in v2.1.1.4. 

which is available now.

 

Coordinator
Apr 5, 2010 at 4:32 AM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.