multipart/x-mixed-replace parsing bug breaks JS libs

[Bill Erickson]

There is what appears to be a bug in Mozilla's multipart/x-mixed-replace message parsing. At unpredictable times, the XHR.responseText value contains the part headers in addition to the response text. This results in failed JSON parsing and, due to how the JS libs are loaded through various layers of Dojo, the error never bubbles up to the console.

In user interfaces that leverage the OpenSRF JS libs, the bug will manifest as communication that quietly stops working. For example, if you were powering a dojo progress dialog via streaming JS, the bar would stop updating at some point and all communication would stop short of completing the overall request.

I've pushed a patch to collab/berick/opensrf-js-multipart-monkey-patch @ working to test and alleviate the issue. Note that console logging in this patch is perhaps too verbose for production use, but is needed in the short term to make sure we're capturing all the failure types.

http://git.evergreen-ils.org/?p=working/OpenSRF.git;a=shortlog;h=refs/heads/collab/berick/opensrf-js-multipart-monkey-patch

Feedback appreciated.

[Bill Erickson (berick)]

Also, it's possible the translator is returning malformed responses in some cases. I've looked for this on several occasions and have been unable to find any evidence of it. If that is in fact the problem and we can find evidence of it, fixing that would of course be preferable to this hack.

[Dan Scott (denials)]

One could also wonder about the decrepit version of XULRunner we're using as another possible suspect (more recent versions have refined XHR support).

We'll go with this hack for now; I've backported it through rel_2_0. Thanks Bill!

[Bill Erickson (berick)]

Thanks Dan.

Just for the record, the problem also occurs in modern versions of Firefox.