Preflight checklist
Describe the background of your feature request
Heimdall's proxy mode already supports regular HTTP traffic, streaming responses such as Server-Sent Events, and classic HTTP/1.1 WebSocket upgrades. It can also negotiate HTTP/2 for TLS connections to upstream services.
However, the current reverse proxy implementation and its related serve configuration were primarily designed around bounded HTTP request/response exchanges. They do not yet provide the explicit transport selection and streaming-compatible timeout semantics required by native gRPC and long-lived bidirectional HTTP/2 streams.
The current implementation also creates some otherwise reusable reverse proxy and transport instrumentation components per request, resulting in avoidable overhead.
Addressing these limitations only as part of gRPC support would either require duplicating proxy-specific logic or relying on transport and timeout behavior that was not designed for long-lived multiplexed streams.
Describe your idea
Modernize Heimdall's reverse proxy implementation and its related configuration so that it provides a secure, efficient, and protocol-correct foundation not only for regular HTTP traffic, but also for native gRPC and long-lived bidirectional HTTP/2 streams.
Are there any workarounds or alternatives?
Not with Heimdall's current proxy implementation.
Version
0.17.22
Additional Context
No response
Preflight checklist
Describe the background of your feature request
Heimdall's proxy mode already supports regular HTTP traffic, streaming responses such as Server-Sent Events, and classic HTTP/1.1 WebSocket upgrades. It can also negotiate HTTP/2 for TLS connections to upstream services.
However, the current reverse proxy implementation and its related
serveconfiguration were primarily designed around bounded HTTP request/response exchanges. They do not yet provide the explicit transport selection and streaming-compatible timeout semantics required by native gRPC and long-lived bidirectional HTTP/2 streams.The current implementation also creates some otherwise reusable reverse proxy and transport instrumentation components per request, resulting in avoidable overhead.
Addressing these limitations only as part of gRPC support would either require duplicating proxy-specific logic or relying on transport and timeout behavior that was not designed for long-lived multiplexed streams.
Describe your idea
Modernize Heimdall's reverse proxy implementation and its related configuration so that it provides a secure, efficient, and protocol-correct foundation not only for regular HTTP traffic, but also for native gRPC and long-lived bidirectional HTTP/2 streams.
Are there any workarounds or alternatives?
Not with Heimdall's current proxy implementation.
Version
0.17.22
Additional Context
No response