Issue

Traces for requests with an unsupported media type are reported as errors, even though they are client errors. Reporting them as server errors clouds real issues and makes alerting vulnerable to malformed client requests.

Specs

• spandex_phoenix version: 0.4.2
• phoenix version: 1.4.17

Background

We've recently been the target of scraping for WordPress vulnerabilities. These scrapers use the /wp-admin/admin-ajax.php route and attempt to send form data to it. When such a request is sent to a Phoenix endpoint that uses the Plug.Parsers plug without pass: ["*/*"], it rightfully raises a Plug.Parsers.UnsupportedMediaTypeError which gets caught by Phoenix and rendered as a "415 Unsupported Media Type" response.

We're using the use SpandexPhoenix approach instead of telemetry (Phoenix 1.4), and since it listens to exceptions raised in the entire endpoint pipeline and marks traces that raised errors as "error traces", we ended up with this kind of traces in Datadog:

Since we had monitors configured to alert us on increased error rates, they started firing. This means that anybody who wanted to mess with our monitoring could just prepare requests with an incorrect Content-Type and fire away.

Solution

As a general solution I think we shouldn't catch errors raised in the endpoint pipeline, but let Phoenix handle them and only check the response status. I'm don't know that much about Phoenix and how it processes the request to suggest any specific solution though.

However, I've noticed 404s aren't suffering from this issue since Phoenix.Router.NoRouteError is explicitly handled in SpandexPhoenix. So I've implemented a fix that does exactly the same but for Plug.Parsers.UnsupportedMediaTypeError since plug is a dependency of spandex_phoenix. We've shipped it to production and seems to solve the issue - PR incoming.