Mozilla/Firefox no longer supports multipart mixed/replace messages

[Bill Erickson]

Multipart mixed/replace XHR messages is the underlying technology which allows the OpenSRF translator to send streams of responses to (certain) web clients. Streaming allows clients to provide incremental updates to users and allows for long-running processes which would timeout in a non-streaming environment.

As of Firefox version 22, Mozilla has removed support for multipart mixed/replace messages:

https://developer.mozilla.org/en-US/docs/Site_Compatibility_for_Firefox_22

https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/22

NOTE: the problems listed here will not affect Evergreen until we adopt to a new version of XULRrunner.

This means that interfaces which rely on streaming for incremental updates and long-running processes will no longer function. The main interfaces that come to mind are Vandelay (very long-running actions), Acquisitions, Serials (I think), Link Checker (I think), most of the conify interfaces, etc. In short, most of the web-based UIs and a few native XUL UIs and anything that uses the translator, which is used a lot.

In most of these cases, we can simply disable streaming and the interfaces will continue to work. Clients will receive one chunk of responses instead of a stream of response. It will be slower, but it should continue to function.

There is another class of interface which relies on streaming for long-running processes, which will not work when streaming is disabled. The main examples are Vandelay and (I think) the Link Checker, and bucket/batch Z39 lookup. There are probably more.

We either need to move to a technology which does support streaming (Mozilla suggests WebSockets and Server-Sent Events) or we need to redesign these interfaces and API calls so that they do not require streaming to the client.

Also, for those of us that use web-accessible UIs from a browser, they will no longer work from Firefox. I'll post a patch shortly which disables streaming for Firefox (but not XULRunner) so that most of the UIs will continue to work. Long-running processes like Vandelay, etc. are now officially unusable from Firefox, though. We may be able to use Chromium as a temporary crutch for browser access, but we should of course devise a long-term plan of action as soon as possible to address the overall problem.

[Bill Erickson (berick)]

I pushed an opensrf commit to disable multipart messages for Firefox to

opensrf/working => user/berick/lp1198983-disable-multipart-firefox

[Bill Erickson (berick)]

^... because the evergreen self-check interface no longer works in Firefox.

[Bill Erickson (berick)]

...or, more specifically, to disable multipart messages to all clients except the staff client.

[Dan Scott (denials)]

Tested the fix in the self-check, and it works as advertised (and is pretty critical). Thanks, Bill!

[Dan Scott (denials)]

Err -- committed to OpenSRF master / rel_2_2. I suppose we need to release a new version of OpenSRF and note the requirement in the Evergreen docs before we can mark the Evergreen bug as committed.

[Dan Wells (dbw2)]

We've run into an issue with this change, and are looking for input. Basically, back in the 2.2 days, Evergreen had code which set the 'general.useragent.override' to something like 'Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.25) Gecko/20111212 oils_xulrunner /xul/rel_2_2_0/server/'. For anyone who once had a 2.2 client installed and upgraded from it, this setting persists (this is the situation for most stations in our library).

Since this string does not match the new test for 'open_ils_staff_client' in the useragent, these clients are not properly streaming requests. This problem was most easily noticed in Vandelay progress bars (they always jumped from 0% to 100%).

At this point, I think we need to consider:

1) Adding code to the client which simply unsets this override if present.

2) Possibly expand the userAgent.match() in this bugfix to also allow for 'oils_xulrunner' (this would be a bit of belt-plus-suspenders, but would also allow older clients to continue to work).

These changes should be simple to code, but does anyone see a better alternative?

[Bill Erickson (berick)]

Thanks Dan, I just encountered this myself. Your solutions both sound sane to me.

As a stop-gap, if anyone needs to get things working quickly in their environment, you can clear the user agent string via staff client custom.js entry (web/xul/server/skin/custom.js)

---
try {
    var prefs = Components.classes['@mozilla.org/preferences-service;1']
        .getService(Components.interfaces['nsIPrefBranch']);
    prefs.clearUserPref('general.useragent.override')
} catch(E) {
    dump('Error clearing "general.useragent.override" in custom.js for '
        + location.href + '\n' + E + '\n');
}
----

We can toss the same code (more or less) right into the staff client proper somewhere, though where it should live, I'm not sure....

[Remington Steed (rjs7)]

I added Bill's code to OpenILS/data.js, with slight modifications to match the surrounding code. I admit that I don't know much about the client build process, so this might not be the only place this code is needed. I know that this code needs to end up in the server-side xul, rather than the client-side. Hopefully this first step will help this move forward.

I tested it by adding the "general.useragent.override" setting to my client, ran the new code, and saw that my setting was remove.

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/rsteed/lp1198983_clear_useragent_override

working/user/rsteed/lp1198983_clear_useragent_override

[Dan Wells (dbw2)]

Looks good, works for me, pushed. Thanks, Remington!