Conform Response HTTPError or even Response to HTTPResponseConvertible? (Feature Request)

[carlynorama]

OpenAPI has a introduced an ErrorHandlingMiddleware

• https://forums.swift.org/t/proposal-soar-0011-improved-error-handling/74736
• https://github.com/apple/swift-openapi-runtime/blob/main/Sources/OpenAPIRuntime/Interface/ErrorHandlingMiddleware.swift#L19

One needs to conform the errors in ones server to HTTPResponseConvertible to work with it by creating separate status, header and body var conformances of types chosen by the OpenAPI generator.

public protocol HTTPResponseConvertible {

    /// An HTTP status to return in the response.
    var httpStatus: HTTPResponse.Status { get }

    /// The HTTP header fields of the response.
    /// This is optional as default values are provided in the extension.
    var httpHeaderFields: HTTPTypes.HTTPFields { get }

    /// The body of the HTTP response.
    var httpBody: OpenAPIRuntime.HTTPBody? { get }
}

The body conformance is the tricky one because it isn't an underlying SwiftNIO type, but an OpenAPIRuntime type.

It's unclear how common it will be for people to want to use Hummingbird generated HTTPError's or Responses but perhaps this package could either:

• Extend OpenAPIRuntime.HTTPBody init to take a ResponseBody or a ByteBuffer. It takes A LOT of things already, but nothing a ResponseBody can offer.
• Extend ResponseBody with a function to provide a OpenAPIRuntime.HTTPBody or something an existing OpenAPIRuntime.HTTPBody init does take.

Then the dev could conform response types as they choose.

Additionally, it's also unclear to this dev how else the OpenAPI Generator folks intend to use this conformance elsewhere / in other middleware.

It could be beneficial to conform Response or at least HTTPError preemptively?

As a note, the OpenAPI generator throws a lot of 500 errors (!!) which this middleware was created to let devs address in their own projects. To catch the early ones it requires extending DecoderError:

• https://forums.swift.org/t/openapi-trying-to-use-soar-0011-errorhandlingmiddleware/81788

It could be a nice touch if this plugin caught those and returned the same default errors the rest of Hummingbird does (while of course allowing overrides on a specific project to match what's spec'd by the API). It might be as simple as creating a conformance to HTTPError in this Package and then the middleware will respond appropriately to the existing Hummingbird Decoding Error handlers?

[adam-fowler]

If we conform OpenAPI DecodingError to Hummingbird protocol HTTPResponseError then Hummingbird can create a correct response for these, instead of a 500.

I don't think we need to conform HTTPError to HTTPResponseConvertible. There is an element of having two systems clashing with each other here. Both OpenAPIs HTTPResponseConvertible and Hummingbird's HTTPResponseError are protocols that generate an HTTP response. HTTPError conforms to HTTPResponseError and will automatically be converted to a HTTP response when the Hummingbird server catches it. There is no need for the OpenAPI to catch it in advance.

[carlynorama]

Makes sense! I defer to your deeper knowledge of both systems.

Full disclosure, they are rethinking their own 500 errors. They seemed surprised my overrides of their 500s worked.

https://forums.swift.org/t/openapi-trying-to-use-soar-0011-errorhandlingmiddleware/81788/6

[adam-fowler]

I think you are best conforming the OpenAPI DecodingError to HTTPErrorResponse and let Hummingbird catch the errors and convert them to error Responses.

[carlynorama]

I'll try that!

[adam-fowler]

I'll try that!

If it's works we can maybe add it to the package.