Trouble reading stream from HttpContext.Response.Body in an ActionFilterAttribute

[guardrex]

Might be an issue ... or more likely ... my noob 👶 status with MVC. I can post on SO if this definitely not an "issue."

I'm setting up an ActionFilterAttribute to do some OnActionExecuted post processing of content. I can write to the HttpContext.Response.Body with a StreamWriter ... that works just fine. I'm trying to get the content so I can work with it before writing it out, but attempts to use HttpContext.Response.Body constantly give me Stream was not readable. How do I read Response.Body here, or is the fact that I can't read the stream an issue?

This works fine and will shoot the text out as the output of the View() when the ActionResult has the filter annotation:

public class PostProcessFilterAttribute : ActionFilterAttribute {
    public override void OnActionExecuted(ActionExecutedContext filterContext) {
        var content = filterContext.HttpContext.Response;
        using (var responseWriter = new StreamWriter(content.Body, Encoding.UTF8)) {
            responseWriter.Write("This is some text to write!");
        }
        base.OnActionExecuted(filterContext);
    }
}

This attempt to read the Response.Body chokes:

public class PostProcessFilterAttribute : ActionFilterAttribute {
    public override void OnActionExecuted(ActionExecutedContext filterContext) {
        var content = filterContext.HttpContext.Response;
        // Next line throws "Stream was not readable"
        using (var responseReader = new StreamReader(content.Body)) {
            // I'd like to do some work with the stream here before shooting it back out
            using (var responseWriter = new StreamWriter(content.Body, Encoding.UTF8)) {
                responseWriter.Write(responseReader.ReadToEnd());
            }
        }
        base.OnActionExecuted(filterContext);
    }
}

[guardrex]

There is one one SO answer that seems relevant (same exception). The post suggests something like:

var buffer = new MemoryStream();
var stream = filterContext.HttpContext.Response.Body;
filterContext.HttpContext.Response.Body = buffer;
buffer.Seek(0, SeekOrigin.Begin);
var reader = new StreamReader(buffer);
string responseBody = reader.ReadToEnd();                    
MemoryStream msNew = new MemoryStream();
using (StreamWriter wr = new StreamWriter(msNew)) {
    wr.WriteLine("This is my new content");
    wr.Flush();
    msNew.Seek(0, SeekOrigin.Begin);
    msNew.CopyTo(stream);
}

... but that is not working and resulting in a reset connection.

[benaadams]

There is one one SO answer that seems relevant (same exception).

In the SO post they replace the response body stream (probably as the first stage in the pipeline) with a memory stream, then run the rest of the pipeline on it:

await next();

Then edit the response, before flushing it to the original response body stream:

await msNew.CopyToAsync(stream);

I imagine the original response body stream would be CanSeek == false and CanRead == false as it can flush to the network rather than trying to keep the entire response in memory.

[guardrex]

Turns out that MVC handles the responses completely if it comes before the SO answer code in Configure. I'm looking for a post-processing option after Mvc has done it's bit.

Will someone on the team confirm ...

I imagine the original response body stream would be CanSeek == false and CanRead == false as it can flush to the network rather than trying to keep the entire response in memory.

... and does that mean that I will never be able to get the rendering stream in ActionFilterAttribute/OnActionExecuted?

... if things aren't going to work out for me that way, how about setting up an HttpResponse.Filter? ... (would that be an IFilter?) for my ActionFilterAttribute/OnActionExecuted?

[nil4]

@guardrex: it appears you found the answer to your questions since you closed this issue. Could you please share the information you found?

[guardrex]

@nil4 The ActionFilterAttribute - ActionExecutedContext doesn't expose the response stream that can be read as @benaadams suggested. I still think it's strange (because there are examples online showing in earlier frameworks/versions of MVC that it can be read and written), but that's the way they have it setup.

I ended up going with a work-around to compress (GZip) output: I'm using IIS to compress the app's output. I couldn't set compression at the application level in IIS ... I had to set it at the Sites level, because Web Deploy will reset the Dynamic Content Compression if you only activate it at the app level; however, if set at the Sites level, the app will inherit the setting after deployment. [I reported this Web Deploy behavior on the IIS Forums, but apparently, this is normal behavior for Web Deploy.]

I would like to investigate using a global filter:

public static void RegisterGlobalFilters(GlobalFilterCollection filters)
{
    filters.Add(new GZipStream(Context.HttpContext.Response.Body, CompressionMode.Compress));
}

... but I don't know if the stream will be available for a filter either, and I haven't researched how to implement a global filter yet.

Actually, I don't really prefer either of these approaches. I would much prefer to decorate individual controller actions for compression with an ActionFilterAttribute. That would rock!

Anyway ... I'm going to re-open since I'm not the only one interested in this issue and would still like to get full control of that stream there. [Also note to @stephentoub ... since this might be a CoreFX thing.]

[benaadams]

@guardrex You'd need someone better informed for Attribute use in MVC6 to comment; but for what you are trying to do you can probably do this, if you insert it before app.UseMvc(); in your Startup class:

app.Use(async (context, next) =>
{
    // Set Gzip stream.
    context.Response.Headers.Item("Content-Encoding") = "gzip";
    // Wrap response body in Gzip stream.
    var body = context.Response.Body; 
    context.Response.Body = new GZipStream( body, CompressionMode.Compress);
    await next();
});

Though that will compress everything, which might not be what you want

[guardrex]

@benaadams I was hoping for an attribute that could decorate individual controller actions for fine control, but I like your code sample. Being new to the pipeline, I might be asking a "dumb" question:

I'm confused about how the pipeline works here in that you say to put that app.Use(...) code before the app.UseMvc(). I thought that these ran in sequence. I would perhaps expect a filter to work that way, but it seems strange that the response would be compressed before Mvc does it's request/response work. I know the flip-side of this doesn't work ... when I put app.UseMvc() before an app.Use(...), Mvc handles the entire request/response ... like it doesn't call a next() at the end ... but maybe that's an option that I can set in the app.UseMvc() and I'm just not aware of how to do that.

[benaadams]

I thought that these ran in sequence. I would perhaps expect a filter to work that way, but it seems strange that the response would be compressed before Mvc does it's request/response work.

What you are thinking is correct; in the example I'm wrapping the response stream in a gzip stream, which needs to happen before its written to, rather than after.

In the SO example you linked to; again they did the same; however they swapped the response stream for a memory stream, when you can then seek and read, and after await next(); is called the rest of the pipeline after has run so you then have result in the memory stream; which you can do what you want with; and then copy the result back to the original response stream.

The app.Use( ... ) items handle both before and after chosen by you where you call await next(); its quite a powerful system.

[guardrex]

@benaadams I see ... and you can see how "linear" my thinking was with regard how streams process data. I simply didn't get it until now. Thanks for clearing that up for me.

I'm going to run one more round of testing later today and report back. I'll leave this open just a bit longer in case one of the team members wants to say if it's impossible by design that the ActionExecutedContext response stream is going to remain unreadable ... or maybe that wasn't what they intended.

[nil4]

@guardrex: thank you for reopening the issue!

[benaadams]

Well ideally you are right and you'd want to do it selectively by marking controllers with attributes; but alas I'm not sure how you'd do that and blend the two approaches; is probably a way.

[benaadams]

@guardrex you could with an ActionFilter that runs before rather than after and wrap the stream in it

[guardrex]

@benaadams The global case (and using IIS as I'm doing now) were truly work-around approaches. I really just wanted to use attributes and not have any global response processing (if that's what you meant by 'blending' there).

The reason this all came about was that there were some edge cases where gzipping the response would break the page I was rendering. Those were really "edge" cases. For example, I had a problem in one app gzipping some Google Maps markup. That issue isn't a problem right now. I just thought it would be cool if we could post-process responses via attributes and get a lot of fine control. It has very wide applications well beyond compression ... if we could get that response context body after the controller action runs, you could do anything under the Sun with it ... that would be cool.

you could with an ActionFilter that runs before rather than after and wrap the stream in it

Yes, I hope the stream is readable in that context. I can't remember if I tried that or not. I'll give it a shot this evening and report back.