![[<<]](pix/httpismall.gif){kind=small}
Back to the main page
Due to the retirement of most of our legacy systems, there are no longer easily accessible servers to test new changes against these very old versions of Perl (we have only one server left running 5.005, and none running 5.6). I have arbitrarily chosen 5.8.8 as the earliest supported version for 1.8 and above, since that is the earliest Perl I have running on the servers presently in operation.
However, 1.7 will indefinitely receive security updates and critical bug fixes as they are reported or discovered. These fixes will be kept compatible with these older Perls to the maximum extent possible. Thus, if you rely on HTTPi for your applications on your legacy Perl installation, I will still support it with maintenance fixes on an irregular basis; there will just be no new development for it.
Versions 1.8 and higher will require at least 5.8.8. Although they may still work on old versions of Perl, you may receive warnings or errors, and they will not be supported with them.
1.6.2 was the last version to support building without the New Security Model. The NSM, which is used to improve HTTPi's security and uid permissions management, has been the well-tested default since 1.5 and there are now some important internal code paths in development that greatly rely on it. As a result, the NSM will now be built-in to 1.7, and all installations will build with it automatically.
The good news is, most of you are probably using it already; those of you who are not should test your installations now, and the vast majority will find that everything still works. However, if you are one of the very few people using an application that demands the NSM be disabled, please let me know ASAP.
I get periodic questions about plans for HTTPi, so here is a capsule answer. HTTPi 1.x is essentially mature, and I plan to keep its code relatively stable for the future to ensure compatibility over the widest range of Perls, notwithstanding the above. Security and bug fixes will continue to occur for 1.x, and I don't have any plans for its retirement; although I have vague plans for HTTPi 2.0, HTTPi 1.x continues to work well enough for my purposes. Thanks for your 20+ years of support which continue to make HTTPi the best and most mature choice for a pure-Perl webserver environment.
launchd is now supported as an inetd-substitute
in 1.6.
OS X users who want to use Demonic should just roll a .plist like anything else for autostarting on bootup, with a tool like Launchd Editor (10.4+) or Lingon (10.5+).
stunnel is now supported as an inetd-substitute
in 1.6. This is the officially supported way to use HTTPi for SSL.
This support should still be considered EXPERIMENTAL, due to the
newness of this code and its high security requirements.
Do note that there is nothing precluding using stunnel for Demonic, but you will need to run Demonic HTTPi as a separate process and allow stunnel to proxy the port (transparent mode would be required for proper logging in this environment, however, which may not function on all OSes).
There are now several requests for this and it will be supported, probably in 1.8. It will not be supported on the 1.7 legacy branch.
Executables that die under HTTPerl in 1.4 and up and return control to the default handlers generate two log entries, one with a return code of 100 and another with the error code (usually 500). Although annoying, the code to defeat this on my inhouse test version turned out to be involved and unreliable, and for this reason I have left the double logging issue alone as a "feature to flag bad executables." It does not affect versions prior to 1.4.
In 1.6.2, this also occurs for preparsed pages that cannot be preparsed, since the webserver can't know in advance if the page failed or not.
There are success reports from Cygwin users, but I do not officially support Cygwin at this time (yet), and the reports did require some changes which I have incorporated partially in 1.6. Please let me know your results.