Chrome removed support for multipart/x-mixed-replace documents. We should too.

[Seth Fowler]

Chrome removed support for multipart/x-mixed-replace main resources in this issue:

https://code.google.com/p/chromium/issues/detail?id=249132 <https://code.google.com/p/chromium/issues/detail?id=249132>

Here’s their explanation:

> This feature is extremely rarely used by web sites and is the source of a lot of complexity and security bugs in the loader. UseCounter stats from the stable channel indicate that the feature is used for less than 0.00001% of page loads.


They made main resources that use multipart/x-mixed-replace trigger downloads instead of being displayed.

The observation that multipart/x-mixed-replace support introduces a lot of complexity is absolutely true for us as well. It’s a huge mess.

Looks like this patch landed in Chromium on June 13, 2013 and has stuck since then, so removing it has not resulted in a disaster for Chrome. With so few people using multipart/x-mixed-replace, and since now both IE and Chrome do not support it, I suggest that we remove support for it from the docloader as well.

- Seth

[Ehsan Akhgari]

Doesn't bugzilla use multipart/x-mixed-replace for its search results page?

[Kyle Huey]

I've been meaning to rip out the putative support for this from XHR (and
all of the complexity that it introduces) for months now. This would be
great.

- Kyle

> - Seth
> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

[Seth Fowler]

On Mar 12, 2015, at 3:52 PM, Ehsan Akhgari <ehsan....@gmail.com> wrote:
>> Looks like this patch landed in Chromium on June 13, 2013 and has stuck since then, so removing it has not resulted in a disaster for Chrome. With so few people using multipart/x-mixed-replace, and since now both IE and Chrome do not support it, I suggest that we remove support for it from the docloader as well.
>

> Doesn't bugzilla use multipart/x-mixed-replace for its search results page?

It looks like it doesn’t anymore, because it works fine in Chrome.

- Seth

[Boris Zbarsky]

On 3/12/15 7:04 PM, Seth Fowler wrote:
> It looks like it doesn’t anymore, because it works fine in Chrome.

Iirc, bugzilla sniffs server-side and sends different things to
different browsers. Worth testing in Firefox with multipart/x-mixed
support disabled.

-Boris

[Boris Zbarsky]

On 3/12/15 6:37 PM, Seth Fowler wrote:
> They made main resources that use multipart/x-mixed-replace trigger downloads instead of being displayed.

So what gets downloaded is the entire mixed stream, right?

> The observation that multipart/x-mixed-replace support introduces a lot of complexity is absolutely true for us as well.

Does this really introduce a lot of complexity in the loader? There's
the actual stream converter, and the fact that people have to worry
about headers on part channels, but apart from that I don't recall much
complexity.

> so removing it has not resulted in a disaster for Chrome. With so few people using multipart/x-mixed-replace

We should use a use counter here, because as far as I know sites decide
via server-side sniffing whether to do this. :(

-Boris

[Ehsan Akhgari]

On 2015-03-12 6:54 PM, Kyle Huey wrote:
> I've been meaning to rip out the putative support for this from XHR (and
> all of the complexity that it introduces) for months now. This would be
> great.

Henri beat you by two years. ;-)

https://bugzilla.mozilla.org/show_bug.cgi?id=843508

[Seth Fowler]

On Mar 12, 2015, at 4:42 PM, Boris Zbarsky <bzba...@mit.edu> wrote:
>
> On 3/12/15 6:37 PM, Seth Fowler wrote:
>> They made main resources that use multipart/x-mixed-replace trigger downloads instead of being displayed.
>
> So what gets downloaded is the entire mixed stream, right?

You know, that’s what the Chromium issue says, but I just tried it and nothing happens. I just get an empty page. Safari downloaded the last part and opened it in Preview. Only Firefox displays it in the tab. (So that makes Firefox the *only* remaining browser to support this stuff.)

Here’s the page I was testing with:

http://blog.dubbelboer.com/2012/01/08/x-mixed-replace.html <http://blog.dubbelboer.com/2012/01/08/x-mixed-replace.html>

>> The observation that multipart/x-mixed-replace support introduces a lot of complexity is absolutely true for us as well.
>
> Does this really introduce a lot of complexity in the loader? There's the actual stream converter, and the fact that people have to worry about headers on part channels, but apart from that I don't recall much complexity.

There’s some really ugly code involved in making MJPEG streams loaded as documents not flicker. Given what a nightmare this stuff has been in ImageLib, I assumed that there was even more ugliness in other places, but you’d know better than I would.

(I have to say if the docloader’s reputation as hard-to-understand code is justified, anything we can do to simplify it is probably a good idea. I’ve only touched it a little, though.)

>> so removing it has not resulted in a disaster for Chrome. With so few people using multipart/x-mixed-replace
>
> We should use a use counter here, because as far as I know sites decide via server-side sniffing whether to do this. :(

That might be a good idea, though I will note that I’d be surprised if many sites treated Firefox and Chrome differently here, because Chrome only dropped support ~9 months ago.

- Seth

[Kyle Huey]

On Thu, Mar 12, 2015 at 4:43 PM, Ehsan Akhgari <ehsan....@gmail.com>
wrote:

Nice. We still have the ridiculous lifetime management in the worker code
that has been the bane of my existence for several years though.

- Kyle

[Gervase Markham]

On 12/03/15 16:04, Seth Fowler wrote:
> It looks like it doesn’t anymore, because it works fine in Chrome.

It does; it browser-sniffs.

Gerv