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 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.
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. Great. Cheers Jean-Frederic > 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 >
