Update the controller responses (via handleAcceptRequests) to use config.web.produces[0] as the default, instead of text/html, if this array is defined (if not, it will explode in a later step, anyway). Adds tests to check for this behaviour, and some of the other behaviour of that helper, while I was at it.
While the commits thus far do not deal with this, it might be prudent to exchange the next default handlers (which result in a 404) with something like 400 Bad Request default handlers, which is something like what @rdegges mentioned in #487 . A not found is not really semantically correct. @robertjd, thoughts regarding this?
Another important thing to note is that this is a breaking change - a good number of our tests failed because they expected it to default to text/html. This can be solved by either defining a ['text/html', 'application/json'] value to the config.web.produces array, or by explicitly setting the Accept header. So far, it was exactly the reverse (explicit setting to application/json was required).
Coverage increased (+0.02%) to 68.555% when pulling 005df40255897232e2721f04788f3577d762fd4f on fix/default-response-content-type into 3b242a09b174d4a7e70fb7a9820bc0531703a2ee on master.
Update the controller responses (via
handleAcceptRequests
) to useconfig.web.produces[0]
as the default, instead oftext/html
, if this array is defined (if not, it will explode in a later step, anyway). Adds tests to check for this behaviour, and some of the other behaviour of that helper, while I was at it.While the commits thus far do not deal with this, it might be prudent to exchange the
next
default handlers (which result in a404
) with something like400 Bad Request
default handlers, which is something like what @rdegges mentioned in #487 . A not found is not really semantically correct. @robertjd, thoughts regarding this?Another important thing to note is that this is a breaking change - a good number of our tests failed because they expected it to default to
text/html
. This can be solved by either defining a['text/html', 'application/json']
value to theconfig.web.produces
array, or by explicitly setting theAccept
header. So far, it was exactly the reverse (explicit setting toapplication/json
was required).Fixes #487