Categories
Computing Web Development

Rails HTTP error 406 in response to JSON requests

Had a painful experience last night trying to get Rails to properly handle a JSON request coming from an Objective-C client. Rails was issuing a semi-exotic HTTP error 406. Error 406 means that the user agent – your browser, my iPhone app – cannot handle the response being sent to it. Apparently it all stems from an HTTP request header, Accept, which tells the server what content it can 'digest'.

In any case, to cure this problem I looked at what Accept header Firefox was sending when Rails was successfully handling its requests. By copying Firefox's Accept header and sending it to with my request, I was able to overcome the 406 error and get a happy 200 response.

The Accept string that worked was:

text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

If this does not work, also examine the Rails controller. Make sure that all REST methods return JSON representations.

Share
Categories
General

SBJSON: Testing for nil / NULL value

I am playing with a variety of JSON frameworks in Objective-C. All are severely under-documented but then, they are simple to use, right? No. Nonetheless, I am deeply in awe and in debt to the great individuals who invested endless hours of their time to build these libraries and give them to us to use free of charge. Thanks you.

Anyway, SBJSON from Stig Brautaset, which I am examining right now, exposed a relatively weird issue. How do you test for null values in the contents of the parsed NSDictionary at hand? 

Plain old ([dictionary valueForKey:@"key"] == null) will not work. The breakthrough came when looking at the dictionary printout to gdb (Right-click the object in memory and select 'Print Description to Console'). The null value was 'stored' in a CFNull reference. To test whether a pointer is pointing at CFNull, you do this:

myVariable == kCFNull where kCFNull is a special memory address dedicated to hold this special null (nil!) value. 

Share
Share