Multipart Support Proposal

Multipart Support

Multipart support specifies that when an XHR request is made with multipart 
enabled, the XHR response should be parsed as a multipart message, where 
each part triggers the XHR response sequence. Multipart handling is enabled 
by setting the multipart property on the XHR object to true. When the 
response begins to stream into the user agent, the XHR response sequence should 
be triggered for each part as it is received, and the user agent should not 
wait for the entire HTTP response to be received. When multipart is enabled, 
the user agent should perform multipart handling for responses with a MIME type 
of any multipart type. That is, when a response includes a Content-Type 
header with value of multipart/* where the subtype can be any value, then 
multipart handling should be performed.

When handling a multipart message, the XHR object should expose an 
additional property multipartState. The multipartState property should 
provide the status of the XHR request exactly as the readyState property 
would when multipart handling is not enabled. As each part is received is 
being received, the multipartState should be 3 and when the response is 
finished the multipartState should be 4.

The XHR object should also provide two additional methods, 
getPartHeader(headerName) and getAllPartHeaders(). These methods should 
provide access to the headers of each part. When a part is encountered, and 
the headers have been received (readyState of 2 or higher), the 
getPartHeader can be called to with a name of a header, and the method 
should return the value for that header within the currently processed part. 
The getAllPartHeaders can be called after the headers have been received and 
it should return the entirety of the header block text for that part.

When the leading boundary prior to each part is received, the 
onreadystatechange handler should be called with the readyState property set 
to 1, and responseText should be an empty string. When the headers have been 
received for the part (that is, two line breaks are encountered), the 
onreadystatechange handler should be called with the readyState property set 
to 2 and the getPartHeader and getAllPartHeaders should be able to return 
header information. When any of the content of the part is received, the 
onreadystatechange handler should be called with the readyState property set 
to 3 and the responseText property with the available content. This may be 
called multiple times as content is streamed in. When the ending boundary is 
encountered, the onreadystatechange handler should be called with the 
readyState property set to 4, and the responseText property with the content 
of the part and the onload handler should be called. Note that since the 
ending boundary is the starting boundary for the next part the beginning 
onreadystatechange handler should be called for the next part immediately 
following the last call for the previous part.

The following is an example of usage:
var xhr = new XMLHttpRequest;
xhr.multipart = true;
xhr.open("GET","/resource", true);
xhr.onreadystatechange=function() {....}
xhr.send(null);

message/http Support
In addition to multpart/* handling, the "message/http" MIME
should also be handled. The "message/http" type consists of 1 or more
HTTP response messages. This format only differs from multipart/message
in that there are no boundaries. Boundaries are not necessary with HTTP
messages since each message defines it's own ending (via the 
Content-Length header or chunked encoding termination) so boundaries
are unnecessary overhead. Each HTTP message would be treated as a
part, with the responseText being set to the response entity and 
getPartHeader and getAllPartHeaders accessing the headers. In addition,
the XHR object's status and statusText properties would reflect the 
status values in each of the contained HTTP messages.

Differences from Mozilla Implementation

Multipart support has been implemented in Mozilla with some notable 
usability issues that are fixed in this proposal. First, there is no way to 
detect when a multipart response is finished since each part triggers a 
readyState of 4. Therefore this proposal adds a multipartState property 
provides overall response status. Second, Mozilla provides no access to the 
headers in each part. This is corrected by adding the getPartHeaders and 
getAllPartHeaders methods (which behave very similar to getResponseHeader 
and getAllResponseHeaders, except on the part instead of the whole 
response). Third, when multipart is enabled, Mozilla only handles responses 
with the MIME type of multipart/x-mixed-replace. This greatly limits the use 
of more meaningful and accurate MIME types such as multipart/mixed,
multipart/message, and message/http. This proposal removes this limitation 
and specifies that multipart handling can be used for any multipart response.