Last Modified: Dec 15, 2020
See more info
Known Affected Versions:
11.2.1, 11.4.0, 11.4.1, 11.5.0, 11.5.1, 11.5.1 HF1, 11.5.1 HF10, 11.5.1 HF11, 11.5.1 HF2, 11.5.1 HF3, 11.5.1 HF4, 11.5.1 HF5, 11.5.1 HF6, 11.5.1 HF7, 11.5.1 HF8, 11.5.1 HF9, 11.5.10, 11.5.2, 11.5.2 HF1, 11.5.3, 11.5.3 HF1, 11.5.3 HF2, 11.5.4, 11.5.4 HF1, 11.5.4 HF2
11.6.0, 11.5.4 HF3
Opened: Jun 20, 2014
Related AskF5 Article: K16690
If filters that buffer messages exist on the chain, then when HTTP switches to pass-through mode, those filters may spuriously fail to see the headers of the response that cased that switch. The problem is due to HTTP immediately switching into pass-through mode, and then sending the headers as raw data through the chain.
The TMM may core, or wrong information may be obtained from filters looking at the HTTP headers of a response that causes a switch to pass-through mode.
A filter on the chain that buffers a RESPONSE_DONE message, and HTTP switches to pass-through, combined with looking at the headers in a filter other than HTTP. This is more likely to happen if the server sends data immediately after a successful CONNECT or transition to websockets. (Without waiting for a response from the client.)
This issue has no workaround at this time.
HTTP now waits until all filters have seen a 101 Switching Protocols or CONNECT 200 Connected response before switching into pass-through mode.