Adrian_Daminato
Sep 27, 2017Nimbostratus
Logic order for profile vs policy vs iRule
We're looking at how some of our legacy iRules can be converted to LTM Policies, as well as trying to optimize some of our work flows. We discovered that our public API traffic has about 10-15% of OPTIONS method calls, and wanted to see if we could bypass our compression profile.
Our current VS looks as follows, on our staging environment
ltm virtual /Common/api-staging-443 {
destination /Common/10.1.1.100:443
ip-protocol tcp
mask 255.255.255.255
persist {
/Common/src_addr_stream {
default yes
}
}
policies {
/Common/add-x-remote-addr { }
}
pool /Common/api-staging-1234
profiles {
/Common/wan-optimized-compression
/Common/api-staging-client-ssl {
context clientside
}
/Common/http { }
}
rules {
/Common/api-connection-ratelimit
}
source 0.0.0.0/0
translate-address enabled
translate-port enabled
}
The policy we are looking to add is as follows:
ltm policy /Common/Drafts/test-options-response {
controls { compression }
last-modified 2017-09-27:14:01:29
requires { http }
rules {
test-options-response-disable-compression {
actions {
0 {
compress
response
disable
}
}
conditions {
0 {
http-method
values { OPTIONS }
}
}
}
}
strategy /Common/first-match
}
The question we have is will this bypass the logic applied by the compression profile (which will look for content-length > 1024), since we know OPTIONS requests will always have a content-length of zero? Or does the TMM already have this short-circuit logic built into the proxy chain?