Forum Discussion

Toni1's avatar
Toni1
Icon for Nimbostratus rankNimbostratus
Oct 17, 2023

Scope and integrity of local variables

Hi there,

I’m presently getting slightly confused about the scope of local variables and how much I can trust their integrity during evaluation even for the same event.

My understanding is that they are stored on a per connection basis:

So where there an iRule that has both an HTTP_REQUEST event as well as an HTTP_RESPONSE event :

- How much can I rely on a variable that let’s say is always set at the start of the HTTP_REQUEST event, to be available always in the HTTP_RESPONSE ?
- And as per above, always match the value it is set to from the matching request (as opposed to some other request that may have occurred under the same connection basically at the same time)?
- I’m asking this question because I was initializing a variable at the very start of HTTP_REQUEST and then in the HTTP_RESPONSE I refer to this variable at the beginning (and assume it has a value). However in a small number of cases there was an error in the log that said this variable was never set… which unsettled me a little since it’s always set in the request event…

One more question sorry!

- Is it possible for the same connection for there to be more than one request occurring at the same time (HTTP/2?)?
- And if there is, then even within the same HTTP_REQUEST event for a particular request, can I rely on the integrity of the local variables to hold during the evaluation of this event, even while there are other requests operating at the same time for a given connection?

Thanks! This will help my understanding and trust a lot in the iRule I am currently writing (which has quite a few variables)

Thanks,

Toni

  • Toni1 As long as it is considered part of the same client connection you should be fine for both of these. Again, I have never had an instance where a variable for one user was unintentionally used by a different user. When the iRule initiates for that users connection any variables should be set so I don't think you have to worry about responses not having the variable.

  • Toni1 In the 15+ years that I have used it I have never had another clients accidentally share variables because of how iRules are executed. It is possible that you have set a variable and it's also possible that the pool member stripped the variable from the response. Your best bet here is to run a tcpdump and then open it in wireshark to confirm the variable is indeed being set and that the connection that is sent to the pool member contains the variable. This will allow you to see the response from the pool member as well to see if it has been removed.

    • Toni1's avatar
      Toni1
      Icon for Nimbostratus rankNimbostratus

      Hi there,

      That's good to know that realistically I probably don't have much to worry about... it's quite a big and important iRule, so i'm being a bit paranoid I suppose...

      I guess my general lack of understanding is whether :

      - There can be simultaneous requests/responses occuring for the same tcp connection (I read that http/2 might do that, but I wasn't sure), and if it is, could the local variables even in the same iRule event (given they are scoped to each connection) ever be in danger of being overwritten by other requests/responses from the same connection?

      - And lastly is it technically possible to have a response without a request? I remembered that we make small use of websockets, so i'm wondering if a response that doesn't know about a local variable that was definately set in the beginning of the request might be due to websocket traffic instead of normal http traffic.

      Thanks 🙂

      Toni

       

      • Toni1 As long as it is considered part of the same client connection you should be fine for both of these. Again, I have never had an instance where a variable for one user was unintentionally used by a different user. When the iRule initiates for that users connection any variables should be set so I don't think you have to worry about responses not having the variable.