Access-Control-Allow-Origin is returned only if Origin header is set
See original GitHub issueRails 3.2.13, Ruby 2.0.0, Mongoid config/application.rb:
...
config.middleware.use Rack::Cors do
allow do
origins '*'
# location of your API
resource '/api/*', :headers => :any, :methods => [:get, :post, :options, :put]
end
end
Using HTTPie:
http -h http://localhost:8080/api/organizations
Access-Control-Allow-Origin
is NOT returned
If I set an Origin header:
http -h http://localhost:8080/api/organizations Origin:http://ohanapi.org
I get:
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: GET, POST, OPTIONS, PUT
Access-Control-Allow-Origin: http://ohanapi.org
Is this expected? I was under the impression that Access-Control-Allow-Origin
would be set to *
even if no Origin was specified.
GitHub’s API returns *
when no Origin is specified. How can I get that behavior as well?
Issue Analytics
- State:
- Created 10 years ago
- Reactions:2
- Comments:8 (1 by maintainers)
Top Results From Across the Web
Access-Control-Allow-Origin - HTTP - MDN Web Docs - Mozilla
The Access-Control-Allow-Origin response header indicates whether the response can be shared with requesting code from the given origin.
Read more >Spring CORS No 'Access-Control-Allow-Origin' header is ...
No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:63342' is therefore not allowed access.
Read more >CORS and the Access-Control-Allow-Origin response header
The CORS specification identifies a collection of protocol headers of which Access-Control-Allow-Origin is the most significant. This header is returned by ...
Read more >Fixing "No 'Access-Control-Allow-Origin' Header Present"
"No 'access-control-allow-origin' header present" is one of the least ... If the constraints set by the resource are met by the script's ...
Read more >The Access-Control-Allow-Origin Header Explained
How to use and when to pass this header. Here's an example of values you can set: Access-Control-Allow-Origin : * : Allows any...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
This issue is 3 years old, but this strict interpretation is indeed causing us issues as described by folks above. In particular, we would like to cache a VERY specific set of headers as our response for our javascript files, regardless of whether the origin is set. By varying the responses based on the request, it is possible for us to have the wrong responses get set in our CDN’s cache, which causes subsequent valid requests to fail.
We might have to manually add these headers as suggested, but I welcome other suggestions or options to force this header.
On a related note, imagine that we have a very particular domain (example.com) that we’d like to specify as a valid origin. So, we’d like to always respond with the header:
Access-Control-Allow-Origin: http://example.com
, regardless of which origin was used in the request. At present, even if we do specify a origin, if we specify an origin other than example.com, the CORS headers are not returned. I realize that this is to spec, but is there a way to force these headers to show up, even if the origin is incorrect?We couldn’t use the workaround suggested by @snikch as adding
Vary: Origin
prevents our CDN from caching any requests, so we ended up writing another middleware to inject a fakeOrigin
header into all requests before they hitrack-cors
:In
application.rb
: