iRule to redirect to new pool and sending it to the SSL proxy (HTTPS) does not work

Anhtuan,

I'm still not entirely sure that I fully understand your problem, but possibly following change may improve things. Assuming that the URI after the redirection to the SSL proxy (for URIs containing "newapp") is supposed to be unchanged, your rule should be:

rule STWLUI_RULE {
   if (http_uri contains "newapp") {
      redirect to " https://%h/%u"
   }
   else {
      redirect to " https://%h/CTP.ecocp"
   }
}

(note the %u instead of "newapp" in the first branch of the rule)

Just to make sure that we are on the same page - following is an overview of steps involved in the HTTP redirection that you want to achieve (if understand correctly your desired behavior):

- client connects to virtual server 172.16.20.243:80 let's say sends

request with URI containing "newapp",

- the virtual server invokes the rule and HTTP 302 redirect response is

returned to the client,

- client closes connection to virtual server 172.16.20.243:80

(clients are required to use new conenction after redirect according

to RFC 2616),

- client establishes new SSL connection to the proxy at

172.16.20.243:443 and sends the URI that has been returned in the

Location header of the redirect response (the content of the Location

header of 302 responses generated by BIG-IP is the argument of the

"redirect to" command with all % macros expanded),

- the SSL proxy decrypts the data and passes the request to virtual

server 127.0.0.243:80 which passes it to one of the servers in the

WLUI-POOL (based on configured persistence and loadbalancing method).

I can also guarantee you that the "404 response", that you've mentioned in your first post, is not generated by the BIG-IP. The only responses generated by BIG-IP are those above mentioned 302 redirects. All other HTTP responses have to come from one of the origin servers (pool members). That makes me think, that the URI returned in the redirection, actually does not exist on your servers. You should consult log files on your servers to confirm/disprove that.