Header version ignored

[pduersteler]

This may be similiar to #124 and #74

According to several slides and docs and wiki pages, I tried this:

version 'v2', :using => :header, :strict => true, :vendor => 'test'

resource :test do
    get :first do
        "v2"
    end
end


version 'v1', :using => :header, :strict => true, :vendor => 'test'

resource :test do
    get :first do
        "v1"
    end
end

curl -H Accept=application/vnd.test-v1+json http://test.localhost.example:3000/api/test/first
curl -H Accept=application/vnd.test-v2+json http://test.localhost.example:3000/api/test/first

The requests above always returns "v2" regardless of the header being set. I also tested those without using the strict param, but got the same results.

[dblock]

Grape from the frontier branch or shipped version?

[pduersteler]

tried the shipped version, explicit master branch and frontier branch.

[rodzyn]

Try this:

curl -H "Accept: application/vnd.test-v1+json" http://test.localhost.example:3000/api/test/first
curl -H "Accept: application/vnd.test-v2+json" http://test.localhost.example:3000/api/test/first

It will be as you expected.

I don't know whether it's a but in curl on OS X or not, but my version of curl does not support grape-wiki-way of passing headers too :) (it assumes accept header as asterisk/asterisk, that's why you have always 'v2')

[pduersteler]

Thats what I've tried on my linux box and I always got response from v2.
Am 14.02.2012 22:24 schrieb "Marcin Olichwirowicz" <
reply@reply.github.com

:

Try this:

curl -H "Accept: application/vnd.test-v1+json"
http://test.localhost.example:3000/api/test/first
curl -H "Accept: application/vnd.test-v2+json"
http://test.localhost.example:3000/api/test/first

It will be as you expected.

I don't know whether it's a but in curl on OS X or not, but my version of
curl does not support grape-wiki-way of passing headers too :) (it assumes
accept header as asterisk/asterisk, that's why you have always 'v2')

---

Reply to this email directly or view it on GitHub:
#133 (comment)

[dblock]

With pull #144 it's doing the correct thing on frontier. If you're still having this issue, reopen it and post the output from curl -v (double-check that the Accept header is included properly).

[seanmoon]

I'm also having a problem with enabling the versioning in Grape.

I've created a new Rails 3.2.9 project with Grape 0.2.2 included here: https://github.com/seanmoon/grape-versioning-example

The output from curl is included in the README and there is also a spec demonstrating the issue that you can run via rspec.

In my actual project, I'd like to include V1 and V2 via separate source files, but even in this more simplified situation I'm running into an issue.

Any suggestions or help would be appreciated.

Here's the source for the API.

https://github.com/seanmoon/grape-versioning-example/blob/master/app/api/api.rb

[dblock]

I'll just reopen this.

[dblock]

I'll try to take a look at this soon-ish. A failing spec for this would be ideal of course.

[seanmoon]

Looks like the issue I'm seeing only happens when the prefix has been specified.

I've written a failing spec here: https://github.com/seanmoon/grape
Relevant (and only) changed file: seanmoon@3c1e695

The specs are also failing using path and params so it seems to be not limited to using a header if my test is failing properly.

In my example project I get a 404 when I should be getting a matching version. I am seeing the same behavior with this failing spec I wrote. I wasn't able to quickly deduce where this issue is manifesting in the code. Perhaps you would have a better idea where to start.

[dblock]

cc: @jwkoelewijn who has implemented a lot of this code, I could use some help

[dblock]

Fixed in 548ceb4

Thanks @seanmoon for the spec, you're correct, it was broken when using prefix.

Header-based versioning works by mounting every version in an identical path, including the prefix. If the version doesn't match from the header, the next one will be tried. With the prefixer middleware we would strip the prefix from PATH_INFO, so the next route would no longer match the path and therefore produce a 404.

[seanmoon]

Awesome, thanks!