Unlock rack-test version

[joshuajaco]

The version lock for rack-test breaks our bundle since we are using version > 1. pact-ruby also seems to work fine with it.

[bethesque]

Please see #164

What I'm concerned with is that a request without a content type in the pact will have a content type set by rack test. I don't have time to look into this at the moment, but if you could investigate and let me know your findings, we can get this version upgrade happening more quickly.

[bethesque]

Any progress on this @joshuajaco?

[RaVbaker]

When @bethesque are you planning to ship this unlock?

[joshuajaco]

We are unsure on how to proceed with pact and contract testing in general, I thus don't have time for this at the moment. I will look into it once I find some time.

[cabello]

This is also affecting us as we use rack-test 1.1.0.

[bethesque]

I need someone to investigate #181 (comment) before I can merge this.

[cabello]

How can we test this? From the original PR rack/rack-test#223 with breaking changes I get the sense that non-GET requests always require a content type: multipart, x-www-form-urlencoded or application/json. But one could expect a DELETE for example DELETE /collection/:id to not need a content type, would that be the scenario we are looking to test?

[bethesque]

Most people should set a content type, but what if someone is testing how the server responds when they don't set a content type? Maybe what I can do is remove the rack version dependency from the ruby version, allowing people to choose which version they want, but then hardcode it in the "standalone" so that there are no changes apparent to other users.

[bethesque]

Ok, I've set the version to '>= 0.6.3', '< 2.0.0'. Fingers crossed it doesn't cause any problems.