> While I support these types of changes, I often wonder if the better > solution to these problems is to gut the httpd API and create a more robust > and abstracted replacement. *prepares for flogging* > > Libevent's http API was created for JIT services, not a apache/nginx/iis > replacement. But the reality is, developers have shown that the system should > be just as robust as the real ones. > > A project to keep an eye on (one I have started using after dealing with > the many faults of the libevent http engine) is > https://github.com/ry/http-parser
I have been debating building something based on http-parser (which I use extensively in other projects)... and am in fact hoping to replace lighttpd one day with a custom/small libevent-based webserver. Your reply makes me worry that I should be starting over from scratch instead of fixing up libevent/http... In any case, the current interface seems fairly reasonable to me, and I'm not too opposed to adding a few more callbacks to it. But maybe I just haven't seen the light of a very simple clean interface that also accounts properly for things like backpressure. However, if we are worried about the actual HTTP parsing of libevent/http.c, I could likely rip it out and replace it with https://github.com/ry/http-parser, but again, I'd love to know if such a change would actually be accepted or not beforehand... Cliff *********************************************************************** To unsubscribe, send an e-mail to majord...@freehaven.net with unsubscribe libevent-users in the body.
