Buffering issues when returning an SSE response

[Kiril Karagyozov]

In the controller I'm basically returning a server-sent event by manually setting the content type, starting the response with Response.StartAsync(cancellationToken) and then directly writing data to Response.Body, finishing with a Response.CompleteAsync(). For additional context - another service is returning the SSE in a Stream, so I'm effectively just calling Stream.CopyToAsync(Response.Body, cancellationToken)

The issue I'm facing is that when the above code runs on Kestrel, the events in the stream are immediately returned and it seems like no buffering is being done.

The moment I switch to IIS or IIS Express though, something weird is going on as the client receives the response after writing to the response body has finished.

After investigating, I thought the Dynamic Response Caching module for IIS was at fault here. But it turns out that it was actually not installed on the system as shown here:

If Dynamic Response Caching is not involved, what else is going on that would screw up the SSE like that? If I have to follow common sense, does the above mean that:

1. By default, Kestrel is configured to NOT buffer the response body. (How do you control this?)
2. By default, IIS is configured to buffer the response body. (How do you control this?)

I find it weird that Kestrel would have no response body buffering by default. Is this really the case? If not, what's going on here? Am I perhaps implementing SSE in a weird way?

Calling HttpContext!.Features.Get<IHttpResponseBodyFeature>()!.DisableBuffering() fixes the issue when running under IIS/IIS Express.

.NET Version: 8.0.300-preview.24203.14

[Chris Ross]

Calling HttpContext!.Features.Get<IHttpResponseBodyFeature>()!.DisableBuffering() fixes the issue when running under IIS/IIS Express.

That's expected, SignalR's SSE implementation has to do the same. Are you still having issues, or are you just trying to understand what component was causing the problem?