| Thaddeus was asking for advice on eventually running Arc behind nginx. I believe doing so is an interesting choice. In a way, I see a lightweight reverse-proxy as part of my (web server) OS: it does a number
of low-level common tasks so that each app server doesn't have to (gzipping,
logging, etc.). And nginx is a very good
reverse-proxy. I don't like Apache very much, for it's half an heavy web
framework, half just a proxy. It does too much, it eats too much RAM for what
I expect it to do, etc. Things like mod_perl are a plague. Nginx is better designed IMO. But aw pointed out that because of srv.arc poor respect of RFC 2616, running
srv.arc behind a proxy is quite hard. This is bad, because (1) I have to serve several websites/domains on the same computer but I have only one 80 port, (2) nginx does some things better and faster than Arc will ever do, and an app server should not have to reinvent the uninteresting parts of the wheel (logging, slow clients handling, static files serving, etc.), (3) don't kill the "clients and servers don't (need to) know who is really at the other end of the wire" REST principe. Because of this, and because I think srv.arc and app.arc suffer from too many other
problems anyway (bad layering, makes too many choices for me, fucks RESTful paths, code too
bloated and too specific to news.arc, etc.), I decided to write a better web dev combo
for my own uses. I use it to power dabuttonfactory.com and a couple of internal apps, and so
far it has prouved robust and useful to me. http.arc is about parsing HTTP messages, and building
generic "low-level" http servers and clients. It is available here: http://pastebin.com/jiXSX8yV
(124 LOC). I consider the need to patch it a bug, for it should just be a
choice-agnostic, blind implementation of HTTP. It is not, however, a strict
implementation of RFC 2616. It can run behind a proxy or standalone. web.arc is a web (site|app) toolkit to use on top of http.arc.
It is available here: http://pastebin.com/9GmhRWqc (96 LOC).
It used to be features-full (session & user logins & more) but the version
linked here is more lightweight. I removed a lot of stuff, because
I've not yet found a good enough, generic enough, solution that suits me. So I chose to extract its core into a toolbox instead of making it a limit(ed|ing) framework.
Adding user sessions is quite easy by reusing the stuff defined or app.arc
or whatever, if you need it. Using this combo may require a bit more effort than using srv/app.arc (see below), but you may not have to remove stuff that is just useless to you (like ken removing /whoami and co), nor to patch it to get over the limited 'defop feature. You may have to extend it, but not throw away
parts of it. $ arc http.arc web.arc -
arc> (defpath / (req) (prn "Hello, World"))
#<procedure>
arc> (defpath /: (req id) (prn "Hello " req!ip ", you requesting post # " id))
(("/:" ((":") #<procedure>)) ("/x/:" (("x" ":") #<procedure>)))
arc> (defpath /user/: (req usr)
(htmlpage ((tag title (pr "User infos"))
(icss "body { text-align: center; }"))
(prn "User infos for user " usr))))
(("/user/:" (("user" ":") #<procedure>)) ("/:" ((":") #<procedure>)) ("/x/:" (("x" ":") #<procedure>)))
arc> (= httpd-handler dispatch)
#<procedure: dispatch>
arc> (start-httpd)
httpd: serving on port 8080
#<thread: start-httpd>
$ curl http://localhost:8080
Hello, World
$ curl http://localhost:8080/42
Hello 127.0.0.1, you requesting post # 42
$ curl http://localhost:8080/user/pal
<!doctype html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"><title>User infos</title><style>body { text-align: center; }</style></head>User infos for user pal
Inspiration: CGI.pm, Hunchentoot, web.py, in short the "anti-framework frameworks". Real frameworks are attracting at first ("OMG so easy"), but when you need more power/control, you realized you are screwed. Frameworks are for sissies. And srv/app.arc is a framework. |
