4
votes

I've implemented a web application that takes advantage of CORS to gather JSON data from another server. The servers run on different subdomains. Everything seems implemented correctly, and it works fine with Chromium. Below is a copy of my requests, from Chromium.

My problem is that in Firefox (tested with 13.0.1), no request is ever made for my AJAX resource. No preflight request is ever sent, and no actual request is made. Instead, I get this error, from the XMLHttpRequest.send() function:

[21:40:27.546] uncaught exception: [Exception... "Access to restricted URI denied"  code: "1012" nsresult: "0x805303f4 (NS_ERROR_DOM_BAD_URI)"  location: "http://192.168.1.99:2502/static/mootools-core-1.4.5.js Line: 5398"]

I am using Mootools' Request.JSON object, which sets various extra headers, meaning that a preflight would indeed be required. However, it is never sent.

Unfortunately, JSONP is not an option, as the data is sensitive.

Does anyone have insight into what the problem could be? Thanks very much.


Working example, from Chromium:

Preflight request:

OPTIONS /api/resource HTTP/1.1
Host: dev0.mydomain.com
Connection: keep-alive
Access-Control-Request-Method: GET
Origin: http://192.168.1.99:2502
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.19 (KHTML, like Gecko) Ubuntu/12.04 Chromium/18.0.1025.151 Chrome/18.0.1025.151 Safari/535.19
Access-Control-Request-Headers: origin, x-request, x-requested-with, accept
Accept: */*
Referer: http://192.168.1.99:2502/
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Cookie: [redacted]

Preflight response:

HTTP/1.0 200 OK
Server: PasteWSGIServer/0.5 Python/2.7.3
Date: Fri, 29 Jun 2012 01:43:37 GMT
Content-Length: 0
Access-Control-Allow-Headers: Cookie, Origin, X-Request, X-Requested-With, Accept
Access-Control-Max-Age: 1
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: http://192.168.1.99:2502
Access-Control-Allow-Methods: GET
Content-Type: text/html; charset=UTF-8

"Real" request:

GET /api/resource HTTP/1.1
Host: dev0.mydomain.com
Connection: keep-alive
Origin: http://192.168.1.99:2502
X-Request: JSON
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.19 (KHTML, like Gecko) Ubuntu/12.04 Chromium/18.0.1025.151 Chrome/18.0.1025.151 Safari/535.19
Accept: application/json
Referer: http://192.168.1.99:2502/
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Cookie: [redacted]

"Real" response:

HTTP/1.0 200 OK
Server: PasteWSGIServer/0.5 Python/2.7.3
Date: Fri, 29 Jun 2012 01:43:37 GMT
Access-Control-Allow-Origin: http://192.168.1.99:2502
Content-Type: text/html; charset=UTF-8
Content-Length: 22
Access-Control-Allow-Credentials: true
1
Is that line in your mootools the send() call? The only ways to get that exception thrown from send() in Gecko, as far as I can tell, are to use a non-HTTP URI (which you're not doing) or to have a username or password directly in the cross-site URI. If you're not doing that last, I'm not sure why this is failing for you. You can't by any chance put this up somewhere public?Boris Zbarsky
Boris, you're right, and I feel a bit silly now! Indeed, I added a username for HTTP authentication in my Mootools Request object, because that was the easiest way to trigger Mootools to turn on the XMLHttpRequest withCredentials option. Chromium didn't send the username (presumably because I didn't include a password), but Firefox does apparently consider it. The solution now is to extend Mootools' Request.JSON object to turn withCredentials on without the HTTP authentication username. Thanks!Sam

1 Answers

3
votes

The answer is given in the comments to the question. Firefox was not sending the request due to the HTTP authentication username I had provided.