Skip to content

Commit 62a11b9

Browse files
halter73Copilot
andcommitted
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>
1 parent 88bad8b commit 62a11b9

File tree

1 file changed

+3
-3
lines changed

1 file changed

+3
-3
lines changed

docs/concepts/sessions/sessions.md

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -482,7 +482,7 @@ How well the server is protected against a flood of concurrent requests depends
482482
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:
483483

484484
- 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
486486
- This is the same backpressure model as **gRPC unary calls** — one request occupies one stream until the response is sent
487487

488488
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
534534

535535
| Configuration | POST held open? | Backpressure mechanism | Concurrent handler limit per connection |
536536
|---|---|---|---|
537-
| **Stateless** | Yes (handler = request) | HTTP/2 streams, Kestrel timeouts | `MaxStreamsPerConnection` (default: 100) |
538-
| **Stateful (default)** | Yes (until handler responds) | HTTP/2 streams, Kestrel timeouts | `MaxStreamsPerConnection` (default: 100) |
537+
| **Stateless** | Yes (handler = request) | HTTP/2 streams, server timeouts | `MaxStreamsPerConnection` (default: 100) |
538+
| **Stateful (default)** | Yes (until handler responds) | HTTP/2 streams, server timeouts | `MaxStreamsPerConnection` (default: 100) |
539539
| **SSE (legacy — opt-in)** | No (returns 202 Accepted) | None built-in; GET stream provides cleanup | Unbounded — apply rate limiting |
540540
| **Stateful + EventStreamStore** | No (if `EnablePollingAsync()` called) | None built-in | Unbounded — apply rate limiting |
541541
| **Stateful + Tasks** | No (returns task ID immediately) | None built-in | Unbounded — apply rate limiting |

0 commit comments

Comments
 (0)