Http4s blaze should provide better feedback when rejecting a bad request (400)

[RafalSumislawski]

I'll start explaining myself with an example. Let's say we deploy an http4s blaze server with info level logging. We then hit the server with a request for http://127.0.0.1:8080/foo?bar={} and get 400 in response. The response body is empty - no feedback there. The logs? No info there too. (for now, let's not discuss why this is a valid URL according to Firefox and Chrome and an invalid according to parboiled)

Switching logger level to debug, would give us the precious error message. But IMO using debug logs on production is not the way to go. I would like the problem to be diagnosable "by default", and the IMO info level is the "default" for production. So what can we do about it?

1. This log could be an info level log.
2. The response message could contain error information.

I can make a PR for one or both of these, but I would like to first hear your (maintainers'/community) opinion on that. Especially I would like to know which solution you would prefer.

[rossabaker]

I'm sorry for the overdue reply, and thank you for reporting.

I'm reluctant to log full stack traces on client errors, because logging stack traces at high volume can really gum up a server, and it becomes an attack vector. I prefer Option 2.

I like what Jetty does. In response to this request,

GET foo/bar HTTP/1.0

We get:

HTTP/1.1 400 Bad URI
Content-Type: text/html;charset=iso-8859-1
Content-Length: 50
Connection: close
Server: Jetty(9.4.39.v20210325)

<h1>Bad Message 400</h1><pre>reason: Bad URI</pre>

It tells us the broad category of what's wrong, without putting anything into the body that could be used in an XSS attack.