[erlang-questions] Erlang http servers

[Fred Hebert]

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
    use this.
 2. *Security*. How do you keep someone from calling
    http://some.host/erlcall?mod=init&func=stop or
    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
    Javascript asks for info in JSON, then the same URI may forward
    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
    look like.

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.

Regards,
Fred.

On 12-10-01 4:01 AM, Joe Armstrong wrote:
> On Sun, Sep 30, 2012 at 11:29 PM, Serge Aleynikov <serge@REDACTED> wrote:
>
>
> It would also be highly desirable to standardize the relationship
> between a http uri and
> and erlang function call.  For example
>
>
>       http://some.host/erlcall?mod=foo&func=bar&arg1=111
>
> means call foo:bar(...) on the server and return the value as html (or
> something)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20121001/567006ef/attachment.htm>