Here's a simple-cased version of the jQuery equivalent, which uses jsonp (thus no same origin policy issues). In the fiddle, I've got the simplest form of .ajax(); you could add the omitted "dataType: 'json'", but it won't change the outcome. http://jsfiddle.net/LvTgf/1/

If you look at your console, you ought to see the same thing I'm seeing in my script, and when running that fiddle:

Object
images: Array[4]
0: Object
1: Object
2: Object
3: Object
length: 4
_proto_: Array[0]
release: "http://musicbrainz.org/release/2c84c9b3-d1d4-48c0-a825-a360f26a5dde"
_proto_: Object
fiddle.jshell.net:33
XMLHttpRequest cannot load http://s3.us.archive.org/mbid-7d166a44-cfb5-4b08-aacb-6863bbe677d6/index.json. Cannot make any requests from null.

That's the json object for the release with coverart, then a null return from the second request, for the release with no CAA data.

------------------

Now, re your gist, if you want to try it at http://jsfiddle.net/KBvtL/ , wrapping an XHR in try/catch doesn't catch errors like you're trying to do in your gist, because the XHR is an async function. The browser throws the error after the try has already successfully made the get request, and thus the try never did fail (thus never triggering the catch). The error is in the return, not the request. In the gist, I'd suggest dropping the try/catch, and try instead
request.onerror = function (e)

;
Your version: http://jsfiddle.net/hR5rK/
Onerror version: http://jsfiddle.net/hR5rK/1/
Note you now do see the "error thrown: XMLHttpRequestException" etc. (Also note, I only changed the error catching in that; http://jsfiddle.net/hR5rK/1/ still has SOP issues because it's not using jsonp.)

I'd expect that gist's code to fail either way, however, because it indeed should run right into the same origin policy. That is why you are seeing the CORS header thing you mention; it's nothing to do with what the CAA is returning. Here's the log output showing that that's what happens with your gisted version:

GET http://svikt.org/ia404.php 404 (Not Found) fiddle.jshell.net:25
XMLHttpRequest cannot load http://svikt.org/ia404.php. Origin http://fiddle.jshell.net is not allowed by Access-Control-Allow-Origin.
error thrown:
XMLHttpRequestException
fiddle.jshell.net:30
requesting http://svikt.org/cors404.php fiddle.jshell.net:21
GET http://svikt.org/cors404.php 404 (Not Found) fiddle.jshell.net:25
status: 404 fiddle.jshell.net:26
body: <?xml version='1.0' encoding='UTF-8'?><Error><Code>NoSuchKey</Code><Message>The specified key does not exist.</Message><Resource>mbid-1735e086-462e-42c3-b615-eebbd5e9f352/index.json</Resource><RequestId>10507ba9-c40f-4b04-a608-742e4309a9fc</RequestId></Error>

You're obviously doing the XMLHttpRequest() differently compared to how I'm doing it

The Content-Type of the 404 response is text/plain, so I don't understand why you are trying to parse that as JSON. If you get a 404, why are you parsing the body?

I have set up two test files, one with a 404 response like the internet archive, and one with an added CORS header. Using the following code, only ia404 throws an exception, cors404 does not:

https://gist.github.com/2782344

This is both in firefox and chrome.

@Kuno: I'm not sure what you're seeing, but getting around XMLHR security issues to get json data from the caa webservice is relatively simple. I already am easily able to get that data. First, a x-ss/CORS-related security error throws a different error message, and second, the error comes not on all releases, but only for those without existing CAA cover art. See attached screenshot; this is within the script I'm writing at the moment. The example uses the first two releases on page 1 of http://musicbrainz.org/artist/5b11f4ce-a62d-471e-81fc-a69a8278c7da/releases . I've also included the console in the screenshot. For the text on the right, (I've removed the unrelated jQuery stuff), you can see my debug logging, as well as the XMLHR error thrown. You can see that at the point of the screenshot, I've clicked the button which told the script to load the data for two releases, one which I know has art, one which I know does not:

Add CAA images to release row button triggered.
Requesting CAA info for 2c84c9b3-d1d4-48c0-a825-a360f26a5dde releases:19
Add CAA images to release row button triggered. releases:19
Requesting CAA info for 7d166a44-cfb5-4b08-aacb-6863bbe677d6 releases:19

So now the 2 requests have been sent out. The next line is the XMLHR request error caused by receiving XML, instead of JSON. I'm not 100% sure why Chrome phrases it as "Cannot make any requests from null.", but what it really means is "the JSON object created from the JSON request is a null object". ie, it's assuming that, minimally, a JSON request will result in {}, even if {} is an empty object. Instead, it's getting back XML, which contains no object definition at all - ie, null, instead of an empty object.

XMLHttpRequest cannot load http://s3.us.archive.org/mbid-7d166a44-cfb5-4b08-aacb-6863bbe677d6/index.json. Cannot make any requests from null.

Then the next line is my debug log output again:

Ignore the XMLHttpRequest error. CAA returned XML stating that CAA has no images for this release. releases:19

And last is my debug log output from the other request, the request for CAA data for the release which does have data at CAA.

Received CAA, parsing...

And over on the left, you can see the final result: Love Buzz / Big Cheese had data for 4 images, which have been parsed and loaded via the CAA-returned JSON. Bleach on the other hand, had no CAA data, so it's only showing editing boxes (a part of my script), but no images which already were in CAA.

Were this error at all related to CORS/XMLHR security issues, then the right side would be showing 2 errors instead of 1, and Love Buzz / Big Cheese would not holding any data nor be showing any images. (JSON is affected by CORS; JSON-P is not.)

Ok, I've done some digging. What you are seeing is unrelated to the content-type mismatch.

The internet archive response doesn't include a CORS header, so the XMLHttpRequest call does not have permission to read the 404 status code or response body, that is why it throws an exception.

As Oliver remarked, we can solve this for index.json.

@Kuno: I understand that javascript (jQuery or whatever you like) can detect the error. Detection is not the same as catching it, however; even when it is caught, an error is still registered and displayed in the error console (at least in Chrome and FF; not sure about IE or Opera). It's non-optimal that any error ever should bubble to the point where the average user might see it and believe it to be a fault in the software they're running. They shouldn't be expected to understand that it's actually a fault in the service itself, with the service returning data in one format, but claiming to be returning it in a different format.

@Oliver: yes, thanks; that summarizes well what I was trying to say above. I'd mention, though, that I've seen two other, different, XML errors in addition to the "no artwork" error I'm seeing via ajax calls. Both of them, I've seen embedded directly into the CAA tab's HTML served by MB. One is the one we all were seeing a week or two back, when (I think) archive.org was overloaded with CAA calls, or something along those lines? The other one, I forget quite what the error was; I just recall it not being that same overloaded error, and also displaying as raw XML within the MB page.

This isn't outside our control. We can query the caa database and look for artwork for the given release MBID. If there's nothing, we can return a hardcoded empty response.

This is outside of our control. These responses send the correct 404 response, with a "text/plain" content-type and XML response body. The mismatch between content-type and response body is obviously an error, but shouldn't present any real problems.

That XMLHttpRequest throws an exception seems like the correct behaviour here.

e.g. with jquery you would do something like this:

var foo = $.getJSON ("http://coverartarchive.org/release/1735e086-462e-42c3-b615-eebbd5e9f352/");

foo.fail (function (jqXHR, status, error) {
console.log ("An error occurred: " + status);
});

foo.success (function (data, status, jqXHR) {
console.log (data.images);
});

I'm working with the CAA in javascript at the moment. This actually makes for some nastyness from XMLHttpRequest. When it gets that XML as response, when it is expecting JSON, it throws a nasty

"XMLHttpRequest cannot load http://s3.us.archive.org/mbid-9d78d5d4-2307-4523-948f-bb072ceb37a8/index.json. Cannot make any requests from null."

(The mbid in that error message can obviously vary). Instead, CAA should be sending back valid JSON with an empty images object:

{"images": [{}],"release": "http://musicbrainz.org/release/d1b25ac5-8ef2-4b9e-b1f6-66d6d2771d16"}

or, at minimum,

though the empty images object version would seem easier on developers. (No need then to test for the existence of images; they can only worry about having to consider if it has any contents).