You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the Trino Gateway's external routing rules engine allows routing decisions based on information sent to an external service, and the service can return a routingGroup and a list of errors.
This issue proposes enhancing the external routing service response to support a mechanism for the service to specify HTTP headers that the Trino Gateway would be able to set on the incoming request before forwarding it to a Trino backend.
Use Case:
A primary use case for this feature is to enable more sophisticated routing logic that can also enforce policies through HTTP headers. For example:
Query Runtime Limiting: An external routing service could determine a query's characteristics and, based on those, set specific session properties via the X-Trino-Session header to enforce runtime limits on the Trino backend. This would allow dynamic policy enforcement at the routing layer.
Dynamic Session Property Configuration: The routing service could set other session properties based on user, source, or other request attributes, providing a more flexible way to configure query execution context.
Proposed Response Format:
I propose extending the JSON response format from the external routing service to include an optional setHeaders field, which would be a JSON object where keys are header names and values are header values. For example:
Considerations:
• Security implications of allowing an external service to set arbitrary headers. The Trino Gateway would need to carefully handle and potentially restrict which headers can be set.
• The interaction with existing header-based routing (e.g., X-Trino-Routing-Group).
• The order of header processing and potential conflicts.
Benefits:
This enhancement would provide a more powerful and flexible way to integrate external routing logic with the Trino Gateway, enabling advanced policy enforcement and dynamic configuration based on routing decisions.
The text was updated successfully, but these errors were encountered:
Currently, the Trino Gateway's external routing rules engine allows routing decisions based on information sent to an external service, and the service can return a routingGroup and a list of errors.
This issue proposes enhancing the external routing service response to support a mechanism for the service to specify HTTP headers that the Trino Gateway would be able to set on the incoming request before forwarding it to a Trino backend.
Use Case:
A primary use case for this feature is to enable more sophisticated routing logic that can also enforce policies through HTTP headers. For example:
Proposed Response Format:
I propose extending the JSON response format from the external routing service to include an optional setHeaders field, which would be a JSON object where keys are header names and values are header values. For example:
Considerations:
• Security implications of allowing an external service to set arbitrary headers. The Trino Gateway would need to carefully handle and potentially restrict which headers can be set.
• The interaction with existing header-based routing (e.g., X-Trino-Routing-Group).
• The order of header processing and potential conflicts.
Benefits:
This enhancement would provide a more powerful and flexible way to integrate external routing logic with the Trino Gateway, enabling advanced policy enforcement and dynamic configuration based on routing decisions.
The text was updated successfully, but these errors were encountered: