Screenshot of the 200 Object] HTTP status code in Firebug

If you’re like me, HTTP status code 200 Object] unknown probably doesn’t ring any bells. Of course, that’s mainly because it doesn’t exist.

So, how did I end up with the screenshot above? I’ve been running with scissors again. It was one of the more popular web frameworks for Node.js that I cut myself with this time: Express.js

Unfortunately, a malformed status code like 200 Object] will cause some browsers (including the version of Chrome I was using at the time) to refuse loading the page at all. That quickly elevated the importance of my strange status code from a trivial oddity to an annoying thorn in the side.

As it turns out, my code was running up against a documented Express feature and the remedy was simple enough.

Status code: RTFM

The site I was working on at the time is simple enough, built from a handful of views and a few supporting scripts that act as “models”. Unfortunately for me, the topic of this particular site led me to pass one of those models into a view using an object property named status:

app.get('/', function(req, res) {
  Models.getIndexViewModel(function(model) {
    res.render('index', { status: model });

You can probably guess where my bizarre HTTP status code came from now, and a quick search through the relevant Express documentation confirms:

This options object is also considered an “options” object. For example when you pass the status local, it’s not only available to the view, it sets the response status to this number. This is also useful if a template engine accepts specific options, such as debug, or compress. Below is an example of how one might render an error page, passing the status for display, as well as it setting res.statusCode.

Head, meet desk.

Instead an HTTP status code, I was passing a JavaScript object to Express and it was trying to interpret the string representation of that object as an HTTP status code to apply to the response. In JavaScript, objects evaluate to a string value of [object Object], which is how Object] ended up being sent down instead.

I didn’t take the time to dive into Express’ source to determine why the [object Object] string ended up being split on the whitespace, with only the second half showing up in the actual response. The net takeaway is the same regardless of why: don’t pass status into your Express views unless you understand what that actually does.

Everything’s easy in hindsight…

In retrospect, it may seem painfully obvious that my choice of property names was the culprit, but I didn’t benefit from this post’s narrow context at the time.

I didn’t end up finding the issue until days after writing the code that caused the problem. Since the odd status code didn’t break anything while I was testing in Firefox, it wasn’t readily apparent that I had introduced a bug at all. By the time I tested in a browser that choked on the invalid status code, I was far removed from the relevant code, and it wasn’t as easy to debug as it might seem now.

I almost decided against posting this for fear of looking like a dunce, but I can’t be the only person that will run into this problem. So, I hope this post saves at least one person from running into the same self-inflicted injury that I did.