Bug ID 482215: Concurrent HTTP::collect calls are not supported

Last Modified: Apr 10, 2019

Bug Tracker

Affected Product:  See more info
BIG-IP LTM(all modules)

Known Affected Versions:
11.3.0

Fixed In:
12.1.0

Opened: Oct 02, 2014
Severity: 4-Minor

Symptoms

If multiple iRules invoked by the same event call HTTP::collect, then the resulting behavior is undefined. When HTTP_REQUEST_DATA/HTTP_RESPONSE_DATA is invoked, it may be due to any of the HTTP::collect calls. Thus HTTP::payload in this situation may not have the data wanted. In addition, if HTTP state-changing commands are invoked in an iRule while HTTP::collect is collecting, then the result is undefined. (Examples of state-changing commands are HTTP::respond, HTTP::disable, HTTP::redirect, HTTP::retry etc.)

Impact

Concurrent HTTP::collect calls are not supported. This is not specified in iRules documentation.

Conditions

Multiple iRules are invoked by the same event. HTTP::collect is called in more than one iRule. HTTP::collect and an HTTP state-changing iRule command are called in more that one iRule.

Workaround

Use a TCL variable as a flag to control calls to HTTP::collect. If HTTP::collect is called, then set that variable. If the variable is set when you want to call HTTP::collect again, then avoid doing so. Clear the variable in the HTTP_REQUEST_DATA/HTTP_RESPONSE_DATA events, when the HTTP::collect is finished. The variable is set, then use that knowledge not to call HTTP state-changing commands. The intent of iRules wanting to do conflicting work while a HTTP::collect can be recorded. When the collection is completed, then those commands can be executed (i.e., move the conflicting code from HTTP_REQUEST or HTTP_RESPONSE to HTTP_REQUEST_DATA or HTTP_RESPONSE_DATA).

Fix Information

Concurrent HTTP::collect calls are not supported. This is now described in iRules documentation along with information about how to work around that, as follows: Use a TCL variable as a flag to control calls to HTTP::collect. If HTTP::collect is called, then set that variable. If the variable is set when you want to call HTTP::collect again, then avoid doing so. Clear the variable in the HTTP_REQUEST_DATA/HTTP_RESPONSE_DATA events, when the HTTP::collect is finished. The variable is set, then use that knowledge not to call HTTP state-changing commands. The intent of iRules wanting to do conflicting work while a HTTP::collect can be recorded. When the collection is completed, then those commands can be executed (i.e., move the conflicting code from HTTP_REQUEST or HTTP_RESPONSE to HTTP_REQUEST_DATA or HTTP_RESPONSE_DATA).

Behavior Change