[webkit-dev] [Proposal] Remove support for 'multipart/x-mixed-replace' main resources

[Brady Eidson]

> On Apr 23, 2015, at 2:38 PM, Maciej Stachowiak <mjs at apple.com> wrote:
> 
> 
>> On Apr 23, 2015, at 1:07 PM, Brady Eidson <beidson at apple.com> wrote:
>> 
>> 
>>> On Apr 21, 2015, at 3:39 PM, Chris Dumez <cdumez at apple.com> wrote:
>>> 
>>> Hi,
>>> 
>>> I would like to suggest we remove support for 'multipart/x-mixed-replace’ main resources while keeping support for multipart images.
>>> 
>>> Based on Chrome usage data, this feature is extremely rarely used by Web sites (less than 0.00001% of page loads) [1]. This feature adds complexity to the loader and is a source of (security) bugs (e.g. [2] recently), current support also seems buggy.
>>> 
>>> Current support in Safari / WebKit:
>>> - Support is not great is WebKit. If you load a Motion JPEG main resource for example, it will keep creating a new ImageDocument and all its DOM tree for every frame (tested on Safari / Mac).
>>> - It looks like support is broken on Safari on iOS (I tried a Motion JPEG main resource on iOS8, I see the first frame then a blank page that never finishes loading).
>>> 
>>> Other browsers:
>>> - Never supported by IE (including IE11) for any resource
>>> - Chrome already dropped support for this (main resources only) almost 2 years ago [3].
>>> - Firefox 37 still supports this based on local testing.
>>> 
>>> Again, I am only proposing dropping support for main resources. For e.g., having an <IMG> element in a page whose src attribute points to a Motion JPEG would still work as intended.
>> 
>> I think it’s fine to drop support for multipart main resources besides MPJEG.
>> 
>> I think loading MJPEG as a main resource and having it be displayed as an ImageDocument is a valuable feature, and I object to dropping support for it. I’m not sure if that’s what you’re proposing, since it’s both a main resource and a multipart image.
>> 
>> I think you might have filed a bug about the new ImageDocument per frame, thought I can’t find it right now. I think fixing that bug is a better solution than dropping that support.
> 
> Does this feature have non-negligible actual use in the wild? There are far better ways to do streaming video, so I think we only need to treat this as a legacy feature, and only support it if use warrants it.

I’d wager “sites in the wild” are the fraction of a fraction of a percent mentioned above.

I use a web cam at home most evenings whose “view live video” link takes you directly to an MJPEG main resource when you’re on a Mac, based on the assumption that the default browser on the platform supports it.

Was that a poor design decision on their part? Yes. Can they fix it now? No.

Killing the feature would lead to a confusing experience for such users.

> On Apr 23, 2015, at 1:44 PM, Anders Carlsson <andersca at apple.com> wrote:
> 
> Given that so few browsers support this I think we should get rid of this feature; it would let us simplify the loader code significantly.

I can think of a handful of ways to kill the general “multipart main resource” feature - which is allegedly supported in the code but not *really* supported - and still maintain the ability to have ImageDocument specifically support this one use case.

Thanks,
 Brady