apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: [PATCH] we need to init _unknown?
Date Mon, 27 Nov 2006 18:58:33 GMT
Joe Orton wrote:
> On Mon, Nov 27, 2006 at 12:13:06AM -0600, William Rowe wrote:
>> Joe Orton wrote:
>>> (The test_get_addr test was to check for a ->remote_addr_unknown 
>>> handling bug alone, FWIW: PR 32737)
>> Right - and it erroneously invokes connect against 0.0.0.0 no matter which
>> way I patch this.  We need to determine that connect-to 0.0.0.0 is portable
>> behavior and emulate, correct the patch to connect to a non-ephemeral addr,
>> or revert the test.
> 
> I've changed it to use 127.0.0.1 on the trunk; does that help?

Yes - although it does complete synchronously - and I'd expect it to far more
often than before.

>> And we need to roll a tarball - this is getting silly.  But I'm not rolling
>> with a borked test.
> 
> The test has been in 1.2.x since September 2005 - did something change 
> since then?

Good question.  Perhaps it's the fact that MS has tossed in an update "fix"
rejecting connect-to 0.0.0.0 as a "security patch"?  Nothing would surprise
me given MS's "understanding" of both transport or protocol layers anymore.

If our understanding is correct, isn't the following patch needed to address
the missing win32 and unix unknown_local_address for bind, and os2 missing
both this and unknown_local_port, and for win32/os2 set up the unknown_remote
initial value?

We would still need to decide how to let the resolver handle get_local_addr
when it remains unknown, of course.  Right now, it round-trips back to the
0.0.0.0 ephemeral address.

Bill




Mime
View raw message