Not Using index.html

A VIP doesn't normally change anything in the URI that the client requests, so in this case how does the client know to request something other than index.html (or one of the other browser defaults) if the VIP is not there?

 

 

While you could certainly use an iRule to change the requested URI (something along the lines of "if the URI is / or /index.html change it to /whateveryourdefaultis.html"), it would need to be sure and capture all iterations of the possible URI's that would need to be converted, as well as ignoring ones that do not need to go to the default page.

 

 

Denny

 

 

Denny,

 

 

Thanks for the response back. The application team wants us to set up a VIP for each instance of applications on the IIS server. So we would know the uri based on the VIP that someone requests. So if the user goes to www.newapp.com the IIS directory the VIP needs to point them to is /newapp/newapp.html instead of the /index.html.

 

 

Joe

Got it, so what I'm asking is how would they have accomplished this without the VIP? Is there a link to www.newapp.com somewhere that would be structured with /newapp/newapp.html? If so then the VIP doesn't need to do anything. Or are they expecting that now that the LTM is in play, that someone can just type in www.newapp.com in the browser and get to /newapp/newapp.html?

What I'm trying to get at is that I don't always consider it good design philosophy to depend on LTM to do something that the app couldn't do by itself in the first place. That being said, if the they are expecting LTM to solve this issue, the rule should be fairly easy. Something like:

 
 when HTTP_REQUEST { 
   if { [HTTP::uri] eq "/" } 
   HTTP::redirect "http://www.newapp.com/newapp.html" 
   } 
 } 
 

(I just did that with no syntax checking so you'd need to double-check that)

So what that rule is saying is if a client makes a request where the only URI is the trailing slash (empty, in other words), then redirect them to the proper path. It will pass through any other URI's (so when the client comes back to the vip with /newapp.html or any other URI then they will just pass through). If you needed to redirect other URI's then the rule would need some more logic.

I would say that there would be negligible performance impact from this rule, since LTM is optimized to do this sort of thing. But it is going to have to inspect every request to the vip to determine if it needs to redirect or not, which is why I come back around to the design philosophy aspect of this that I mentioned earlier. If the app was designed such that it wasn't depending on LTM to solve the problem, you eliminate a potential performance issue. Just something to keep in mind going forward.

Hope that helps!

Denny