Re: [webkit-dev] XMLHttpRequest and readyState==3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Maciej Stachowiak wrote: 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). Thanks for the ideas! We tried both of these fixes (separately and in combination), but unless we're doing something wrong, neither is actually working 100%: - - In FF/linux, they all work. - - In Safari/windows, neither works. - - In Safari/Mac OS X, the 1+2 worked a little, but still missed some input. The URL for 1+2: http://www.synchroedit.com/pf1/ The URL for 2 only: http://www.synchroedit.com/pf2/ Sources 1+2: http://www.synchroedit.com/pf1/perl-fix-1.tar.gz Sources 2: http://www.synchroedit.com/pf2/perl-fix-2.tar.gz The first solution would most likely work if we increased the garbage from 256 chars to something like 512, but the overhead at 256 is already at something akin to 300% more data in transit, which sounds like a major performance loss. If at all possible, getting things to work without priming the connection would be ideal. Any ideas? - -Kalle. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGgnoGdNQyXs/kj34RAi8PAJ4rfal6Fh9M4sQa6KLa3E28GnDWCQCffcvJ BSZD/iRbZnqioB3wEDBjGDA= =yV9f -END PGP SIGNATURE- ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] XMLHttpRequest and readyState==3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sorry for spamming the list, but thought I'd add that I've filed this as a bug here: http://bugs.webkit.org/show_bug.cgi?id=14431 - -Kalle. Kalle Alm wrote: Maciej Stachowiak wrote: 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). Thanks for the ideas! We tried both of these fixes (separately and in combination), but unless we're doing something wrong, neither is actually working 100%: - In FF/linux, they all work. - In Safari/windows, neither works. - In Safari/Mac OS X, the 1+2 worked a little, but still missed some input. The URL for 1+2: http://www.synchroedit.com/pf1/ The URL for 2 only: http://www.synchroedit.com/pf2/ Sources 1+2: http://www.synchroedit.com/pf1/perl-fix-1.tar.gz Sources 2: http://www.synchroedit.com/pf2/perl-fix-2.tar.gz The first solution would most likely work if we increased the garbage from 256 chars to something like 512, but the overhead at 256 is already at something akin to 300% more data in transit, which sounds like a major performance loss. If at all possible, getting things to work without priming the connection would be ideal. Any ideas? -Kalle. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGgnwwdNQyXs/kj34RApajAJ46HjDExd9dkdU5IPYzIqiuebhlJACfcBe1 5FLFKAaFmqard8c2FngI96I= =hR1E -END PGP SIGNATURE- ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] XMLHttpRequest and readyState==3
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
