Bug 14392 - Add support for multipart/x-mixed-replace to XMLHttpRequest
: Add support for multipart/x-mixed-replace to XMLHttpRequest
Status: NEW
: WebKit
XML
: 523.x (Safari 3)
: All All
: P2 Enhancement
Assigned To:
:
:
:
:
  Show dependency treegraph
 
Reported: 2007-06-25 11:55 PST by
Modified: 2013-01-25 09:49 PST (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2007-06-25 11:55:46 PST
Add support for multipart/x-mixed-replace to XMLHttpRequest as was done in Firefox.  Please use same method calls so API is compatible between WebKit, Safari & FireFox.

https://bugzilla.mozilla.org/show_bug.cgi?id=237319
------- Comment #1 From 2007-06-25 13:10:50 PST -------
Confirmed.

Please note that support for multipart/x-mixed-replace is not even considered for inclusion in future versions of XMLHttpRequest spec yet, as seen in the current draft of the spec, <http://www.w3.org/TR/XMLHttpRequest/#notcovered>. We may want to discuss its possible standardization first.
------- Comment #2 From 2007-06-26 06:18:01 PST -------
HTML5 seems to have <event-source> for server push.
------- Comment #3 From 2007-06-26 08:09:18 PST -------
(In reply to comment #2)
> HTML5 seems to have <event-source> for server push.
> 
<event-source> seems nice at first glance, but it will have a number of problems and is re-inventing the wheel (poorly).  

The data format for sending events is too simplistic.  It won't support binary data well.  This will force the use of encoding schemes like base64 for pushing binary data.  Base64 encoding of binary data is inefficient because it increases the data size by 1/3.  Imagine increasing your bandwidth usage by 1/3 across thousands of users - not a good thing.

Encoding scheme's also require more CPU and nearly twice the memory on both the client and server.  One in-memory copy of the encoded data and one in-memory copy of the decoded data while the encoding/decoding is taking place.  Why use twice the memory on both the client and server and waste CPU to do encoding/decoding?  This severely reduces the scalability of an application. Base64 is just an example, any encoding scheme will have similar problems.

This wouldn't be necessary with multipart/x-mixed-replace because it is based on MIME and handles binary data well without encoding.  Additionally multipart/x-mixed-replace supports a unique content-type and other headers for each content chunk.  This isn't currently available with <event-source>.

People expect to use XmlHttpRequest for interacting with the server.  This is an evolutionary step for XmlHttpRequest.  It could honestly be considered a bug that XmlHttpRequest doesn't support multipart/x-mixed-replace because that is a valid content type that has existed for some time.

I have a problem with overloading the DOM event system to support server interaction.  Conceptually, it's a nice feature because there is a single system for handling "events" from the client or server.  But that is where the benefits end.  Anything fired within the DOM event loop takes time away from UI responsiveness.  Normally JavaScript is only single threaded, but with developments like Google Gears there is now some support for multiple threads and background tasks.  This allows the UI to remain responsive.

As more "desktop" applications move to the web I expect features like the ones provided by Google Gears and Adobe Air (formerly Apollo) to migrate into web browsers.  This would cause a problem with <event-source> because when multiple "threads" are supported by a browser the UI thread would still be involved in handling server events.  With XmlHttpRequest, server interaction could be moved into the background and only when the UI is updated will the UI thread need to be involved.
------- Comment #4 From 2007-06-26 08:17:45 PST -------
(In reply to comment #1)
> Confirmed.
> 
> Please note that support for multipart/x-mixed-replace is not even considered
> for inclusion in future versions of XMLHttpRequest spec yet, as seen in the
> current draft of the spec, <http://www.w3.org/TR/XMLHttpRequest/#notcovered>.
> We may want to discuss its possible standardization first.
> 

Standardization happens via 2 routes.  Route 1, everyone gets in a room and creates a spec with little or no real world experience.  These specs sound great on paper, but usually have a great deal of problems when people try to implement them.

Route 2, someone comes up with an innovative idea and everyone says "Wow, that's cool".  They then copy that idea as closely as possible.  Everyone now supports that "defacto" standard and eventually it is documented as "the standard" by some committee.  Route 2 usually results in better software and more rapid innovation.

This is particularly relevant to XmlHttpRequest. It was originally an IE only extension and the rest of the browser world said "Wow, that's cool".  Soon it showed up in all the other browsers (without the need for ActiveX on which IE's XmlHttpRequest is based).  

It might be worthwhile to implement support for multipart/x-mixed-replace in WebKit in a manner compatible with Firefox's and then push for that to become the standard with the appropriate group.
------- Comment #5 From 2007-10-09 22:56:51 PST -------
Personally I think supporting this is really important.  I might even try and hack a patch together.
------- Comment #6 From 2007-12-18 05:20:30 PST -------
May be related to Bug 14149.
------- Comment #7 From 2009-11-02 11:11:27 PST -------
EventSource is now available in WebKit (and proposals to standardize support for any of the multipart/* flavors were few, and never got enough attention to be added to XMLHttpRequest).
------- Comment #8 From 2010-12-28 07:34:39 PST -------
I have to agree with Rob. EventSource implementation is a disaster. Besides poor design, it has memory leaks and cannot be used from Java: http://code.google.com/p/chromium/issues/detail?id=66666
It is obvious that it was not tested very well.

I cannot imagine anyone would prefer EventSource to the multipart/x-mixed-replace.
------- Comment #9 From 2013-01-25 09:49:33 PST -------
Hi guys
is there any news about this issue?
FF has this option since a long time... https://bugzilla.mozilla.org/attachment.cgi?id=144021&action=diff

Thanks a lot