views:

838

answers:

2

I'm trying to make a request using dojo.xhrGet to grab some XML data from a server. I'm using dojo 1.4.0.

The server requires that I pass credentials through a custom HTTP header called Myauthtoken.

Everything works fine in Safari. The code pops up a dialog showing [object Document]. But in Firefox, the dialog shows null. Somewhere along the process, the custom header is being dropped or corrupted, and the server doesn't accept it.

The relevant code looks something like this:

dojo.xhrGet({
  url: 'https://host.com/path/to/thing?param1=one&param2=two',
  headers: {
    'Myauthtoken': 'username:password'
  },
  handleAs: 'xml',
  load: function(response) {
    alert(response);
  },
  error: function(e) {
    alert("error: " + e);
  }
});

In Firefox, Firebug displays the following Request Headers:

Host: host.com
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Origin: null
Access-Control-Request-Method: GET
Access-Control-Request-Headers: myauthtoken,x-requested-with

The server responds with a 403 (Forbidden) and these Response Headers:

Date: Thu, 28 Jan 2010 20:02:47 GMT
Server: Noelios-Restlet-Engine/1.0.6
Content-Type: text/html; charset=ISO-8859-1
Content-Length: 337
Connection: close


Update! I've been researching, and it looks like the problem is that Firefox is attempting to preflight the request because of the custom headers, while Safari isn't, and is instead just sending the custom headers without first checking if they're valid.

I also figured out how to look at the Request in Safari:

Cache-Control: max-age=0
Content-Type: application/x-www-form-urlencoded
Myauthtoken: username:password
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_8; en-us) AppleWebKit/531.21.8 (KHTML, like Gecko) Version/4.0.4 Safari/531.21.10

And the Response Headers:

Cache-Control: no-store
Connection: close
Content-Length: 236391
Content-Type: application/xml; charset=ISO-8859-1
Date: Fri, 29 Jan 2010 23:02:22 GMT
Server: Noelios-Restlet-Engine/1.0.6

The main difference being the Content-Length: 235391

Unfortunately, I'm still not much closer to actually finding a solution- still looking for some good ideas, or really any ideas at all.

Any thoughts on what's going on and how I can get around this?

Thanks!

A: 

For custom headers, I believe you need to use the X- prefix:

X-Myauthtoken: username:password

  headers: {
    'X-Myauthtoken': 'username:password'
  },

The server will need to accept it as well, since it's a non-standard header.

LiraNuna
In what context do you need an `X-` prefix? It works fine with Safari and curl. Is this only in Firefox? Do you know of any documentation?
Eric Freese
The server has to accept it as well as you need to send it.
LiraNuna
A: 

After a bit more research, it looks like the problem is that the server is expecting the headers to be case-sensitive, while Firefox is converting the headers to lowercase.

Firefox is sending myauthtoken, while the server is expecting Myauthtoken.

In the end, it all came down to a bit of code where we were using getFirstValue(String name), which defaults to case-sensitive, instead of getFirstValue(String name, boolean ignoreCase).

Watch out for case-sensitive headers!

Eric Freese