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