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. 1.7.1 was just released and still supports legacy Perls.
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.
HTTPi 2.0 will be a complete rewrite. Its chief improvement will be a serious overhaul of the fork()-based Demonic core (hopefully getting rid of fork() entirely except for executables), but it will still continue to support its various inetd-like flavours. I am also considering making it autoconfiguring to allow integration with modern package managers. The end result should be greatly improved performance and reduced system resource usage, at the expense of possibly impairing compatibility. I have no code written for 2.0, and I don't expect to imminently. As I figure out more core goals for 2.0, they will be posted here.
The long and short of it is, you can expect that I will continue to be supporting HTTPi for a long time to come, and the long-lived 1.x series branch will be supported at least as long as Perl 5 is (and probably longer :). Since I'm a HTTPi user too, you can rely on that promise. Thanks for your 10+ 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
stunnel is now supported as an
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.
Yes, I know this continues to be an issue. There seems to be some problem
with the Classic Mac MacPerl site, and it doesn't seem to have been updated
in some time. An ActiveState
port may become available, but I am (still!)
waiting for patches from one user who hacked
inetd-based HTTPi to work in this environment.
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.