[erlang-questions] Erlang http servers
Mon Oct 1 14:57:25 CEST 2012
I did not have much to say about the rest (except that different
interfaces may emerge based on the use cases that the server optimizes
for), and I mostly nodded in agreement to most of your points, but the
last one I believe is a very bad idea.
This is a problem in terms of:
1. *Maintenance*. You don't want to usually give such an obvious window
into your server as it somewhat crystallizes your internal
application as a public API, what the URI is usually used for. We
should strive to have URIs never change (see W3C - Cool URIs don't
change <http://www.w3.org/Provider/Style/URI.html> ). Unless you're
ready not to change the function calls under the hood, I would not
2. *Security*. How do you keep someone from calling
http://some.host/erlcall?mod=os&func=cmd&arg1="rm -rf /" ? If you go
look at tryerlang.org's repository, you'll see how restrictive
Roberto Aloi had to make it to avoid people doing tricky things like
passing binaries of funs calling things they shouldn't indirectly
just to crash the system. This is absolutely non-trivial as soon as
you move out from using a very restrictive white list of valid
functions -- at which point you may as well hide them behind URIs.
3. *Clarity*. What are the argument types? Should we treat the '111' as
a string? a binary? an integer? An IO List? Should the server force
all arguments to be of a given type that needs to be converted later
so you need to have some kind of intermediary function doing
conversion for you? It's not different from what we get right now,
but there's a difference in expectations from the developer. A minor
issue, I guess.
4. *RPC and HTTP*. Whether RPC is still a good way to do things is up
to debate (look for Steve Vinoski's essays and posts on the topic).
Shouldn't the erlcall URI be extended to also handle timeouts? Or
are these server options unrelated to the function call? More than
that is the idea of how you write things that may depend on
content-type (such as RESTful web services). For example, a browser
that sends a request to a page in HTML may be served HTML. If
JSON. There is an out-of-URL mechanism to deal with different
requests and ideas.
5. *HTTP Spec problems*. GET and HEAD requests should be idempotent.
PUT, POST, and DELETE can be used in ways that change information on
the server. If I use POST to
http://some.host/erlcall?mod=foo&func=bar&arg1=111 and it updates
data, what should it do when I use GET or HEAD on it? Do we prefer
to use the POST body for the requests that are done under the POST
method? What if I include both POST arguments and querystring
arguments and they are different?
More than that, HTTP doesn't specify what happens when you have more
than one querystring argument being the same (from memory). It
should thus be possible to have arg1 four times in the URL, with
arg3 being there only once, and arg2 being entirely missing. Same
with the module or function name. How do we make this interface
behave at that point? Things are way more complex than what they
There are likely more issues with this approach. Ideally, it should be
impossible for the user of your server to know what you used to
implement it -- this is what should give you the most freedom in terms
of implementation when lots of people start using it. At this point I'm
thinking we should start using different protocols from HTTP if we're
not really willing to respect it, but that's for another discussion.
And yes, more user management would definitely be nice. I've written a
tiny library to handle passwords themselves, but it's not close enough
to be something a framework would use without surrounding support -- it
just handles the core of password hashing and verification. It's
currently hosted at https://github.com/ferd/erlpass . Then each platform
such as Zotonic likely reimplemented their own, although I don't know
how moveable they are outside of the project.
On 12-10-01 4:01 AM, Joe Armstrong wrote:
> On Sun, Sep 30, 2012 at 11:29 PM, Serge Aleynikov <> wrote:
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions