Forum Discussion
Normally if a connection is blocked by an F5 security product and HTTP is involved a 200 OK with an error code via the body is presented and a connection is not simply dropped so I would recommend a packet capture to validate where the TCP connection is dropped.
PURGE and PURGE_URL are non standard HTTP methods and are not listed in any RFC. If the TCP connection being dropped by BIG-IP there is a virtual server processing the traffic that has an HTTP security profile applied to it and the methods in question are not on the allowed list via a custom method.
I took a quick look at an HTTP protocol security profile in AFM which shows that PURGE and PURGE_URL are not in our standard list of methods. To allow them one needs to explicitly create them via Security --> Security Profiles --> HTTP. The exact details of the configuration will vary based on how the system is setup and the documentation on the product. I recommend a case be opened to further investigate the config setting you need since DDoS hybrid defender also has wizards that may obfuscate the setting or require other settings be touched.
hello. Thank you for your reply.
I previously confirmed that Allow for PURGE_URL is possible when creating iRules as follows. Please review whether the requested item cannot be implemented with the iRules.
(In addition, url_destroy was a syntax that did not work in that version.)
- Edit the iRule:
In the "Definition" section, add the following iRule script:
when HTTP_REQUEST {
if {[HTTP::method] equals "PURGE" || [HTTP::method] equals "PURGE_URL"} {
set allow_purge_method 1
}
}
when HTTP_RESPONSE {
if { [info exists allow_purge_method] } {
unset allow_purge_method
set respond_purge_method 1
}
}
when RULE_INIT {
set respond_purge_method 0
set allow_purge_method 0
}
when RULE_DESTROY {
if { [info exists allow_purge_method] } {
unset allow_purge_method
}
}