On Mon, Mar 5, 2018 at 3:16 AM, Daniel Ruggeri <drugg...@primary.net> wrote: > >> -----Original Message----- >> From: Yann Ylavic [mailto:ylavic....@gmail.com] >> Sent: Sunday, March 04, 2018 5:09 PM [] >> 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.
I meant that before the patch, "ab" already succeeded for (e.g.) https://localhost/ or https://192.168.x.x/ that is if the connect is quick enough to not trigger the bug (though it's not necessarily the case in local networks either). This is probably why we didn't notice it on manual testing, "ab"-ing external/wan/google servers is not that usual... So I wonder which server is used by r1825841, and if everyone can run the test from home with being banned by gg.com or a.o ;) Thanks for the test anyway (no idea about perl/pipe things :/ ). Regards, Yann.
