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
Use generic HTTP server terminology instead of Kestrel-specific
IIS and HTTP.sys also enforce MaxStreamsPerConnection and request
timeouts, so the backpressure discussion should not be Kestrel-specific.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copy file name to clipboardExpand all lines: docs/concepts/sessions/sessions.md
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -482,7 +482,7 @@ How well the server is protected against a flood of concurrent requests depends
482
482
In the default configuration, each JSON-RPC request holds its POST response open until the handler produces a result. The POST response body is an SSE stream that carries the JSON-RPC response, and the server awaits the handler's completion before closing it. This means:
483
483
484
484
- Each in-flight handler occupies one HTTP/2 stream
485
-
-Kestrel's `MaxStreamsPerConnection` (default: **100**) limits concurrent handlers per connection
485
+
-The HTTP server's `MaxStreamsPerConnection` (default: **100** in Kestrel) limits concurrent handlers per connection
486
486
- This is the same backpressure model as **gRPC unary calls** — one request occupies one stream until the response is sent
487
487
488
488
One difference from gRPC: handler cancellation tokens are linked to the **session** lifetime, not `HttpContext.RequestAborted`. If a client disconnects from a POST mid-flight, the handler continues running until it completes or the session is terminated. But the client has freed a stream slot, so it can submit a new request — meaning the server could accumulate up to `MaxStreamsPerConnection` handlers that outlive their original connections. In practice this is bounded and comparable to how gRPC handlers behave when the client cancels an RPC.
@@ -534,8 +534,8 @@ Stateless mode provides the same HTTP-level backpressure as default stateful mod
534
534
535
535
| Configuration | POST held open? | Backpressure mechanism | Concurrent handler limit per connection |
0 commit comments