IE8 and IE9 have the HttpXmlRequest object, but unlike the implementation in IE10+ and current versions of Safari, Chrome and Firefox it does not support CORS, so will not allow you to attempt any kind of cross domain request.
In IE8 and IE9, Microsoft separated out cross domain activity into the XDomainRequest interface:
https://developer.mozilla.org/en-US/docs/Web/API/XDomainRequest
This sits alongside XmlHttpRequest in IE8 and IE9 (and was dropped in IE10 when XHR became fully-CORS), and you use it when you want to go cross domain. This works fine for many Ajax scenarios, and you can shim it into jQuery with this library, which hides the distinction between the two interfaces when you do CORS from jQuery:
https://github.com/MoonScript/jQuery-ajaxTransport-XDomainRequest
However, although you can do some cross domain Ajax with it, XDomainRequest does not do enough to support the IIIF Auth flow:
https://developer.mozilla.org/en-US/docs/Web/API/XDomainRequest/onerror
Specifically:
Note: There is no way to determine the cause of the error from the XDomainRequest interface.
This means two things:
- You can't see the body of the info.json unless it is returned as HTTP 200. So you can't see the services.
- You can't distinguish between 401 and 403. They are all just "error" events.
So in IE8/9, XmlHttpRequest won't let you load the info.json at all (unless on the same domain) and XDomainRequest won't let you do anything with it unless it was a 200. XmlHttpRequest in IE8/9 (and, in fact, even earlier) will let you see the status code.
The upshot of this is that auth won't work in IE8 and IE9 cross domain. With some careful control over what jQuery is doing, it could be made to work same domain (where the script and the image services are on the same domain). We could ensure we never use XDomainRequest under any circumstances. A viewer could accomodate a same domain auth flow, and that might be more common than we hope in library reading rooms and inside institutions where people are forced to use IE9 to look at their own authed materials. If a viewer sees that a cross-domain auth flow is required, and jQuery.support.cors is false, then the viewer can tell the user to use a different browser ("Authenticated content from different domains requires a browser that implements CORS, such as IE10+, Chrome, Firefox...")
Although it doesn't sound ideal, the same domain bit would work for Wellcome today because all the things the embedded viewer needs to show when embedded on the Wellcome site are Wellcome things (true even when the viewer is embedded externally, the script source and the image services are still the same domain).
However, we're about to move the image services to a different domain - to dlcs.io. But we could host the UV there too.
I think that having an auth flow that requires CORS cross domain but will support IE8/9 on the same domain is actually all right, in 2016. Stakeholders who care about the /item/ page and external embeds working in IE9 for Wellcome content will be happy. You won't be able to do this in IE9:
But people who do that there won't be using IE9.
You won't be able to view a manifest from multiple sources where each source is authed. But again, that is not the standard "catalogue" view of items for a library.
We will need to load the UV code from the DLCS when we move to it.