appspace pollution :)

[Chris Pressey]

For the curious... my webserver and some of my other Erlang projects can
be found at:

  http://kallisti.mine.nu/projects/

(This machine is not a proper internet server in terms of the resources it
can dedicate to serving clients, so don't be surprised if/when the page is
slow or fails to resolve.)

The webserver application, OpenFlax, is still very much an experimental
project, and will probably remain so (intentionally), but the core bits
seem quite stable.  It's been tested with a modest pool of clients.

Whether OpenFlax is useful enough and unique enough to acquire its own
niche remains to be seen.  From my point of view, yaws' agenda is to be
high-performance; inets' agenda is to be conformant and Apache-compatible;
and pico's agenda is to be minimalistic.  OpenFlax has it's own agenda,
that is, to be secure and reliable - secure in the sense of not being a
liability to the machine it's running on - while at the same time
providing a base for higher functionality, and experimentation.

Some examples of the spiffier things that OpenFlax can do include
automatically creating gzipped tarballs from specified directories, and
automatically applying previously-uploaded diffs to files before they are
downloaded.  Both of these functionalities are implemented entirely in
Erlang so that no external programs are called.  The practical result
is that OpenFlax can serve it's own sources, and any bug fixes for it can
theoretically be obtained immediately therefrom.  This is a long-view
aspect of the kind of security OpenFlax aims to provide.

The OpenFlax "API", such as it is, is skeletal on the theory that
abstraction is overrated.  IIRC this is similar to pico's approach.

Specifically, each OpenFlax module conforms to a behaviour; it provides a
callback for generating any pages it is called on to serve.  The callback
is passed a regular Erlang TCP socket, with the process dictionary full of
variables such as what was in the HTTP request headers.  There are a few
helper functions for sending an HTTP response header, a raw file, etc, to
a socket, but there is no official interface - gen_tcp:send/2 can even be
used.

Of course, this is subject to change without warning.  This project has
been an experiment for several months now, and will no doubt continue to
be an experiment.  On the other hand, it works.  Some of the observations
I've made and conclusions I've drawn over the past few months are:

- you can't uniquely identify a client by IP address if that IP address is
the address of their proxy server.  I've been trying to avoid cookies at
all costs, but for a public user system, they might be a necessary evil. 
On the other hand, associating user logins to an IP address should be OK
for an intranet server.
- if there is an inherent flaw in all common web servers it is that they
serve objects from the filesystem - the same place the important stuff
(OS, programs, data, etc) is.  The use of chroot should be investigated
for having OpenFlax serve files.  The practice of serving objects from a
database (like the wikie) should be investigated.  The webserver code
would then never access the filesystem directly, but instead rely on a
database package (such as mnesia).  The drawback would be the extra effort
required to import the objects you wish to serve, into the database.
- security can always be improved by deleting modules.
- {active, true} sockets should probably never be used on a public
network.  As nicely as they map to the Erlang programming paradigm, they
present too great a risk of flooding the Erlang runtime with messages. 
The only times my webserver has actually 'hard' crashed (as opposed to
processes 'soft' crashing) have been because of message overflow.
- the problem of proliferation of webserver software in Erlang is
probably not as important a problem as the proliferation of API's for
these webservers.

Also it's clear that a webserver is only a tiny fraction of what OpenFlax
is trying to 'be' - my vision (hazy as it is) is something along the lines
of a mini-sourceforge that operates like the FreeBSD ports tree except
running peer-to-peer, that *happens* to be accessible via HTTP.  It would
be interesting to write a client and associated server module which
negotiate a different connection using the Upgrade header.

Flames, trolls (etc) welcome  :)

-Chris