I ❤ HTTP::Engine

It’s too bad I can’t use it at work, but HTTP::Engine rocks my world. It does “The Right Thing ™” for negotiating HTTP requests and their content in a wonderfully transport-agnostic way. That means that if you’re running in mod_perl, FastCGI, plain ‘ol CGI, or even running as a stand-alone development-mode daemon, it will just work.

At my work, we’re building new user interface components to our email security appliance product, and for the first time we’re building a web interface that will be used by a potentially high number of public users. Up until now, all of our target users were internal to our customers, meaning system administrators and a small number of workgroup users. Now however, their customers and the recipients of potentially a high number of emails will be able to interact with our appliance. This means we have to scale a lot higher than we have needed to in the past, all with limited hardware and memory.

So for the first time in eons, since before I started working with mod_perl back in the late 90’s, I’m having to parse HTTP POST data, including file uploads, by hand. Catalyst does it really well, but unfortunately the list of dependancies it has makes it prohibitive to pull in to our build. That’s when I discovered HTTP::Engine. It looks great, it does what Catalyst does for managing HTTP requests in a flexible and extensible way, gives all sorts of great developer hooks to access internal information about the request, and it doesn’t require that you buy in to Catalyst’s way of doing things (of course, when I’m at home, I develop my apps using Catalyst).

Sadly though, HTTP::Engine’s list of dependancies is almost as long as Catalyst’s. Normally this wouldn’t be a problem, but given our restricted memory limits, I just can’t justify using it. Which really blows, because as CPAN modules go, this one is pretty darned sexy!

I’ve decided to simply write a sub-class of HTTP::Request that does what we need, and tie it in to the Nginx 3rd-party module for file uploads.

Maybe someday I’ll be able to use Moose, Catalyst and HTTP::Engine on our appliances deployed in customer locations around the world, but for now I’ll just have to roll my own.


  1. Before you start writting your own HTTP::Engine::Simple, take a look at Mojo (I recommend that you use the git version, a new release is imminent and it is much niceier).Not only it has zero dependencies (which seems something that you need), it also is the most HTTP spec compliant stack on CPAN.Even better: it includes a full MVC Web framework with modern dispatching.I use it at $work.

  2. Yeah, I’ve looked at Mojo, but for what we’re doing it’s still a bit heavyweight. Thanks to this article on the memory footprint of CPAN modules, I discovered CGI::Simple which should do enough of what we need to allow this project to move forward.This is a really simple webapp though; in the future our more complicated administrative interface will need to move to FastCGI away from mod_perl2, so we’ll look at Mojo or HTTP::Engine again then.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.