Hi all, We’re going to revert to the 2.4.33 version of mod_ratelimit for now.
HEAD requests with large amount of headers were still problematic in our testing with both versions of the patch applied. Thanks, Cory McIntire Release Manager - EasyApache cPanel, Inc. > On Jul 19, 2018, at 3:36 PM, Yann Ylavic <[email protected]> wrote: > > On Thu, Jul 19, 2018 at 10:30 PM, Yann Ylavic <[email protected]> wrote: >> Hi, >> >> On Thu, Jul 19, 2018 at 10:16 PM, Cory McIntire <[email protected]> wrote: >>> >>> Upon some initial testing of the patch we have found some conditions to >>> which this will still break, consider the following: >>> >>> Put something like this into your php file, >>> >>> for ($i = 1; $i <= 2000; $i++) { >>> header("x$i: $i"); >>> } >> >> Yes I was thinking about this, currently mod_ratelimit is not able to >> ratelimit headers when chunked encoding is to be used for the body. >> >> This is because the http (header) filter assumes nothing retains the >> headers in between itself and the chunked filter (which itself assumes >> everything it receives is the body). >> >> I'm looking at the best way to address this, possibly mod_ratelimit's >> filter should be moved after the "CHUNK" filter (i.e. >> AP_FTYPE_TRANSCODE)? The requirement seems to be after deflate but >> before network filter... > > The patch would be something like this (instead of the previous one): > > Index: modules/filters/mod_ratelimit.c > =================================================================== > --- modules/filters/mod_ratelimit.c (revision 1835556) > +++ modules/filters/mod_ratelimit.c (working copy) > @@ -327,7 +327,7 @@ static void register_hooks(apr_pool_t *p) > { > /* run after mod_deflate etc etc, but not at connection level, > ie, mod_ssl. */ > ap_register_output_filter(RATE_LIMIT_FILTER_NAME, rate_limit_filter, > - NULL, AP_FTYPE_PROTOCOL + 3); > + NULL, AP_FTYPE_TRANSCODE + 1); > } > > -- > > This seems to work for me too...
smime.p7s
Description: S/MIME cryptographic signature
