Parse JSON when lower-case content-type is given

[mopp]

Thank you for your nice gem to make our application robust.
I would like to fix a small problem.

Problem to be solved

committee doesn't parse the response when content-type: application/json header is given.
Then, the validation failed due to comparing an object and String.

{
    "id":"invalid_response",
    "message":"#/paths/~1characters/get/responses/200/content/application~1json/schema expected object, but received String: \"{\\\"Otonokizaka\\\":[\\\"Honoka.Kousaka\\\"]}\""
}

How to solve it

Parse also the response when content-type: application/json.

Alternative

Convert the given headers into Rack::Headers always at

committee/lib/committee/middleware/response_validation.rb

Line 15 in 8e3e43d

status, headers, response = @app.call(request.env)

But the Rack::Headers was introduced in rack 3.0.0.beta1
So we need to change the committee requirement in this way.

s.add_dependency "rack", ">= 1.5", "< 3.2" 

References

• Are HTTP headers case-sensitive? - Stack Overflow

  • Each header field consists of a name followed by a colon (":") and the field value. Field names are case-insensitive.

• rack/SPEC.rdoc at v3.1.9 · rack/rack

  • Header keys must not contain uppercase ASCII characters (A-Z)

• Make content_type case insensitive ota42y/openapi_parser#178 (comment)
  • This comment also refers to the same problem.

[geemus]

Hey, thanks for the detailed report and references. I think it might make sense to think about using an approach very similar to what we did in openapi_parser. At least presently we only really care about the content-type header, so we probably don't need the full Rack headers stuff, but it would still be good to allow any variation of capital letters for content type (so lower, title, upper or whatever mix really).

So we could use a detect + casecmp to figure out the variation in use:

    content_type_key = headers.keys.detect { |k| k.casecmp?('Content-Type') }

And then lookup the value underlying that:

    headers.fetch(content_type_key, nil)&.start_with?('application/json')

I think that feels like a relatively minimal change and would resolve the issue. What do you think?

Beyond that it looks like there might be some lint issues for us to cleanup, but we can deal with that once we settle on a fix. Thanks!

[mopp]

@geemus Thank you for reviewing ✨
Your way looks good and I followed them.

I pushed the changes separately. But I can squash them into a commit if you prefer.

[geemus]

lgtm, thanks!

[geemus]

released in v5.5.1