Using templates as values
You can use any of the current request headers, query parameters, and captured
URI groups as templates to populate supported config fields.
To escape a template, wrap it inside quotes and pass inside another template.
Note: The plugin creates a non-mutable table of request headers,
query strings, and captured URIs before transformation. So any update or removal
of parameters used in the template does not affect the rendered value of template.
The content of the placeholder
$(...) is evaluated as a Lua expression, so
logical operators may be used. For example:
Header-Name:$(uri_captures["user-id"] or query_params["user"] or "unknown")
This will first look for the path parameter (
uri_captures); if not found, it will
return the query parameter; or if that also doesn’t exist, it returns the default
Constant parts can be specified as part of the template outside the dynamic
placeholders. For example, creating a basic-auth header from a query parameter
auth that only contains the base64-encoded part:
Lambdas are also supported if wrapped as an expression like this:
$((function() ... implementation here ... end)())
A complete lambda example for prefixing a header value with “Basic “ if not
local value = headers.Authorization
if not value then
if value:sub(1, 6) == "Basic " then
return value -- was already properly formed
return "Basic " .. value -- added proper prefix
Note: Especially in multi-line templates like the example above, make sure not
to add any trailing white-space or new-lines. Since these would be outside the
placeholders, they would be considered part of the template, and hence would be
appended to the generated value.
The environment is sandboxed, meaning that Lambda’s will not have access to any
library functions, except for the string methods (like
sub() in the example
Examples using template as value
Add a service named
test which routes requests to the httpbin.org upstream service:
curl -X POST http://localhost:8001/services \
--data 'name=test' \
Create a route for the
test service, capturing a
user_id field from the
third segment of the request path using a regex:
Kubernetes users: Version
v1beta1 of the Ingress
specification does not allow the use of named regex capture groups in paths.
If you use the ingress controller, you should use unnamed groups, e.g.
(?<user_id>\w+). You can access
these based on their order in the URL path. For example
obtains the value of the first capture group.
curl -X POST http://localhost:8001/services/test/routes --data "name=test_user" \
You can learn more about using regexes in paths in the Kong Gateway
traffic routing reference.
request-transformer-advanced plugin to add a new header,
whose value is being set from the captured group in the route path specified above:
curl -XPOST http://localhost:8001/routes/test_user/plugins --data "name=request-transformer-advanced" --data "config.add.headers=x-user-id:\$(uri_captures['user_id'])"
Now send a request with a user id in the route path:
curl -i -X GET localhost:8000/requests/user/foo
You should notice in the response that the
x-user-id header has been added with a value of