Debugging and Diagnosing the Kong Gateway With Ease

We’re excited to announce the general availability of Kong Gateway 3.5 for Open Source (OSS). This release enables Javascript developers to extend the Gateway via the WebAssembly layer which is currently in Beta, delivers some enormous observability enhancements, and unlocks top-end performance. Keep reading for the latest on Kong Gateway 3.5 for OSS!

The WebAssembly beta continues to deliver: Better, easier, JavaScriptier

The fast-paced beta cycle of WebAssembly support in Kong Gateway continues in 3.5 at full steam! 

Since our initial release in 3.4, we’ve taken your feedback to heart and made various changes and improvements to both the back-end implementation of this feature and the end-user experience. With the enhanced WebAssembly support in Kong Gateway 3.5, users can now experience increased performance, a more intuitive configuration process, and a broader range of language options, making the integration and development of Wasm filters not only smoother but also more adaptable to diverse development backgrounds.

The implementation of WebAssembly in Kong Gateway keeps getting more robust. We’ve pushed several bug fixes and improvements in both memory and execution performance to our WasmX module, which powers WebAssembly in Kong Gateway. We’ve also upgraded the Wasm engine used by WasmX: Kong Gateway 3.5 now ships with Wasmtime 12.

The interfaces are also now easier and safer to use. In the previous release, Wasm filters were configured using raw string configurations, which could only be validated at runtime. We now support structured data configuration, which can be validated using JSON Schema by the Control Plane at configuration time. This not only improves the ergonomics when setting up filter chains via declarative configuration or the Admin API, but it also makes the whole process more robust by providing early validation checks without having to check runtime logs.

Last but not least, AssemblyScript (a WebAssembly-oriented dialect of TypeScript) now joins Go and Rust in our list of tested and recommended languages for Wasm filter development! If you come from the JavaScript ecosystem, you should be readily familiar with AssemblyScript as they share the same syntax and language constructs. Just as we did for Rust and Go in release 3.4, we’re providing some example filters written in AssemblyScript for you to use as a starting point when developing your own.

WebAssembly support in Kong Gateway 3.5 is still beta, as we want to validate these changes with your feedback before we graduate it to GA. For this reason, we encourage everyone to provide us feedback on Kong Nation and report any issues on GitHub.

One ID to rule them all: Easier per-request debugging!

Entire solutions are devoted to helping developers better understand how requests transit in/out of individual systems. Needless to say, debugging complex systems is challenging. Kong offers a variety of ways to help ease this burden today. Some examples include our OpenTelemetry plugin as well as our Correlation ID plugin. While all of these are useful, Kong itself doesn’t generate a unique identifier for each request that it processes — well, until today that is! 

In 3.5, Kong Gateway will produce a unique identifier for all requests named `X-Kong-Request-Id`. This identifier will be present in `access` and `error` logs, which helps to diagnose an issue faster with your API gateway. All logging/telemetry plugins will now carry this `x-kong-request-id` by default, empowering you to easily correlate requests with direct log entries if needed. This ID can also be surfaced in custom error templates returned to users. 

Under pressure to debug? Get Gateway timing on demand!

When users are experiencing latency and you’re under pressure to find out why, it’s not the easiest time to instrument an observability pipeline. We get that. Sometimes you need a quick way to understand what’s causing latency. In this release, we’ll support on-demand request timing information using a secure token.

Each Kong Gateway instance will write a secure token to disk on startup (or restart/reload). This token can be retrieved and appended as a request header. If a given Kong Gateway receives a request with this secure request header specified, the Kong Gateway will emit a response header full of useful timing information in JSON format. The information includes all phases of the request lifecycle, all the plugins that ran, any third-party network calls, and other critical timing information like DNS lookup time. This helps users who are under pressure to diagnose an issue quickly. 

One important note: the response header format should be considered dynamic. As we continue to improve this feature we’ll add more and more timing information to the debug response header. You should never consider this response schema as static! Happy debugging!

You can read more about this feature here.

Packing a powerful performance boost with dedicated configuration processing

Kong Gateway seeks to do it all, from intelligent routing all the way to security and identity management and day two operations and visibility. When running Kong Gateway in hybrid mode, the Data Planes have one more item they need to account for — receiving and processing configuration changes from the Control Plane. Every time the configuration changes, the Control Plane (CP) will stream the new configuration to the Data Planes (DPs). The DPs then update their own configuration based on the state sent by the CP. While this is happening, the DPs also have to attend to proxy traffic they’re processing. Occasionally, in very complex deployments, this can lead to contention between proxy traffic and configuration processing, especially for very large configurations. An observable symptom can be a somewhat elevated P99 time for proxy traffic.

Starting in 3.5, by default, the Kong Gateway will reserve a small amount of capacity specifically to process configuration sent by a CP when running as a DP in hybrid mode. This will result in zero resource contention between the proxy traffic and the configuration processing! You can learn more about this feature here.

When it’s OK to ask for something private: Private network access in the CORS plugin

Recently, Google promoted Chrome version 117 to the stable channel. With this promotion comes the long-planned implementation of the `Access-Control-Private-Network-Access` directive from within the cross-origin resource sharing, or CORS, framework. 

As a reminder, CORS exists to ensure that browsers aren’t running malicious third-party scripts and making unexpected HTTP requests to unsuspecting origins. Most developers, however, will know CORS as that thing they always forget about! Luckily, you can offload that headache with the Kong Gateway CORS plugin, which remains one of our most popular plugins for this reason. 

Starting in 3.5 this plugin will also support the `Access-Control-Allow-Private-Network` directive as well — and you can instruct Kong to reply with the required `"Access-Control-Allow-Private-Network":”true”` header when asked by the browser in the preflight request. This special preflight request is triggered when the browser is making a request to an origin on RFC1918, i.e. ‘internal’, IP space. Here’s to less time dealing with CORS and more to writing code!

Next steps

For a complete rundown of features, fixes, and updates, check out the Kong Gateway 3.5 OSS CHANGELOG. Get your hands on Kong Gateway 3.5 by downloading it. Or level up instantly with Kong Konnect, offering the quickest route to try out Kong Gateway 3.5.