Summary
ServerSentEventReader parses lines via StreamReader.ReadLineAsync, which buffers a single line without an upper bound. A server (or man-in-the-middle) sending one endless line with no terminator could grow the buffer until the client runs out of memory.
The SSE slice design (docs/superpowers/specs/2026-06-14-sse-slice-design.md §4) calls for "a bounded line buffer [to guard] against unterminated input"; the current implementation meets the parsing rules but not this bound.
Proposed direction
- Add a configurable maximum line length (e.g. a default cap of ~1 MiB) to the reader /
SseReconnectOptions.
- When a single line exceeds the cap before a terminator is seen, fail with a clear
StreamingException (or a dedicated SSE error) rather than buffering unboundedly.
- A custom incremental line reader is likely needed since
StreamReader.ReadLineAsync has no length cap.
Notes
- Low severity for the common trusted-API-server case, but a genuine resilience/DoS hardening for untrusted or proxied streams.
- BCL only; trim/AOT-safe.
Summary
ServerSentEventReaderparses lines viaStreamReader.ReadLineAsync, which buffers a single line without an upper bound. A server (or man-in-the-middle) sending one endless line with no terminator could grow the buffer until the client runs out of memory.The SSE slice design (
docs/superpowers/specs/2026-06-14-sse-slice-design.md§4) calls for "a bounded line buffer [to guard] against unterminated input"; the current implementation meets the parsing rules but not this bound.Proposed direction
SseReconnectOptions.StreamingException(or a dedicated SSE error) rather than buffering unboundedly.StreamReader.ReadLineAsynchas no length cap.Notes