http/https redirect

Hi Steve -

 

 

You typically would not need to check the local port in a rule like this, since virtual servers are usually port-specific (but if you needed to, you could use [TCP::local_port]). Unless you are applying the iRule to a wildcard virtual configured to support both HTTP and HTTPS, you'll have separate virtuals, one for HTTP and one for HTTPS, and all requests on each virtual would either be HTTP or HTTPS (not both). Since you are intending to redirect in some cases to the same hostname, different scheme, you will definitely need to have separate virtuals for HTTP and HTTPS to prevent an infinite redirect loop on your last 2 conditions. So you most likely would apply this iRule to the HTTP virtual only, and allow traffic on the HTTPS virtual to fall through to the CONTENT pool.

 

 

The confusion I mentioned earlier was specifically regarding where you are checking for the "." and the trailing slash. What value are you expecting to see for the variable "target"? (Logging the value of derived variables is a primary iRule troubleshooting technique you can leverage -- "log local0. $target" will reveal the value of the variable in the LTM log.)

 

 

It seems as if the iRule you originally created was intended to: * Honor HTTP requests for resources within the 4 listed directories and forward to the CMS pool (cleartext on both sides)

 

* Redirect to HTTPS any request with a different first directory which doesn't contain a "." or doesn't include a trailing slash

 

* Redirect to HTTPS any request for a hostname beginning with cms.

 

* Honor all other HTTP requests and forward to the CONTENT pool. which sort of seems to leave some odd holes in the resulting redirection pattern -- see these sample URI's and results using my current logic:http://cms.domain.com/da/my.directory.................forward to CMS pool (because of first directory in uri)

 

http://cms.domain.com/my.directory....................redirect to https://cms-d3.tmi.telus.com (because of hostname)

 

http://cms.domain.com/my.directory/...................redirect to https://cms-d3.tmi.telus.com (because of hostname)

 

http://cms.domain.com/my.directory/something_else.....redirect to https://cms-d3.tmi.telus.com (because of hostname)

 

http://host.domain.com/my.directory...................forward to CONTENT pool (no conditions match because of "." in directory name)

 

http://host.domain.com/myDirectory/...................forward to CONTENT pool (no conditions match because of "/" trailing directory name)

 

http://host.domain.com/myDirectory....................redirect to https://host.domain.com/myDirectory/ (because no "." and no "/")

 

http://host.domain.com/myDirectory/other..............forward to CONTENT pool (no conditions match because of "/" trailing directory name)

 

http://host.domain.com/myDirectory/another............forward to CONTENT pool (no conditions match because of "/" trailing directory name)Bottom line, you may need to further clarify the traffic management goals, and I'd definitely recommend adding some logging before or within each condition to see what values are being evaluated by each condition.

 

 

HTH

 

/deb