POST bodies that can't be parsed should return HTTP 415 Unsupported Media Type

[atheriel]

At present, if you decorate a POST endpoint with a parser (e.g. @parser json), and the client does not send you JSON data, you'll just see a message in the console and the endpoint handler will run anyway (even though, presumably, it will fail).

I don't think this is a particularly good way to surface errors to either the client or the operator -- even with the server logs, one can't use a generic message to track down which request had the problem.

Since this is a client error, the client should get a HTTP 4xx response. It turns out there is an existing HTTP status code for exactly this situation: 415 Unsupported Media Type. I'd like to see this returned instead. And, as with #757, I'd ideally like the response body/headers to be controllable.

[meztez]

I really like your issues. Keep them coming. They are great insights into making plumber more robust.

[atheriel]

Aw, that's kind.

[schloerke]

Yes, agreed. Keep them coming @atheriel .

---

As you said, this will need its own set methods like we do with 404 and 405.

I'm wondering if this should enabled by default.

• If we do, it is a breaking change.
• If we don't, then authors are running routes with missing / malformed data.

[schloerke]

As we add more methods (and the become more off the traditional set), I'm wondering if we should have a pr_set_response_code_handler(pr, code, handler) method.

pr_set_404() and pr_set_405() could wrap this function. Adding more response handlers to plumber would just be adding to a switch statement on known handlers.

[schloerke]

Tagging #809... We should have the ability to remove filters or the ability to overwrite the defaults. Something other than "all" or "up to filter Y"