I agree it would be a kludge to let the first connection hang and then know to disable HTTP for the subsequent connections. I think it would technically be possible to do using the steps you've outlined. You can get the destination IP address (ie, what IP the client requested) using IP::local_addr in the clientside context. The server IP address doesn't exist in the CLIENT_ACCEPTED event as the server side connection hasn't been established yet. So running 'serverside {IP::remote_addr} will result in a TCL error. You could use the session table (
Click here) to record the client and destination IP's with a timeout value. If a matching session table exists in CLIENT_ACCEPTED, then disable HTTP. If it doesn't exist, then add a session table entry in CLIENT_ACCEPTED. In HTTP_REQUEST, you would remove the session table entry as you know the client-server IP pair is HTTP.
One question I have is: do you need to use an HTTP profile for some connections? Are you wanting to parse the HTTP traffic as HTTP? If not, you could just remove the HTTP profile from the VIP. Do you have a list of known HTTP servers? If so, you could create either more specific virtual servers or a datagroup containing the list of IP addresses (or subnets) for which to leave the HTTP profile enabled. Or is this VIP handling traffic for an arbitrary collection of port 80 connections?
I like the idea of adding a timeout option to the collect commands. However, I'm not a developer (or an F5 employee). You could propose this officially by opening a 'request for enhancement' case with F5 Support (
Click here). If you end up doing this and getting a change request (CR) number, please reply with it here so others can reference it if they want to add another request to the RFE.
Aaron