> -----Original Message----- > From: Yann Ylavic [mailto:ylavic....@gmail.com] > Sent: Sunday, March 04, 2018 5:09 PM > To: httpd-dev <dev@httpd.apache.org> > Subject: Re: Fix for ab defect (was: [VOTE] Release httpd-2.4.31) > > On Sun, Mar 4, 2018 at 11:48 PM, Daniel Ruggeri <drugg...@primary.net> > wrote: > > > > I'd like to ask a followup question... how do we catch this in the > > test suite? With this (100% failure), ab still returns a 0 exit code. > > It *does* at least give the error message to STDERR. Perhaps we > > should add to the test suite that `ab -q` completed against the http > > and https vshosts with no lines printed to STDERR and has a 0 exit > > code? > > The best way is probably to capture stderr... > In this case though, this is not exactly "100% failure" in any > circonstances, for instance on localhost (or fast enough local > network) it won't fail since the errorneous path is not taken when > non-blocking connect succeeds. > It might not be easy/wise to launch/automate "ab" on an external > server in a test suite...
I just added r1825841 to stub out some very basic ab tests (and r1825842 now that I noticed a shortcoming). I'm not sure about the statement above. Maybe I misunderstand, but with my tests before/after the patch, the new test can detect this particular failure and should at least also protect us from trying to ship an ab build that returns non-zero and has anything in STDERR under normal circumstances. Review much appreciated, of course. What I greatly dislike about the above commit is that (at least on my tests), the STDERR and STDOUT from the child process appears to be folded into STDOUT. Thus, I added a failsafe check that STDOUT doesn't contain what looks to be an SSL error. This may be a side effect of the test suite because when running the same command in a standard shell the SSL complaint is on STDERR. I'm wondering if anyone can explain that behavior since IPC::Open3 has always segregated these streams? > > Regards, > Yann. -- Daniel Ruggeri
