bug(transport/http): server-side timeout kills streaming connections (SSE/WebSocket)

[DrReMain]

What happened:

HTTP server applies Timeout uniformly to all requests, including streaming ones (SSE, WebSocket). Any server-streaming or bidirectional-streaming RPC exposed via HTTP is forcibly disconnected after the configured timeout, making long-lived streaming connections unusable.

This is a design inconsistency with the gRPC transport: the gRPC streamServerInterceptor intentionally omits the timeout for streaming calls (only unary calls get ctx, cancel := transport.contextWithTimeout(c, timeout)), but the HTTP transport makes no such distinction.

What you expected to happen:

HTTP streaming connections (server-streaming / bidirectional-streaming) should behave consistently with gRPC streaming — the server-side timeout should not be applied to streaming RPCs, allowing long-lived connections to remain open as long as needed.

Both transports serve the same proto definition; the timeout behavior should be aligned.

How to reproduce it (as minimally and precisely as possible):

1. Define a server-streaming RPC in a proto file:

   rpc Subscribe(SubscribeRequest) returns (stream SubscribeResponse);

2. Generate both gRPC and HTTP transports via protoc-gen-go-http.
3. Configure an HTTP server with a timeout:

   httpSrv := http.NewServer(http.Timeout(10 * time.Second))

4. Implement the streaming handler to send events over 30 seconds.
5. Observe:
   • gRPC client: receives all events correctly (stream has no timeout).
   • HTTP client (SSE): connection is killed after 10 seconds by the server timeout.

Anything else we need to know?:

Root cause analysis:

In transport/http/server.go, the timeout is applied to every request via middleware, with no check for whether the handler is streaming:

// transport/http/server.go — applies timeout to ALL requests
func (s *Server) handle(path string, h http1.Handler) {
    s.router.Handle(path, s.filterChain(path, h))
}

Meanwhile, in transport/grpc/server.go, the interceptor explicitly distinguishes:

// transport/grpc/server.go — stream interceptor does NOT apply timeout
func (s *Server) streamInterceptor() grpc.StreamServerInterceptor {
    // ... no timeout applied for streaming
}

References:

• [Question] Allow excluding SSE/WebSocket from http.Timeout in Kratos HTTP server #3775 — previous report of the same issue, closed without resolution
• transport/grpc: streamClientInterceptor does not apply WithTimeout, unlike unaryClientInterceptor #3833 — demonstrates that gRPC intentionally omits timeout for streaming

Suggested fix direction:

The HTTP transport layer needs awareness of whether a handler is streaming vs unary. Possible approaches:

1. Add a streaming-aware wrapper that skips/disables the per-request timeout for streaming handlers.
2. Use context.WithoutCancel or similar mechanism to detach the timeout from the streaming response writer.
3. Allow per-route timeout configuration so streaming endpoints can set unlimited timeout.

Environment:

• Kratos version: v3 (main branch, commit dc13681 and later)
• Go version: go1.24+
• OS: macOS / Linux
• Others: Affects all HTTP streaming use cases (SSE, WebSocket via bidi-streaming)

[dosubot]

Hi @DrReMain! I'm Dosu and I'm helping the Kratos team.

Your analysis is accurate. I can confirm the design inconsistency you've identified.

In the HTTP transport, the timeout is applied uniformly to all requests via the global filter() middleware in server.go — it calls context.WithTimeout(req.Context(), s.timeout) for every request when s.timeout > 0, with no distinction for streaming handlers [1]. The filter is registered globally via srv.router.Use(srv.filter()) [2].

In contrast, the gRPC transport explicitly differentiates:

• Unary: unaryServerInterceptor applies context.WithTimeout(ctx, s.timeout) [3]
• Streaming: streamServerInterceptor deliberately skips any timeout, treating streams as long-lived connections [4]

This is a clear transport-level inconsistency — both transports may serve the same proto definitions, but only gRPC correctly exempts streaming RPCs from the server-side timeout.

Regarding your references:

• #3833 documents a related but distinct issue on the client side — the gRPC streamClientInterceptor doesn't apply WithTimeout either, meaning client-side streaming calls can hang indefinitely without a bounded timeout.
• I wasn't able to find [Question] Allow excluding SSE/WebSocket from http.Timeout in Kratos HTTP server #3775 in the indexed data, so I can't confirm its status.

Your suggested fix directions are reasonable. The core challenge is that the HTTP transport's filter() middleware has no way to know whether a downstream handler is streaming or unary. A per-route or per-handler opt-out mechanism (e.g., a route-level option that disables the timeout context wrapping) would likely be the least invasive approach while maintaining backward compatibility for unary handlers.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.