Workaround found: http://stackoverflow.com/questions/10883211/deadly-cors-when-http-localhost-is-the-origin
On Wednesday, July 2, 2014 8:41:40 AM UTC+10, Brent Lacey wrote: > > Just wanted to add my 2 cents as well as I have been trying to track down > a similar cors issue with a get request and angular, as soon as you add a > header to the request, my requests dont work. Some of the previous ops, > mention working with chrome, could the cause be to the failing request (if > you are sending headers) the known chrome bug with local development work. > See here: https://code.google.com/p/chromium/issues/detail?id=96007 > > I havent come across a work around yet, but i finally had some success > when trying the exact same angular app in firefox. > > > On Tuesday, May 13, 2014 2:54:34 AM UTC+10, Mathis Gardon wrote: >> >> Sorry to dig up a relatively old post, but what kevin Shay pointed out is >> important : >> >> When using CORS with a preflight request (OPTIONS verb), if you have >> everything set up correctly on the CORS side, the first OPTION response is >> handled correctly by the browser, thus it sends the POST/... request as >> expected. >> But if then an error happens in your server code and the server does not >> respond to your normal request, the chrome/firefox dev tools will say that >> there was a CORS error (because they expect a response with a CORS header >> to complete the CORS handshake). >> >> This is something rather annoying and if possible, it should be handled >> better by the browser debuggers : is there any bug ticket in ff & chrome >> for this problem ? I couldn't find one. >> >> On Friday, April 4, 2014 3:25:58 AM UTC+2, Kevin Shay wrote: >>> >>> I haven't looked at the details of your report too carefully, but one >>> thing we've noticed is that when the backend does not return any response >>> at all (i.e. a timeout), the browser confusingly reports this as a CORS >>> error due to the absence of any headers being returned. So we've seen this >>> sort of apparent CORS issue from problems that in fact had nothing to do >>> with CORS--the backend is just failing in some other way and not returning >>> a response. >>> >>> Kevin >>> >>> >>> On Thu, Apr 3, 2014 at 4:48 PM, Walter B. <[email protected]> wrote: >>> >>>> Still happening for me. We've experimented with a solution blogged >>>> about by Foursquare ( >>>> http://engineering.foursquare.com/2011/12/08/web-sites-are-clients-too/) >>>> and with a post parameter, _METHOD, containing the actual HTTP method we'd >>>> like to use. I personally like the second option, especially if your >>>> backend framework supports this functionality out of the box as ours did. >>>> >>>> >>>> On Thursday, April 3, 2014 1:32:01 PM UTC-4, Greg H. wrote: >>>>> >>>>> hey guys, >>>>> >>>>> Did anyone ever found an answer to that issue? >>>>> I'm actually experiencing the same problems with: angular 1.2, and a >>>>> rack-cors on the server side >>>>> >>>>> For some reasons it's only working when my server is local... >>>>> here is my local option req/res => https://www.dropbox.com/s/ >>>>> nc33gn5g5ykx5nh/Screenshot%202014-04-03%2009.53.30.png >>>>> and the local post req/res => https://www.dropbox.com/s/ >>>>> guykmp1etpvsli0/Screenshot%202014-04-03%2009.53.59.png >>>>> >>>>> here is when it's hitting the server side: >>>>> OPTION req/res => https://www.dropbox.com/s/ >>>>> bj5g3qg0t1cbsor/Screenshot%202014-04-03%2010.29.33.png >>>>> POST req => https://www.dropbox.com/s/8bhhoml7gjb3emy/Screenshot% >>>>> 202014-04-03%2010.30.21.png >>>>> >>>>> And i'm having exactly the same issue as you: >>>>> XMLHttpRequest cannot load U >>>>> <http://svoxipay.herokuapp.com/transactions/topup/4153618279>RL. No >>>>> 'Access-Control-Allow-Origin' header is present on the requested >>>>> resource. >>>>> Origin 'http://localhost:4567 <http://localhost/>' is therefore not >>>>> allowed access. >>>>> >>>>> thx >>>>> Le jeudi 23 janvier 2014 09:41:56 UTC-8, Walter B. a écrit : >>>>>> >>>>>> I have been having issues using the latest version of Chrome, >>>>>> AngularJS 1.2.0 rc3, and CORS set up with Apache via .htaccess. >>>>>> >>>>>> .htaccess settings: >>>>>> >>>>>> Header set Access-Control-Allow-Origin * >>>>>> Header set Access-Control-Allow-Methods "GET,PUT,POST,DELETE,OPTIONS, >>>>>> PATCH" >>>>>> Header set Access-Control-Allow-Headers "Content-Type,Accept" >>>>>> >>>>>> When a page is loaded and we perform an action on our API (different >>>>>> domain than our site) that involves a GET/POST, everything works fine - >>>>>> forever. However, if the action we take performs a PUT/DELETE or other >>>>>> less-common verb, we have a 10 second window to perform these requests >>>>>> after which all future PUT/DELETE/etc requests receive no response. Here >>>>>> is >>>>>> a sample timeline to help make this more clear: >>>>>> >>>>>> 0s - page loads >>>>>> 1s - user clicks button that triggers a DELETE >>>>>> 1.2s - OPTIONS preflight request is sent, 200 OK received >>>>>> 1.3s - DELETE request is sent, 200 OK received >>>>>> ... >>>>>> 10.2s - user clicks button that triggers a DELETE >>>>>> 10.3s - DELETE request is sent and server hangs up - no response >>>>>> received (preflight request must be cached, as it is not sent again) >>>>>> >>>>>> A sample successful preflight OPTIONS request is pasted below: >>>>>> >>>>>> Request URL:https://api.example.com/stuff/i/want >>>>>> Request Method:OPTIONS >>>>>> Status Code:200 OK >>>>>> >>>>>> Request Headers >>>>>> Accept:*/* >>>>>> Accept-Encoding:gzip,deflate,sdch >>>>>> Accept-Language:en-US,en;q=0.8 >>>>>> Access-Control-Request-Headers:accept, content-type >>>>>> Access-Control-Request-Method:PUT >>>>>> Cache-Control:no-cache >>>>>> Connection:keep-alive >>>>>> Host:api.example.com >>>>>> Origin:https://www.example.com >>>>>> Pragma:no-cache >>>>>> Referer:https://www.example.com/my/page >>>>>> User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_0) >>>>>> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36 >>>>>> >>>>>> Query String Parameters >>>>>> access_token:***** >>>>>> >>>>>> Response Headers >>>>>> Access-Control-Allow-Headers:Content-Type,Accept >>>>>> Access-Control-Allow-Methods:GET,PUT,POST,DELETE,OPTIONS,PATCH >>>>>> Access-Control-Allow-Origin:* >>>>>> Connection:Keep-Alive >>>>>> Content-Length:194 >>>>>> Content-Type:application/json;charset=utf-8 >>>>>> Date:Thu, 23 Jan 2014 17:25:33 GMT >>>>>> Keep-Alive:timeout=5, max=97 >>>>>> Server:Apache >>>>>> Set-Cookie:ROUTEID=.0; path=/ >>>>>> Via:1.1 balancer >>>>>> X-Powered-By:PHP/5.3.27-1ubuntu3.6 >>>>>> >>>>>> I have made changes to our .htaccess settings (such as setting a >>>>>> specific value for Access-Control-Allow-Origin) to verify that >>>>>> everything >>>>>> is working as expected, and have found no issues there. Open to any and >>>>>> all >>>>>> ideas/suggestions. Thanks for reading! >>>>>> >>>>>> -Walter >>>>>> >>>>>> On Monday, August 12, 2013 9:14:50 PM UTC-4, john tigernassau wrote: >>>>>>> >>>>>>> our rest server works with CURL, not with Angular http. Any help >>>>>>> appreciated >>>>>>> >>>>>>> We've tried every CORS option we can find but angular still reports >>>>>>> an error with different origin >>>>>>> >>>>>>> Node Express running on port 3026: >>>>>>> >>>>>>> app.post('/api/account', function(req,res) { >>>>>>> //res.header("Access-Control-Allow-Origin","http://localhost:3025 >>>>>>> "); >>>>>>> res.header("Access-Control-Allow-Origin","*"); >>>>>>> res.header("Access-Control-Allow-Headers","X-Requested-With"); >>>>>>> res.header("Access-Control-Allow-Methods","GET, POST"); >>>>>>> .... >>>>>>> >>>>>>> Our CURL test posts data just fine into our Node Express server >>>>>>> >>>>>>> curl -i -X POST http://localhost:8026/api/account -d >>>>>>> '{"accountname":"test", .... >>>>>>> "password":"xxx"}' -H "Content-Type: application/json" >>>>>>> >>>>>>> >>>>>>> angular running on port 3025: >>>>>>> >>>>>>> angular config: (doesn't work with / without) >>>>>>> >>>>>>> app.config(['$httpProvider', function($httpProvider) { >>>>>>> $httpProvider.defaults.useXDomain = true; >>>>>>> delete $httpProvider.defaults.headers.common['X-Requested- >>>>>>> With']; >>>>>>> } >>>>>>> ]); >>>>>>> >>>>>>> angular controller: >>>>>>> >>>>>>> $scope.subscribe = function() { >>>>>>> var resturl = 'http://localhost:3026/api/account'; >>>>>>> var jsondata = JSON.stringify($scope.account); >>>>>>> $http({ >>>>>>> method : 'POST', >>>>>>> url : resturl, >>>>>>> data : $scope.account, >>>>>>> headers: {'Content-Type':'application/json'} >>>>>>> }). >>>>>>> success(function(data){.... >>>>>>> >>>>>>> angular error msg: >>>>>>> >>>>>>> XMLHttpRequest cannot load http://localhost:3026/api/account. >>>>>>> Origin http://localhost:3025 is not allowed by >>>>>>> Access-Control-Allow-Origin. >>>>>>> localhost/:1 error >>>>>>> >>>>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "AngularJS" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> To post to this group, send email to [email protected]. >>>> Visit this group at http://groups.google.com/group/angular. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> -- You received this message because you are subscribed to the Google Groups "AngularJS" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/angular. For more options, visit https://groups.google.com/d/optout.
