[webkit-dev] XMLHttpRequest and readyState==3

[Maciej Stachowiak]

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