httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ruediger Pluem <>
Subject Re: svn commit: r730835 - /httpd/httpd/trunk/server/core.c
Date Sat, 03 Jan 2009 11:08:20 GMT

On 01/02/2009 10:50 PM, Ruediger Pluem wrote:
> On 01/02/2009 10:27 PM, William A. Rowe, Jr. wrote:
>> Ruediger Pluem wrote:
>>> Otherwise the table will not be empty anymore in the case that
>> Uhm ... huh?  What gave you the idea that APR_TCP_DEFER_ACCEPT
>> is a volatile?  It's present in apr 1.3 (our baseline) and will
>> be sticking around into the foreseeable future.
>> It is neither a HAS nor HAVE feature flag.  In fact it's the reason
>> I started refactoring this code, it was complete twaddle.

As I dig deeper into this I think that the whole AcceptFilter config
is busted:

ap_apply_accept_filter allows you set up individual accept filters
for each listening socket. This seems right to me.
OTOH AcceptFilter only allows you to do a global mapping of protocols
to accept filters.
Thus if I want to have two different listeners with the same protocol
but different accept filters I cannot do this configuration wise.
This doesn't seem correct to me.
Furthermore if all this stuff is global the following loop from
listen.c::ap_setup_listeners doesn't really make sense to me:

    for (lr = ap_listeners; lr; lr = lr->next) {
        found = 0;
        for (ls = s; ls && !found; ls = ls->next) {
            for (addr = ls->addrs; addr && !found; addr = addr->next) {
                if (apr_sockaddr_equal(lr->bind_addr, addr->host_addr) &&
                    lr->bind_addr->port == addr->host_port) {
                    found = 1;
                    ap_apply_accept_filter(s->process->pool, lr, ls);

        if (!found) {
            ap_apply_accept_filter(s->process->pool, lr, s);

Why do we need to iterate over the server recs then (2nd loop)?
The config information about protocol filter mappings should be
only in the main server rec.



View raw message