Cirrostratus
CirrostratusSince nobody else seems willingly to answer me, I'll provide the answer myself ;-)
Short version: it currently works flawlessly when using HTTP_RESPONSE_RELEASE as event in the last part of the iRule.
Long version: I have doubts whether this can be deployed in production or not, because according to the official iRule API documentation, HTTP::respond is disallowed under an HTTP_RESPONSE_RELEASE event. That's also the reason why I haven't even tried this at first, although it came to my mind before. The big question now is: is there any guarantee that this will continue to work, let's say for example after an upgrade from (currently) 12.1.3 to 13.x or maybe someday 14.x? I'm trying to get an official statement from f5 concerning this.
MVPAs I used your post for ideas I know that 4 years have passed but with ASM/Advanced WAF this can be done under "ASM_REQUEST_BLOCKING" event as shown in the below link:
https://clouddocs.f5.com/api/irules/ASM_REQUEST_BLOCKING.html
You can trigger a custom ASM violation based the ADAPT result to then match and trigger the ASM event.
Or to bypass the ADAPT_REQUEST_RESULT but better to trigger HTTP response before contacting te backend server and uploading a malware for example. Maybe at "HTTP_REQUEST_SEND" event as it seems valid but I will have to test this https://clouddocs.f5.com/api/irules/HTTP__respond.html .
when ADAPT_REQUEST_RESULT {
if {[ADAPT::result] == "respond"} {
# Force ADAPT to ignore any direct response from IVS
# (contrived example, probably not useful as-is).
ADAPT::result bypass
}
}