fhttpd an HTTP daemon - a program, which allows users from other machines on the Internet to access some information, stored on server machine in the form of text, pictures, sounds, hypertext documents, binary files and to run some programs on the server. To access that information users use some HTTP client, such as Netscape, Mosaic, Lynx, etc. If you are reading this on the fhttpd distribution site, you are using some HTTP client already
fhttpd also supports FTP protocol, which does exactly the same, although is designed primarily for file transfer, while HTTP is mostly used for "interactive" use and applications. So, fhttpd stands for
file / hypertext transfer protocols daemon.
It is distributed under GNU General Public License. API library and some applications, written by me for fhttpd are under "BSD-style" license, and socket objects library is under GNU Library General Public License. All three allow free (re)distribution, but impose different restriction on derivative works and use of libraries.
fhttpd is written by me, Alex Belits. The development of fhttpd started in 1995, although for most of time it was "too experimental" for general-purpose FTP/HTTP server. Some parts of it have been changed multiple times, implementing different models of the server that I tried to use. Now HTTP part of it uses the model that I found to be the best suitable for the server that supports both file transfer and applications. This is still a beta version, it's still under development, and I know that a lot of its code should be optimized, new modules added, API expanded, utilities written, etc. However now it is significantly more efficient and reliable than previous versions, and it is at least at the same level of quality as other servers that are in wide use now. The server model, I have implemented, is more flexible than anything else that I have seen in other HTTP servers, so adding features that now exist in other servers, is not a problem. I will continue the development of fhttpd, and I expect the version 1.0 to match all possible needs of web sites that now are not met by other servers. I will be glad to accept contributions to server code, especially new modules (database interfaces, interpreters, protocol converters), configuration scripts and other currently missing parts.
Please, send me by email any bugs and misfeatures, that you find in fhttpd.
~username" to the directory under user's home can be configured. Also it's possible to configure fhttpd to access files, run scripts and modules under that user's userid, if such remapping is used.
fhttpd distribution is stored at this server.
All development is done on Linux 2.0.x-2.2.x, and all configuration files are set for that system by default. It also works on FreeBSD 2.x - 3.x, SunOS 4.1.x, Solaris 2.x (SunOS 5.x), AIX 3.2.x - 4.2, Digital Unix 3.x (OSF/1), IRIX 6.x and HP-UX 10.x . Makefile has commented lines for those systems, so to compile fhttpd on them, just uncomment corresponding lines and comment Linux ones. I believe it will work on other Unix-based systems without any problems, too. Since version 0.3.0 it uses fd passing mechanism that differs significantly between Unices, so porting to systems that implement it in some unusual way may be a problem.
Non-unixlike systems are not supported, and I think, that porting servers to them is a Bad Thing. Porting this server to systems that poorly emulate Unix instead of implementing it will be a waste of time because the whole idea of fhttpd development is to use Unix features the way, they are intended to be used, not making a hack (ported server) over a kludge ("POSIX emulation subsystem"). If one needs an HTTP or FTP server for OS with non-Unixlike native kernel, it's easier to write a server from scratch.
It's hard to tell, how many bugs are in the current version, although in the past experience (since version 0.1) severe bugs very rarely appeared in betas. Most of bugs were some kinds of protocol incompatibilities, bug compatibility problems or inefficient code, although some of bugs that caused coredump on incorrectly handled situations existed in earlier versions. Version 0.3.0 should be more clean because it's the first beta that I can claim suitable for general public, so I did large amount of code-checking and testing before release. Still, it's a beta so watch out for bugs and report them to me.
Basically server is as secure as your system is. I have put a lot of
effort to make it
secure, so I don't think that properly configured fhttpd
on the properly configured system by itself can allow
someone to access something, he/she was not supposed to access.
Unless users have specified their username and correct password,
both the FTP and HTTP servers will disallow them to do anything
with user IDs, other than "ftp" in FTP or user IDs that are used for running modules in HTTP. File access for "ftp" user is
limited to the tree with root in ftp home directory or virtual
home directory, and HTTP uses configured default root directory or the
same virtual directory as FTP. However neither server executes
chroot(), so symbolic links from those subtrees pointing to
other parts of the directory tree will work. It is not a security problem,
if the "ftp" user can not login, groups are set up, and file attributes
properly. Since wrong configuration in any of those things will
cause security problems even without fhttpd, I consider fhttpd to
be a secure program, which may be used for something harmful if
security problems already exist.
Buffer overflow bug was found once in fhttpd, however I don't think, bugs of this kind are left in it.
There were some security bugs in beta releases (fixed them in 0.1.8). Severe bugs that were found later were not security-related (except, of course that server crashes caused denial of service), and even bugs that caused coredumps were not related to buffer overflows, and could not be used for anything but crashing the server. I think, it's very unlikely than new security problems will appear.
However, packet sniffing can be used to intercept information in transfer, although that is a problem, unavoidable by means, other, than strong encryption. fhttpd does not support encryption yet, although that will be included in later versions. For now, just use PGP or other strong encryption systems to encrypt files, you are going to make available for a limited set of users, before putting them into downloadable area at the server - and no one but people with keys will be able to read them.
Keep-Alive" is an option, sent by some HTTP 1.0
which tells the server to keep connection open after sending the
response and wait for another request. First it was implemented in
NCSA 1.5 httpd and Mosaic 2.7 beta. I have
implemented it in fhttpd, and some things went wrong:
Content-Lengthclearly indicated that. It looked like Netscape made it compatible with their own version of "
Keep-Alive", implemented in Netsite 2.0, although I neither have seen that specification, nor was able to test it on Netsite 2.0 because nobody (including Netscape itself) used it at the moment. I decided that Netscape betas were just buggy. Netscape 3.x and 4.x work just fine with
Keep-Alivefrom all servers that support it, including fhttpd.
Other browsers either support
Keep-Alive the way,
compatible with Netscape 3.x, or never send this option, thus
leaving old versions of Mosaic and Netscape the only programs,
Keep-Alive requests and having problems with
understanding the response, so I suppose, I have got the idea of
Keep-Alive should do right, and all software
have any problems with my implementation, if it handles other
servers' one well. HTTP 1.1 (currently not implemented completely
in fhttpd) allows use of
Keep-Alive although doesn't
contain any definition of it, so I assume that since my
implementation is compatible with others and is similar to
HTTP/1.1 persistent connections (with exception that it doesn't
allow requests to be sent while response wasn't
returned to previous ones) it's implemented correctly. When HTTP/1.1 will be implemented, fhttpd
will support asynchronous requests, too.
So, I recommend to enable "
option by using
HonorKeepAlive line in
AF_UNIXsockets fd passing crash problem
AF_UNIX sockets are used by fhttpd to pass data and file
descriptors from the main process to locally running modules that require
direct handling of connection to clients (including the default file I/O and CGI module). Modules, connected through pipes
or TCP/IP (
AF_INET) sockets do not use this mechanism and instead
pass the data through the main server. When file descriptors passing is used,
under high load large number of file descriptors is passed from the main
process to modules, although since it's a lightweight operation, by itself
it does not cause any problems. However some systems (it was first seen on
FreeBSD 2.2.2 and then found or suspected to exist in other systems) have
a bug that causes kernel panic in this situation. I have received from
David Greenman <email@example.com> a workaround
for FreeBSD that probably will work on anything 4.4BSD-derived that has this
problem: to use
NMBCLUSTERS=n in the kernel config, where
n is about 2000-4000. This does not fix the original problem,
but will allow server to work under any imaginable load. Linux 2.x,
SunOS 4.1.3, AIX 3.2.5 and AIX 4.2 didn't show this problem in my tests.
AIX 4.1 is suspected to have this problem.
wildmat.cby Rich $alz <firstname.lastname@example.org> and Lars Mathiesen <email@example.com>, with modifications by Alex Belits.