Last Modified: Apr 24, 2024
Affected Product(s):
BIG-IP LTM
Known Affected Versions:
11.6.0, 11.6.1, 11.6.2, 11.6.3, 11.6.3.1, 11.6.3.2, 11.6.3.3, 11.6.3.4, 11.6.4, 11.6.5, 11.6.5.1, 11.6.5.2, 11.6.5.3, 12.1.4.1, 12.1.5, 12.1.5.1, 12.1.5.2, 12.1.5.3, 12.1.6, 13.1.4.1, 13.1.5, 13.1.5.1, 14.1.4.3, 14.1.4.4, 14.1.4.5, 14.1.4.6, 14.1.5, 14.1.5.1, 14.1.5.2, 14.1.5.3, 14.1.5.4, 14.1.5.6, 15.1.4, 15.1.4.1, 15.1.5, 15.1.5.1, 15.1.6, 15.1.6.1, 15.1.7, 15.1.8, 15.1.8.1, 15.1.8.2, 15.1.9, 15.1.9.1, 15.1.10, 15.1.10.2, 15.1.10.3, 15.1.10.4, 16.0.1.2, 16.1.0, 16.1.1, 16.1.2, 16.1.2.1, 16.1.2.2, 16.1.3, 16.1.3.1, 16.1.3.2, 16.1.3.3, 16.1.3.4, 16.1.3.5, 16.1.4, 16.1.4.1, 16.1.4.2, 16.1.4.3, 17.0.0, 17.0.0.1, 17.0.0.2, 17.1.0, 17.1.0.1, 17.1.0.2, 17.1.0.3, 17.1.1, 17.1.1.1, 17.1.1.2
Opened: Jun 17, 2021 Severity: 3-Major
Standard (bigd-based, not In-TMM) HTTP monitors have a double CRLF appended (\r\n\r\n) to the send string. This does not comply with RFC1945 section 5.1 which states requests must terminate with a single CRLF (\r\n). This non-compliant behavior can lead to unexpected results when probing servers.
Servers probed by these non-RFC-compliant HTTP monitors may respond in an unexpected manner, resulting in false negative or false positive monitor results.
Standard bigd (not In-TMM) HTTP monitors
There are several workarounds: 1. If running 13.1.0 or later, switch monitoring from bigd-based to In-TMM. In-TMM monitors properly follow RFC1945 and will send only a single CRLF (\r\n) 2. Remain with bigd-based monitoring and configure probed servers to respond to double CRLF (\r\n\r\n) in a desired fashion Depending on server configuration, a customized send string, even with the double CRLF, may still yield expected responses.
None