Fix do_not_route_options! handling: do not respond to OPTIONS if disabled!

[jf]

FYI: so apparently this wasn't caught by spec/grape/dsl/routing_spec.rb. Not too sure how to fix that.

[dblock]

First, there should be a test for the fixed behavior, please.

[dblock]

If this is caused by #1120 then the CHANGELOG should be a bit clearer.

[jf]

No, it's not caused by #1120. #1120 is a separate issue. Just to be clear, I can fix #1119 with this PR. But #1120 still remains.

[dblock]

Thanks @jf. The only think I am missing in this PR is a test for #1119 being fixed.

[jf]

Can I get some clarification on that?

"Test for #1119 being fixed":

• would that refer to my 2nd commit for this PR which fixed the Travis build (jf@cb44238)?
• are you looking for something less brittle and not reliant on a fixed ordering of the options as per now? (Because that's what broke Travis. A change in the order)
• if you're talking about putting something into spec/grape/dsl/routing_spec.rb, now that I've had the chance to see it, would you say that Travis has highlighted that I should be looking to fix spec/grape/api_spec.rb instead (which I have sort of done; but am happy to make the test little brittle as mentioned) ?

[dblock]

The order of headers isn't the problem in the bug. There should be a test (in any spec appropriate) that reproduces the actual problem, aka that the API responds to OPTIONS when it shouldn't. That test should fail without the fix. Does this help?

[arempe93]

@jf Is the objective of this PR to remove OPTIONS from the Allow header when do_not_route_options! is active?

[jf]

Yup. That was the spirit of jf@3f3c0ba. OPTIONS should not be be advertised as an allowed method when do_not_route_options! is set. Thanks for completing this! Don't know why I didnt describe the patch better, but at least now with the test, I know that things work as intended. Thanks!

[dblock]

So this can be closed in favor of #1266. @jf reopen if I got it wrong.