HTTP Explicit Proxy and http requests

Sample iRule Basic Logic

when CLIENT_ACCEPTED {

block by IP

} ; CLIENT_ACCEPTED

when HTTP_PROXY_REQUEST {
 if {[HTTP::method] eq "CONNECT"} {
   HTTP Profile will forward via tunnel to transparent proxy
  return
 }

otherwise you know it is non-tls and as such could use HTTP:: commands to parse request and decide on allow/disallow.

} ; HTTP_PROXY_REQUEST

James,

This was the way the explicit proxy was designed, I cannot go into specifics as I am not aware of complete reasoning but because of the way TLS vs. non-TLS is handled using the CONNECT verb from the client side it was determined for various reasons at the time that any manipulation by HTTP traffic could be handled on the explicit VS directly as I mentioned above and then passed using routing to the end web server directly as opposed to going through another layered VS as is done for HTTPS to improve performance, etc... There is discussions about improving the options in the explicit proxy profile to potentially allow more options to this behavior in the future but as of now this is how it is designed. To allow for adding of disallowed ipuri's in a single place each of the irules (explicit+wildcard VS) could make calls to a datagroup(s) that would compare current connection ip/uri to disallowed ip/uri's in the datagroup(s) so that as an admin you would just need to update the datagroup(s) and both irules on different VS's would block those new ip/uri's dynamically based on that. Hopefully this helps!

One additional thought to add as to why, if the goal is big IP to act as an explicit proxy then the easiest thing would be to accept client connection and then just pass all connections out default routing. But then for HTTPS since it would CONNECT and then try to negotiate SSL through that tunnel if big IP wanted to decrypt HTTPS at that point you would have to have another VS with a clientside and serverside SSL profile to allow decryption and then utilize full big IP feature set on decrypted traffic before passing to end webserver re-encrypted by BIG IP. But instead of forcing HTTP to use this methodology as well even though not necessary as it is non-TLS it was decided for improved performance to allow it to just use routing and bypass that additional layered VS. Again, not a concrete answer based on direct knowledge but just some more insight.