Bug 14431 - XMLHttpRequest readyState 3 & responseText buffer issues
Summary: XMLHttpRequest readyState 3 & responseText buffer issues
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: XML (show other bugs)
Version: 523.x (Safari 3)
Hardware: All All
: P2 Normal
Assignee: Nobody
URL: http://www.synchroedit.com/pt/
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2007-06-27 08:01 PDT by Kalle Alm
Modified: 2007-08-28 12:21 PDT (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kalle Alm 2007-06-27 08:01:11 PDT
Safari 3 does not seem to handle the updating of the responseText buffer during readyState 3 (interactive/loading) of XMLHttpRequests appropriately. The expected behavior is that whenever the server sends/flushes output to the client (browser), the client sets readyState to 3 (if not already), updates the responseText buffer, and triggers a readystatechange. 

Safari seems to only set readyState to 3 once (when loading begins and responseText is an empty string) and then nothing until the loading finishes (readyState -> 4). During tests, we discovered that by "priming" the connection as described by M. Stachowiak below, Safari for Mac OS X seemed to get it some times, but not all. By increasing the "garbage" from 256 to 512 bytes, this solution might work all the time, but this solution isn't exactly ideal. 

In email discussion, Geoffry Garen confirmed that Safari 3 does indeed issue a ready state change of 3 every time it receives data, and that responseText IS updated every time, which indicates the above behavior is a bug.

We have additionally tried two workarounds, as proposed by Maciej Stachowiak, namely:
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). 

From our tests, it would appear that neither of the above tests seem to do the trick on our example code. 

Demo URLs:
- http://www.synchroedit.com/pt/ (perl test -- clean)
- http://www.synchroedit.com/pf1/ (perl fixes 1+2 above)
- http://www.synchroedit.com/pf2/ (perl fix 2 only)

Source code URLs:
- http://www.synchroedit.com/pt/perl-test.tar.gz
- http://www.synchroedit.com/pf1/perl-fix-1.tar.gz
- http://www.synchroedit.com/pf2/perl-fix-2.tar.gz
Comment 1 Alexey Proskuryakov 2007-06-27 09:31:49 PDT
Since the network layer is outside WebKit (and is not open-source), you may want to also file a bug at <http://bugreport.apple.com> (free registration required). Please post the resulting "Radar" number here.

Once we get a method to disable buffering, we'll need to use it for XMLHttpRequests.
Comment 2 Kalle Alm 2007-06-27 10:13:00 PDT
Submitted report at Apple as well. Problem ID is 5298296.
Comment 3 Alexey Proskuryakov 2007-06-27 11:24:04 PDT
Thank you!
Comment 4 Kalle Alm 2007-07-02 13:12:42 PDT
This test WORKS FINE in the iPhone version of Safari.
Comment 5 Anders Carlsson 2007-08-28 12:21:50 PDT
Committed revision 25274.

However, this also depends on changes to lower-level frameworks so it won't work until newer versions of those have been released.