Accept header handling is incorrectly designed

[omervk]

I've started working with the Accept header and have found two issues lacking:

1. When the server can not answer any of the Accept header preferences, the client should receive a 406 Not Acceptable status code, rather than a 400 Bad Request one.
2. Only checking for the ability to respond with a content type according to the Accept header after all of the logic has been run in the route causes side-effects. Assume a call that creates an object on the server that only returns application/json but receives an Accept header of text/html. The server creates the object and then fails with 4xx, not meeting the client's expectation that the object has not been created.

This is easily fixed with a custom filter, which checks for acceptability before the code is run, but I would suggest this be integrated into Ninja itself to preserve best practices.

ref: http://www.ninjaframework.org/documentation/content_negotiation.html

[omervk]

I looked into Ninja's code to create my own acceptance filter and found another big issue: https://github.com/ninjaframework/ninja/issues/488