A Miscellany Of Http Status Codes

Initial Idea

Dean: Like a lot of ideas, HTTPflies appeared almost entirely by accident. I saw a tweet a few months ago, from someone who had seen an obscure HTTP status code. The tweet jokingly said something like, ‘you rarely see this in the wild’. The notion of ‘rare code’ got me thinking.

This got me thinking about the documentation and classification of animals – could we do something fun, along these lines, but for code? So Tom and I started chatting about butterfly collections, and whether we could do something to experiment with generating multiple versions of something, from a few basic graphics.

Why use SVG


  1. SVG is cool.
  2. Scalable graphics are good and responsive.
  3. When embedded into a page it can be manipulated with tools like jQuery (just like HTML can be).
  4. It can be like a library (a relatively small download which is then reused to create far more complex things through manipulation and combination of the parts).
  5. It forms a nice half-way point between hand-crafted imagery and code-created imagery, in that some parts can be done by hand but can then be manipulated by code.

That last point is interesting. There’s something in that about how “designers” and “coders” work together and how SVG forms an interesting span across that gap. You could create the graphics entirely in code (with combination of squares and circles etc) but I like the fact that an artist can create something in illustrator and that it pops out in a form which is perfect to be coded with. With PSD’s etc you have to translate the pixels into code, but with SVG the graphic is already code. Not that SVG would be good to do web design in, but just it’s an interesting half-way point somehow.

Library of shapes

diagram of butterfly wing layers

Tom: We reduced the anatomy of a butterfly down to some component parts. Deciding that a single body would suffice and that for each wing-type we’d want at least two layers. As every school-child knows you only need to paint half a butterfly and so it was here with one set of wings being enough to create a full butterfly. Once we had these components in place we could pick out the wings shapes we wanted, duplicate and re-colour the different parts and present as many different butterflies as we needed all with pure code. Using SVG as a repository of reusable elements like this seems like it might have interesting possiblities for the future.


Dean: We wanted the colours to be generated kind of randomly, but it soon became clear that some combinations and types of colours were pretty hideous. We needed some logic to ensure the HTTPflies were all beautiful, and harmonious, while at the same time not too similar to others. Tom was able to omit certain colours and make some rules around how we worked out each HTTPfly’s palette. Also, it was important that after each HTTPfly’s palette was assigned, it would be the same each time (and not randomly created on page refresh).

Download Size

Tom: As one of the main aims was to create a lot out of very little it was important that the initial download of the site would be as small as possible. Not only that but also it was vital that we made as much of that download as possible.

The normal routine of concatenating and minifying CSS and JavaScript files was still important but as this was to be a single page website it became clear that we could simply serve the entire thing as a single HTML file which could then be served (and gzipped in transit) and not need to be added to with any other external files in order to support further interactions. Not only this but apart from the SVG code we were including inline we could also reference other (smaller) graphics via embedded data URIs meaning even the incidental imagery was included in the same file.

Now, this would obviously not always for desirable for larger websites (where caching benefits kick in) but for an experiment like this it seemed to fit nicely within the overall idea, to serve the whole thing as one file.

So we hope you like it. It was great fun to make.


We need to give credit to a number of giants on whose shoulders etc etc...

  1. That wonderful fellow who created the JSON with all the status codes in it.
  2. The nice guy who made the jQuery library which makes it possible to work with SVG (and also the bloke who updated that code to solve a problem I was having).
  3. The lovely chap who created the excellent JavaScript colour library we used.
  4. The phenonimnal MDN SVG documentation which is awesome and usable.
  5. Copious people on StackOverflow who had already asnwered every question I ever thought of asking.

A quick note on xHTML

Tom: There was a moment in the middle where I thought I was going to have to serve the whole thing as xHTML. This came from a problem I had with my version of Safari (5 — for some reason) and I found a question on stackoverflow which seemed to point to this as the solution. I did quite a lot of work to make everything xHTML compatible (escaping various characters & using CDATA blocks for JS and CSS) and it was only when I implemented Modernizr at the end to check for compatibitly that I realised that Safari 5 isn't considered a browser that supports inline SVG. So we dropped support for it and went back to serving HTML5 instead. You live and learn.

Any thoughts?

If you've got any thoughts or suggestions we'd love to hear from you, tweet us @httpflies.