Adding a response cookie from IResourceFilter.OnResourceExecuted doesn't emit Set-Cookie when result is ViewResult

[rwasef1830]

Steps to reproduce:

Modify the default ASP.net MVC template so that the home controller looks like this:

    public class HomeController : Controller
    {
        public IActionResult Index()
        {
            return View();
        }

        public IActionResult Redirect()
        {
            return this.RedirectToAction("About");
        }

        public IActionResult About()
        {
            ViewData["Message"] = "Your application description page.";

            return View();
        }
    }

Add an IResourceFilter:

    public class TestResourceFilter : IResourceFilter
    {
        public void OnResourceExecuting(ResourceExecutingContext context)
        {
            context.HttpContext.Response.Cookies.Append("OnResourceExecuting", "1");
        }

        public void OnResourceExecuted(ResourceExecutedContext context)
        {
            context.HttpContext.Response.Cookies.Append("OnResourceExecuted", "1");
        }
    }

Register it in startup:

public void ConfigureServices(IServiceCollection services)
{
     // ...
     services.AddMvc(o => o.Filters.Add(new TestResourceFilter()));
     // ...
}

Visit /Home/Index:

• Only the OnResourceExecuting cookie is present in the Set-Cookie header.

Visit /Home/Redirect:

• The 302 response that returns has both cookies in the Set-Cookie header (OnResourceExecuting and OnResourceExecuted).
• The 200 response after the redirect (/Home/About) only has OnResourceExecuting.

This bugs breaks using CookieTempDataProvider (I ported https://github.com/brockallen/CookieTempData to MVC 6) because it depends on serializing TempData into a cookie when registered as a ITempDataProvider.

Edit: Forgot to mention, this is with ASP.net 5 / MVC 6 RC1.

[rynowak]

A resource filter's OnResourceExecuted runs after the action result, and as a result the headers may have been flushed to the client. Anything you do to headers or cookies at that point can't work because the headers have already gone out over the wire.

This works with the session provider because the session content isn't part of the response, only the session ID (which has already been determined).

If you want this to work, I'd suggest adding the response buffering middleware https://github.com/aspnet/BasicMiddleware/tree/dev/src/Microsoft.AspNetCore.Buffering

[rwasef1830]

This is interesting, because the same code worked as-is in MVC 5 / ASP.NET 4.6
I assume the older framework was buffering by default ?

Well, if this is an expected behavior, I find the silent failure surprising, maybe modifying request headers should throw an exception if the headers have gone over the wire instead of appearing to work and then silently failing.

[Eilon]

@Tratcher any thoughts on silent failure when headers are modified after they're flushed? I'm sure we've discussed this before...

[Tratcher]

It shouldn't be silent, we want it to be a loud failure. @halter73 Did this check ever get added to Kestrel?

[Tratcher]

Apparently not. aspnet/KestrelHttpServer#628 filed.

[Eilon]

Closing this bug because the observed behavior is down to two external factors:

1. Buffering on vs. off. When everything is buffered, you can set headers as you wish. With buffering off, you snooze you lose.
2. Kestrel has a bug that we will fix.