> On Thu, Nov 22, 2007 at 08:39:47AM +0100, [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.
>
> You mean evhttp_request, right? There are a bunch of http-related
structures in libevent.
>
No. not really.
If you look into the function called "evhttp_set_cb", we have a structure
called http_cb:
"struct evhttp_cb *http_cb;"
The structure is used to store the uri and the associated callback "
http_cb->what = strdup(uri);
http_cb->cb = cb;
http_cb->cbarg = cbarg;
"
Since the uri is linked to a host, my proposition would be to add the
host in that structure.
>> 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.
>
> What logic did you have in mind for X-Forwarded-For? Do you mean the
header, or the environment variable? My understanding is that the
environment variable is mainly used by CGI stuff, and I don't want to
make libevent CGI-specific by default.
>
This is not linked to environment variable, but http headers.
Indeed, within the http header you can find the uri that the browser
request. Their you find the host too: "remote_host".
But, if there is proxy between the browser and the server, If I'm not
wrong we should take the header called X-Forwarded-For (sorry my previous
mail was not correct).
That means that the function called "evhttp_dispatch_callback" must be
adapted to search the valid uri AND, if there is one, the valid
virtualhost.
>> To be backward compatible, an empty virtualhost means that the uri is
always valid.
>
> Sounds reasonable.
>
>> 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
>
> Changing code is no problem. Changing APIs is not so good, though, if
it makes old code stop working. I think the only function whose
interface would need to change would be evhttp_set_cb. Instead, it
would probably be best to add a new fuction.
>
> There's already some discussion of improving the callback-matching
interface in the sourceforge feature request tracker at
> [ 1826562 ] Add wildcard calbacks to http.c
>
> http://sourceforge.net/tracker/index.php?func=detail&aid=1826562&group_id=50884&atid=461325
>
> It would be neat to come up with an interface that satisfied both the
need of adding wildcards and adding vhost support.
>
;-). Yes this is coming from me too.
>
>> Does the core developers will accept to port it in the trunk of
>> libevent ?
>
> Sounds reasonable, if the code is clean. It would be even better if it
came with regression tests. :)
>
> peace,
> --
> Nick
William
_______________________________________________
Libevent-users mailing list
Libevent-users@monkey.org
http://monkeymail.org/mailman/listinfo/libevent-users
