HTTP Profile breaking HTTPS site

Great question. You also have to think of iRules in relation to the OSI layers. So by the time you get to layer 7 HTTP in the protocol stack, and can use HTTP profile events and commands, you've already processed layer 4 TCP. Assuming the traffic isn't encrypted, the TCP events should be able to see the same thing that the HTTP events see, and can act on the data as well. The HTTP profile filter adds an "ease-of-use" feature set so that you can JUST act on the HTTP data elements (headers, cookies, payload, etc.). From TCP's perspective, however, all of HTTP is just payload. So to do an HTTP redirect in a TCP event (in the absence of an HTTP profile), you have to carefully craft your responses.

So for example, to do a redirect in an HTTP_REQUEST event (with an HTTP profile applied to the VIP), you'd do something like this:

when HTTP_REQUEST {
    HTTP::redirect "https://[HTTP::host][HTTP:uri]"
}

That takes care of all the HTTP semantics under the hood. To do the same thing with the CLIENT_ACCEPTED event, this is what it might look like:

when CLIENT_ACCEPTED {
    TCP::collect
}
when CLIENT_DATA {
    set HOST [findstr [TCP::payload] "Host: " 6 "\r\n"]
    switch -glob [TCP::payload] {
        "GET*" {
            set URI [findstr [TCP::payload] "GET " 4 "HTTP/1."]
        }
        "POST*" {
            set URI [findstr [TCP::payload] "POST " 5 "HTTP/1."]
        }
        "HEAD*" {
            set URI [findstr [TCP::payload] "HEAD " 5 "HTTP/1."]
        }
    }

    TCP::respond "HTTP/1.1 302 Found\r\nLocation: https://${HOST}${URI}\r\n\r\n"
    TCP::release
}

Because all of HTTP is just payload in the TCP event, you have to manually parse out the HTTP elements (host, uri) and then craft the HTTP redirect payload by hand. The good news is that you could do this sort of thing to support basically ANY protocol.