This wired behavior of Chrome is really annoying. I tried to figure out how GMail (Googleβs own application) implements a comet in Chrome, but there is no suitable Http Sniffer to catch Chrome HTTP traffic forever.
Solution 1: My original thought:
We can have the Content-Type: multipart / x-mixed-replace header in the Comet Http response. I tested it. If the response is multiple , xhr.responseText is not empty if ( xhr.readyState == 3 ) is true.
The only problem is that xhr.responseText is the whole answer instead of the "substituted" answer, as Firefox does. For example, the server sends βAβ, then βBβ instead of βAβ, then βCβ to replace βBβ. In Firefox, you get "A", "B", "C" when xhr.readyState == 4 . In Chrome, you will get "A", "AB" and "ABC" when xhr.readyState == 3.
So, your javascript client should parse xhr.responseText to retrieve the migrated data.
Solution 2: This is recommended by Safari http://lists.macosforge.org/pipermail/webkit-dev/2007-June/002041.html .
The webit engine does not display pending data until a sufficient number of bytes appear. It is claimed that an initial pad of 256 bytes is required. I tried in Chrome (4.1.249.1036 (41514)). It seems like it takes about 1 kilobyte byte for the first payload trigger (readyState == 3).
Make sure XHR is not sent directly to the onload event handler. Otherwise, the page has a download indicator in the header or URL bar.
Morgan cheng
source share