Fiddler is essentially just an HTTP traffic inspector which allows me to see all traffic on the machine. It clearly shows what you are indicating, i.e. the actual response is just fine but the Javascript app doesn't like it because of the missing header. The Access-Controll-Allow-Origin header is definitely not in the response. Unfortunately I doubt I'm going to have any success getting the vendor to add that header. I also cannot use our hosting server to proxy the requests because the requirement of this project was that sensitive data NOT be sent to our hosting server at all. The idea was to use an AJAX request directly to the vendor's REST service, receive a response and then proceed.
It's looking like we may have to go the JSONP road which I was truly hoping to avoid. Thanks for the info. On Thursday, July 10, 2014 2:58:56 PM UTC-7, Eric Eslinger wrote: > > I've never used fiddler, so I can't speak to that. But the specific error > is (and pardon me if I'm over-explaining something you already knew) that > the resource is coming off of the server just fine (200, plus content), but > without the Access-blah headers set on the response. This is a relatively > recent security "upgrade" that lets us get XHR requests from servers that > aren't the javascript origin (same origin policy) without having to resort > to JSONP strategies. > > If fiddler can show you the headers on the response, does it include the > Access-Control-Allow-Origin one? You should also be able to see them in the > OPTIONS request that generates the error in the chrome debug panel. It > could also be that the header doesn't specifically allow your client (you > don't have to specify *, you could specificially whitelist who is allowed > to use the service, which could be a way to keep people from repackaging > your api). It could be that the vendor's api was written from the > perspective that it there would be middleware between it and the actual > client, so it doesn't have CORS because it doesn't need it, not being > written for the browser. In that case, your server could proxy or prefetch > data and serve it back to the user. > > Or it could be something completely different, not 100% sure here due to a > lack of info. > > e > > > > > On Thu, Jul 10, 2014 at 2:25 PM, Dane Vinson <[email protected] > <javascript:>> wrote: > >> Yeah I don't believe that the issue is Chrome as the same error occurs in >> IE as well. >> >> Unfortunately I do not control the service code so I cannot change it at >> all. >> >> The piece that has me the most troubled is that according to Fiddler the >> response is a total success. For some reason Angular is swallowing the 200 >> success and forcing an error. >> >> >> On Thursday, July 10, 2014 1:02:47 PM UTC-7, Eric Eslinger wrote: >> >>> I disagree with Lucian's position there. I have gotten that error in the >>> past with some angular $http calls. Inspecting the headers on the response >>> (from the server) indicated no Access-Control-Allow-Origin headers on the >>> response. You can figure out using curl if the headers are on the response >>> at all. >>> >>> Personally, since I was also writing the backend, it was just a matter >>> of including the proper headers (I just used the 'cors' middleware since my >>> server is using express, but there's a rubygem for it too). >>> >>> If the response has a ACAO header and chrome is still complaining, then >>> yes, that's a chrome bug. But I'd be surprised if that's the case. >>> >>> Another thing to remember is proxy servers, I know I had some really >>> hairy CORS problems when my users were behind a school web firewall / >>> content filter. The content filter stripped off the CORS headers for some >>> reason I couldn't fathom, so it could be that the headers would normally >>> exist, but are being pulled out down the road. >>> >>> e >>> >>> >>> On Thu, Jul 10, 2014 at 12:47 PM, Lucian Enache <[email protected]> >>> wrote: >>> >>>> Technically CORS are not failing because of the vendor but because of >>>> your local application. >>>> >>>> Two things that come in to my mind: >>>> >>>> 1. use firefox >>>> 2. Run chrome with --disable-web-security parameter. >>>> >>>> Sent from my iPhone >>>> >>>> On 10/lug/2014, at 21:41, Dane Vinson <[email protected]> wrote: >>>> >>>> My Angular app is making a get request to an external source. The >>>> developer console in Chrome (and in IE) is showing "No >>>> 'Access-Control-Allow-Origin' header is present on the requested >>>> resource.", the result of the request is error and the promise's .error is >>>> showing a data argument which is empty. The error seems to indicate that >>>> the host service isn't set up for CORS but I have a hard time believing >>>> that as it's a national vendor who takes this sort of request routinely. >>>> Further, Fiddler is showing a response code of 200 for the request and the >>>> return data is exactly what I expect, no indication of any error. It seems >>>> quite odd that $http's get is returning error but Fiddler is showing a 200. >>>> >>>> Any help you may provide will be appreciated. >>>> >>>> Thanks >>>> >>>> -- >>>> 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. >>>> >>> >>> -- >> 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] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> 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.
