On Jun 26, 2007, at 10:29 AM, Christopher Allen wrote:
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?
This is a networking layer issue - it buffers the data up to some
limit depending on what MIME type you send it with. Two workarounds
that I think will work:
1) "prime" the connection with 256 bytes sent before any of the real
data.
2) Use a MIME type that won't be subject to sniffing (I think
"application/xml" as opposed to "text/xml" may fit the bill).
Regards,
Maciej
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
