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).