apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jean-frederic clere <jfcl...@gmail.com>
Subject Re: Roll 0.9.15 this week?
Date Thu, 16 Aug 2007 07:15:21 GMT
William A. Rowe, Jr. wrote:
> 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  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.

Thank that explains the used of remote_addr_unknown. So
(*new)->remote_addr_unknown = 0 wasn't the problem.

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

Yes I have tested that too.

>  On apr 1.2.x the backports of r442135 and r443262
> have been reverted in r473681.

With r565517 we have the same logic in 0.9.x

> 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

View raw message