2010/5/31 Derrell Lipman <derrell.lip...@unwireduniverse.com>: > On Mon, May 31, 2010 at 09:16, Qoo Goo <qoo...@gmail.com> wrote: >> >> 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's not really a "doesn't like it" scenario, it's just a difference of > implementation. Both are correct. There is no guarantee that when the server > closes the socket, that all data that the server has sent has yet been > received by the peer (client), let alone processed by the client. Most > likely (but not necessarily), if data is sent before a connection is closed, > that data arrives at the client and is queued for processing at the client. > If it has not yet been processed at the time that the client receives the > connection reset (closing), the client has the option of immediately > flushing the data queue, or of processing what's left in that queue and then > processing the close operation. Apparently, Chrome is choosing to flush the > queue immediately upon receipt of the command to close the stream, whereas > the other browsers are queuing the close command behind the pending data > commands, so they are processed in the order received. > > TCP supports a "negotiated close" operation, which I'm guessing is what > Response.End() initiates. That would ask the peer to agree to the close, > which it wouldn't do until it had processed the pending messages. I'm > guessing that Response.Close() does an immediate reset of the connection, > and since Chrome is not queuing that request you lose your connection > immediately. > > So... do the right thing. :-) Call Response.End() and you won't have the > problem. > > Derrell
Yes, I agree. It's not the same calling a Response.End() than calling Response.Close(), for sure (I must admit that I haven't never used this method, I have to catch up who was!!). In fact, quoting VS built-in methods' descriptions, the first "Sends all currently buffered output to the client, stops execution of the page, and raises the System.Web.HttpApplication.EndRequest event" while Response.Close() simply "Closes the socket connection to a client." Anyway, I think this is a Chrome's bug because if you flushes explicitly the contents before closing the connection, every bit of data should arrive at client side before the connection is closed and in this situation I think the browser should definitely process data before considering that the connection is finished (because it was not closed when content was sent). But above all I think this is a bug because it changes the behaviour from previous versions (and back again to next versions, as seen in Chromium 6). This can break applications! The good thing is that this bug (or "behaviour"), helped us finding and solving a bug in our software :-) Thanks again for your interest. Al ------------------------------------------------------------------------------ _______________________________________________ qooxdoo-devel mailing list qooxdoo-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
