Support for asynchonous request handling #2

wants to merge 8 commits into


None yet
9 participants

ept commented Aug 10, 2011

Hi Calvin, thanks for rack-cors, loving it!

We're using asynchonous request processing in our app — you throw :async to tell the web server (e.g. thin) that the response will be sent later; then the web server can serve other requests, and once the response is ready, it is sent out via env['async.callback'].call([status, headers, body]).

I've extended rack-cors to support adding the CORS response headers to asynchonous responses as well. This is done by catching and re-throwing the throw :async, and by wrapping Rack's async callback in a proxy which adds the appropriate headers.

Feel free to use this change if you want :)


sujal commented Nov 26, 2011

Hey folks, I've forked cyu's master branch and merged in this request. I then modified it to add support for Goliath (and any other server, I believe, that returns a status of -1 instead of throwing :async. My branch is here:

Let me know what you think. I don't have a handy test case for the "throw" case, so if you could make sure I didn't break anything, that would help.

I do need think of a way to write a test for this. Not sure yet how to tackle that.

Replacing env['async.callback'] should happen before calling original app inside of catch(:async){} cause application could save it to local variable before throwing :async

Would love to see @sujal's fork make its way into rack-cors. :)

Why will you not merge this?

Actually it works to use async-rack instead:

require 'async-rack'

module AsyncRack
  class Cors < AsyncCallback(:Cors)
    include AsyncRack::AsyncCallback::SimpleWrapper

cyu commented Oct 31, 2013

I haven't had the opportunity to understand async handling in Rack works. I'll try to block off some time to look into this.

demisx commented Feb 14, 2014

Any update on this please? Will this be merged?


Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment