Add content-type wildcard support to validation

[kconwayatlassian]

This implements the cascading wildcard behavior described in the OpenAPI
specification for request body and response body validation.

https://swagger.io/docs/specification/describing-request-body/

Closes #91

[fenollp]

I'm thinking we either should return nil or panic or even not handle that case.
What do you think?

[fenollp]

Can there be mimes without / in them? Should this case really be considered at all?

[kconwayatlassian]

@fenollp I don't believe mime types are valid without the subtype. However, since they are arbitrary string input from a client I'd prefer if we degraded to the wildcard rather than panic. Alternatively, we can return nil for this case instead of the wildcard if that would be preferable. I'm not sure how the OpenAPI specification intends for this case to be handled other than this blerb from the docs:

*/* represents all types and is functionally equivalent to application/octet-stream

This seems to suggest that */* should be used in all cases where a better match is not found.

My concern is that if I'm using the request/response validation in production then a panic on bad input might be an avenue for denial of service if a client is sending invalid mime types. I'd prefer the response to be "400 Bad Request" wherever possible for faulty input.

[fenollp]

Agreed wrt panics.
I’d like ya to return nil as this would at least not go unnoticed. I’m sure there’s a nonzero amount of things out there that send an incorrect content type mime type but I very much prefer strictness and to discuss an optional behavior when someone has a use case.
What do you think?

[kconwayatlassian]

@fenollp I've updated the PR to return nil for cases of invalid mime types.

Adding the test for this actually exposed a bug in my initial patch where any mime type that did not have metadata such as ;encoding=utf-8 would return the double wildcard result rather than the single wildcard result if there was no direct match. I've increased the test coverage to account for this and patched the logic to behave as expected.

[fenollp]

Amazing! Thanks!