Forum Discussion

hoolio's avatar
hoolio
Icon for Cirrostratus rankCirrostratus
Nov 21, 2007

Valid events in STREAM_MATCHED event? (avoiding

Hi,

 

 

I was thinking that you could make decisions based on request or response data without actually collecting the HTTP data by using the stream profile. For example, this person (Click here) was trying to re-select a new node if a specific string was found in the response content. If you could use a stream command to look for that string and then put the reselect code in the STREAM_MATCHED event, you could avoid collecting the response data.

 

 

This is what I was thinking:

 

 


when HTTP_RESPONSE {
    Look for the error text in the response content
   STREAM::enable
   STREAM::expression @some error text@@
}
when STREAM_MATCHED {
    Found the error string, so select a new node"
   LB::mode rr
   LB::detach
   HTTP::retry $request
}

 

Error: command is not valid in current event context (STREAM_MATCHED)] [HTTP::retry $request]

 

 

 

However, in 9.2.4, I get an error stating the HTTP::retry command isn't valid in the current event. When I work around that error using eval, and the HTTP::retry command is triggered, I see a TCL error: "Not connected". I assume this means the proxy isn't in a state where it can resend an HTTP request.

 

 

Is this expected? If so, are there any workarounds you can think of to use a stream profile to inspect request or response data without collecting it?

 

 

Aaron
  • spark_86682's avatar
    spark_86682
    Historic F5 Account
    Unfortunately, this really can't be done. Since the stream profile is designed to do minimal buffering of server response data, it's quite possible that the client would already have gotten part of the server response by the time the STREAM_MATCHED event fired. So if you could successfully do an HTTP::retry in that event, then the client could see part of the first response followed by all of the second, which is almost certainly not what you want. That's why it's critical to actually buffer the server response if you might retry the request (so the client only ever sees one response).

     

     

    As far as a workaround, well, if you know that the error string always appears in the first N bytes, you could use TCP level commands to only buffer that many bytes, which would at least minimize the amount of buffering you do.
  • hoolio's avatar
    hoolio
    Icon for Cirrostratus rankCirrostratus
    Hi guys,

     

     

    That makes sense. Thanks for the info.

     

     

    Aaron