2010/5/27 Derrell Lipman <derrell.lip...@unwireduniverse.com>: > On Thu, May 27, 2010 at 14:08, Qoo Goo <qoo...@gmail.com> wrote: >> >> Hi everybody, >> >> We are facing a problem with Chrome 5 (5.0.375.55) that is driving us >> crazy. >> >> We have an application that has been working since now in main >> browsers, including IE 5 to 8, FF and Chrome. We are migrating the app >> to Qx 1.1 (originally in 0.7.4), but the problem arises in both the >> new and the old one. >> >> The error we are getting is: >> >> "qx.io.remote.Exchange: Unknown status code: 0 (4) >> Failed to send data: Error: NETWORK_ERR: XMLHttpRequest Exception 101" >> >> I've been able to find some people out there that have this same or >> similar problem (see >> http://code.google.com/p/chromium/issues/detail?id=36869), but I >> couldn't find any clue in Qooxdoo's lists, although it seems to be a >> common problem in ajax applications using XMLHttpRequest and Webkit >> engines. >> > > This is similar to the issue I was working on a day or two ago, trying to > return a more meaningful error message when cross-domain or requesting > domain was file://. In those cases, and apparently in this one too, an error > occurs in the heart of the browser's networking code, but what gets back to > the XHR handler is garbage. The linked bug in the linked bug indicates that > the result of the request is: > > xhr.onerror is called with xhr.status == 0, xhr.readyState == 4 > > readyState=4 means that the request is complete, which is when we're > supposed to look at the status code. xhr.status=0 is meaningless > information.
Yes this is exactly what I am getting. Unless you can debug the browser's code itself, it is hard to find a solution. > > Unfortunately, there's not a lot that qooxdoo can do to help you with this. > My suggestion would be to use wireshark or some similar protocol analyzer, > and look at exactly what packets are going back and forth (if any) on the > wire. If you can build a sample application that causes this problem, that I > can reproduce with chromium on Linux (I'm currently using 4.0.249.30 (Ubuntu > build 33928)), I do the wireshark trace to see what's going on. I already did it, you get out of my mind! Seriously, now I am at home and cannot do this test, but at work the sniffer showed that request arrives well to the server and server responds as expected as well. From this point of view, everything seems correct, even response's content-type (text/xml) and charset (utf-8) look well. Tomorrow I will try to send a wireshark capture, and prepare a sample that crashes. And now... some good news: it is working from my home's computer using Chromium 6.0.416.0 for Linux x64 (last nightly build for Ubuntu). At work I use Windows (I didn't say it). So it will probably be solved in near future, but now the problem we have is that we do not control browsers' updates in our customers offices. They will, as we are doing, upgrade their software and this is breaking our application. I know this has to do with Chrome and not with Qooxdoo, but I ask it here just in case any of you know a workaround. You know: sometimes, most silly things can solve this kind of problems (I've been able to do it in the past with known IE bugs). I was thinking for example in headers (one thing I didn't say is that if you create an XML file with exactly the same contents that is sent by server's script it is loaded correctly, although is not the same because you are not sending data in your request). > > Cheers, > > Derrell > Thanks a lot for your answer ------------------------------------------------------------------------------ _______________________________________________ qooxdoo-devel mailing list qooxdoo-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
