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
>>> neither APR_HAS_SO_ACCEPTFILTER nor APR_TCP_DEFER_ACCEPT is set.
>> 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) {
num_listeners++;
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.
Regards
Rüdiger
