You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "William A. Rowe Jr." <wr...@rowe-clan.net> on 2011/10/10 21:06:12 UTC
Re: Windows 2.3.13 :: Win32DisableAcceptEx
On 9/29/2011 7:30 PM, Jeff Trawick wrote:
>
> This is well past the point where one needs to know the Listen
> configuration, exact problem symptom, etc. ;) Either way it seems
> that there were some oddities around the presence/absence of
> IPV6_V6ONLY. In its absence APR should have been returning
> APR_ENOTIMPL instead of not-set for a query, then httpd would have
> grown different logic.
Right. I discovered that loading an IPv6 APR against a IPv4 compiled
libhttpd.dll on Win32 is a very lethal combination. The buffer sizes,
for one, are all wrong.
Chalk these complaints about APR 1.x up to user-error.
Re: Windows 2.3.13 :: Win32DisableAcceptEx
Posted by Jeff Trawick <tr...@gmail.com>.
On Mon, Oct 10, 2011 at 3:06 PM, William A. Rowe Jr.
<wr...@rowe-clan.net> wrote:
> On 9/29/2011 7:30 PM, Jeff Trawick wrote:
>>
>> This is well past the point where one needs to know the Listen
>> configuration, exact problem symptom, etc. ;) Either way it seems
>> that there were some oddities around the presence/absence of
>> IPV6_V6ONLY. In its absence APR should have been returning
>> APR_ENOTIMPL instead of not-set for a query, then httpd would have
>> grown different logic.
>
> Right. I discovered that loading an IPv6 APR against a IPv4 compiled
> libhttpd.dll on Win32 is a very lethal combination. The buffer sizes,
> for one, are all wrong.
>
> Chalk these complaints about APR 1.x up to user-error.
In APR 1.x the problem of the varying apr_sockaddr_t size was
addressed for modern Unix, but I think it breaks on Windows due to
lack of awareness of the presence of sockaddr_storage (which in turn
may be due to the need to support a wide range of SDKs).