HTTP HTTPS Proxy redirect question

The short answer is yes, but the solutions for HTTP and HTTPS can be slightly different.

Assuming you're going to use standard ports (80 for HTTP and 443 for HTTPS), for HTTP traffic you can do what's commonly called "host-based load balancing", where the load balancer sends traffic to a pool based on the HTTP request URI. Here's an example:

when HTTP_REQUEST {
    switch [string tolower [HTTP::host]] {
        "app1.example.com" {
            pool app1_pool
        }
        "app2.example.com" {
            pool app2_pool
        }
    }
}

This is probably the easiest method. You could also use an app-based URI if the host name was the same for both applications (ex. www.example.com/app1 or www.example.com/app2). The real beauty of this approach is that you're putting each application (based on IP and/or port) into its own pool. To add additional resources you can simply add new nodes to the pools and actively load balance and monitor the applications.

The above takes care of port 80 HTTP applications using a single IP address. Doing this for HTTPS is little more complicated in that the SSL negotiation is 1) based on the host name, and 2) happens before the HTTP host name can be evaluated. You can use the same exact iRule above, but you also need to configure the SSL properties of the VIP to accommodate multiple host names. Your options are:

1. A "Wildcard" certificate applied to the single client SSL profile applied to the VIP - this is a single certificate with a wildcard host name (ex. (.example.com) that would cover any host name that matches this domain pattern. These certificates tend to be expensive.

2. A "Subject Alternative Name (SAN)" certificate applied to the single client SSL profile applied to the VIP - this is a single certificate with a single subject name, but multiple subject alternative names. Like a wildcard it can support multiple host names, but unlike a wilcard it only supports a specified subset of host names.

3. Server Name Indicator (SNI) - an extension to TLS 1.0 and above that allows the F5 VIP to switch between multiple single cert client SSL profiles based on the server_name attribute sent by the client in the CLIENTHELLO message of the SSL handshake. This requires TLS so some legacy clients can't use this (ie. WinXP and earlier).

All of these options have the effect of allowing you to negotiate SSL with a single VIP, without error, and then use the host-based iRule above to send traffic to the correct application pool.