Compress Response
Overview
The Compress Response Traffic Policy action enables you to improve the performance of your web applications by compressing HTTP response bodies returned by your upstream service.
Configuration Reference
This is the Traffic Policy configuration reference for this action.
Action Type
compress-response
Configuration Fields
Parameter | Type | Description |
---|---|---|
algorithms | []string | The list of allowed compression algorithms to be considered during encoding type negotiation. Defaults to gzip , deflate , br , compress . |
Supported Compression Algorithms
Full list of supported compression algorithms:
Algorithm |
---|
br |
compress |
deflate |
gzip |
Supported Phases
on_http_request
on_http_response
Supported Schemes
https
http
Behavior
When an HTTP request includes an Accept-Encoding
header, HTTP responses are
automatically compressed, and a Content-Encoding header is added to the
response.
If the response is already compressed by your upstream service, no additional compression will be applied.
Streaming Compression
When compression is applied, the response body is not buffered; it is compressed in real-time as it streams through the ngrok endpoint.
Algorithm Choice
If a request specifies Accept-Encoding
but none of the requested algorithms
are supported, no compression is applied, and the upstream response is returned
unmodified.
Quality Values
Compression is negotiated based on the Accept-Encoding
header as defined by
the RFC,
respecting q-values and selecting the supported algorithm with the highest
q-value.
For example:
Accept-Encoding: gzip;q=1.0, br; q=0.5, *;q=0
The algorithm gzip
would be selected because it has the highest q-value of 1.0
.
Response Headers
When this action performs compression, the following changes are made to the HTTP response headers:
- The
Content-Length
header is removed. - A
Content-Encoding
header is added, specifying the negotiated algorithm. - A
Vary: Accept-Encoding
header is added to indicate that the response varies based on theAccept-Encoding
request header.
Examples
Compressing API Responses Based on URL Path
The following Traffic Policy
configuration demonstrates how to set this up using the compress-response
action with an expression to compress traffic on specific URL paths.
Example Traffic Policy Document
- YAML
- JSON
---
on_http_response:
- expressions:
- "req.url.path.startsWith('/api/')"
actions:
- type: "compress-response"
config:
algorithms:
- "gzip"
- "br"
- "deflate"
- "compress"
{
"on_http_response": [
{
"expressions": [
"req.url.path.startsWith('/api/')"
],
"actions": [
{
"type": "compress-response",
"config": {
"algorithms": [
"gzip",
"br",
"deflate",
"compress"
]
}
}
]
}
]
}
For this example, we are assuming that an ngrok agent is pointing at the upstream service https://jsonplaceholder.typicode.com.
Example Request
$ curl -i https://jsonplaceholder.ngrok.app/api/posts
HTTP/2 200 OK
content-encoding: gzip
content-type: application/json; charset=utf-8
<compressed-body-here>
In this example, when a request is made to /api/posts
,
ngrok compresses the response using one of the specified algorithms
(e.g., gzip
). The response includes the content-encoding: gzip
header, and
the body is compressed accordingly.
This setup ensures that only API responses
for paths starting with /api/
are compressed, enhancing performance and
responsiveness for only those endpoints.
Action Result Variables
The following variables are made available for use in subsequent expressions and CEL interpolations after the action has run. Variable values will only apply to the last action execution, results are not concatenated.
Name | Type | Description |
---|---|---|
actions.ngrok.compress.already_compressed | boolean | Will be true if the body was already encoded. |
actions.ngrok.compress.negotiated_algorithm | string | The algorithm selected by the action. |