> Hi William, > > you can just register a generic callback for all HTTP requests and > then provide the switching logic in your Python module. The HTTP > layer is not really meant to provide a fully configurable system akin > to Apache. > > Let me know if that works for you. >
Thanks for your answer. Yes, in my current code all callbacks (thus python one) first check the virtualhost. And yes it works. My problem with it are: - callbacks become to be unclear, and the "plugable" aspect of wsgi is lost. Indeed, every callbacks needs to be updated when they move from one virtualhost to an another one. - performance decrease. Indeed, I'm triggering several python callbacks for nothing before finding the one associated to the correct virtualhost. I would prefer to detect it as soon as possible (thus in libevent). I hope you understand my point of view. On the other hand, I understand that my request could not be shared with other libevent users. In that case does libevent provide api that would allow such usage of http ? Thanks to "coach" me a little bit to find an "elegant" and performant way to do it. William > Niels. > > On Nov 21, 2007 11:39 PM, <[EMAIL PROTECTED]> wrote: >> >> For my python binding to evhttp (temporarily called fapws2 >> http://www.opensource4you.com/cgi-bin/gitweb.cgi?p=fapws2;a=summary), I >> would like to implement the concept of virtual host. >> >> >> Is there anyone having expertise with that within libevent ? >> >> I'm thinking to add it within the http structure. Indeed, an uri is >> always >> coupled with a virtual host. >> Then the evhttp_dispatch_callback need to check the uri AND the >> virtualhost against the HTTP_X_FORWARDED_FOR environment variable (in >> case >> of proxy) or the req->remote_host. >> To be backward compatible, an empty virtualhost means that the uri is >> always valid. >> >> Unfortunately this is quite invasive within the libevent code. If I'm >> not >> wrong the following calls must be adapted: >> evhttp_free >> evhttp_set_cb >> evhttp_del_cb >> evhttp_set_gencb >> >> >> Does the core developers will accept to port it in the trunk of libevent >> ? >> >> Is there a better way to do it ? >> >> Thanks >> >> William >> >> _______________________________________________ >> Libevent-users mailing list >> Libevent-users@monkey.org >> http://monkeymail.org/mailman/listinfo/libevent-users >> >> > > _______________________________________________ Libevent-users mailing list Libevent-users@monkey.org http://monkeymail.org/mailman/listinfo/libevent-users
