![[<<]](pix/httpismall.gif){kind=small}
Back to the main page
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:
inetd and HTTPi only
runs when it's needed; run it in Demonic and HTTPi autothrottles to as
few forks as possible
Moreover, HTTPi supports most of the major functions the "big boys" do, including:
stunnel)
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.
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.
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.
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.
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.
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.
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. Perl, however,
is a standard part of Mac OS X and HTTPi will build and run on any system
from Mac OS X 10.2 Jaguar forward. HTTPi also has specific support for the
launchd superserver introduced in 10.4 Tiger. It runs unmodified
on PowerPC and Intel Macintoshes, and I routinely test on 10.4 and 10.5 systems
as part of QA.
Microsoft Windows (95/98/ME/NT/2000/XP/2003/Vista/2008) support:
As ActiveState Perl 5.6 and higher
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.
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, and I am planning to officially extend overt support for Cygwin users in the future. 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.