iRule Redirect Question/Help

Thanks Aaron -- I'll reply point by point below:

First thing is to remove the $:: prefix from your iRule's reference to the data group(s). This won't work in 10.x+. [I need to look at the deprecation list, and what changes need to be made so my iRules don't break later on down the road - but the rule I have written above does work to append trailing slashes to requests and we're on 10.2.3. I've alrady been warned that the 11.x syntax does change, so I will be reviewing all of my iRules and updating accordingly whenever we get around to updating to 11.x. Thanks for the heads up - this is definitely something I'm looking more into because I don't want my stuff to break when we upgrade to 11.x.]

Also note that the HTTP path will never be null. If a user types in http://example.com into the address bar, the browser appends a default path of /.

[The check for the trailing slash is due to the fact that the LTM is passing incoming SSL traffic to http traffic on the backend - so that trailing slash doesn't get passed - the end result is the IIS on the backend server thinks it's a file and not a directory - so it tries to pass a file it can't find instead of the default document within the virtual directory - 404]

Next, in order to know which paths to redirect with a trailing slash, you should be able to include them in your existing TrailingSlash_DataList data group.

[The TrailingSlash_DataGroup isn't evaluating paths. it's used to compare the path in order to determine if the extension exists or not. Basically because of the situation above, I have to evaluate all incoming traffic to see if it has an extension or a trailing slash.]

You shouldn't need to check if the path already ends with a trailing slash as your data group entries shouldn't have a trailing slash. So you can remove this 'and !($req ends with "/")'.

[Again, see above notes]

If things aren't working, add some debug logging of the original path and what you're redirecting to to help troubleshoot.

[I'm not sure where to do the debugging, but I used Fiddler 2 to monitor my outbound http/https traffic in order to learn about the need for the trailing slash and write the iRule and DataGroup to support it.]

Aaron

Now, as to the original question, I actually got it to work... Here's the iRule I setup to get it working.

when HTTP_REQUEST { 

 When the request first comes in, we're going to check to see if it's to the FQDN with nothing appended 
 ie https://ac.fsg.amer.csc.com (this condition results in the uri equaling a "/" only) 
 If the uri is only a slash, then we'll redirect to the virtual directory (ACWeb) 
 IIS interprets this "ACWeb/" entry as a request to a directory and loads the default page. 

  if { [HTTP::uri] equals "/" } { 
    HTTP::redirect https://[HTTP::host][HTTP::uri]ACWeb/ 
  } elseif { !([matchclass [HTTP::path] ends_with $::TrailingSlash_DataList]) and !([HTTP::path] ends_with "/") } { 

 If, for some reason, a request is made directly to ACWeb or any other virtual directory (without the slash) 
 then we need to make sure the trailing slash is added in a redirection. 

    HTTP::redirect https://[HTTP::host][HTTP::uri]/ 
  } 
}

Some test results:

User browses to https://www.mydomain.com - redirected to https://www.mydomain.com/ACWeb/

User browses to https://www.mydomain.com/ACWeb - redirected to https://www.mydomain.com/ACWeb/

User browses to https://www.mydomain.com/ACWeb/ - no redirection - traffic passed through http class.

User browses to https://www.mydomain.com/ACWebServices - redirected to https://www.mydomain.com/ACWebServices/

User browses to https://www.mydomain.com/ACWeb/Login.aspx - no redirection - traffic passed through http class.

I'm not sure if this is the best or most efficient way to do this, but it works. If you know of a way this can be done better, I'm all ears.