Rethinking Payload Parsing: Native JSON Handling in iRules
iRules have long been a cornerstone for customization in F5 workflows, a flexible tool that lets users solve traffic management and security challenges in rapid, clever, creative ways. Whether optimizing app performance, fine-tuning protocol behavior, or even defending against unusual attack vectors, iRules empower users to think beyond what’s “standard” and craft solutions tailored to their needs. Over the years, as JSON became a dominant format for transmitting data between systems, the iRules community adapted to handle it: crafting intricate regular expression patterns to parse payloads and extract key information. It worked, but it wasn’t ideal. Regex parsing is notoriously labor-intensive, requiring precision, patience, and constant debugging to ensure accuracy and maintain reliability in production. When taken in the context of iRules, the addition of more labor and increased attention to fine details made the process of creating such an iRule a much more demanding, high-stakes task. Now, there’s a better path forward: native JSON parsing capabilities built directly into iRules. Introduced in TMOS 21.0, this feature removes much of the heavy lifting for JSON processing, replacing manual parsing work with automatic handling via JSON profiles. This means faster customization, reduced complexity, and an easier way to tackle modern traffic challenges. Why Native JSON Parsing Matters To better understand the significance of this development, let’s revisit what JSON parsing traditionally required within an iRule. Imagine needing to capture data points like a session token, a user ID, or an API call parameter embedded in a JSON payload. The typical approach involved carefully writing regular expressions to match specific patterns in the data. While regex is powerful, it demands exact syntax. Even the slightest mistake could break functionality, leading to hours of troubleshooting. With native JSON parsing, much of that toil disappears. Instead of manually defining how to parse a payload, iRules users gain access to JSON profiles that do the reading and processing automatically. Payload data is extracted seamlessly so users can focus on higher-level logic and customizations that drive value in their unique environment. Here’s what this can look like in practice: Simplified Customization for AI Protocols: Whether you’re handling machine-to-machine traffic (e.g., MCP or A2A protocols) or managing real-time API workflows, JSON parsing allows iRules to adapt more easily to protocol-specific traffic customization. Reduced Regex Dependency: Regex patterns are no longer the default method for handling JSON. Native parsing reduces code complexity while also mitigating the risk of hidden errors in regex logic. Time Savings: Less time spent debugging payload-handling code means more time spent solving problems and optimizing workflows. Let’s look at an example: Imagine you have a large JSON body that contains the list of tools available from an MCP server. You want to produce a list of the tools and potentially modify that list before passing them back to a client. Before BIG-IP LTM v.21.0, you would need to collect a payload and use multiple regex passes to extract the tool’s information. Even then, the regex approach is fragile because the logic would need to be re-examined any time the JSON structure changed. The regex also has no concept of nesting depth, so keys from nested objects could potentially leak into the tool list. Truly solving this with regex alone would require a custom brace-depth tracking loop in TCL, essentially writing a partial JSON parser by hand. With the new JSON events and commands available in iRules; when a JSON profile is attached to the virtual server, the iRule becomes much more reliable & performant due to its’ structural awareness of JSON, elimination of payload buffering, and removal of regex processing. In both cases, a typical iRule would have additional events, more error handling, and perform more actions on the result than just logging, but this comparison shows how much more intuitive the code becomes for this task when using the new JSON events and commands. The difference becomes even more stark when we examine how we would remove one of the tools from the list before sending the response back to the client. Without the JSON parser, we are required to hand-write a brace-depth tracking loop just to find the boundaries of the entry to remove, while also ensuring we don’t invalidate the JSON format, all within a performance-sensitive event. In contrast, the approach with the JSON parser hasn’t changed much from the previous example. We can simply remove the object we don’t want and respond with the modified content. Integrating JSON profiles transforms the way teams interact with iRules, and thus the way iRules interact with modern traffic, enabling faster, smarter decisions at scale. Learning from the iRules Community Showcasing this new enhancement merits further exploration into how exactly iRules can become tools for innovation. The depth of creativity around iRules in F5’s community is unmatched, as users consistently craft solutions that push the boundaries of what is possible in-app delivery. This ingenuity is evident in iRules contests that spotlight the best work from the community. Each year, participants create bespoke iRules to address a problem offered up by F5’s DevCentral evangelists. Without fail, the submissions shed light on how some ingenious scripting can solve real-world challenges. From impressive performance optimizations to cutting-edge security use cases, the results consistently reflect the practical ingenuity behind the community’s success. Here are three examples of how users approached their problems creatively from this year’s AppWorld iRules contest: LLM Prompt Injection Detection & Enforcement Problem: As enterprises integrate AI APIs, public LLM, and self-hosted LLM’s into production applications, a critical and largely unaddressed attack surface has emerged: prompt injection. Unlike traditional web attacks that target code parsers, prompt injection targets the AI model itself. Attackers embed malicious instructions inside legitimate-looking API requests. Currently, there is no existing iRule or BIG-IP capability that addresses this. Solution: Implement a multi-layer, real-time Prompt Injection Detection (PID) engine in line with LLM API traffic on BIG-IP, requiring zero backend changes Rate limiting WebSocket messages for Agents Problem: Protecting WebSocket-based AI services from Overload caused by high message rates; temporary spikes via burst control; resource waste from duplicate or repeated messages; aggressive/malicious agents with temporary penalties, and lack of visibility via structured JSON logging. Solution: Protect WebSocket endpoints from aggressive or misbehaving AI agents by enforcing message rate limits, burst controls, and duplicate suppression. Each client IP is allowed up to 40 messages per 10 seconds with a maximum of 20 messages per second. AI Token Limit Enforcement Problem: Without proper limits, users or applications can generate excessive inference requests and consume GPU or CPU capacity uncontrollably. Inference stacks may lack built-in mechanisms for enforcing per-user or per-role token budgets, so organizations need a way to control usage before requests reach the model. Solution: Enables token budget enforcement directly on BIG-IP LTM without requiring additional modules or external gateways. By validating JWTs and extracting user and role information, the iRule applies role-based token limits before requests reach the inference service. This provides a simple, native way to introduce quota control and protect on-premise AI infrastructure from uncontrolled usage. These are just three examples from AppWorld 2026. The depth of knowledge and innovation that the iRules community has cultivated over the last decade is a testament to the way teams can use a tool like iRules to craft novel, bespoke solutions for their environments. What Comes After the Shift to Simplification In the story of iRules’ evolution, the addition of native JSON parsing is a small step, but it reflects a broader trend in the evolution of our digital tools: making powerful capabilities more accessible to more users. While iRules remain as flexible and intricate as ever, developments like JSON parsing streamlines foundational tasks, allowing users to spend less time on granular parsing and more time solving bigger challenges. For those engaged in heavy traffic customization, the impact of this shift is substantial: AI-driven workflows like MCP become easier to configure; payload handling becomes less reliant on regex, minimizing complexity; and customization scales alongside traffic demands, no matter how intricate protocols become. As iRules continues to evolve, the F5 community remains at the heart of innovation, exploring new ways to address critical application delivery challenges and raising the bar for what’s possible. The tools enable the vision; your ingenuity delivers results. Take your next step by exploring native JSON parsing in TMOS 21.0, and if you haven’t already, dive into the winning solutions from this year’s iRules contests for even more inspiration.
iRules LX Sideband Connection
Problem this snippet solves: Sideband connections in traditional TCL iRules can be large, complex and difficult to support. Additionally doing something with the information retrieved (such as JSON) may require the use of regular expressions to parse the content before it can be used, something to be avoided if at all possible due to the performance overhead. Using the inbuilt capabilities of Node.js, sideband calls in iRules LX are much easier to implement and with a range of inbuilt as well as NPM packages, the possibilities are endless. To make the external request, the example uses 'https' package from the standard library, however many more are available via NPM such as 'request' which is much simpler to use and doesn't need to chuck the response. The advantage of using the standard library in this instance is this can be done 'out of the box' and doesn't require the use of NPM. In this simple example, a traditional iRule requests the object 'title', which is a JSON object from a publicly available API (https://jsonplaceholder.typicode.com/). { "userId": 1, "id": 1, "title": "delectus aut autem", "completed": false } iRules LX will, make the call using the standard 'https' library, parse the JSON data and return the value for 'title' to the calling iRule, which will be then returned to the user as an HTTP response How to use this snippet: Add the following iRule to yout iRules LX Workspace. This will make an RPC call to iRules LX, using the plugin 'ilx_pl' and the extension 'ilx_ext' You can however call this what you like providing your update the ILX::init command to reflect this. when HTTP_REQUEST { # pass argument to ILX in form of a requested JSON object: # {"userId": 1,"id": 1,"title": "delectus aut autem","completed": false} set arg title set ilx_handle [ILX::init "ilx_pl" "ilx_ext"] if {[catch {ILX::call $ilx_handle "httpRequest" $arg} result]} { log local0.error "Client - [IP::client_addr], ILX failure: $result" HTTP::respond 400 content "<html>There has been an error.</html>" return } HTTP::respond 200 content $result log local0. "retrieved parsed JSON value for $arg: $result" } Use the iRules LX code below for the index.js file, within your workspace Code : var https = require("https"); var f5 = require("f5-nodejs"); var ilx = new f5.ILXServer(); function httpRequest (req, res) { https.get('https://jsonplaceholder.typicode.com/todos/1', function (resp) { var data = ''; // A chunk of data has been recieved. resp.on('data', function (chunk) { data += chunk; }); // The whole response has been received. Parse JSON resp.on('end', function () { res.reply(JSON.parse(data).title); }); }).on("error", function (err) { console.log("Error: " + err.message); }); } ilx.addMethod('httpRequest', httpRequest); ilx.listen(); Tested this on version: 12.1
/stats returning JSON nested objects instead of array?
I noticed that requesting a list of virtuals returns a JSON array, while the stats for the same collection returns nested objects. Is this intentional? https://hostname/mgmt/tm/ltm/virtual << returns JSON array https://hostname/mgmt/tm/ltm/virtual/stats << returns JSON nested objects ` Details (tweaked to protect the innocent): `https://hostname/mgmt/tm/ltm/virtual?$select=destination,name { "kind": "tm:ltm:virtual:virtualcollectionstate", "selfLink": "https://localhost/mgmt/tm/ltm/virtual?$select=destination%2Cname&ver=12.1.2", "items": [ { "name": "vs_vlan1", "destination": "/Common/10.15.15.0:0" }, { "name": "vs_vlan2", "destination": "/Common/any:0" } ] } The above output stores the virtuals (and its details) in an array. However, /stats changes that to nested objects: https://hostname/mgmt/tm/ltm/virtual/stats?$select=destination,tmName { "kind": "tm:ltm:virtual:virtualcollectionstats", "selfLink": "https://localhost/mgmt/tm/ltm/virtual/stats?$select=destination%2Cname%2CtmName&ver=12.1.2", "entries": { "https://localhost/mgmt/tm/ltm/virtual/~Common~vs_vlan1/stats": { "nestedStats": { "entries": { "destination": { "description": "10.15.15.0:any" }, "tmName": { "description": "/Common/vs_vlan1" } } } }, "https://localhost/mgmt/tm/ltm/virtual/~Common~vs_vlan2/stats": { "nestedStats": { "entries": { "destination": { "description": "any:any" }, "tmName": { "description": "/Common/vs_vlan2" } } } } } }How to still get alerts from an allowed JSON profile?
I have a configuration similar to below in ASM v12, and would like to be able to still get an alert when the exact attack signature would be met: /allowed/url.html with header based JSON profile "allow SQL signature X" This "SQL signature X" is in blocking for the rest of the site, but I would still like to get an alert if it is seen on the /allowed/url.html Is it possible for that to happen, or since it is in the allowed url in the JSON profile is that not an option? Thanks!Working with iControl REST Data on the Command Line
I'm still pretty entrenched in "old school" iControl with the soap interface, but with Colin's new series on the iControl REST interface underway, I thought I'd start taking more than a glance. While Colin's sed-fu in his latest article is impressive, I want to see the json data returned from iControl REST calls parsed properly (no offense, Colin!) This can be done with any number of bash, perl, python, and more tools, but I ran across one on twitter last night that is somewhat magical. jq is a single binary you can download and it just works. So why bother? Well, as Colin pointed out, the returned json data (by default) is none too fabulous in format: But with jq, you get nice pretty text with field callouts (jq .): But wait! There's more! You can also narrow the selection to the fields you want (jq '{ name, apiAnonymous }'): If you want to pull all the rules together, but still only return the name and code, just index by item (jq '.items[] | { name, partition, apiAnonymous }'):
