Responses that are of Content-type:multipart/x-mixed-replace contain many multipart sections, each of which logically replaces the preceding section. I am finding that as the response continues, Webkit does indeed replace the content of the page with the values, but Webkit's memory requirements grow along with the response lifetime. I would expect it not to grow. My evidence: 1. Activity tab shows the content of the response URL to grow apace the content stream. 2. Task Manager/Activity Monitor show the memory usage growing as well. 3. Drosera shows the entire content of the response stream rather than the current value, as expected. For a comparison, Firefox 2.0.0.11 Does not leak with the same content stream.
Created attachment 18800 [details] Multipart output html file
I set up the test case at <http://bdash.net.nz/files/multipart-mixed-replace.php> for easy access.
I cannot reproduce any unusual memory growth while loading the test case. "leaks" reports no unexpected leaks after loading the page either.
Hmm, I think I need to put together a better test case. The problem I see occurs while the content is streaming into the browser. I am using this content-type for server push (I guess that is obvious) so the connection stays open indefinitely. What type of CGI would you prefer? PHP, Perl, JSP?
PHP or Perl would be fine. I have a personal preference for PHP over Perl, but either of those would be great.
Created attachment 18912 [details] PHP file to demonstrate this bug The bug is triggered by the existence of a 'charset' element in the Content-Type header. The PHP file has a working header and a bug-triggering header; the working header is commented out to make it easy to test. This bug exists in the Windows version of Safari as well. It works as expected (charset in header) on both Firefox 2 and Opera 9. It is difficult, sometimes impossible, to remove the charset element from Content-Type, as app servers will automatically insert one if it is missing.
Changing description to match the bug
Safari 3.1 for OS X and Windows still exhibit this bug.
I have tried to reproduce this by leaving the page open for a few minutes, but the memory usage (I looked at RPRVT column in top) didn't grow beyond the original 13 Mb. However, I also don't see it work correctly - new content is appended instead of replacing the old. I'm using Safari 3.1 on Mac.
The memory usage is ancillary--the real issue is that the content does not replace on the page as it should.
OK, that I can confirm (got confused by the description, which talked about memory usage exclusively). Please file a separate bug about memory usage, if you are seeing it grow on pages without charset, too.
<rdar://problem/5822305>