[erlang-questions] Erlang http servers
Mon Oct 1 10:01:31 CEST 2012
On Sun, Sep 30, 2012 at 11:29 PM, Serge Aleynikov <> wrote:
> Haven't had a need for an HTTP server in Erlang for a while since I last
> used inets-based http server five years back, and now examining what
> exists in public domain.
> The results are quite surprising - everyone who seems comfortable coding
> in Erlang, feels compelled to implement an HTTP server. Previously we
> had only one contender to inets - yaws. Now the landscape is quite a
> mouthful - inets, yaws, cowboy, musultin, mochiweb, etc. As Steve
> Vinoski rightfully points out (*) this doesn't help to pull the blanket
> in all directions. From personal experience with inets, I recall that
> once I figured out how to use it, it happened to be a very helpful and
> powerful HTTP library for building an application server. So why don't
> all the authors of those wonderful alternative libraries just patch the
> inets to extend it with something they feel missing so that we only have
> one good and documented library to use as the common denominator?
I can think of several reasons why this does not happen:
a) You have to distinguish between functional and non-functional behavior.
All web-servers implement the same protocol (HTTP) - so they are
equivalent - but their non-functional behavior is very different
- one server
might be optimized for large numbers of short-lived sessions,
another for a few long-lived
sessions. One might cache content, another not. So even though they are
all http servers they have very different behaviour - this is good.
b) Servers have two interfaces - the protocol interface (HTTP) and
the interface towards
Erlang (the API if you like). As far as I can see most severs
have different Erlang APIs.
This is bad.
c) Inets is shipped with OTP ie built and maintained by the OTP group.
This is not really
"core business" as far as the OTP group is concerned, better for
everybody if non-core
applications get taken over by third-part vendors.
d) As things mature - people want more in the way of "service" - ie
good documentation and the ability
to buy support - the problem with software is not so much that of
writing it - which can be
easy or difficult depending upon the problem but with the "burden of support"
Personally I'm quite happy with there being several different http
servers, It gives me several to choose
from. No server in the world will do exactly what I want so they all
need tweaking in one way or another.
What I don't like is that all have different APIs - this make swapping
between severs a pain.
Some degree of standardization of the APIs necessary to setup and
manage the servers would be
It would also be highly desirable to standardize the relationship
between a http uri and
and erlang function call. For example
means call foo:bar(...) on the server and return the value as html (or
Currently the http-server side of things seems ok - what I'm missing is the
entire user management cycle - password management, authentication, cookies,
forgotten passwords etc. - this needs far more than an http server, it needs
a persistent database, security and so on ...
> (*) http://steve.vinoski.net/blog/2011/05/09/erlang-web-server-benchmarking
> erlang-questions mailing list
More information about the erlang-questions