For more information regarding the security incident at F5, the actions we are taking to address it, and our ongoing efforts to protect our customers, click here.

Forum Discussion

albert_forster_'s avatar
albert_forster_
Icon for Nimbostratus rankNimbostratus
Apr 05, 2005

relate_client & relate_server

We use TCP::collect and TCP::payload to gather the initial OPTIONS command. Then use TCP::respond to send an options response back to the client. With TCP::collect and TCP::payload we get the DESCRIBE...
application delivery
dev
devops
iRules
unRuleY_95363's avatar
unRuleY_95363
Historic F5 Account
Apr 05, 2005
BTW, Dr.Teeth's comments about the TCP::collect/TCP::release might seem confusing, so here's some further notes about the TCP::collect & TCP::release commands:

 

 

There are several implicit rules that are probably worth mentioning regarding the CLIENT_DATA/SERVER_DATA events.

 

 

1) If TCP::collect is specified with no arguments, it is considered an indefinite hold. New incoming data will continuously be aggregated in the payload and trigger CLIENT_DATA/SERVER_DATA events until an explicit TCP::release is given. If TCP::release is used with an argument, the indefinite hold will continue and only the specified amount of data is released. If TCP::release is used without arguments, the entire payload is released and the indefinite hold is cancelled.

 

 

2) There is an implied TCP::release at the end of the CLIENT_DATA/SERVER_DATA event if TCP::collect was specified with an explicit amount. This implied release can be overriden with an explicit TCP::release command or a new TCP::collect command in the event.

 

 

So, Dr.Teeth's remark about the additional TCP::collect is due to the fact that the original TCP::collect in CLIENT_ACCEPTED was an indefinite hold. However, it also does not adversely effect anything having the extra TCP::collect in there.

 

 

Hope this helps.