WIP, add/backport generic server-sent events support to Azure Core

[Xiaofei Cao (XiaofeiCao)]

Scope

Adds Azure Core support for single-response generic SSE consumption. It parses one established Response<BinaryData>; it never reconnects, replays, or sends Last-Event-Id.

• New: ServerSentEvent<T>, ServerSentEventListener<T>, ServerSentEventStreams, incremental SSE parsing, close-owning response handling, and optional typed terminal-event predicates.
• Updated: REST proxy live-body preservation, response logging protection, and SSE media-type helpers.
• Unchanged: HTTP pipeline, general policies, transports, BinaryData, and Reactor.
• Separate stacked work: generated client APIs, shared proxy declarations, and generated event conversion.

Contract

ServerSentEventStreams is exported from com.azure.core.http; parser and response-owner types remain internal. Response overloads require a Closeable response and fail fast with IllegalArgumentException otherwise. Non-204 responses require exactly one text/event-stream content type; explicit non-UTF-8 charsets are rejected. Invalid or null-body responses are closed before failure.

Existing overloads complete on EOF or HTTP 204. Predicate overloads deliver the matching typed terminal event, close the response, and complete; EOF before a match is an incomplete-stream error. All paths close the physical response on completion, failure, interruption, or Reactor cancellation.

Accept: text/event-stream preserves a live body only when its q value is syntactically valid and greater than zero.

Validation

• Focused SSE, media-type, and REST proxy tests
• Azure Core package build
• Checkstyle and SpotBugs

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).
34 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[Weidong Xu (weidongxu-microsoft)]

The incremental parser needs a bounded pending-event size before this is safe to ship.

appendByte doubles lineBytes without a maximum, and completed data: lines are accumulated in data until a blank line. A server (or intermediary) can therefore send either one unterminated line or an unlimited sequence of data: lines without an empty-line dispatch and make the client retain the entire stream until heap exhaustion. This affects both the async and listener paths.

Please enforce a documented maximum line/event size and terminate the stream with a clear exception when it is exceeded. Add tests for both an oversized single line and many bounded lines without a terminating blank line.

it is a draft

[Xiaofei Cao (XiaofeiCao)]

The incremental parser needs a bounded pending-event size before this is safe to ship.

appendByte doubles lineBytes without a maximum, and completed data: lines are accumulated in data until a blank line. A server (or intermediary) can therefore send either one unterminated line or an unlimited sequence of data: lines without an empty-line dispatch and make the client retain the entire stream until heap exhaustion. This affects both the async and listener paths.

Please enforce a documented maximum line/event size and terminate the stream with a clear exception when it is exceeded. Add tests for both an oversized single line and many bounded lines without a terminating blank line.

Some thoughts(evidence collected by agent):

• Our repo seems doesn't have a size limit for eagerly-read response body(BinaryData)
• Spring WebFlux's default event size limit is 256kb: https://docs.spring.io/spring-framework/reference/web/webflux-webclient/client-builder.html#webflux-client-builder-maxinmemorysize
• search's knowledgebase retrieval maxoutputsize official doc use 6000kb as example: https://learn.microsoft.com/en-us/azure/search/agentic-retrieval-how-to-retrieve?tabs=2026-05-01-preview&pivots=csharp#limit-final-grounding-documents
  and it's configurable
• .NET doesn't expose any event size limit in current azure-core

Spring's 256kb limit doesn't seem to fit our knowledgebase retrieval case. Since currently we don't have configuration for response body size(correct me if I'm wrong), I'd say we don't enforce this.

[Weidong Xu (weidongxu-microsoft)]

Three minor follow-ups from the API/protocol pass:

1. ServerSentEventStreams publicly accepts any Response<BinaryData>, but internally requires the runtime response to implement Closeable. Consider making that ownership requirement explicit in the API/type contract, or at least documenting it, so wrapped/custom responses don't fail unexpectedly.
2. isTextEventStreamContentType currently accepts an explicitly non-UTF-8 charset such as text/event-stream; charset=iso-8859-1, while the parser always decodes UTF-8. SSE is UTF-8-only, so an incompatible charset declaration should be rejected.
3. acceptsTextEventStream treats malformed or out-of-range quality values such as q=bogus, q=-1, and q=2 as enabled. It would be safer to validate the HTTP q-value grammar and only enable the media range for a valid value greater than zero.

These are non-blocking compared with the pending-event size concern.

[Weidong Xu (weidongxu-microsoft)]

Agent-generated Java SSE interface design comparison and recommendations: https://gist.github.com/weidongxu-microsoft/f99f792a78f16cef8c9c1674c68e7d1b

[Weidong Xu (weidongxu-microsoft)]

Agent-generated Java SSE interface design comparison and recommendations: https://gist.github.com/weidongxu-microsoft/f99f792a78f16cef8c9c1674c68e7d1b

Summary aside, this is more or less the "alternative design" we've discussed. A closable stream pattern for sync.