Geoffrey Garen wrote:
From code inspection, I see that XMLHttpRequest updates responseText
every time it receives data.
Perhaps you're seeing the results of slightly different networking
implementations. For example, you might need to send data in larger
chunks in order to convince the networking layer to flush its data up to
the application level.
We've written up a simple example using perl cgi and js/xhr to
demonstrate this problem. In Firefox, the expected behavior appears.
Every second, a new line appears counting up from 1 to 10. In Safari,
there's a 10 second delay with nothing, and then 10 lines appear
counting up from 1 to 10 all at once, just as the readyState goes from
3 to 4. We never see readyState going from 3 to 3 as we do with
Firefox.
URL demonstrating this behavior: http://www.synchroedit.com/pt/
URL with source code for this test:
http://www.synchroedit.com/pt/perl-test.tar.gz
The perl cgi script has autoflushing enabled, which means the buffer
is flushed for every newline. In Firefox, the responseText is updated
whenever the perl side sends and flushes data, while Safari's
responseText stays empty until the perl cgi closes the connection and
the request enters readyState 4.
So to return back to our original question -- this capability is
needed for synchronous applications that keep an ongoing connection to
the server to avoid polling and other performance issues. Is this
capability supposed to be to in Safari, thus our test above
demonstrates a bug? Are we missing something? Is there an alternative
approach that would make this behavior work right in WebKit/Safari 3
as well?
Thanks for your help!
-- Christopher Allen
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
