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/09/29 20:58:35 UTC
Re: Windows 2.3.13 :: Win32DisableAcceptEx
On 7/7/2011 3:39 AM, Gregg L. Smith wrote:
> I have an error log full of these;
>
> [Thu Jul 07 00:15:58.010625 2011] [mpm_winnt:warn] [pid 2840:tid 1572] (OS 64)The
> specified network name is no longer available. : winnt_accept: Asynchronous AcceptEx failed.
This might be http://svn.apache.org/viewvc?view=revision&revision=1091826
confusing the issue if you build with Win32 IPv6 toggled on, depending on
your operating system and the SDK you used to build... it was introduced
in 1.4.3, you might want to try reverting this patch after first working
through the ticket below...
> Thanks to Steffen's bringing this up, I now know how I should be fixing this.
>
> The problem is, if I set
>
> AcceptFilter http none
>
> I lose all my vhosts and everything reverts to the main host. If I use
Implies that the host headers are not queried for ***normal*** sockets,
and reviewing http://svn.apache.org/viewvc?view=revision&revision=1088569
it looks like this was "optimized" (read:bugged) away.
Could you please revert this APR 1.4.3 change and report back what you
observe? Another option is to simply try APR 1.4.2 binaries.
It seems AcceptEx() crap still pollutes APR. We can't optimize for the
AcceptEx() case because that is handled in httpd. The flag simply prevents
us from querying twice (and this becomes stranger because getpeername()
simply fails for an AcceptEx'ed socket anyways). The unknown flag can only
be tripped if we can affirmatively set the correct value.
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).
Re: Windows 2.3.13 :: Win32DisableAcceptEx
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
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 "William A. Rowe Jr." <wr...@rowe-clan.net>.
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.
Agreed, my original assessment was wrong. httpd 2.2 was in a working
state with IPv6 on Win2k3/XP but its clearly broken on Win2k8/7 right
now. Again, I'm digging through this, but agree with the original
assessment that some legacy 9x code needs to be un-removed to get the
AcceptFilter 'none' working... and something relative to the new code
causes IPv6 to still misbehave on W2k8/7. I'll quit speculating till
this is working on both W2K3 and W2K8 for 2.2 (which should be very
close to correct already) and then apply that to trunk along with the
extra effort to restore the broken accept() code path.
Re: Windows 2.3.13 :: Win32DisableAcceptEx
Posted by Jeff Trawick <tr...@gmail.com>.
On Thu, Sep 29, 2011 at 8:02 PM, Jeff Trawick <tr...@gmail.com> wrote:
> On Thu, Sep 29, 2011 at 5:00 PM, William A. Rowe Jr.
> <wr...@rowe-clan.net> wrote:
>> On 9/29/2011 2:22 PM, Jeff Trawick wrote:
>>> On Thu, Sep 29, 2011 at 2:58 PM, William A. Rowe Jr.
>>> <wr...@rowe-clan.net> wrote:
>>>> On 7/7/2011 3:39 AM, Gregg L. Smith wrote:
>>>>> I have an error log full of these;
>>>>>
>>>>> [Thu Jul 07 00:15:58.010625 2011] [mpm_winnt:warn] [pid 2840:tid 1572] (OS 64)The
>>>>> specified network name is no longer available. : winnt_accept: Asynchronous AcceptEx failed.
>>>>
>>>> This might be http://svn.apache.org/viewvc?view=revision&revision=1091826
>>>> confusing the issue if you build with Win32 IPv6 toggled on, depending on
>>>> your operating system and the SDK you used to build... it was introduced
>>>> in 1.4.3, you might want to try reverting this patch after first working
>>>> through the ticket below...
>>>
>>> That doesn't look hopeful, as that patch only modifies behavior for
>>> Windows < Vista; Greg reports the same problem with XP *and Vista*.
>>> (OS level detection would have to be broken?)
>>
>> It certainly contributes, maybe something similar is missing from
>> httpd-2.2/2.3-beta sources. The old code certainly appeared to work.
>>
>>>>> The problem is, if I set
>>>>>
>>>>> AcceptFilter http none
>>>>>
>>>>> I lose all my vhosts and everything reverts to the main host. If I use
>>>>
>>>> Implies that the host headers are not queried for ***normal*** sockets,
>>>> and reviewing http://svn.apache.org/viewvc?view=revision&revision=1088569
>>>> it looks like this was "optimized" (read:bugged) away.
>>>
>>> Supposedly that commit means "hey, we just got the peername from
>>> accept(); don't call getpeername()".
>>>
>>> I don't follow the "host headers are not queried" connection to
>>> anything in APR... (I guess we're talking about name-based vhosts.)
>>
>> Sorry, bad wording. You can't getpeername() on an AcceptEx() socket.
>> You must getpeername() on non-AcceptEx() sockets.
>
> This patch affects only the accept() (apr_socket_accept()) path. The
> WinNT MPM in trunk doesn't call apr_socket_accept().
>
> APR_DECLARE(apr_status_t) apr_socket_accept(apr_socket_t **new,
> apr_socket_t *sock, apr_pool_t *p)
> {
> ...
> s = accept(sock->socketdes, (struct sockaddr *)&sa, &salen);
> (11 lines omitted)
> ->>> (*new)->remote_addr_unknown = 0; <<<-
>
> Obviously this doesn't affect httpd trunk. For 2.2, is the
> configuration with Win32DisableAcceptEx broken? (I don't see an
> indication of that in this thread.
>
>>
>> These patch, I believe, broke both 2.3-beta as well as 2.2 when compiled
>> using IPV6 and older VC6/SDK's... my team was able to reproduce problems
>> on Vista/W2K8 that don't exist on W2K3 once your changes are introduced
>> to 2.2 compiled with APR_HAS_IPV6.
>
> Are any of these problems with 2.2 and Win32DisableAcceptEx enabled?
>
> Let's see...
>
> Windows >= Vista, old SDK:
>
> Before the patch: APR_IPV6_V6ONLY returns APR_ENOTIMPL
>
> After the patch: It actually calls setsockopt(); I'm suspicious that
> apr_socket_opt_get() never calls getsockopt() but I haven't checked
> that thoroughly
>
> From an httpd perspective:
>
> AP_ENABLE_V4_MAPPED is never defined for Windows.
>
> make_sock() thus calls apr_socket_opt_set(s, APR_IPV6_V6ONLY, 1).
> Before the patch (old SDK) this was APR_ENOTIMPL, after the patch it
> actually calls setsockopt()
>
> open_listeners() calls apr_socket_opt_get(s, APR_IPV6_V6ONLY, ?)
> Before the patch (old SDK) this always returned 0; after the patch it
> should return 1 (since the apr_socket_opt_set(APR_IPV6_V6ONLY = 1)
> worked). IOW, before the patch an IPv6 socket was removed from the
> list because it was believed to overlap, now it is not removed from
> the list.
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.
>
>
>
>>
>> Also, the apparent splitting of IPV6_ONLY sockets from IPV4/6 sockets
>> causes IPV4 sockets to barf on recycling. Still trying to pin this down.
>> Working on mitigating the damage to 2.2 and 2.3-beta now.
>>
>>
>
>
>
> --
> Born in Roswell... married an alien...
>
--
Born in Roswell... married an alien...
Re: Windows 2.3.13 :: Win32DisableAcceptEx
Posted by Jeff Trawick <tr...@gmail.com>.
On Thu, Sep 29, 2011 at 5:00 PM, William A. Rowe Jr.
<wr...@rowe-clan.net> wrote:
> On 9/29/2011 2:22 PM, Jeff Trawick wrote:
>> On Thu, Sep 29, 2011 at 2:58 PM, William A. Rowe Jr.
>> <wr...@rowe-clan.net> wrote:
>>> On 7/7/2011 3:39 AM, Gregg L. Smith wrote:
>>>> I have an error log full of these;
>>>>
>>>> [Thu Jul 07 00:15:58.010625 2011] [mpm_winnt:warn] [pid 2840:tid 1572] (OS 64)The
>>>> specified network name is no longer available. : winnt_accept: Asynchronous AcceptEx failed.
>>>
>>> This might be http://svn.apache.org/viewvc?view=revision&revision=1091826
>>> confusing the issue if you build with Win32 IPv6 toggled on, depending on
>>> your operating system and the SDK you used to build... it was introduced
>>> in 1.4.3, you might want to try reverting this patch after first working
>>> through the ticket below...
>>
>> That doesn't look hopeful, as that patch only modifies behavior for
>> Windows < Vista; Greg reports the same problem with XP *and Vista*.
>> (OS level detection would have to be broken?)
>
> It certainly contributes, maybe something similar is missing from
> httpd-2.2/2.3-beta sources. The old code certainly appeared to work.
>
>>>> The problem is, if I set
>>>>
>>>> AcceptFilter http none
>>>>
>>>> I lose all my vhosts and everything reverts to the main host. If I use
>>>
>>> Implies that the host headers are not queried for ***normal*** sockets,
>>> and reviewing http://svn.apache.org/viewvc?view=revision&revision=1088569
>>> it looks like this was "optimized" (read:bugged) away.
>>
>> Supposedly that commit means "hey, we just got the peername from
>> accept(); don't call getpeername()".
>>
>> I don't follow the "host headers are not queried" connection to
>> anything in APR... (I guess we're talking about name-based vhosts.)
>
> Sorry, bad wording. You can't getpeername() on an AcceptEx() socket.
> You must getpeername() on non-AcceptEx() sockets.
This patch affects only the accept() (apr_socket_accept()) path. The
WinNT MPM in trunk doesn't call apr_socket_accept().
APR_DECLARE(apr_status_t) apr_socket_accept(apr_socket_t **new,
apr_socket_t *sock, apr_pool_t *p)
{
...
s = accept(sock->socketdes, (struct sockaddr *)&sa, &salen);
(11 lines omitted)
->>> (*new)->remote_addr_unknown = 0; <<<-
Obviously this doesn't affect httpd trunk. For 2.2, is the
configuration with Win32DisableAcceptEx broken? (I don't see an
indication of that in this thread.
>
> These patch, I believe, broke both 2.3-beta as well as 2.2 when compiled
> using IPV6 and older VC6/SDK's... my team was able to reproduce problems
> on Vista/W2K8 that don't exist on W2K3 once your changes are introduced
> to 2.2 compiled with APR_HAS_IPV6.
Are any of these problems with 2.2 and Win32DisableAcceptEx enabled?
Let's see...
Windows >= Vista, old SDK:
Before the patch: APR_IPV6_V6ONLY returns APR_ENOTIMPL
After the patch: It actually calls setsockopt(); I'm suspicious that
apr_socket_opt_get() never calls getsockopt() but I haven't checked
that thoroughly
>From an httpd perspective:
AP_ENABLE_V4_MAPPED is never defined for Windows.
make_sock() thus calls apr_socket_opt_set(s, APR_IPV6_V6ONLY, 1).
Before the patch (old SDK) this was APR_ENOTIMPL, after the patch it
actually calls setsockopt()
open_listeners() calls apr_socket_opt_get(s, APR_IPV6_V6ONLY, ?)
Before the patch (old SDK) this always returned 0; after the patch it
should return 1 (since the apr_socket_opt_set(APR_IPV6_V6ONLY = 1)
worked). IOW, before the patch an IPv6 socket was removed from the
list because it was believed to overlap, now it is not removed from
the list.
>
> Also, the apparent splitting of IPV6_ONLY sockets from IPV4/6 sockets
> causes IPV4 sockets to barf on recycling. Still trying to pin this down.
> Working on mitigating the damage to 2.2 and 2.3-beta now.
>
>
--
Born in Roswell... married an alien...
Re: Windows 2.3.13 :: Win32DisableAcceptEx
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 9/29/2011 2:22 PM, Jeff Trawick wrote:
> On Thu, Sep 29, 2011 at 2:58 PM, William A. Rowe Jr.
> <wr...@rowe-clan.net> wrote:
>> On 7/7/2011 3:39 AM, Gregg L. Smith wrote:
>>> I have an error log full of these;
>>>
>>> [Thu Jul 07 00:15:58.010625 2011] [mpm_winnt:warn] [pid 2840:tid 1572] (OS 64)The
>>> specified network name is no longer available. : winnt_accept: Asynchronous AcceptEx failed.
>>
>> This might be http://svn.apache.org/viewvc?view=revision&revision=1091826
>> confusing the issue if you build with Win32 IPv6 toggled on, depending on
>> your operating system and the SDK you used to build... it was introduced
>> in 1.4.3, you might want to try reverting this patch after first working
>> through the ticket below...
>
> That doesn't look hopeful, as that patch only modifies behavior for
> Windows < Vista; Greg reports the same problem with XP *and Vista*.
> (OS level detection would have to be broken?)
It certainly contributes, maybe something similar is missing from
httpd-2.2/2.3-beta sources. The old code certainly appeared to work.
>>> The problem is, if I set
>>>
>>> AcceptFilter http none
>>>
>>> I lose all my vhosts and everything reverts to the main host. If I use
>>
>> Implies that the host headers are not queried for ***normal*** sockets,
>> and reviewing http://svn.apache.org/viewvc?view=revision&revision=1088569
>> it looks like this was "optimized" (read:bugged) away.
>
> Supposedly that commit means "hey, we just got the peername from
> accept(); don't call getpeername()".
>
> I don't follow the "host headers are not queried" connection to
> anything in APR... (I guess we're talking about name-based vhosts.)
Sorry, bad wording. You can't getpeername() on an AcceptEx() socket.
You must getpeername() on non-AcceptEx() sockets.
These patch, I believe, broke both 2.3-beta as well as 2.2 when compiled
using IPV6 and older VC6/SDK's... my team was able to reproduce problems
on Vista/W2K8 that don't exist on W2K3 once your changes are introduced
to 2.2 compiled with APR_HAS_IPV6.
Also, the apparent splitting of IPV6_ONLY sockets from IPV4/6 sockets
causes IPV4 sockets to barf on recycling. Still trying to pin this down.
Working on mitigating the damage to 2.2 and 2.3-beta now.
Re: Windows 2.3.13 :: Win32DisableAcceptEx
Posted by Jeff Trawick <tr...@gmail.com>.
On Thu, Sep 29, 2011 at 2:58 PM, William A. Rowe Jr.
<wr...@rowe-clan.net> wrote:
> On 7/7/2011 3:39 AM, Gregg L. Smith wrote:
>> I have an error log full of these;
>>
>> [Thu Jul 07 00:15:58.010625 2011] [mpm_winnt:warn] [pid 2840:tid 1572] (OS 64)The
>> specified network name is no longer available. : winnt_accept: Asynchronous AcceptEx failed.
>
> This might be http://svn.apache.org/viewvc?view=revision&revision=1091826
> confusing the issue if you build with Win32 IPv6 toggled on, depending on
> your operating system and the SDK you used to build... it was introduced
> in 1.4.3, you might want to try reverting this patch after first working
> through the ticket below...
That doesn't look hopeful, as that patch only modifies behavior for
Windows < Vista; Greg reports the same problem with XP *and Vista*.
(OS level detection would have to be broken?)
>
>> Thanks to Steffen's bringing this up, I now know how I should be fixing this.
>>
>> The problem is, if I set
>>
>> AcceptFilter http none
>>
>> I lose all my vhosts and everything reverts to the main host. If I use
>
> Implies that the host headers are not queried for ***normal*** sockets,
> and reviewing http://svn.apache.org/viewvc?view=revision&revision=1088569
> it looks like this was "optimized" (read:bugged) away.
Supposedly that commit means "hey, we just got the peername from
accept(); don't call getpeername()".
I don't follow the "host headers are not queried" connection to
anything in APR... (I guess we're talking about name-based vhosts.)
>
> Could you please revert this APR 1.4.3 change and report back what you
> observe? Another option is to simply try APR 1.4.2 binaries.
>
> It seems AcceptEx() crap still pollutes APR. We can't optimize for the
> AcceptEx() case because that is handled in httpd. The flag simply prevents
> us from querying twice (and this becomes stranger because getpeername()
> simply fails for an AcceptEx'ed socket anyways). The unknown flag can only
> be tripped if we can affirmatively set the correct value.
>
>
--
Born in Roswell... married an alien...
Re: Windows 2.3.13 :: Win32DisableAcceptEx
Posted by "Gregg L. Smith" <gl...@gknw.net>.
Bill,
I think it's been realized that the APR/IPv6 has no bearing on this but
I can confirm that
2.3.15-dev at r1177210 with apr 1.4.2 and ipv6 set to 0 does the exact
same thing.
Cheers,
Gregg
On 9/29/2011 11:58 AM, William A. Rowe Jr. wrote:
> On 7/7/2011 3:39 AM, Gregg L. Smith wrote:
>> I have an error log full of these;
>>
>> [Thu Jul 07 00:15:58.010625 2011] [mpm_winnt:warn] [pid 2840:tid 1572] (OS 64)The
>> specified network name is no longer available. : winnt_accept: Asynchronous AcceptEx failed.
> This might be http://svn.apache.org/viewvc?view=revision&revision=1091826
> confusing the issue if you build with Win32 IPv6 toggled on, depending on
> your operating system and the SDK you used to build... it was introduced
> in 1.4.3, you might want to try reverting this patch after first working
> through the ticket below...
>
>> Thanks to Steffen's bringing this up, I now know how I should be fixing this.
>>
>> The problem is, if I set
>>
>> AcceptFilter http none
>>
>> I lose all my vhosts and everything reverts to the main host. If I use
> Implies that the host headers are not queried for ***normal*** sockets,
> and reviewing http://svn.apache.org/viewvc?view=revision&revision=1088569
> it looks like this was "optimized" (read:bugged) away.
>
> Could you please revert this APR 1.4.3 change and report back what you
> observe? Another option is to simply try APR 1.4.2 binaries.
>
> It seems AcceptEx() crap still pollutes APR. We can't optimize for the
> AcceptEx() case because that is handled in httpd. The flag simply prevents
> us from querying twice (and this becomes stranger because getpeername()
> simply fails for an AcceptEx'ed socket anyways). The unknown flag can only
> be tripped if we can affirmatively set the correct value.
>
>
Re: Windows 2.3.13 :: Win32DisableAcceptEx
Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Monday 10 October 2011, William A. Rowe Jr. wrote:
> On 10/10/2011 2:22 PM, Eric Covener wrote:
> > Trying to fully resolve the 2.3 accptex thread -- Should I add a
> > <note> about Win32DisableAcceptEx to mpm_winnt doc? Or even add
> > it back in as a "directive" to point to AcceptFilter?
Add at least a note to docs/manual/upgrading.xml.
> On a similar note; non-server flavors of Windows have crippled the
> entire TransmitFile API (SendFile enabled) allowing only two
> simultaneous file transmissions. I'm thinking of setting SendFile
> to disabled by default on any non-server Windows OS in the
> pre-config phase, and letting the user enable it explicitly if
> desired. I don't see a reason to change the default for windows
> server OS's.
SendFile is disabled by default since 2.3.9. So nothing needs to be
changed there. But if it doesn't work with certain Windows flavors,
there should be a note in the SendFile docs.
Re: Windows 2.3.13 :: Win32DisableAcceptEx
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 10/10/2011 2:22 PM, Eric Covener wrote:
>> Precisely. As we have context->buff allocated for all AcceptFilter
>> schemes, I added the appropriate queries into that buffer in r1181140,
>> and the world seems at peace again for just this short moment.
>
> Trying to fully resolve the 2.3 accptex thread -- Should I add a
> <note> about Win32DisableAcceptEx to mpm_winnt doc? Or even add it
> back in as a "directive" to point to AcceptFilter?
I'm actually giving this further thought... we have three basic modes
right now; acceptex+recycle, acceptex+recycle+data, or accept. Only
the acceptex+recycle+data is new.
In fact, 90% of users observed acceptex problems were -never- with the
acceptex itself. The error occurs in recycling a broken socket handle.
Eliminate socket recycling by default and most problems are going to
go away, whether it is because a network stack component refuses to
properly disconnect a socket and make it ready for recycling, or whether
a previously IPv4 socket turns out to be incapable of handling an IPv6
connection on the next go-around.
So really, we aught to support acceptex and acceptex+data modes without
socket recycling, as well.
My preference would be to treat acceptex as 'none'/default. 'data' means
acceptex+data. 'accept' means accept, rather than acceptex (and it has
no concept of recycling).
Then, add 'recycle', or 'recycle+data', for those who wish to use the
socket recycling feature. I'd advise against it given everything we've
seen over the past 10 years. But if it works as advertised on a user's
particular combination of network stack drivers, then let them keep the
feature if they explicitly enable it. In fact, since Server 2003 (now
that we've killed Server 2000 support)...
if (!DisconnectEx(hSock, NULL, TF_REUSE_SOCKET, 0)
hSock = INVALID_HANDLE;
would let us recycle the non-TransmitFile sockets as well.
On a similar note; non-server flavors of Windows have crippled the entire
TransmitFile API (SendFile enabled) allowing only two simultaneous file
transmissions. I'm thinking of setting SendFile to disabled by default
on any non-server Windows OS in the pre-config phase, and letting the
user enable it explicitly if desired. I don't see a reason to change the
default for windows server OS's.
Re: Windows 2.3.13 :: Win32DisableAcceptEx
Posted by Eric Covener <co...@gmail.com>.
> Precisely. As we have context->buff allocated for all AcceptFilter
> schemes, I added the appropriate queries into that buffer in r1181140,
> and the world seems at peace again for just this short moment.
Trying to fully resolve the 2.3 accptex thread -- Should I add a
<note> about Win32DisableAcceptEx to mpm_winnt doc? Or even add it
back in as a "directive" to point to AcceptFilter?
Re: Windows 2.3.13 :: Win32DisableAcceptEx
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 9/29/2011 2:41 PM, Eric Covener wrote:
>
> I took a look at this in the AM, and it looks like the acceptfilter
> none path is relying on data set only by AcceptEX (context->buffer) to
> fill in context->sa_server (child.c:590). In 2.2 the context->buffer
> is seeded by the 9x specific code.
>
> Seems like that block of code just needs a backport from
> win9x_get_connection to set the server side of this structure
> correctly before it's copied into "sockinfo" later in the same
> function.
Precisely. As we have context->buff allocated for all AcceptFilter
schemes, I added the appropriate queries into that buffer in r1181140,
and the world seems at peace again for just this short moment.
Re: Windows 2.3.13 :: Win32DisableAcceptEx
Posted by Eric Covener <co...@gmail.com>.
On Thu, Sep 29, 2011 at 2:58 PM, William A. Rowe Jr.
<wr...@rowe-clan.net> wrote:
> On 7/7/2011 3:39 AM, Gregg L. Smith wrote:
>> I have an error log full of these;
>>
>> [Thu Jul 07 00:15:58.010625 2011] [mpm_winnt:warn] [pid 2840:tid 1572] (OS 64)The
>> specified network name is no longer available. : winnt_accept: Asynchronous AcceptEx failed.
>
> This might be http://svn.apache.org/viewvc?view=revision&revision=1091826
> confusing the issue if you build with Win32 IPv6 toggled on, depending on
> your operating system and the SDK you used to build... it was introduced
> in 1.4.3, you might want to try reverting this patch after first working
> through the ticket below...
>
>> Thanks to Steffen's bringing this up, I now know how I should be fixing this.
>>
>> The problem is, if I set
>>
>> AcceptFilter http none
>>
>> I lose all my vhosts and everything reverts to the main host. If I use
>
> Implies that the host headers are not queried for ***normal*** sockets,
> and reviewing http://svn.apache.org/viewvc?view=revision&revision=1088569
> it looks like this was "optimized" (read:bugged) away.
>
> Could you please revert this APR 1.4.3 change and report back what you
> observe? Another option is to simply try APR 1.4.2 binaries.
I took a windows laymen look in the other 2.4 GA thread, pasted below:
I took a look at this in the AM, and it looks like the acceptfilter
none path is relying on data set only by AcceptEX (context->buffer) to
fill in context->sa_server (child.c:590). In 2.2 the context->buffer
is seeded by the 9x specific code.
Seems like that block of code just needs a backport from
win9x_get_connection to set the server side of this structure
correctly before it's copied into "sockinfo" later in the same
function.
I can't easily build it and not sure what other non-acceptex 9x-isms
are in win9x_get_connection.
This matches the reports of the base VH being picked every time, but I
couldn't find on the list where the culprit had been identified
before.