On 25.07.2013 14:55, Rainer Jung wrote: > On 25.07.2013 13:43, Plüm, Rüdiger, Vodafone Group wrote: >> I see many tests for mod_deflate currently failing on trunk (OS is RH5 64 >> Bit). >> >> Failed Test Stat Wstat Total Fail Failed List of Failed >> ------------------------------------------------------------------------------- >> t/modules/deflate.t 47 33 70.21% 2-4 6-8 10-12 14-16 18-20 >> 22-24 26-28 30-32 34-36 >> 38- >> 40 42-44 >> Failed 1/1 test scripts, 0.00% okay. 33/47 subtests failed, 29.79% okay. > > Thanks for the information.Confirmed here. Most likely due to my change > r1502775 in the test framework. Will look into it later today.
Behavior is really different between 2.4.6 and current trunk. in 2.4.6 ap_get_client_block() simply returns a negative result. In trunk we insert an error bucket. In this case the error returned by mod_deflate was APR_EGENERAL which was mapped to an error 400 by ap_map_http_request_error(). The corresponding change is r1482918 which together with several more changes to http_filters.c wasn't yet ported back (or even proposed). I fixed some of the tests. The test which is still problematic is checking for spurious data coming after a compressed request body. This test was disabled before I enabled it recently. It would work for 2.4 but on trunk I had no idea how to fix it: if the request body is big enough (the 14KB logo) there is enough data in front of the garbage such that the response is already started. For 2.4 the error reaches mod_echo_post which adds "!!!ERROR!!!" at the end of the response. For trunk there is now an error brigade inserted which doesn't end up in the response send to the client. Therefore I disabled the test again. I have some doubts/questions about r1502775 I'll post in another thread. Regards, Rainer
