Bug 17100 – multipart/x-mixed-replace fails if charset is present in Content-Type header

• Component: Page Loading
• Status: NEW

[Matt Bishop]

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.

[Matt Bishop]

Created attachment 18800 [details]
Multipart output html file

[Mark Rowe (bdash)]

I set up the test case at <http://bdash.net.nz/files/multipart-mixed-replace.php> for easy access.

[Mark Rowe (bdash)]

I cannot reproduce any unusual memory growth while loading the test case.  "leaks" reports no unexpected leaks after loading the page either.

[Matt Bishop]

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)]

PHP or Perl would be fine.  I have a personal preference for PHP over Perl, but either of those would be great.

[Matt Bishop]

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]

Changing description to match the bug

[Matt Bishop]

Safari 3.1 for OS X and Windows still exhibit this bug.

[Alexey Proskuryakov]

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]

The memory usage is ancillary--the real issue is that the content does not replace on the page as it should.

[Alexey Proskuryakov]

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]

<rdar://problem/5822305>