Christoph Dorn wrote:
> Does the XMLHttpRequest object support multipart/mixed response
It supports multipart/x-mixed-replace. multipart/mixed doesn't really make much
sense in an XMLHttpRequest context -- it would require that the parts be exposed
to the caller all at once, which the API doesn't really allow.
For multipart/x-mixed-replace, it's basically treated like multiple
> I presume this is the intended and proper result?
> Is there any way to set an additional header to make the object just
> read the text/xml section and load the XML document properly?
> The other option would be to intercept and parse the response to
> return the text/xml section only to the XMLHttpRequest object. Is this
Not from untrusted script. From trusted script you could just do all the HTTP
access yourself, of course.
> It supports multipart/x-mixed-replace. multipart/mixed doesn't really make much
> sense in an XMLHttpRequest context -- it would require that the parts be exposed
> to the caller all at once, which the API doesn't really allow.
I agree that the multipart/mixed response does not make much sense in
the XMLHttpRequest context but was not sure if it is handled the same
as when the browser displays a multipart/mixed response with a text/
xml section directly. I have a custom handler for the text/firephp
section (via a Firefox extension) which eats the data so that when the
browser displays the multipart/mixed response it only shows the text/
xml section and properly renders the XML structure. When looking at
the source of the page the full multipart message is visible though.
If the XMLHttpRequest object loaded the response data at the same
point as the text/xml renderer then it should in theory work but I
guess it looks at the response at a lower level.
The multipart/x-mixed-replace response type does not work for my
purposes as I would need to send the debug information first and then
send the actual response as only the last multipart section survives.
Looks like I will have to obtain the debug information for a request
via a different mechanism than a multipart response. I was trying to
avoid a second request to the server to fetch it but I guess its the
Christoph Dorn wrote:
> Looks like I will have to obtain the debug information for a request
> via a different mechanism than a multipart response. I was trying to
> avoid a second request to the server to fetch it but I guess its the
> only way.
Yes I could, but it would be a special solution for XML. I am hoping
to find a solution which I can use with any response without needing
special cases for different types.
I am going to set a Request ID in a response header field and then
cache the debug output on the server so I can fetch it via a second
request. This will work for any response type even JSON responses that
may only contain the specific JSON formatted string so it may be
loaded into a JS object easily and without modification of existing