Loading...
Loading...
ADAPT iRules cannot inspect adapted headers because the rule sees the original headers before the request is adapted. Similarly for the ADAPT_RESPONSE_RESULT event.
It is impossible to inspect the modified headers. One consequence is that if a request adaptation modifies the 'Host:' value, it is not possible to use an iRule to apply that to the transport connection, and as a result the modified request goes to the original server.
Using request-adapt or response-adapt profiles, and an internal virtual server that can modify the HTTP headers. Along with an iRule such as: when ADAPT_REQUEST_RESULT { log local0. "Modified host = [HTTP::host]" }
None.
Two new ADAPT iRule events have been added (ADAPT_REQUEST_HEADERS and ADAPT_RESPONSE_HEADERS) which trigger after ADAPT has received the modified headers, when the IVS is returning a modified request or response. They do not trigger when the IVS has instructed ADAPT to bypass or a service-down condition has occurred.
Two new ADAPT iRule events have been added (ADAPT_REQUEST_HEADERS and ADAPT_RESPONSE_HEADERS) which trigger after ADAPT has received the modified headers, when the IVS is returning a modified request or response. They do not trigger when the IVS has instructed ADAPT to bypass or a service-down condition has occurred.
Click on a version to see all relevant bugs
F5 Integration
Learn more about where this data comes from
BugZero Plan
Streamline upgrades with automated vendor bug scrubs
BugZero Prevent
Wish you caught this bug sooner? Get proactive today.