CODEWITHSUNDEEP
c#.netasp.net-core
Marc Wittke
Marc Wittke

Reputation: 3155

ASP.Net Core middleware cannot set status code on exception because "response has already started"

Related: Modify static file response in ASP.NET Core

However, I do not understand why the following code works when my business logic throws one of my custom exceptions like UnprocessableException:

try
{
    await next.Invoke(context);
}
catch (UnprocessableException uex)
{
    Logger.Warn(uex);
    context.Response.StatusCode = 422;
    var responseContent = JsonConvert.SerializeObject(new { uex.Message });
    await context.Response.WriteAsync(responseContent);
}
// more specific exceptions resulting in HTTP 4xx status

but when a totally unexpected IndexOutOfRangeException is caught by the last catch block in the chain

catch (Exception ex)
{
    Logger.Error(ex);
    context.Response.StatusCode = (int)HttpStatusCode.InternalServerError;
    var responseContent = env.IsDevelopment()
                              ? JsonConvert.SerializeObject(new { ex.Message, ex.StackTrace })
                              : JsonConvert.SerializeObject(new { Message = "An internal error occured" });
    await context.Response.WriteAsync(responseContent);
}

this exception is thrown when trying to set the status code:

System.InvalidOperationException: StatusCode cannot be set, response has already started.
   bei Microsoft.AspNetCore.Server.Kestrel.Internal.Http.Frame.ThrowResponseAlreadyStartedException(String value)
   bei Microsoft.AspNetCore.Server.Kestrel.Internal.Http.Frame.set_StatusCode(Int32 value)
   bei Microsoft.AspNetCore.Server.Kestrel.Internal.Http.Frame.Microsoft.AspNetCore.Http.Features.IHttpResponseFeature.set_StatusCode(Int32 value)
   bei Microsoft.AspNetCore.Http.Internal.DefaultHttpResponse.set_StatusCode(Int32 value)
   bei Anicors.Infrastructure.Middlewares.ScopeMiddleware.<Invoke>d__5.MoveNext()

Upvotes: 41

Views: 77428

Answers (9)

Jimmy
Jimmy

Reputation: 91

One other thing to look out for when this happens: in my exception handler middleware I was calling WriteAsJsonAsync before setting context.Response.StatusCode. You need to set the status code first (otherwise you will see this error).

Upvotes: 0

Tiaraju
Tiaraju

Reputation: 139

That would depend on your situation, but for me, as I was implementing a IAsyncExceptionFilter, setting

context.ExceptionHandled = true;

did the trick.

The whole code would look like:

 context.HttpContext.Response.Clear();
 context.HttpContext.Response.StatusCode = 500;
 context.HttpContext.Response.ContentType = MediaTypeNames.Application.Json;
 await context.HttpContext.Response.Body.WriteAsync(Encoding.UTF8.GetBytes(
        JsonConvert.SerializeObject(new
        {
            Error = "ERROR",
            Message =  "MESSAGE",
            OperationId = Guid.NewGuid()
        })));
 context.ExceptionHandled = true;

Hope it helps.

Upvotes: 0

codeMonkey
codeMonkey

Reputation: 4845

I was able to resolve this error by taking code that was creating problems and moving it to inside app.UseStatusCodePages; see longer answer here: https://stackoverflow.com/a/71652771/4009972

app.UseStatusCodePages((StatusCodeContext statusCodeContext) =>
{
    var context = statusCodeContext.HttpContext;
    if (context.Response.StatusCode == 401)
    {
        context.Response.ContentType = _applicationJsonMediaHeader;
        return context.Response.Body.WriteAsync(_serializedUnauthorizedError).AsTask();
    }

    return Task.CompletedTask;
});

Upvotes: 1

John Nyingi
John Nyingi

Reputation: 1120

The solution is quite simple. Once you write a response you should not pass the context to the request delegate; as shown in the below example.

        public async Task InvokeAsync(HttpContext context)
        {
            try
            {
                string header = "X-API-KEY";

                if(!context.Request.Headers.TryGetValue(header, out var extractedApiKey))
                {
                    await HandleError(context, "Missing X-API-KEY Header");
                }
                else
                {
                    string key = context.Request.Headers[header];
                    var appSettings = context.RequestServices.GetRequiredService<IConfiguration>();
                    string apiKey = appSettings.GetValue<string>("YUi:APIKEY");

                    if (!key.Equals(apiKey))
                    {
                        await HandleError(context, "API-KEYs Don't Match");
                    }
                    else
                    {
                        await _next(context);
                    }
                }

                
            }
            catch(Exception ex)
            {
                await HandleError(context, ex.Message);
            }

        }


        private static Task HandleError(HttpContext context, string ex)
        {
            
            HttpStatusCode code = HttpStatusCode.InternalServerError; // 500 if unexpected


            string result = JsonConvert.SerializeObject(new { error = ex });

            context.Response.ContentType = "application/json";
            context.Response.StatusCode = (int)code;

            return context.Response.WriteAsync(result);

        }

Ensure that RequestDelegate doesn't get the context in response status.

NOTE:

As soon as you set the StatusCode the context changes to Response.

Upvotes: 3

Hypenate
Hypenate

Reputation: 2064

I had this error thrown by my custom middleware, but you can check if the 'response has already started' by checking it:

    if (!context.Response.HasStarted)
        { ... }

Full code:

    private Task HandleExceptionAsync(HttpContext context, Exception ex)
    {
        if (!context.Response.HasStarted)
        {
            string result;

            context.Response.StatusCode = StatusCodes.Status500InternalServerError;
            result = JsonConvert.SerializeObject(new { error = "An error has occured" });
            _logger.LogError(ex, CreateErrorMessage(context));              

            context.Response.ContentType = "application/json";
            return context.Response.WriteAsync(result);
        }
        else
        {
            return context.Response.WriteAsync(string.Empty);
        }
    }

Upvotes: 18

Dan Bitter
Dan Bitter

Reputation: 259

In my case, I was trying to print to the console to debug some stuff, and found Response.WriteAsync(); from somewhere on the internet. I pasted it to the top of my method, and that's why I was getting the error "System.InvalidOperationException: StatusCode cannot be set because the response has already started."

Removing the Response.WriteAsync("test") method solved my issue! The simplest things ¯_(ツ)_/¯

Thanks to CularBytes' suggestion of return new EmptyResult(), which printed my WriteAsync("test") and exposed my mistake.

Upvotes: 2

J.P.
J.P.

Reputation: 5763

Just to weigh in here: I received this error from a controller that handled WebSocket connections. When the WebSocket connection was closed (user closes browser tab), this exception got thrown: System.InvalidOperationException: StatusCode cannot be set because the response has already started. Note also that that controller responsible for handling the WebSocket connection is nowhere to be found in the stacktrace:

System.InvalidOperationException: StatusCode cannot be set because the response has already started.
   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpProtocol.ThrowResponseAlreadyStartedException(String value)
   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpProtocol.set_StatusCode(Int32 value)
   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpProtocol.Microsoft.AspNetCore.Http.Features.IHttpResponseFeature.set_StatusCode(Int32 value)
   at Microsoft.AspNetCore.Http.Internal.DefaultHttpResponse.set_StatusCode(Int32 value)
   at Microsoft.AspNetCore.Mvc.StatusCodeResult.ExecuteResult(ActionContext context)
   at Microsoft.AspNetCore.Mvc.ActionResult.ExecuteResultAsync(ActionContext context)
   at Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker.InvokeResultAsync(IActionResult result)
   at Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker.InvokeNextResultFilterAsync[TFilter,TFilterAsync]()
   at Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker.Rethrow(ResultExecutedContext context)
   at Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker.ResultNext[TFilter,TFilterAsync](State& next, Scope& scope, Object& state, Boolean& isCompleted)
   at Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker.InvokeResultFilters()
   at Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker.InvokeNextResourceFilter()
   at Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker.Rethrow(ResourceExecutedContext context)
   at Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker.Next(State& next, Scope& scope, Object& state, Boolean& isCompleted)
   at Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker.InvokeFilterPipelineAsync()
   at Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker.InvokeAsync()
   at Microsoft.AspNetCore.Builder.RouterMiddleware.Invoke(HttpContext httpContext)
   at Microsoft.AspNetCore.StaticFiles.StaticFileMiddleware.Invoke(HttpContext context)
   at Microsoft.AspNetCore.Cors.Infrastructure.CorsMiddleware.Invoke(HttpContext context)
   at MyApp.Middleware.MyAppNotFoundHandlerMiddleware.Invoke(HttpContext context) in C:\Proj\MyApp\Middleware\MyAppNotFoundHandlerMiddleware.cs:line 24
   at MyApp.Middleware.MyAppExceptionHandlerMiddleware.Invoke(HttpContext context) in C:\Proj\MyApp\Middleware\MyAppExceptionHandlerMiddleware.cs:line 26
   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpProtocol.ProcessRequests[TContext](IHttpApplication`1 application)

Here's the controller action where it went wrong:

[HttpGet]
[AllowAnonymous]
public async Task<IActionResult> Get()
{
    if (HttpContext.WebSockets.IsWebSocketRequest)
    {
        var socket = await HttpContext.WebSockets.AcceptWebSocketAsync();
        Clients.Add(socket);
        await WaitForClose(HttpContext, socket);
    }
    return Ok();
}

And as mentioned by the other answers, the culprit is the return Ok(). This statement is executed when the socket closes, but by then, the HTTP connection has long been closed.

I was using the NuGet package Microsoft.AspNetCore.WebSockets version 2.1.0.

Upvotes: 10

CularBytes
CularBytes

Reputation: 10321

Since this is the top search result on Google, I might as well tell new comers how I came up with this error. I was trying to use this answer by zipping files and downloading them (streaming) to the client. I returned return Ok() at the end of the actual controller action. I needed to return return new EmptyResult()

Upvotes: 69

Marc Wittke
Marc Wittke

Reputation: 3155

Oh, well, I was investigating further and while trying to reproduce the case more isolated I found the root cause.

But first some history: I've seen these errors then and when in production, but never was able to reproduce it. Now I am developing another feature and due to an error in my database structure on my development machine this error happens on every request using a decently joined query. So I thought, hey, that's the moment to resolve this issue... but it ended up here.

However, trying to isolate it more, I made an action just throwing a NotImplementedException in my face. And guess what: it works as expected. HTTP 500, no "StatusCode cannot be set, response has already started".

What's the difference? The difference is, that my other failing controller returns this:

IQueryable<MySearchRecords> searchResult = service.Search(/*snipped boring stuff*/);
var result = DataSourceLoader.Load(searchResult, loadOptions);
return Ok(result);

while DataSourceLoader is a .net class to support DevExpress' DevExtreme JS Framework. It turns out, that result is object, because it returns either a plain array or a wrapping type that also provides some metadata (e.g. for paging and stuff). In my case it applies some Take and Skip but: does not enumerate the search result but returns an IQueryable<>! So enumerating is not done earlier than during rendering the result to JSON. That's why I see the InvalidOperationException above in this special case, but not when throwing it directly from the controller.

Nevertheless, it shows that my exception handling is not working as expected in all cases. I've read that you can replace the whole response stream to avoid this issue, but this has some downsides. So what would be the right way of handling such a situation? I'd like to have the HTTP 500 with my custom JSON content anyway.

Upvotes: 3

Related Questions