x-request-id
it will be added to the response as X-Request-Id
$tyk_context.
namespace$tyk_meta.
namespacetransformResponseHeaders
object to the middleware.global
section of the Tyk OAS Extension (x-tyk-api-gateway
) in your Tyk OAS API Definition.
You only need to enable the middleware (set enabled:true
) and then configure the details of headers to add
and those to remove
.
For example:
X-Static
with the value foobar
X-Request-ID
with a dynamic value taken from the request_id
context variableX-User-ID
with a dynamic value taken from the uid
field in the session metadataX-Secret
operationId
defined in the OpenAPI Document that declares both the path and method for which the middleware should be added. Endpoint paths
entries (and the associated operationId
) can contain wildcards in the form of any string bracketed by curly braces, for example /status/{code}
. These wildcards are so they are human readable and do not translate to variable names. Under the hood, a wildcard translates to the “match everything” regex of: (.*)
.
The response header transform middleware (transformResponseMethod
) can be added to the operations
section of the Tyk OAS Extension (x-tyk-api-gateway
) in your Tyk OAS API Definition for the appropriate operationId
(as configured in the paths
section of your OpenAPI Document).
You only need to enable the middleware (set enabled:true
) and then configure the details of headers to add
and those to remove
.
For example:
GET
requests to the /status/200
endpoint. Any response received from the upstream service following a request to that endpoint will have the X-Static
header removed and the X-Secret
and X-New
headers added (with values set to the-secret-key-is-secret
and another-header
).
The configuration above is a complete and valid Tyk OAS API Definition that you can import into Tyk to try out the endpoint-level response header transform.
X-Secret
header will be added (by the endpoint-level transform first) and then removed (by the API-level transform). Subsequently, the result of the two transforms for a call to GET /status/200
would be to add four headers:
X-Request-ID
X-User-ID
X-Static
X-New
response_processors
element in Tyk 5.3.0.global_response_headers
object to the versions
section of your API definition. This contains a list of key:value pairs, being the names and values of the headers to be added to responses.
To delete headers from all responses from your API (i.e. for all endpoints), you must add a new global_response_headers_remove
object to the versions
section of the API definition. This contains a list of the names of existing headers to be removed from responses.
For example:
X-Static
with the value foobar
X-Request-ID
with a dynamic value taken from the request_id
context variableX-User-ID
with a dynamic value taken from the uid
field in the session metadataX-Secret
transform_response_headers
object to the extended_paths
section of your API definition.
It has the following configuration:
path
: the endpoint pathmethod
: the endpoint HTTP methoddelete_headers
: a list of the headers that should be deleted from the responseadd_headers
: a list of headers, in key:value pairs, that should be added to the responseGET
requests to the /status/200
endpoint. Any response received from the upstream service following a request to that endpoint will have the X-Static
header removed and the X-Secret
and X-New
headers added (with values set to the-secret-key-is-secret
and another-header
).
X-Secret
header will be added (by the endpoint-level transform first) and then removed (by the API-level transform). Subsequently, the result of the two transforms for a call to GET /status/200
would be to add four headers:
X-Request-ID
X-User-ID
X-Static
X-New
header_transform
was added in Tyk 2.1 specfically to allow you to ensure that headers such as Location
and Link
reflect the outward facade of your API Gateway and also align with the expected response location to be terminated at the gateway, not the hidden upstream proxy.
This is configured by adding a new rev_proxy_header_cleanup
object to the response_processors
section of your API definition.
It has the following configuration:
headers
: a list of headers in the response that should be modifiedtarget_host
: the value to which the listed headers should be updatedLink
and Location
headers will be modified from the server-generated response, with the protocol, domain and port of the value set in target_host
.
This feature is rarely used and has not been implemented in the Tyk Dashboard UI, nor in the Tyk OAS API.
global_response_headers
object to the versions
section of your API definition. This contains a list of key:value pairs, being the names and values of the headers to be added to responses.
To delete headers from all responses from your API (i.e. for all endpoints), you must add a new global_response_headers_remove
object to the versions
section of the API definition. This contains a list of the names of existing headers to be removed from responses.
An example is listed below:
/httpbin-global-header
and forwards requests upstream to http://httpbin.org.
This configuration will add three new headers to each response:
X-Static
with the value foobar
X-Request-ID
with a dynamic value taken from the request_id
context variableX-User-ID
with a dynamic value taken from the uid
field in the session metadataX-Secret
transform_response_headers
object to the extended_paths
section of your API definition.
In this example the Response Header Transform middleware (transform_response_headers
) has been configured for HTTP GET
requests to the /xml
endpoint. Any response received from the upstream service following a request to that endpoint will have the Content-Type
header added with a value set to application/json
.
response_processor
object must be added to the API definition containing a header_injector
item, as highlighted below: