[4.x] Add content-type for the default error renderer

[adriansuter]

This PR addresses #2749.

There is one commit 419f9bd that is actually a fix (independent of the issue).

[coveralls]

Coverage remained the same at 100.0% when pulling ab1abe0 on adriansuter:patch-errorHandler into be94ac0 on slimphp:4.x.

[l0gicgate]

So one thing I noticed is that right now we're letting the request Accept header dictate which renderer is being used. Let's just take a real world example where I'm building an API and I want to force the renderer to ALWAYS be rendering in application/json, don't you agree that we should make the defaultErrorRenderer override the determined content type?

[adriansuter]

That is absolutely true. In fact, it is the route that could define, what error content type to be expected. Or the user might even set the response content type based on a route param. For example, say we have a route that would usually return html, but if we add ?json to the url, then the content type should be json. How do we know in the error handler, what content type the user would like to return?

[l0gicgate]

For example, say we have a route that would usually return html, but if we add ?json to the url, then the content type should be json. How do we know in the error handler, what content type the user would like to return?

This is why we used the Accept header in the first place.

So what I'm thinking is that we need to introduce two modes into the handler. First mode is detect which detects the content type (it would also be the default mode) and then a force mode which would force the content type to be what the user defines.

$errorHandler->forceContentType('application/json')

There's a few more things we need to do with this handler. Namely add default headers for the response since it creates an entirely new response and if you need CORS headers then you'd need to extend the ResponseEmitter in order to add headers to that response which kind of sucks. I'm not sure if we need to add setDefaultHeaders or perhaps include a way to add middleware so we can do something like:

$errorHandler->addResponseMiddleware(function (Response $response) {
    return $response->withHeader(...);
});

[adriansuter]

Would it be possible to set the forced content type in a route handler? I'm asking because if you mix different content types in the same route handler (or between different route handlers), then it should be possible to do that. Or do you recommend that the client does have to set the accept header correctly in that case?

Concerning the response headers: one callback should be enough. Or do you think that there could be more than one "middleware"? Probably some sort of ErrorResponseHeaderRenderer or ErrorResponseHeaderHandler.

[l0gicgate]

I don't think that's necessary. Also, I'm thinking that maybe we should modify the ResponseEmitter instead to give the opportunity to append default headers via there since all content that gets emitted gets funneled through there. Lets' just add the detect and the force mode to the error handler and I think we'll be good to go. We can dive into appending default headers in a separate PR.

[l0gicgate]

Is this PR good to go @adriansuter? or are you going to add the detect/force mode?

[adriansuter]

I will add the force mode.

[adriansuter]

@l0gicgate The forceContentType() is added to the error handler. I think that this should be added to the docs somewhere.

[l0gicgate]

Yes we should probably put it in the advanced error handling section