Local variables are valid only for the TCP connection. They are persisted throughout the TCP connection, so that a variable set for one HTTP request will be available (and modifiable) in subsequent requests on the same TCP connection.
Is this an accurate summary of the problem?
I assume the first client request on the TCP connection is a POST request with a fair amount of data. The rule triggers when the HTTP headers for that request are parsed and the local (valid only for that TCP connection) variable is set to 1. Then, before the first request's data is processed and a server side connection is established (SERVER_CONNECTED), the client sends a second request over the same TCP connection. This request doesn't match the criteria for modifying the timeout, so the variable is set to 0. When the server side connection is established for the first HTTP request, the variable is set to 0, so the timeout isn't modified.
This sounds like requests are being pipelined. Though in theory, POST requests shouldn't be pipelined.
Is there a proxy server in front of the BIG-IP? Or does the client use pipelining? If you connect directly to the VIP (not through a proxy server) and disable pipelining on the client, does the problem go away? Do you have OneConnect enabled on the HTTP profile or the VIP?
Aaron