dotnet / aspnetcore

ASP.NET Core is a cross-platform .NET framework for building modern cloud-based web applications on Windows, Mac, or Linux.

Home Page:https://asp.net

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Buffering issues when returning an SSE response

kikaragyozov opened this issue · comments

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:
image

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

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?