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: Roll 0.9.15 this week?
Date Wed, 15 Aug 2007 17:38:17 GMT
jean-frederic clere wrote:
> Ruediger Pluem wrote:
>> On 08/13/2007 09:34 PM, William A. Rowe, Jr. wrote:
>>> It's a nice idea in 1.3, but since it's causing issues, simply revert.
>> Done in r565517.
> 
> Wasn't the (*new)->remote_addr_unknown = 0; causing the problem?

Are you thinking of the unix issue or windows issue?

The windows issue is that we defined that remote address was flagged known
before - and became known, because httpd filled it in on AcceptEx from
the data.  Windows 2000 could *only* recall the remote IP from the AcceptEx
command, and the classic socket commands returned 0.0.0.0.  This had been
already fixed in the last apr release, and filling in the remote IP from
httpd now causes the 'unknown' to be toggled false.

RĂ¼diger observed (with respect to a platform he didn't identify);
-------------------------
These regression are caused by an apr problem. 2.0.59 is shipped with
apr 0.9.12 whereas 2.0.60 is shipped with apr 0.9.14.

The regressions are caused by r442526 and r443264 which are backports
of r442135 and r443262 from apr trunk.
These revisions change apr_socket_accept in network_io/unix/sockets.c.
Why does this not happen with apr trunk / 1.2.x?

On apr trunk we have r447894. Backporting this patch to 0.9.14 fixes
the regressions.  On apr 1.2.x the backports of r442135 and r443262
have been reverted in r473681.

So I guess we either have to ship 2.0.x with an older release of apr 0.9.x
or we have to wait for a new release of apr 0.9.x that fixes this problem.
--------------------------

So although rpluem has gone ahead and verified that reverting this solves
the issue; you should feel welcome to craft a complete backport that does
NOT introduce the bug discovered in httpd.  Although I felt changing the
contract was unnecessary, I don't object if it solves other problems or
makes the previous API contracts more conformant.

I'm rolling today, although not quite first thing as I had planned.  I've
spent my time since vacation fighting with Win32-foo, and want to make sure
the release is solid on Win32 as well as unix.

If anyone is working on any last minute spit-n-polish (no major changes
please!!!) then ping on irc as well as the list, so I don't 'roll over' you.

Bill

Mime
View raw message