Skip to content
This repository has been archived by the owner on Dec 18, 2018. It is now read-only.

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

jodavis opened this issue Jun 23, 2016 · 4 comments


Copy link

jodavis commented Jun 23, 2016

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.

Copy link

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

@halter73 halter73 added the bug label Jun 24, 2016
@halter73 halter73 added this to the 1.0.1 milestone Jun 24, 2016
Copy link

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

Copy link

Eeek 😄

@cesarblum cesarblum self-assigned this Jun 27, 2016
Copy link

@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.

xabikos added a commit to xabikos/aspnet-webpack that referenced this issue Jul 24, 2016
… add a workaround for correctly replacing the response because of a bug in kestrel aspnet/KestrelHttpServer#940
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
None yet

No branches or pull requests

6 participants