On Tue, Aug 28, 2018 at 4:21 PM Cory McIntire wrote:
>
> We’ve tested this in house and it does seem to resolve the issues from the
> previous patch. Looks good to us. :)
Thanks Cory for the tests, it has been merge in 2.4.x and will be
available in next 2.4 version.
Regards,
Yann.
Hi Luca,
We’ve tested this in house and it does seem to resolve the issues from the
previous patch. Looks good to us. :)
Thanks,
Cory
> On Aug 27, 2018, at 8:50 AM, Cory McIntire wrote:
>
> Hello Luca,
>
> Sorry for late reply, we’re digging into and testing this version of the
> patch
Hello Luca,
Sorry for late reply, we’re digging into and testing this version of the patch
now, will update this week
with more info, preliminary results seem to be positive however.
Thanks,
Cory McIntire
Release Manager - EasyApache
cPanel, Inc.
> On Aug 23, 2018, at 11:25 AM, Luca Toscano
Hi Cory,
Il giorno gio 2 ago 2018 alle ore 14:10 Yann Ylavic
ha scritto:
>
> On Fri, Jul 27, 2018 at 6:56 PM, Cory McIntire wrote:
> >
> > {quote}
> > While it will probably resolve the issues we saw, I’d be hesitant to
> > move forward with that patch as it modifies how all output filters
> >
On Fri, Jul 27, 2018 at 6:56 PM, Cory McIntire wrote:
>
> {quote}
> While it will probably resolve the issues we saw, I’d be hesitant to
> move forward with that patch as it modifies how all output filters
> work with HEAD requests, this is too large a change, especially when
> the bug(s) being
I'd concur that this suggested change is lighter weight and less fragile.
On Fri, Jul 27, 2018, 12:56 Cory McIntire wrote:
> Hi Luca,
>
> Sorry for the delay in response.. we did look into it further..
>
> On of our devs had been looking into it and came up with the following:
>
> {quote}
>
Hi Luca,
Sorry for the delay in response.. we did look into it further..
On of our devs had been looking into it and came up with the following:
{quote}
While it will probably resolve the issues we saw, I’d be hesitant to move
forward with that patch as it modifies how all output filters work
Hi Cory,
2018-07-20 13:47 GMT+02:00 Yann Ylavic :
> Hi Cory,
>
> On Thu, Jul 19, 2018 at 11:23 PM, Cory McIntire wrote:
>>
>> 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
> -Ursprüngliche Nachricht-
> Von: Yann Ylavic
> Gesendet: Montag, 23. Juli 2018 10:52
> An: httpd-dev
> Betreff: Re: Bug in mod_ratelimit?
>
> On Mon, Jul 23, 2018 at 7:45 AM, Plüm, Rüdiger, Vodafone Group
> wrote:
> >
> >
> >> ---
On Mon, Jul 23, 2018 at 7:45 AM, Plüm, Rüdiger, Vodafone Group
wrote:
>
>
>> -Ursprüngliche Nachricht-
>> Von: Eric Covener
>> Gesendet: Sonntag, 22. Juli 2018 21:58
>> An: Apache HTTP Server Development List
>> Betreff: Re: Bug in mod_ratelimit
> -Ursprüngliche Nachricht-
> Von: Eric Covener
> Gesendet: Sonntag, 22. Juli 2018 21:58
> An: Apache HTTP Server Development List
> Betreff: Re: Bug in mod_ratelimit?
>
> > > You probably didn't test with chunked encoding (neither did I!), see
> > &
> > You probably didn't test with chunked encoding (neither did I!), see
> > how ap_http_header_filter() adds the "CHUNK" filter after the headers
> > have been sent, so if anything retains the headers they will be
> > considered as the body by the (late) ap_http_chunk_filter()..
would it be
Hi Yann,
2018-07-19 22:55 GMT+02:00 Yann Ylavic :
>
> Hi Luca,
>
> On Thu, Jul 19, 2018 at 9:59 PM, Luca Toscano wrote:
> >
> > I confirm that it works fine in my local dev environment, plus now gdb's
> > dump_brigade makes sense, but I am not sure that I have understood what was
> > wrong. In
Hi Cory,
On Thu, Jul 19, 2018 at 11:23 PM, Cory McIntire wrote:
>
> 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 for letting us know.
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
Hi Luca,
On Thu, Jul 19, 2018 at 9:59 PM, Luca Toscano wrote:
>
> I confirm that it works fine in my local dev environment, plus now gdb's
> dump_brigade makes sense, but I am not sure that I have understood what was
> wrong. In my tests, the headers were the first heap bucket reported by
>
On Thu, Jul 19, 2018 at 10:30 PM, Yann Ylavic wrote:
> Hi,
>
> On Thu, Jul 19, 2018 at 10:16 PM, Cory McIntire 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
Hi,
On Thu, Jul 19, 2018 at 10:16 PM, Cory McIntire 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++) {
>
Hello,
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");
}
Set your rate limit pretty low and
Hi Yann,
2018-07-19 21:41 GMT+02:00 Yann Ylavic :
> On Thu, Jul 19, 2018 at 8:23 PM, Luca Toscano
> wrote:
> >
> > Yann, any idea?
>
> Looks like we missed the simplest case :/
>
> Index: modules/filters/mod_ratelimit.c
> ===
> ---
On Thu, Jul 19, 2018 at 3:41 PM Yann Ylavic wrote:
>
> On Thu, Jul 19, 2018 at 8:23 PM, Luca Toscano wrote:
> >
> > Yann, any idea?
>
> Looks like we missed the simplest case :/
>
> Index: modules/filters/mod_ratelimit.c
> ===
> ---
Hello Yann,
We can confirm this patch works on our end. We’ll apply this and send out an
update.
> On Jul 19, 2018, at 2:41 PM, Yann Ylavic wrote:
>
> On Thu, Jul 19, 2018 at 8:23 PM, Luca Toscano wrote:
>>
>> Yann, any idea?
>
> Looks like we missed the simplest case :/
>
> Index:
On Thu, Jul 19, 2018 at 8:23 PM, Luca Toscano wrote:
>
> Yann, any idea?
Looks like we missed the simplest case :/
Index: modules/filters/mod_ratelimit.c
===
--- modules/filters/mod_ratelimit.c(revision 1835556)
+++
On Thu, Jul 19, 2018 at 2:23 PM Luca Toscano wrote:
>
> Hi again Cory,
>
> 2018-07-19 19:02 GMT+02:00 Cory McIntire :
>>
>> Hi Luca,
>>
>> Sorry for quick reply but we were able to replicate it just now:
>>
>> # setup a brand new install of wp on a domain (don't have to go through the
>> 'db'
Hi again Cory,
2018-07-19 19:02 GMT+02:00 Cory McIntire :
> Hi Luca,
>
> Sorry for quick reply but we were able to replicate it just now:
>
> # setup a brand new install of wp on a domain (don't have to go through
> the 'db' setup process, just configure wp-config.php to get to install.php
>
Hi Luca,
Sorry for quick reply but we were able to replicate it just now:
# setup a brand new install of wp on a domain (don't have to go through the
'db' setup process, just configure wp-config.php to get to install.php redirect)
# install mod_ratelimit, and setup a vhost.conf with the
Hi Luca,
So far we’ve not seen much in the logs of our customer reports, however I was
able to get the following settings:
SetOutputFilter RATE_LIMIT
SetEnv rate-limit 512
SetEnv rate-initial-burst 625
When removed/commented out and/or removing mod_ratelimit the site would begin
to work
Hi Cory,
2018-07-19 16:10 GMT+02:00 Cory McIntire :
> Hello all,
>
> We’re starting to see some issues where mod_ratelimit change here:
>
> *) mod_ratelimit: fix behavior when proxing content. PR 62362.
> [Luca Toscano, Yann Ylavic]
>
> Is causing some sites to load in plain text/source
Hello all,
We’re starting to see some issues where mod_ratelimit change here:
*) mod_ratelimit: fix behavior when proxing content. PR 62362.
[Luca Toscano, Yann Ylavic]
Is causing some sites to load in plain text/source code…
We haven’t found the connection beyond unloading
29 matches
Mail list logo
