We are excited to announce that the IIS.NET Forums are moving to the new Microsoft Q&A experience. Learn more >

Features for URL Rewrite Module V2RSS

27 replies

Last post Jun 01, 2009 05:14 PM by ruslany

  • Features for URL Rewrite Module V2

    Jan 23, 2009 06:09 PM|ruslany|LINK

    URL rewrite team is doing research to determine what functionality and features would be useful to have in future releases of URL rewrite module. One of the features we are considering is providing support for getting substitution URL from an external data source or from custom code. For example, you could use it to get the rewritten URLs from a database table or from some text or XML file.

    To give you an idea about when this can be used:

    • <div mce_keep="true">You want to rewrite URL from http://www.mysite.com/some-title to http://www.mysite.com/article.asxp?id=234, where title to ID mapping is stored in a database table.</div>
    • You want to use some of the string manipulation functions, that are not provided in URL rewriter by default. E.g. replace, substr, toupper, etc
    • <div mce_keep="true">You want to use some of the .NET functions to make rewriting decision, e.g. rewrite based on time of day.</div>

    Please let us know what you think about this functionality by answering the following poll.

    [Poll]

    If you have other uses cases for this functionaity, please let us know. Also if you have any other feature suggestoins for future releases of URL rewrite module, please reply to this thread.

    URL RewriteV2

  • Re: Features for URL Rewrite Module V2

    Jan 24, 2009 05:22 AM|steve schofield|LINK

    This is exciting you are asking the community for design feedback.  Here is a list of 'features' I'd like to see.

    1) Perfmon counters metrics

    2) Logging similar to urlscan.  The biggest difference between urlscan and urlrewrite is use of regular expressions.  I'm a huge fan of urlscan, the company I work for can't use urlscan since it blocks too many good urls.  We are investigating the use of urlrewrite.

     

    Steve Schofield
    Windows Server MVP - IIS
    http://iislogs.com/steveschofield
    http://www.IISLogs.com
    Log archival solution
    Install, Configure, Forget

  • Rovastar Rovastar

    5495 Posts

    MVP

    Moderator

    Re: Features for URL Rewrite Module V2

    Jan 26, 2009 09:48 AM|Rovastar|LINK

    I must admit I am often a little confused as to how much of URL rewrite is focused on the (traditional) IIS admin side as opposed to the dev side. Personally (as IIS admin) I can see this feature being used much more by devs rather than by admin so maybe you could also askfor  new features questions for devs on a place like asp.net? *shrug*

    steve schofield

    This is exciting you are asking the community for design feedback.  Here is a list of 'features' I'd like to see.

    1) Perfmon counters metrics

    2) Logging similar to urlscan.  The biggest difference between urlscan and urlrewrite is use of regular expressions.  I'm a huge fan of urlscan, the company I work for can't use urlscan since it blocks too many good urls.  We are investigating the use of urlrewrite.

    Steve, If urlscan cannot do what you want than I am not sure urlrewrite will be able (or at least easily) to either.

    It will be much easier to work on the logic of why it is failing in URLscan rather than urlwrite (I shudder to think of the complexities of even having a minimal set of rules as regular expressions let alone 'really' complex ones) and logic is mostly the key for trapping or, equally important, no blocking valid content.

    I am struggling to think of examples of  where URLScan would not work (with well thought out rules, not the standard MS ones) and URLrewrite would work?

     

    (Even after discussions with Nazim here: http://blogs.iis.net/nazim/archive/2008/06/30/using-the-new-rules-configuration-in-urlscan-v3-0-beta-part-2.aspx I am not convinced. )

    Troubleshoot IIS in style
    https://www.leansentry.com/
  • Re: Features for URL Rewrite Module V2

    Jan 26, 2009 03:05 PM|ruslany|LINK

    Rovastar,

    In fact we are expecting this feature to be used by IIS admins more. The usage scenario for it is that you as IIS admin want to enable clean url without touching the legacy web application code. Or your CMS system has so many rewrite/redirection mappings that it becomes not practical to keep them all in a web.config file.

    URL RewriteV2

  • Rovastar Rovastar

    5495 Posts

    MVP

    Moderator

    Re: Features for URL Rewrite Module V2

    Jan 26, 2009 06:51 PM|Rovastar|LINK

    I suppose it depends on what you class as an IIS admin. I must say in the years I have been doing it I don't really touch web.config files in this way (in fact I would be wary about any changes to a web.config file) or the structure files/etc.

    I (at the moment anyway) will class this as a dev type role obviously web.config,etc need changing but the devs will change them first and then they will be copied to the server.

    If a change needed to be made for legacy apps - to get more friendly URLs - then it will, most of the time, in most organisations I have been involved with, be a dev type task. The company and design of the site drive the need for a URLwrite implementation and it is unlikely in my experience that an IIS admin will do the changes or get involved in that stage.

    Maybe others disagree and maybe this is something that might change in the future as IIS 7 and these types of possibities get adopted more but it is not at the moment, in my experience, the way orginisations manage their site / hosting infrastucture.

    Troubleshoot IIS in style
    https://www.leansentry.com/
  • Re: Features for URL Rewrite Module V2

    Jan 26, 2009 07:59 PM|steve schofield|LINK

    I second Rovastar on managing the URLRewrite from a dev perspective is more common in my experience.  Not sure beyond blocking sql injections using urlscan or urlrewrite or protecting the server from junk HTTP requests. 

     

    Steve Schofield
    Windows Server MVP - IIS
    http://iislogs.com/steveschofield
    http://www.IISLogs.com
    Log archival solution
    Install, Configure, Forget

  • Re: Features for URL Rewrite Module V2

    Jan 26, 2009 10:19 PM|steve schofield|LINK

    I"ll see if I can post a example explaining my request further.  The company I'm at now has tried URLScan and it gave too many false positives.  The RegEX is needed to exactly tell what is blocked.

    Steve Schofield
    Windows Server MVP - IIS
    http://iislogs.com/steveschofield
    http://www.IISLogs.com
    Log archival solution
    Install, Configure, Forget

  • Re: Features for URL Rewrite Module V2

    Feb 06, 2009 07:49 PM|DanielVL|LINK

    Steve,

    URL Rewrite Module raises ETW events for each request, FRT/FREB listens those events and if it is enabled it writes XML files in the file system, as you know. But FREB is just a listener; so you could disable it and write another listener to listen just URL Rewrite events and do your statistics yourself out of the box (how many AbortRequest? How many Rewrites? The top 10 rewritten URLs, etc)

    Here is how:http://blogs.msdn.com/danielvl/archive/2009/02/02/how-to-consume-etw-events-from-c.aspxIt is not perfect, but it may help.

    Thanks.

    Daniel Vasquez Lopez
    IIS Team
  • Re: Features for URL Rewrite Module V2

    Feb 10, 2009 08:06 AM|steve schofield|LINK

    Here are some examples I spoke with the person who tried to integrate URLScan. 

    /APage/webpage.aspx  ?itemno=999999&src=selector  select  
    /APage/webpage.aspx  ?itemno=ABCDEF&src=selector  select  
    /ASearch/webpage.aspx  ?Ntt=dishdrop tablet  drop+table
    /ASearch/webpage.aspx  ?Ntt=dish drop tablets  drop+table

    In addition, one of the pages that accepted the persons email address would block legit address.  For example, if we were looking for the phrase CAST and a persons name had that in their name, the page would not load. 

    Hope that helps explain our position.

    Steve Schofield
    Windows Server MVP - IIS
    http://iislogs.com/steveschofield
    http://www.IISLogs.com
    Log archival solution
    Install, Configure, Forget

  • Re: Features for URL Rewrite Module V2

    Feb 10, 2009 08:07 AM|steve schofield|LINK

    Thanks Daniel.  I'll check this out.  This looks promising.

     

     

    Steve Schofield
    Windows Server MVP - IIS
    http://iislogs.com/steveschofield
    http://www.IISLogs.com
    Log archival solution
    Install, Configure, Forget

  • Rovastar Rovastar

    5495 Posts

    MVP

    Moderator

    Re: Features for URL Rewrite Module V2

    Feb 10, 2009 10:01 AM|Rovastar|LINK

    Steve,

    Using reserved word with a blank space identifier will help here

    e.g.

    select%

    table%

    drop%

    instead of the simple reserved words.

    This will stop all the cases you mentioned and still give you protection.

    You will have to check the syntax of each SQL command to see what is allowed. Most have to have blank space before running it as a command some like CAST allow parenthesise '(', etc. So cover these too.

    I really need to write blog article on this.

    One of the biggest floors in URLSCan is the inability of multiple keyword combinations. For many SQL Injection attacks you have to have multiple SQL terms. e.g with a word like SELECT you cannot AFAIK create a an attack on that you need at least another reserved word. (CAST however is more powerful as it can mask multiple sql command via encoding)

    If URLrewriter could solve this problem then it could be a valid alternative.

    Troubleshoot IIS in style
    https://www.leansentry.com/
  • Re: Features for URL Rewrite Module V2

    Feb 11, 2009 04:00 PM|n8wei|LINK

    Hello Rovastar,

    As someone who has had personal experience with this issue, I feel I need to comment on this.

    Simply adding one blank space does indeed eliminate some false positives.  However, it does not eliminate them all.  As an example in one of Steve's post, the following text in the query string of a site search...

              ?Ntt=dish drop tablets

    ...would still be caught (erroneously) by the drop% filter defined in your list.

    Additionally, any whitespace is legal in T-SQL, so spaces are not the only characters to be checked for.  A CRLF would be valid after SELECT, as would a TAB.

    Furthermore, the word "table" by itself is something that would show up in the query string fairly regularly.  In one implementation, I have used "drop table", or "drop+table", which eliminates virtually all false positives, however it leaves the attack vector wide open for anyone using more than one space, or alternate whitespace characters.

    The following RegEx expression, however, would catch all of the identified keywords, beginning at a word boundary (i.e. after whitespace, beginning of string, etc), followed by 1 or more "whitespace" characters, additionally followed by one or more "non-whitespace" characters, ensuring that the word stands by itself, is not part of another string, and  something actually comes after the detected keyword.

    Almost all false positives are eliminated using this method, while the attack vector is still as tight as it would be simply searching for the words anywhere in the string.  (i.e. no valid SQL with any of these keywords would be looked over)

    \b(?:delete|declare|varchar|exec|execute|select|fetch)\s+\S+

    • Case insensitive
    • Assert position at a word boundary
    • Match the regular expression below
      • Match either the regular expression below (attempting the next alternative only if this one fails)
        • Match the characters "delete" literally
      • Or match regular expression number 2 below (attempting the next alternative only if this one fails)
        • Match the characters "declare" literally
      • Or match regular expression number 3 below (attempting the next alternative only if this one fails)
        • Match the characters "varchar" literally
      • Or match regular expression number 4 below (attempting the next alternative only if this one fails)
        • Match the characters "exec" literally
      • Or match regular expression number 5 below (attempting the next alternative only if this one fails)
        • Match the characters "execute" literally
      • Or match regular expression number 6 below (attempting the next alternative only if this one fails)
        • Match the characters "select" literally
      • Or match regular expression number 7 below (the entire group fails if this one fails to match)
        • Match the characters "fetch" literally
    • Match a single character that is a "whitespace character" (spaces, tabs, line breaks, etc.)
      • Between one and unlimited times, as many times as possible, giving back as needed (greedy)
    • Match a single character that is a "non-whitespace character"
      • Between one and unlimited times, as many times as possible, giving back as needed (greedy)

    Likewise, in the case of CREATE, ALTER, and DROP, using Regular Expressions, we can get specific and block all instances of those three words, but ONLY when they begin at a word boundary, occur only once, are followed by one or more whitespace characters, and are also followed by valid keywords, which themselves begin and end at word boundaries, and also only occur once.  (in other words, only block these three words when they occur in conjunction and in proper syntax with other keywords, which are indicative of valid SQL syntax):

    \b(?:create|alter|drop){1}\b\s+\b(?:action|aggregate|application|assembly|asymmetric|cell|certificate|... contract|credential|database|default|dimension|endpoint|event|fulltext|... function|index|login|master|member|message|mining|partition|primary|... procedure|queue|remote|role|route|rule|schema|service|set|statistics|... subcubesymmetric|synonym|table|trigger|type|user|view|xml){1}\b

     

  • Rovastar Rovastar

    5495 Posts

    MVP

    Moderator

    Re: Features for URL Rewrite Module V2

    Feb 11, 2009 06:16 PM|Rovastar|LINK

    Thanks for the Regex to emulate SQL injection. That has enlightened me more on this and is indeed an improvement over what URLScan can do. Using /b for word boundaries is very useful. 

    Yes, you are correct the drop% will not work there in this example.

    However you are mistaken on

    "Additionally, any whitespace is legal in T-SQL, so spaces are not the only characters to be checked for.  A CRLF would be valid after SELECT, as would a TAB."

    As it is a URL scanner all white spaces have to be converted to hex first before it can processed therefore:

    A space is

    %20

    and tab %09, CR %0d and LF %0a, etc are all caught with the <keyword>% format.

    It is difficult to define the start of a word in URLScan however you could use %20<keyword>%, %09<keyword>%, etc for each sql command you want to stop. (probably more characters too + etc could be used possibly) Which if I understand you correctly is what you are doing in the regex.

    However you have not taken into account inline comments like CA/*blah*/ST which is valid syntax.

    So you need to block /* and */ anywhere in the URL string. Which is another additional feature you need to add to your REgex.

    I can see the advantages with the multiple words which is something that is lacking in URLscan. Still there is no URLrewrite before IIS7 and thus it is worth investing in proper URLScan rules for these versions.

    Troubleshoot IIS in style
    https://www.leansentry.com/
  • Re: Features for URL Rewrite Module V2

    Feb 12, 2009 12:25 PM|n8wei|LINK

    Rovastar,

    Excellent points!  I totally forgot about the inline comments.  That would definately throw a wrench in things.  I will need to make sure that I account for those.  I'm positive that the RegEx will allow me a nifty way to detect those, without many false positives.  Perhaps I can even find a way to have the RegEx pattern matching exclude the commented portion by using a replacement of a sub match or something.  (I'm no expert on RegEx, and I know that there is power far beyond what I'm currently implementing)

    In regards to all white spaces having to be converted to hex in the URL.  I understand that completely.  Actually, the plus sign (+) can be used in place of a space in the querystring portion of the URI as well, so it becomes a little more complex.

    That is actually a problem with URLRewrite, as URLScan properly decodes all of the data prior to comparison.  As a matter of fact, URLScan does a double decoding to make sure that there are not encoded characters in the initial decode, and allows me to block all requests with such encoding, preventing a hacker from double, tripple, or further encoding their hack to avoid detection.  Unfortunately, that feature isn't built into URLRewrite, so I will still leave URLScan in place to catch things such as that. 

    I initially ran into a problem using URLRewrite with the RegEx patterns, because it wasn't catching word boundaries due to the fact that they were encoded in hex.  Using URLRewrite, I had to implement the URLDecode() function in the URLRewrite rules, so that all of the rules were applied to the raw ASCII, and not the encoded version of the text.  If I did not do this, none of the "word boundary", or "whitespace" rules from the RegEx would catch anything.

    Hence, CR, LF, TAB, etc, are indeed converted into their ASCII representations, and not left in the %xx notation.  By the time, my RegEx rule is applied, the character string contains the actual characters.

     

  • Rovastar Rovastar

    5495 Posts

    MVP

    Moderator

    Re: Features for URL Rewrite Module V2

    Feb 13, 2009 10:37 AM|Rovastar|LINK

    I would hope that /* and */ would not be used in any valid URL but there is no accounting for developers.

    URLscan's scans default ini file I believe blocks these. (Either not both which is actually what is need for the syntax to work but by that logic if you actually have say /* in a valid URL on your site you could just block */ in URLscan )

    Thanks for further explanation on how you setup your URLrewrite. I still haven't used much IIS7 and not touched URLrewrite yet but this explains a lot for this scenario.

    Also using both scan and rewrite is a great idea I can see more now they have different functionality and can be part of different roles in securing the sites.

    Do you know what order it processes these 2 filters in? Is it configurable?

    The more a look at this I see that complex SQL injection prevention from the URL is difficult but by no means impossible to get effective security. Again logic is the key here in using any (or ideally both) tools.

    Also I have only been really focusing on TSQL when you have other

    To be honest you really need a few SQL commands to make an injection attack (with the expection of the damn CAST (and I imagine CONVERT) syntax.) Therefore I would be looking at any say 2 examples of all the keywords to prevent an attack. This will allow flexability of useability of the site and security. But that is something to do when I tackle URLSCan when we migrate across. I too don't understand the black art of RegEX enough either, yet.:)

    Oh apologies ruslanY for derailing your thread. :)

    Troubleshoot IIS in style
    https://www.leansentry.com/
  • Re: Features for URL Rewrite Module V2

    Feb 13, 2009 11:19 AM|steve schofield|LINK

    Rovastar

    Do you know what order it processes these 2 filters in? Is it configurable?

    Here is a thread me asking that particular question except I don't believe the order can be configured.  That would be a great feature, the only way I can think of is adjusting the Global Modules in applicationHost.config.

    http://forums.iis.net/p/1152314/1882020.aspx#1882020

    Steve Schofield
    Windows Server MVP - IIS
    http://iislogs.com/steveschofield
    http://www.IISLogs.com
    Log archival solution
    Install, Configure, Forget

  • Rovastar Rovastar

    5495 Posts

    MVP

    Moderator

    Re: Features for URL Rewrite Module V2

    Feb 13, 2009 12:54 PM|Rovastar|LINK

    Thanks Steve. That is useful to know. 'by default' implies that they are configurable.......

     

    Troubleshoot IIS in style
    https://www.leansentry.com/
  • Re: Features for URL Rewrite Module V2

    Feb 19, 2009 10:39 AM|olemichelsen|LINK

    A very important feature for me, would be rewrite of content URL's just before they are sent to client.

    Other rewrite modules (such as LinkFreeze) does this, and it makes sure that you can apply rewriting on existing sites, without modification. It also makes it possible to apply new rules to static HTML content.

     That you have to alter your URL's in your code, is both difficult to implement in existing code, and it requires you to maintain the URL rewrite "scheme" two places. You have to add them to the IIS filter and then also hard code it into your app.

     I actually thought this was supported "out of the box" since it seems like a pretty essential thing to me, but after some trial and error and fugtile searching I found out that this was not included in initial release.

    Pleeeease add this - I know it has been mentioned in other posts under various titles.

     LOVE the UI reg exp generator btw - it is brilliant!

  • Re: Features for URL Rewrite Module V2

    Feb 23, 2009 01:23 PM|ruslany|LINK

    Thanks for feedback olemichelsen. Outbound URL rewriting is something that we are considering for the next version of the module.

    outbound rewrite

  • Re: Features for URL Rewrite Module V2

    Mar 10, 2009 02:19 PM|emumford|LINK

    A thought I just had for a feature, although it could very well be a moot point depending on the other feature sets of V2, but how about a "goto" action... meaning you could write a light weight rule to check if you can bypass a set of rules for evaluation and jump to another named rule in the ruleset, bypassing the cost of evaluating the rules between...

    I've been writing a rather complicated set of rewrite and redirect pairs for an SEO optimisation of an existing site, and it just occured to me that rule evaluation for either or is moot for either or... and becomes more so as you begin to produce rules for other subpaths in the domain/site...

    Another idea for this type of check would be "ruleset" action instead, so that rules could be nested below a simpler rule, allow that subset of rules to only be evaluated and acted upon...

    I've created a small rule at the begining of my ruleset that evaluates the first section of the URL to see if it exists in a map for sections that need to processed... if the path is not there, or the map value is not set to "true" it provides a noaction response and exits the URLRewrite module...

    I do praise the speed of the URLRewrite module as it stands, but I believe that any way to bypass any unnecessary code execution is always a good thing..

    One other thing... how come I can't layer map/function calls?  i.e. {MapName:{UrlDecode:{R:1}}}... solved easily enought with conditional stacking or your creative conditional result passing... but that does make it complicated.

  • Re: Features for URL Rewrite Module V2

    Mar 13, 2009 03:05 PM|ruslany|LINK

    emumford, these are valid suggestions - thanks for taking a time to report those to us!

    URL RewriteV2

  • Re: Features for URL Rewrite Module V2

    Apr 17, 2009 11:03 PM|takeos|LINK

    ruslany


    Also if you have any other feature suggestions for future releases of URL rewrite module, please reply to this thread.

    One suggestion/question: would there be some performance benefit in being able to flag a rewrite rule as "Only if 404?" Such a rule would be processed only if and when a file or directory is not found in its original form. I see that some sites have hundreds of legacy URLs to maintain, and the idea that this list gets parsed for each access, when 99% of users don't need it, seems inefficient. Not sure if this makes sense. In theory it should already be possible to internally optimize the list in this way, but it would have do be done based on usage metrics, so I guess a little hint in the form of an explicit flag could be helpful?

    Also there is a hybrid case (combination of file not found and redirect) that I would like to suggest. Right now IIS, like other web servers, redirects www.example.com/path to www.example.com/path/ if there is no file, but there is a directory matching "path/". This is fine, but if "path/" is redirected to "path2/" (via a rule), this is broken, and one has to add two explicit rules, one for "path" and the other for "path/". My proposal would be to redirect "path" to "path2/" if "path" is not found, and a redirect exists from "path/" to "path2/". This would be consistent with non-redirect behavior, and would halve the number of required rules, with no side effects (rule is triggered only in case of file not found), to the contrary, restoring the original server behavior of the original path. and applying it after the original path changes.

    As a third case, I would like to propose to apply file-to-directory notation redirection (and viceversa) for redirection URLs in case of files or directories not found. For example, if I set up a rule to redirect www.example.com/facebook/ to point to our facebook group, and the user enters www.example.com/facebook (or vice versa), then so be it, I would like to have a way to simplify all these potentials of broken URLs. After all it's only a matter of adding or removing a "/", which is not so formal in the user's heads anyway, and servers already handle this redirection in an automated way.

  • Re: Features for URL Rewrite Module V2

    Apr 23, 2009 03:52 PM|Jeff24|LINK

    Hi,

    WOW!!!

    This is exactly what i need : You want to rewrite URL from http://www.mysite.com/some-title to http://www.mysite.com/article.asxp?id=234, where title to ID mapping is stored in a database table.

    When do you think it will be available?

    Thanks

  • Re: Features for URL Rewrite Module V2

    May 25, 2009 06:57 PM|takeos|LINK

    > Also if you have any other feature suggestions...

    A quick one: putting the host name in the Rewrite action URL currently triggers a 404.4 (unless you have ARR set up, which is not what the user wants, if the host is the same as the current URL). It's a common condition, if you look up searches and posts. Maybe the host name should be tolerated in this context, I mean, recognizing that it is the same host name we had in the first place, not really using a different server. Or the error message should be more helpful. Just a thought!

  • Re: Features for URL Rewrite Module V2

    May 26, 2009 03:26 PM|anilr|LINK

    The host being same as the current url may not be enough to execute the request without ARR as one site can be broken up into multiple application-pools and there is no way to route to another application pool without ARR.

    Anil Ruia
    Software Design Engineer
    IIS Core Server
  • Re: Features for URL Rewrite Module V2

    May 27, 2009 06:54 PM|emumford|LINK

    takeos

    ruslany


    Also if you have any other feature suggestions for future releases of URL rewrite module, please reply to this thread.

    One suggestion/question: would there be some performance benefit in being able to flag a rewrite rule as "Only if 404?" Such a rule would be processed only if and when a file or directory is not found in its original form. I see that some sites have hundreds of legacy URLs to maintain, and the idea that this list gets parsed for each access, when 99% of users don't need it, seems inefficient. Not sure if this makes sense. In theory it should already be possible to internally optimize the list in this way, but it would have do be done based on usage metrics, so I guess a little hint in the form of an explicit flag could be helpful?

    Also there is a hybrid case (combination of file not found and redirect) that I would like to suggest. Right now IIS, like other web servers, redirects www.example.com/path to www.example.com/path/ if there is no file, but there is a directory matching "path/". This is fine, but if "path/" is redirected to "path2/" (via a rule), this is broken, and one has to add two explicit rules, one for "path" and the other for "path/". My proposal would be to redirect "path" to "path2/" if "path" is not found, and a redirect exists from "path/" to "path2/". This would be consistent with non-redirect behavior, and would halve the number of required rules, with no side effects (rule is triggered only in case of file not found), to the contrary, restoring the original server behavior of the original path. and applying it after the original path changes.

    As a third case, I would like to propose to apply file-to-directory notation redirection (and viceversa) for redirection URLs in case of files or directories not found. For example, if I set up a rule to redirect www.example.com/facebook/ to point to our facebook group, and the user enters www.example.com/facebook (or vice versa), then so be it, I would like to have a way to simplify all these potentials of broken URLs. After all it's only a matter of adding or removing a "/", which is not so formal in the user's heads anyway, and servers already handle this redirection in an automated way.

    1. <div mce_keep="true">Both <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" /> and <add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" /> conditions allow for this "404" check... these both verify that the URI being requested does NOT exist on disk.  After this check a simple rule lookup the requested URI against a translation map allows you to simply have one rule that maps x to y... a little critical thinking and you can see how to use these condition individually, or with out the negate to accomplish many other things...</div>
    2. <div mce_keep="true">There is a simple construct in Regex that allows you to write a single rule for either case, path or path/... that is "path/?" the "?" portion states that the previous character may or may not exist... causing both to match, and therefor redirect to "path2/".  Even if I am confusing your example for a single rule instead of two, using example one and this you could accomplish multiple possible states, file or directory existance, or what ever... it's already a part of URLRewrite v1.x.</div>
    3. <div mce_keep="true">see 2.  it's the same case of matching "^facebook/?" and redirecting to your facebook group URI...</div>
  • Re: Features for URL Rewrite Module V2

    May 27, 2009 07:17 PM|emumford|LINK

    ruslany and analir,

    Is there any news regarding a V2?  Is it in the works or is it just a possibility?  If it is in the works, any kind of idea on an ETA?  Current roadmap?  Pretty please?

  • Re: Features for URL Rewrite Module V2

    Jun 01, 2009 05:14 PM|ruslany|LINK

    It is in works right now. The development is in progress and beta is expected this summer.