Allow customizing the server's default error response

Version
1.6.0

Platform
Linux x86-64

Description

When hyper gets a header with 0x7f in it, it generates a 400 response with no content type specified and no body.

The problem is, our OpenApi specification for our service defines a different response for 400, which matches the behavior of our services endpoints.

However, OpenAPI 3.0.x only allows you to define multiple response types for the same response code IF and ONLY IF they ALL have a content type. You can only have one response schema per distinct content type.

This breaks our CI. Our automated tests trigger hypers default 400 response. The response does not conform with our OpenAPI spec, so the breakage is 100% correct. It's not possible to define an OpenAPI spec which includes both hypers 400 response, and our designed 400 response.

The upshot is, Hyper has squatted on 400 and we can't re-define it, if we want a valid OpenAPI specification, and a service which 100% reflects it.
So our choices if we want to use 400 and have a valid spec is return no information in the error, this is not possible for us.
This has meant we can't use 400 at all.

Interestingly, hyper internally comments the response can be any 4xx, but the trait that would be needed to customize the Server struct is not public outside the crate, so it has proven impossible to get Hyper to have different behavior than an empty 400 with no content type.

We have spent a lot of time trying to solve this, but have we missed something and it is possible to redefine what hyper will return for 400?

Start by tracing the server's default 400 response and the internal trait mentioned in the issue, paying particular attention to why the trait needed to customize Server is not public. Confirm whether the public API can support a configurable error response with a content type and body, and define done as allowing the service's OpenAPI-compatible 400 response without changing other default errors.