Handle improper Accept headers

[bschmeck]

We have observed situations where our API has received a request from a network scanner that has an improperly formatted Accept header. In these cases, Rack:Accept::Header.parse_media_type returns an empty array (https://github.com/mjackson/rack-accept/blob/master/lib/rack/accept/header.rb#L42) and subtype is set to nil.

This PR checks that we actually received a subtype before checking against the vendor and version regexes.

[dblock]

This is good. Fix CHANGELOG.

It would be a good idea to add some unit tests that include actual calls to vendor? and such after parsing an invalid accept header.

[dblock]

Missing a period at the end. It could also be more specific: "Fix: vendor/subtype parsing in an invalid Accept header"

[bschmeck]

Pushed a correction to the CHANGELOG, I had missed the comment from grape-bot.

vendor? and version? are private methods, which I generally don't write unit tests for, but am happy to do so if that's a common approach in grape. Do you think they should live in spec/grape/middleware/versioner/header_spec.rb? I ask because these will be the first tests for something other than #call in that spec.

[dblock]

Thanks, makes sense. I would refactor this and take parsing out of the header middleware implementation, and then we can have tests, but that's beyond the scope of this PR.

[dblock]

https://travis-ci.org/ruby-grape/grape/jobs/434730968 has a failure, I am not sure what's up with that, care to check it out?

[bschmeck]

I will try to find some time to work on extracting the parsing logic and wrapping it in tests.

I'll dig into the failure, too. It appears to be only on rails_edge, related to HashWithIndifferentAccess#except and there was just a PR merged to ActiveSupport around that.

[dblock]

I am sure it's unrelated, but we do need a green build one way or another.

[bschmeck]

The upstream problem in ActiveSupport was fixed and the build is now green for this PR.

[dblock]

Thanks, merged.