The HTTPi FAQ

• Why should I use HTTPi?

  If you believe "smaller is better," this is the webserver for you. It's small, lightweight on system resources, speedy and fully extensible (100% Perl, no modules, additives or cheap fillers). And if you don't believe it's up to the task of being your personal or corporate webserver, look closely at the headers: HTTPi is serving this document to you right now.

  HTTPi shines at:

  • low system overhead -- run it in inetd and HTTPi only runs when it's needed; run it in Demonic and HTTPi autothrottles to as few forks as possible
  • ultra-small system requirements -- can run with just the Perl executable (no extra Perl modules needed: not even the standard distribution, nor Socket.pm, Net.pm or LWP)
  • tiny footprint -- just barely 10K max, easy to comprehend and fast to compile and interpret
  • high reliability
  • easy expansion and customization with included configure system

  Moreover, HTTPi supports most of the major functions the "big boys" do, including:

  • SSL (with stunnel)
  • user pages
  • virtual hosting (both IP-based and IP-less)
  • executables
  • HTTP/password, IP-based and client-based protection and authentication
  • server-parsed pages

  And it does it all in a small space to boot -- just a few kilobytes.

  In short, if you want to run a web server, but don't want it to take over your entire system (like larger servers are wont to do), try HTTPi. It's fast, flexible, small and, most of all, respectful of your system resources.

  Check out our growing list of HTTPi-powered sites.

• Why shouldn't I use HTTPi?

  Because HTTPi's watchword is ultra-miniaturisation, the feature set of a larger webserver just isn't there. Moreover, HTTPi has non-standard executables (basically NPH-CGI; not fully CGI/1.1 compliant) and only implements enough of the HTTP/1.0 and /1.1 specifications to render token compliance.

  More importantly, HTTPi is truly a hacker's webserver. While you can build and run HTTPi more or less out of the box, to get the most out of it you will need good knowledge of your system and fair working knowledge of Perl.

  So, if you're looking for a big, enterprise-level webserver, unless you intend to write your own based on HTTPi (and tell me if you do :-), try Roxen Challenger instead. But, if you want a small, efficient server that you can hack like crazy, you've found it.

• Why are there multiple flavours? What's Demonic HTTPi?

  HTTPi comes in multiple versions to suit the way you want to run it.

  HTTPi originally ran out of inetd, which is still supported and still commonly used on the small-storage systems for which it was originally designed. In 0.4, HTTPi added support for xinetd, a fast, secure and more feature-packed inetd replacement. xinetd allows you all the advantages of an inetd-based install, along with IP-based virtual hosting, greater security, and better process flexibility. In 1.6, HTTPi added support for Apple's launchd as an inetd-like clone.

  Demonic HTTPi is the most popular method, a daemonised version of HTTPi introduced in 0.7 that runs as a daemon process like many other webservers. It also offers IP-based virtual hosting, excellent stability, and is the fastest of the available methods.

  Finally, if you need SSL, HTTPi added support for stunnel in 1.6, allowing you to use stunnel and your server's cryptographic libraries to SSL-wrap your HTTPi transactions.

  By offering multiple flavours (including a Generic install for "none of the above" sites), HTTPi can be configured to your taste from the word go.

• Does HTTPi support SSL?

  HTTPi supports SSL by using an external tool, specifically stunnel (others may also be compatible); there is specific support for stunnel in HTTPi and a special configuration option is included. Note that HTTPi does not contain its own cryptographic or SSL negotiation code; these are provided by your system's crypto library (such as OpenSSL) and stunnel.

• What do I need to run HTTPi?

  For the Demonic version, just the Perl executable. No modules necessary. You will also need superuser access to run Demonic HTTPi on port numbers lower than 1024, like any other server process.

  For the other flavours, you need Perl, a compatible inetd or equivalent (like xinetd, launchd or stunnel), and superuser access to your (x)inetd's configuration files.

• Does HTTPi work on non-Unix systems?

  In theory, yes, since there is nothing in HTTPi that is not officially supported in Perl, or depends on oddiments of your system (eh, well, nothing the programmer knows about :-). However, in practise, not always. The reason is that HTTPi needs calls such as fork() and (preferentially) alarm() for proper process isolation, and while these are supported and standard functions in Perl, they are not implemented in all of the Perl ports. To run HTTPi, your Perl should have support for alarm(), but as of 0.99 this is no longer required. To run Demonic HTTPi, your Perl must have support for fork().

  • Classic MacOS and Mac OS X support: HTTPi does not currently run on classic Macintosh systems under the original classic MacPerl, and due to the apparent death of that port may not ever run under it. Perl, however, is a standard part of Mac OS X. The 1.7 legacy branch will run on any version of Mac OS X from 10.2 Jaguar forward, and HTTPi also has specific support for the launchd superserver introduced in 10.4 Tiger. It runs unmodified on PowerPC and Intel Macintoshes. Future versions will run just fine on the built-in Perl with 10.5+, or using later Perls built with MacPorts and/or Fink on 10.2 through 10.4. I do not recommend using 10.0 or 10.1, though it will probably also work on those machines.

    If you absolutely must run a classic Mac OS, however, the legacy HTTPi 1.7 branch does run and is tested on Power MachTen (I do recommend that you install a newer Perl than the one it comes with, though). You may also be able to run it under A/UX.

  • Microsoft Windows support: As ActiveState Perl for Windows now includes some fork support, you may be able to hack Demonic HTTPi to run under Win32 in this environment, but no support for this is available yet. Good luck, please let me know if it works ;-) You may also be successful in connecting the (x)inetd HTTPi flavours to your inetd clone, but this has neither been tested nor is it supported either. The configure.generic profile may be helpful in this regard (see the Installation instructions). Since I don't own a Windows-based PC, I would appreciate any bugs being reported to me at httpi@floodgap.com.

  • Cygwin support: There have been success reports from Cygwin users of prior versions, but some modifications were required, some of which I have included currently in the present distribution. Although there is no official support for Cygwin yet, it will probably work. I would appreciate any bugs being reported to me at httpi@floodgap.com.

  If you don't know if your port will run HTTPi, fear not. The configure scripts will check if the functions are implemented in Perl before they even get started, so the worst that will happen is that you just won't get very far.