Take the 2-minute tour ×
Stack Apps is a question and answer site for apps, scripts, and development with the Stack Exchange API. It's 100% free, no registration required.

This looks like it might have been requested before:

Add CORS headers to API output

In order for CORS to work, the Access-Control-Allow-Origin header (and related headers) must be set. With CORS support, I can have client-side javascript that accesses the API methods directly, rather than proxying the data through my own server or injecting "script" tags with JSONP. The result is less load for me, less risk of injection issues, and less needless copying of data around.

CORS is supported in all browsers but Opera. Firefox and Chrome have had support for quite some time now.

https://api.stackexchange.com/2.0/users/moderators?order=desc&sort=reputation&site=stackoverflow

HTTP/1.1 200 OK
Server: nginx/0.7.65
Date: Fri, 20 Jan 2012 02:06:16 GMT
Content-Type: application/json; charset=utf-8
Connection: keep-alive
Cache-Control: private
Content-Encoding: gzip
X-AspNetMvc-Version: 3.0
X-AspNet-Version: 4.0.30319
Content-Length: 4828

Contrast that with the Glitch API:

http://api.glitch.com/simple/locations.getHubs

Access-Control-Allow-Credentials:false
Access-Control-Allow-Methods:POST, GET, OPTIONS
Access-Control-Allow-Origin:*
Access-Control-Max-Age:1728000
Connection:keep-alive
Content-Encoding:gzip
Content-Length:317
Content-Type:text/plain; charset=utf-8
Date:Fri, 20 Jan 2012 02:07:15 GMT
Server:Apache/2.2.17
Vary:Accept-Encoding

Access-Control-Allow-Origin is the important header here - it tells AJAX-enabled browsers whether or not they are allowed to access the content returned in the message.

Since this header effectively limits only AJAX-based API requests, the only security or performance issues would be related to whether or not it was "okay" for browsers to access the API methods directly via AJAX.

share|improve this question
1  
Not that it invalidates this request in any way, but note that the API does support JSONP. –  Tim Stone Jan 20 '12 at 2:36
    
@TimStone, that's my backup plan, should this be deferred. –  agent86 Jan 20 '12 at 4:06
    
This has started happening intermittently again just now. Could it be related to moving facilities or testing failover like I heard about on a recent podcast? –  hippietrail Oct 30 '12 at 10:24
1  
@hippietrail, I've noticed issues in other areas, so I'm assuming the migration has a few hiccups. If it persists, you might ask a new question to file a bug with the team - I got pinged for your comment, and I can't do anything, I'm just a guy who codes against their API for entertainment :( –  agent86 Oct 30 '12 at 13:58
    
Thanks @agent86 - I'll keep an eye out and will file a new bug report if it doesn't just go away. –  hippietrail Oct 30 '12 at 14:01
add comment

1 Answer

up vote 3 down vote accepted

The API now responds with the following headers:

HTTP/1.1 200 OK
Server: nginx/0.7.65
Date: Fri, 20 Jan 2012 18:53:44 GMT
Content-Type: application/json; charset=utf-8
Connection: keep-alive
Cache-Control: private
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST
Access-Control-Allow-Credentials: false
Content-Length: 12345

Since we don't current serve anything that requires preflighting* requests, I think this is sufficient.

*Hitting any route with an OPTIONS request results in undefined behavior, currently.

share|improve this answer
2  
Awesome. If I had cookies and a way to give them to you, I'd totally give you some. –  agent86 Jan 20 '12 at 18:59
add comment

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .