When HttpResponse.Body is replaced, the replacement is used for future requests

[jodavis]

This is a contrived example to illustrate the point:

app.Use(next => context =>
{
    if (context.Response.Body is MemoryStream)
    {
        throw new Exception("Wrong stream type in context.Response.Body");
    }

    context.Response.Body = new MemoryStream();

    return context.Response.WriteAsync("Hello, world!");
});

Run the application and browse to it. The first request returns nothing (content was written to the MemoryStream). Subsequent requests will hit the Exception.

The real-world case is when the Body stream is decorated for a given request. The decorator stream will be re-used for a subsequent request, which could result in re-decorating the stream, and ultimately produce a long chain of decorators.

It appears that Kestrel is trying to be efficient by re-using its underlying Stream instances. But the reusable instances are being replaced, with unintended consequences for future requests.

[halter73]

Nice catch. These lines should be moved outside the if condition so the streams get reset between every request.

[benaadams]

@halter73 good follow though; couldn't find what situation InitializeStreams wasn't called

[davidfowl]

Eeek 😄

[halter73]

@jodavis As a workaround until we get a new release out, you can store the original Body before replacing it and set it back before the middleware exits. Body is the same stream for all requests on a given connection when it's not replaced.