Computing / Web Development1 Comment
Feb 11

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:


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

May 09

OS X printer setup bug: No IPP over HTTP

I have an old-ish US Robotics (!) wireless router which while not spectacular like many Linux-ed has one truly nifty trick up its sleeve – a USB print server. It allows you to plug in virtually any non-network-enabled printer and share it among whoever is connected to your wired or wireless network.

Today I tried to set it up to work with my Mac. The router is old enough to show OS X 10.3 (I think) support information on how to connect the Mac to a printer attached to its print server. I am on OS X 10.5 and there was one thing that was pretty darn off:
On OS X 10.5 your choices are more limited than on that older version in that photo. The add printer dialog box offers you three options for network connections: IPP, or Internet Printing Protocol – which is used by my router, LPD – a UNIX network printing protocol, and HP JetDirect, HP’s proprietary printing protocol.
Still, my printer would not work and after a while I found out why. The router’s network print server uses a URL such as
The add printer dialog only allows you to add a printer by specifying its IP address and port, as well as its queue name. What it does not allow you to specify is what *protocol* to use when using IPP. The result URLs stemming from the dialog look close to the one I needed, but not right:
If you notice, the URL is now with an ipp protocol prefix. And that does not work because it is simply the wrong protocol. There is literally no way to make this happen, through the ‘conventional’ means offered by OS X – this add printer dialog. I doubt that this is too big of an issue for too many people, but the fact that it used to work in previous versions of the operating system is a bit sad. So how do you still make it work?

A few years ago, Apple took over one of the biggest undertakings of the open source community – making printing on UNIX and Linux suck less. The CUPS project actually achieved that goal and its print server is built into every OS X machine. CUPS, like on any UNIX machine, can handle virtually any common printer on any protocol – part of the beauty of open source. And on OS X you can access its administrative screens (a bit rough but very usable) by going to the URL
Once there, you can follow CUPS’ web-based wizard to add a new printer and lo and behold – it offers a network print protocol option of (drumroll), of Internet Printing Protocol over HTTP. Make sure you have your password for the machine to actually complete the printer but once it is added, it appears in the normal, OS X printing screens.

In short – it appears to be an OS X bug or omission, but luckily not something beyond the realm of accomplishing.

Sep 08

How browsers detect whether the URL points to a file or a directory

Suppose you are a browser and you get a URL like:
How do you know if awesome is a directory or a file?
A really nice hint you’d be nice to give is to append a slash to the URL whenever you denote a directory.

So how *can* you find that out?
The only way I found out had to do with headers. It appears that when web servers are sent a URL like and awesome *is* a directory, the response header will redirect the browser (or requestor for that matter) to the properly specified URL which has the trailing slash character. I am sure that has to do with server setup.

Need to research this issue more…