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:

  • security -- thoroughly tested for holes and rigourously pounded on
  • 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:

  • 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.

• Is HTTPi Y2K compliant?

  Yes, and it always has been (as long as your Perl and OS are, also). If this doesn't make sense to you, read the compliance statement.

• Why are there three flavours? What's Demonic HTTPi? What's xinetd?

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

  HTTPi originally ran out of inetd, which is still supported (and the best way to go for a practically invisible web server).

  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.

  Demonic HTTPi is the other method, a daemonised version of HTTPi 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 three, but autothrottles its process load for a webserver that's visible, but just barely.

  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?

  SSL is not internally supported, but can be added with external tools such as 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 (x)inetd versions, you need Perl, a compatible inetd or equivalent (like xinetd), 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 (x)inetd 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().

  MacOS support: HTTPi does not currently run on classic Macintosh systems. However, since Mac OS X is actually Unix, it builds and runs there without a problem, and people are using it with OS X right now. Myself, I have successfully built and run Demonic HTTPi on Mac OS X from 10.2.8 forward and it works great and is fully supported.

  Microsoft Windows (95/98/ME/NT/2000/XP/2003) support: As ActiveState Perl 5.6 for Windows includes some rudimentary 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 modern Windows based PC, testing and development on this fork is slow.

  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.