NEW 17100
multipart/x-mixed-replace fails if charset is present in Content-Type header 
https://bugs.webkit.org/show_bug.cgi?id=17100
Summary multipart/x-mixed-replace fails if charset is present in Content-Type header
Matt Bishop
Reported 2008-01-30 13:40:37 PST
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.
Attachments
Multipart output html file (507.27 KB, text/plain)
2008-01-30 14:16 PST, Matt Bishop 		no flags
Details
PHP file to demonstrate this bug (536 bytes, text/plain)
2008-02-04 11:44 PST, Matt Bishop 		no flags
Details
Show Obsolete (1) View All Add attachment proposed patch, testcase, etc.
Matt Bishop
Comment 1 2008-01-30 14:16:37 PST
Created attachment 18800 [details] Multipart output html file
Mark Rowe (bdash)
Comment 2 2008-01-31 08:49:37 PST
I set up the test case at <http://bdash.net.nz/files/multipart-mixed-replace.php> for easy access.
Mark Rowe (bdash)
Comment 3 2008-01-31 09:07:11 PST
I cannot reproduce any unusual memory growth while loading the test case. "leaks" reports no unexpected leaks after loading the page either.
Matt Bishop
Comment 4 2008-01-31 11:43:49 PST
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?
Mark Rowe (bdash)
Comment 5 2008-01-31 12:02:00 PST
PHP or Perl would be fine. I have a personal preference for PHP over Perl, but either of those would be great.
Matt Bishop
Comment 6 2008-02-04 11:44:26 PST
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.
Matt Bishop
Comment 7 2008-02-04 11:46:50 PST
Changing description to match the bug
Matt Bishop
Comment 8 2008-03-25 09:55:09 PDT
Safari 3.1 for OS X and Windows still exhibit this bug.
Alexey Proskuryakov
Comment 9 2008-03-26 01:04:20 PDT
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.
Matt Bishop
Comment 10 2008-03-26 07:24:35 PDT
The memory usage is ancillary--the real issue is that the content does not replace on the page as it should.
Alexey Proskuryakov
Comment 11 2008-03-26 08:00:10 PDT
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.
Alexey Proskuryakov
Comment 12 2008-03-26 08:01:00 PDT
<rdar://problem/5822305>
Note You need to log in before you can comment on or make changes to this bug.