Introduction

The release notes include important installation changes and known issues. They also highlight ways that you can take advantage of new features or enhancements to improve your product usage.

For more information, see the following related resources:

đŸ”Ĩ Breaking changes

Review details about the following breaking changes. To review when breaking changes were released, you can use the comparison feature of the open source changelog or enterprise changelog. The severity is intended as a guide to help you assess how much attention to pay to this area during the upgrade, but can vary depending on your environment.

🚨 High

Review severe changes that can impact production and require manual intervention.

  • No high-severity changes are currently reported.

🔔 Medium

Review changes that might have impact to production and require manual intervention, but possibly not until the next version is released.

Envoy version upgrade

The Envoy dependency in Gloo Gateway 1.21 was upgraded from 1.35.x to 1.36.x. This change includes the following upstream breaking changes. For more information about these changes, see the changelog documentation for Envoy v1.36.

Envoy v1.36:

  • ExtProc changes: Removed support for fail_open and FULL_DUPLEX_STREAMED configuration combinations. For more information, see the related Envoy pull request.

  • Tracing changes: A route refresh now results in a tracing refresh. The trace sampling decision and decoration of the new route is applied to the active span. This change can be reverted by setting the runtime guard envoy.reloadable_features.trace_refresh_after_route_refresh to false. Note, that if pack_trace_reason is set to true (default value), a request that is marked as traced cannot be unmarked as traced after the tracing refresh.

  • HTTP/2 default value changes: The following default values were changed.

    • The maximum number of concurrent streams in HTTP/2 changed from 2147483647 to 1024.
    • The initial stream window size in HTTP/2 changed from 256MiB to 16MiB.
    • The initial connection window size in HTTP/2 was changed from 256MiB to 24MiB.

    You can temporarily revert this change by setting the runtime guard envoy.reloadable_features.safe_http2_options to false.

  • HTTP/1 CONNECT request changes: The HTTP/1.1 proxy transport socket now generates RFC 9110 compliant CONNECT requests that include a Host header by default. When the proxy address is configured via endpoint metadata, the transport socket now prefers hostname:port format over IP:port when the hostname is available. The legacy behavior that allows CONNECT requests without a Host header can be restored by setting the runtime flag envoy.reloadable_features.http_11_proxy_connect_legacy_format to true.

ℹī¸ Low

Review informational updates that you might want to implement but that are unlikely to materially impact production.

  • No low-severity changes are currently reported.

⚒ī¸ Installation changes

In addition to comparing differences across versions in the changelog, review the following installation changes from the previous minor version to version 1.21.

  • No installation changes are currently reported.

🌟 New features

Review the following new features that are introduced in version 1.21 and that you can enable in your environment.

HPA support

Starting in Gloo Gateway 1.21, you can bring your own Horizontal Pod Autoscaler (HPA) plug-in to automatically scale gateway proxy pods up and down based on thresholds such as memory and CPU consumption. To allow integration with HPA plug-ins, replicas are no longer managed by Gloo Gateway when no custom replicas are set in the GatewayParameters resource.

For setup instructions, see Horizontal Pod Autoscaling (HPA).

Multiple extProc filter variants

Starting in Gloo Gateway v1.21, you can configure up to three external processing (extProc) filters that run at different positions in the Envoy filter chain. Previously, only a single extProc filter was supported.

FieldPosition in filter chain
extProcEarlyEarly in the filter chain. Stage is configurable via filterStage.
extProcMiddle of the filter chain. Stage is configurable via filterStage.
extProcLateFinal filter before a request leaves Envoy; first filter when a response enters Envoy. Always runs as an upstream_http_filter regardless of filterStage.

All three fields are available at the global Settings, HttpListenerOptions, VirtualHostOptions, and RouteOptions levels. You can enable or disable individual variants at the listener level with disableExtProcEarly and disableExtProcLate.

For more information, see ExtProc filter variants and the Header manipulation guide.

Regex matching for JWT claims

Starting in Gloo Gateway v1.21, you can match JWT claims against regular expressions (regex) instead of the default exact string comparison. To enable regex matching, set the matcher field to REGEX_MATCH in the jwtPrincipal of your RBAC policy, and provide a regex pattern as the claim value. For example, to match an email claim against a pattern:

  
rbac:
  policies:
    viewer:
      principals:
      - jwtPrincipal:
          claims:
            email: "dev[0-1]@solo\\.io"
          matcher: REGEX_MATCH

For more information and additional examples, see Authorize access based on claims.

Custom host URL and path for LLMs

By default, Gloo Gateway uses the default host URL for a particular LLM, such as https://api.openai.com for OpenAI when sending a request to the LLM. You can customize the host URL and specify the base or full path that you want to use for your requests. This setup is useful in cases where your LLM is hosted through a different provider, such as IBM API Connect.

For more information, see Custom host URL and path.

OpenAI Realtime API WebSocket support

Starting in Gloo Gateway 1.21, you can proxy WebSocket connections to the OpenAI /v1/realtime endpoint through an AI upstream. Previously, the AI transformation filter rewrote all paths to /v1/chat/completions, which broke WebSocket upgrade requests. Now, the AI transformation filter automatically passes through WebSocket connections without rewriting the path.

No additional configuration is required. When you route traffic to an AI upstream, the gateway automatically enables WebSocket passthrough for the AI transformation filter.

In addition, a new global setting enableAutoWebsocketTransformationPassthrough is available in the Settings resource to enable WebSocket passthrough for non-AI transformation filters.

OpenAI Responses API support

Starting in Gloo Gateway 1.21, you can proxy requests to the OpenAI /v1/responses endpoint through an AI upstream. Previously, the AI transformation filter applied chat completions logic to all proxied requests, which caused requests to /v1/responses to fail.

No additional configuration is required. The AI transformation filter automatically detects requests to /v1/responses and passes them through.

Note the following feature support with the /v1/responses endpoint:

  • Supported: auth token injection, custom host URL and base path, and dynamic metadata extraction.
  • Not supported: rate limiting, prompt injection, RAG, guardrails, webhooks, semantic caching, and moderation.

Configurable PodMonitor scrape interval

You can now configure the scrape interval for the PodMonitor resource by setting the global.glooStats.podMonitor.interval Helm value. The default interval is 15s. This is useful when using managed monitoring services such as Grafana Cloud, where you want to control the scraping rate to reduce costs.

Installation changes

Redis image version update

The default Redis image version was updated to 7.2.11-alpine to fix CVEs. If you installed Gloo Gateway in an airgapped environment, make sure to update the Redis image accordingly.

For more information, see the Airgap installation guide.

🔄 Feature changes

Review the following changes that might impact how you use certain features in your Gloo Gateway environment.

XSLT transformation deprecated

The XSLT transformation feature is deprecated in Gloo Gateway v1.21 and will be removed in v1.22.0. If you use XSLT transformations, plan to use an external processing server to process this type of transformation. For more information, see External processing.