Hi Derrell and everyone, We've been able to solve the problem. It was one of those kind of extremely silly problems that sometimes are hard to find. I post the explanation here just to prevent others (we've lost almost two days of work!).
I was just that we were closing the socket in server side. I don't now why, but in one of our server's scripts we were erroneously calling (asp.net) Response.Close() instead of Response.End() after flushing contents to the client. The first method closes the socket and it seems that Google Chrome 5 (only Chrome 5) doesn't like it. It can't handle this kind of "reset by peer" event, even when the script has finished sending its contents (related with the keep-alive?). All other browsers, including FF, IE, Opera, Safari and other Chrome/Chromium versions (older and newer) handle it without problems. Thanks again, Al 2010/5/27 Derrell Lipman <derrell.lip...@unwireduniverse.com>: > > > On Thu, May 27, 2010 at 15:57, Qoo Goo <qoo...@gmail.com> wrote: >> >> 2010/5/27 Derrell Lipman <derrell.lip...@unwireduniverse.com>: >> > 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. > > Ok. Please be sure to send me a binary capture, not a text one. If you can > put a Linux machine on a network hub (not a switch!) with your client > machine, and run the following command, it'll let me easily import it to see > what's going on: > > tcpdump -s 0 -w somefile.pcap > > Modern versions of wireshark also seem to have some Save-As filetype options > (libpcap format) which is likely the same thing, but I know the tcpdump > command works. > >> 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. > > Let me see the packet sniff tomorrow and maybe I'll have some suggestions > for you to try. > Also, if you can show me the working example of sending the same data from > an XML file, that'd be useful as well. > > Cheers, > > Derrell > > > ------------------------------------------------------------------------------ > > > _______________________________________________ > qooxdoo-devel mailing list > qooxdoo-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel > > ------------------------------------------------------------------------------ _______________________________________________ qooxdoo-devel mailing list qooxdoo-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
