freezes on :options... do I need a route for this?

[cyu]

freezes on :options... do I need a route for this?

[nashby]

Yeah, you can use something like this to add OPTIONS support for your route:

match :foo, via: [:get, :options], controller: 'users'

(I know it was 8 months ago but still)

[monfresh]

@dfl Here is how I got it to work in Rails 4.0:

# config/application.rb
config.middleware.use Rack::Cors do
  allow do
    origins '*'
    resource '*', headers: :any, methods: [:get, :put, :patch, :post]
  end
end

# config/routes.rb
match '/locations' => 'locations#render_204', via: [:options]
match '/locations/:id' => 'locations#render_204', via: [:options]

# app/controllers/locations_controller.rb
def render_204
  head 204
end

With that in place, I can now issue an OPTIONS request like so:

curl -i http://www.lvh.me:8080/api/locations/1 -H "Origin: http://example.com" -X OPTIONS

And I get the correct headers in the response:

Access-Control-Allow-Origin: http://example.com
Access-Control-Allow-Methods: GET, PUT, PATCH, POST
Access-Control-Expose-Headers:
Access-Control-Max-Age: 1728000
Access-Control-Allow-Credentials: true

If you have many resources and routes that need to be able to respond to an OPTIONS request, you can create a separate controller that just defines the render_404 method. For example:

# app/controllers/cors_controller.rb
class CorsController < ApplicationController
  def render_204
    head 204
  end
end

Then send all requests to that controller:

# config/routes.rb
match '*foo' => 'cors#render_204', via: [:options]

@cyu Does this look right to you? If so, I think it should be documented in this repo as it's not obvious to CORS beginners. I'd be happy to submit a PR for a README update, or I can add a Wiki page.

[cyu]

@monfresh this looks great - yes a PR would be great!

[cyu]

This issues is a duplicate of #44

[cyu]

Ok, reviewing this issue in context #57, there does seem to be an issue here, but it's not what you'd expect.

The issue as I see it is that non-preflight OPTIONS requests are returning CORS headers when they shouldn't be. The curl command @monfresh used in his example isn't a valid Preflight request (it's missing the Access-Control-Request-Method header which is required for Preflight). That request should be treated as a non-CORS request and not return those headers at all.

I'm going to create a new issue and close this one.