I’ll broadly agree with Vagrant on the cause:
- your action was executing, writing markup to response stream
- the stream was unbuffered forcing the response headers to get written before the markup writing could begin.
- Your view encountered a runtime error
- Exception handler kicks in trying to set the status code to something else non-200
- Fails because the headers have already been sent.
Where I disagree with Vagrant is the “cause no errors in binding” remedy – you could still encounter runtime errors in View binding e.g. null reference exceptions.
A better solution for this is to ensure that Response.BufferOutput = true;
before any bytes are sent to the Response stream. e.g. in your controller action or On_Begin_Request in application. This enables server transfers, cookies/headers to be set etc. right the way up to naturally ending response, or calling end/flush.
Of course also check that buffer isn’t being flushed/set to false further down in the stack too.
MSDN Reference:
HttpResponse.BufferOutput