Submit cross domain ajax POST request

Question

I swear I saw an article about this at one point but can not find it...

How can I perform a jQuery ajax request of type POST on another domain? Must be accomplished without a proxy. Is this possible?

Answer 1

Yes you can POST all you want, even $.post() works...but you won't get a response back.

This works, the other domain will get the POST:

$.post("http://othersite.com/somePage.php", { thing: "value" }, function(data) {
  //data will always be null
});

But the response, data in the above example, will be null due to the same-origin policy.

Answer 2

All the options I've experimented with:

1) PORK: http://www.schizofreend.nl/Pork.Iframe/Examples/ Creates an iframe and submits the post there, then reads the response. Still requires same base domain per request (i.e. www.foo.com can request data from www2.foo.com, but not from www.google.com) . Also requires you to fiddle with the document.domain property, which causes adverse side effects. And there's a pervasive problem in all the major browsers where reloading the page basically shuffles the cached contents of all iframes on the page if any of them are dynamically written. Your response data will show up in the box where an ad is supposed to be.

2) flxhr: http://flxhr.flensed.com/ Can even be used to mask jQuery's built-in ajax so you don't even notice it. Requires flash though, so iPhone is out

3) jsonp: Doesn't work if you're posting a lot of data. boo.

4) chunked jsonp: When your jsonp request is too big, break the query string up into manageable chunks and send multiple get requests. Reconstruct them on the server. This is helpful but breaks down if you're load balancing users between servers.

5) CORS: http://www.w3.org/TR/cors/ doesn't work in older browsers (IE7, IE6, Firefox 2, etc)

So we currently do the following algorithm:

• If request is small enough, use JSONP
• If not small enough, but user has flash, use FlXHR
• Else use chunked JSONP

Spend one afternoon writing that up and you'll be able to use it for good. Adding CORS to our algorithm might be good for faster iPhone support.

Answer 3

If you have control over the code running at the other domain, just let it return an appropriate Access-Control-Allow-Origin header in the response. See also HTTP Access-Control at MDC.

Answer 4

If you need to know that the POST was successful, and don't have control over the remote server:

                $.ajax({
                    type:"POST",
                    url:"http://www.somesite.com/submit",
                    data:'firstname=test&lastname=person&email=test@test.com',
                    complete: function(response){
                        if(response.status == 0 && response.statusText == "success")
                        {
                            /* CORS POST was successful */
                        }
                        else
                        {
                            /* Show error message */
                        }
                    }
                });

If there was a problem with the submission then response.statusText should equal "error".

Note: some remote servers will send the HTTP header Access-Control-Allow-Origin: *, which will result in a 200 OK HTTP status code response. In that case, ajax will execute the success handler, and this method is not needed. To look at the response just do console.log(JSON.stringify(response)); or use FireBug's 'Net' panel.

Answer 5

If you want a fire and forget POST where you don't care about the response then just submit a form to a hidden iframe. This requires a Transitional Doctype.

<form method="POST" action="http://example.com/" target="name_of_iframe">

If you want to parse the response, then using a proxy if the only real option.

If you are desperate, and control the remote site, then you can:

1. Submit a form as above
2. Set a cookie in the response (which might be blocked before the iframe could cause the cookie to be considered '3rd party' (i.e. likely to be advertising tracking).
3. Wait long enough for the response to come back
4. Dynamically generate a script element with the src pointing to the remote site
5. Use JSON-P in the response and take advantage of the data previously stored in the cookie

This approach is subject to race conditions and generally ugly. Proxing the data through the current domain is a much better approach.