The niceties of TrafficScript

So having worked with several ADC vendors over the last few years, I have had my fare share of interaction with manipulating traffic with a rules based framework like TrafficScript.  One of the niceties of Stingray TrafficScript is that is truly has come from an applications

background rather than a "packet mangling" network appliance.  For example, the first time I had to use TrafficScript to help a customer parse a response body, I was pleasantly surprised when I read the TrafficScript Reference for the http.getResponseBody() command (nb: the interesting bit is underlined below):

http.getResponseBody( [count] )

Returns the body of the HTTP response. 
If the response has chunked transfer encoding this function will return the de-chunked body. Similarly if the response is gzip or deflate compressed the body will be returned uncompressed.
If the optional 'count' parameter is provided, http.getResponseBody() will read and return the first 'count' bytes of the response. If count is 0, http.getResponseBody() will return the entire response.

# Read the entire response body
$body = http.getResponseBody();

Now, having done similar things with both iRules on F5 BigIP and with actions on Citrix NetScaler, the fact that the Traffic manipulation language takes care of de-chunking and decompressing the body content means one simple thing:

With Stingray Traffic Manager, I can spend more time doing what I sat down to do and less time fiddling with the ADC platform...

Simple really..