Re: [VOTE] Release httpd-2.4.59-rc1 as httpd-2.4.59
+1 CentOS 6 CentOS 7 AlmaLinux 8 AlmaLinux 9 Ubuntu 20 Ubuntu 22 Thanks for RM’n. Regards, Cory McIntire | Release Manager cory.mcint...@webpros.com<mailto:cory.mcint...@webpros.com> | cPanel – a webpros company From: Eric Covener Date: Wednesday, April 3, 2024 at 07:26 To: Apache HTTP Server Development List Subject: [VOTE] Release httpd-2.4.59-rc1 as httpd-2.4.59 Hi all, I would like to call a SHORTENED VOTE to release this candidate tarball httpd-2.4.59-rc1 as 2.4.59: [ ] +1: It's not just good, it's good enough! [ ] +0: Let's have a talk. [ ] -1: There's trouble in paradise. Here's what's wrong.
Re: [VOTE] Release httpd-2.4.58-rc3 as httpd-2.4.58
+1 Built/tested on: CentOS 6 CentOS 7 AlmaLinux 9 Ubuntu 20.04 Ubuntu 22.04 Regards, Cory McIntire | Lead – cPanel Application Security Team | Release Manager – EasyApache cory.mcint...@webpros.com<mailto:cory.mcint...@webpros.com> | cPanel – a webpros company From: Stefan Eissing via dev Date: Monday, October 16, 2023 at 10:08 To: dev@httpd.apache.org Cc: Stefan Eissing Subject: [VOTE] Release httpd-2.4.58-rc3 as httpd-2.4.58 Hi all, after fixing my merge mistake in rc2 (sorry!), we go again: Please find below the proposed release tarball and signatures: https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fhttpd%2F=05%7C01%7Ccory%40cpanel.net%7Ce5c41228d1ce4a24971208dbce59cb59%7Cf8497356a834406086b6d4b1d8059ee0%7C0%7C0%7C638330657304238920%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=Hvd0FLQKHpx%2F4%2Flfj2iYh2mCcE4jNevfMZDL0piuolQ%3D=0<https://dist.apache.org/repos/dist/dev/httpd/> I would like to call a VOTE over the next few days to release this candidate tarball httpd-2.4.58-rc3 as 2.4.58: [ ] +1: It's not just good, it's good enough! [ ] +0: Let's have a talk. [ ] -1: There's trouble in paradise. Here's what's wrong. The computed digests of the tarball up for vote are: sha256: 503a7da4a4a27fd496037998b17078dc9fe004db32c657c96cce8356b8aa2eb6 *httpd-2.4.58-rc3.tar.gz sha512: 5c11faf0572035ef67b27775d975999411c689cb774553175299a9e99b63d3d7138b0c7f15048ec28038494d8513689f916202c2289d557947d8b190d46ca9f3 *httpd-2.4.58-rc3.tar.gz The SVN candidate source is found at tags/2.4.58-rc3-candidate. Cheers, Stefan
Re: [VOTE] Release httpd-2.4.52-rc1 as httpd-2.4.52
+1 CentOS 6 CentOS 7 AlmaLinux 8 Ubuntu 20.04 Regards, Cory McIntire PO – cPanel Security Team Release Manager – EasyApache cPanel / WebPros From: Stefan Eissing Date: Thursday, December 16, 2021 at 8:03 AM To: dev@httpd.apache.org Subject: [VOTE] Release httpd-2.4.52-rc1 as httpd-2.4.52 Hi all, Please find below the proposed release tarball and signatures: https://dist.apache.org/repos/dist/dev/httpd/ I would like to call a VOTE over the next few days to release this candidate tarball httpd-2.4.52-rc1 as 2.4.52: [ ] +1: It's not just good, it's good enough! [ ] +0: Let's have a talk. [ ] -1: There's trouble in paradise. Here's what's wrong. The computed digests of the tarball up for vote are: sha256: 296c74a8adde1a8acd6617b21fc3d19719ff4fa39319b2bdbd898aca4d5df97f *httpd-2.4.52-rc1.tar.gz sha512: b9012096d6658f7d34a3c655eac31b39ffd439c11de6f3e6e9f309d55f4186a4fb26134eb97522e416ae8ca10ed008a14e96fa01a3e3105d9e547f72e2dc3bc2 *httpd-2.4.52-rc1.tar.gz The SVN candidate source is found at tags/candidate-2.4.52-rc1. Kind Regards, Stefan
Re: Season Greetings
Happy Holidays to all and thanks to everyone involved in this little webserver that powers so many of our lives. Cheers, Cory McIntire PO – cPanel Security Team Release Manager – EasyApache cPanel / WebPros From: Steffen Land Date: Saturday, December 11, 2021 at 2:29 AM To: dev@httpd.apache.org Subject: Season Greetings Happy holidays to all the HTTPD Community developers and users and enjoy the holidays ! We wish for you, your friends and your families time to reconnect, enjoy traditions, and to find some rest during the holiday season. Whatever you celebrate, I hope you take a moment to reflect on the year that is closing and on your goals for 2022 as it approaches. For the next weeks, I'll be spending time with my family enjoying Christmas and end of year festivities. As exciting as computers and servers can be, this year will also forever serve as a reminder of what is really important: family, friends and the compassion of strangers. Steffen
Re: [VOTE] Release httpd-2.4.51-rc1 as httpd-2.4.51
+1 Cent6/7/8 Ubuntu 20.04 Thanks, Cory McIntire PO – cPanel Security Team Release Manager – EasyApache cPanel / WebPros From: ste...@eissing.org Date: Thursday, October 7, 2021 at 8:17 AM To: dev@httpd.apache.org Subject: [VOTE] Release httpd-2.4.51-rc1 as httpd-2.4.51 Hi all, due to found security weaknesses in our 2.4.50 release, the security team feels it is necessary to do a new release on very short notice. We will skip the usual 3 day voting period and close the vote once we feel comfortable with our testing. Please find below the proposed release tarball and signatures: https://dist.apache.org/repos/dist/dev/httpd/ I would like to call a VOTE over the next few days^h^h^h^hhours to release this candidate tarball httpd-2.4.51-rc1 as 2.4.51: [ ] +1: It's not just good, it's hopefully good enough! [ ] +0: Let's have a talk. [ ] -1: There's trouble in paradise. Here's what's wrong. The computed digests of the tarball up for vote are: sha1: 516128e5acb7311e6e4d32d600664deb0d12e61f *httpd-2.4.51-rc1.tar.gz sha256: c2cedb0b47666bea633b44d5b3a2ebf3c466e0506955fbc3012a5a9b078ca8b4 *httpd-2.4.51-rc1.tar.gz sha512: 507fd2bbc420e8a1f0a90737d253f1aa31000a948f7a840fdd4797a78f7a4f1bd39250b33087485213a3bed4d11221e98eabfaf4ff17c7d0380236f8a52ee157 *httpd-2.4.51-rc1.tar.gz The SVN candidate source is found at tags/candidate-2.4.51-rc1. Kind Regards, Stefan
Re: [VOTE] Release httpd-2.4.50-rc1 as httpd-2.4.50
+1: It's not just good, it's good enough! Looks good for us, Cent6/7/8 Alma8 Thanks for RM’n. Cory McIntire PO – cPanel Security Team Release Manager – EasyApache cPanel / WebPros From: ste...@eissing.org Date: Friday, October 1, 2021 at 9:41 AM To: dev@httpd.apache.org Subject: [VOTE] Release httpd-2.4.50-rc1 as httpd-2.4.50 Hi, all; Please find below the proposed release tarball and signatures: https://dist.apache.org/repos/dist/dev/httpd/ I would like to call a VOTE over the next few days to release this candidate tarball httpd-2.4.50-rc1 as 2.4.50: [ ] +1: It's not just good, it's good enough! [ ] +0: Let's have a talk. [ ] -1: There's trouble in paradise. Here's what's wrong. The computed digests of the tarball up for vote are: sha1: afac1bf6aaa84ea2878c56ed56a49f5efdd7ff73 *httpd-2.4.50-rc1.tar.gz sha256: feb87f9cc60e02782d795d30cd60a36e918c82fe9a2e7363b0ae28a78be9613a *httpd-2.4.50-rc1.tar.gz sha512: 3b5e06d8428f14bae8173dbb27921496831c7c14c31850d2df0c0d6f69e931bbf0e4e71c6a250b4f5c0d646d1b7da813bbe61711f8a79ab5f80d39dfd176f57c *httpd-2.4.50-rc1.tar.gz The SVN candidate source is found at tags/candidate-2.4.50-rc1. Kind Regards, Stefan
Re: [VOTE] Release httpd-2.4.48
Hello All, +1: It's not just good, it's good enough! CentOS6, CentOS7, and CentOS8 builds and passes test suite for us. Thanks, Cory McIntire PO – cPanel Security Team Release Manager – EasyApache cPanel, L.L.C. From: Christophe JAILLET Date: Monday, May 17, 2021 at 4:37 PM To: dev@httpd.apache.org Subject: [VOTE] Release httpd-2.4.48 Hi, all; Please find below the proposed release tarball and signatures: https://dist.apache.org/repos/dist/dev/httpd/ I would like to call a VOTE over the next few days to release this candidate tarball as 2.4.48: [ ] +1: It's not just good, it's good enough! [ ] +0: Let's have a talk. [ ] -1: There's trouble in paradise. Here's what's wrong. The computed digests of the tarball up for vote are: sha1: b581bcfdd939fe77c3821f7ad3863c7307374919 *httpd-2.4.48.tar.gz sha256: 315c0bc50206b866fb17c2cdc28c1973765a8d59ca168b80286e8cb077d0510e *httpd-2.4.48.tar.gz sha512: 91980f757fc0dede8c6cbf54ed973f82a63098aa50d0fce15fe3537687b4ffbb48ed50cdb4ae14eb4a8703450f032daf73f4f3d5e2dd0f75721948e12a9c6dfb *httpd-2.4.48.tar.gz The SVN tag is '2.4.48' at r1889975. -- Christophe JAILLET
Re: 2.4.38
I’m all for this as well, because people want the new hotness. That said, for people downstream that have to support httpd, y’all are releasing really fast. I get it, and we haven’t really had any problems (minus a weird semaphore issue we haven’t tracked down yet), I’m noticing an increase of releases lately. Just curious what is the rush lately? Is this all a build up to 2.6 coming out or something else? > On Nov 8, 2018, at 3:11 AM, Stefan Eissing > wrote: > > >> Am 07.11.2018 um 16:15 schrieb Jim Jagielski : >> >> Now that we have a 2.4.37 out, one in which the number of enhancements and >> fixes and feature were limited, it makes sense to consider having a 2.4.38 >> release somewhat "soonish", esp considering the number of backports that >> lack only a single vote. >> >> Comments? > > I am all for it. And I have reasons! :-) > > 1. We are well on track to automate the whole thing nicely. We need some more > iterations to make it tight. This is easier done in short intervals. > 2. I think regular releases are good for the people here and motivate people > from outside to contribute. > 3. h2 and Let's Encrypt still get attention and there are some small > improvements I'd like to throw out there. Nothing serious, just would be nice. > > Cheers, > > Stefan Super off topic but this is one of the best communities I deal with in my day to day, even when y’all are mad you’re good to each other, means a lot to those of us that just need to follow the feed. Thank you all for that. Thanks, Cory McIntire Release Manager - EasyApache cPanel, L.L.C. smime.p7s Description: S/MIME cryptographic signature
Re: [VOTE] Release httpd-2.4.37
Just a note, the date here is Sept instead of Oct :) http://httpd.apache.org/dev/dist/Announcement2.4.html http://httpd.apache.org/dev/dist/Announcement2.4.txt (I realize this might not be final version of said text.. just wanted to mention) Thanks Cory McIntire Release Manager - EasyApache cPanel, L.L.C. > On Oct 22, 2018, at 9:08 AM, Daniel Ruggeri wrote: > > On 2018-10-18 09:36, Daniel Ruggeri wrote: >> Hi, all; >> Please find below the proposed release tarball and signatures: >> https://dist.apache.org/repos/dist/dev/httpd/ >> I would like to call a VOTE over the next few days to release this >> candidate tarball as 2.4.37: >> [ ] +1: It's not just good, it's good enough! >> [ ] +0: Let's have a talk. >> [ ] -1: There's trouble in paradise. Here's what's wrong. >> The computed digests of the tarball up for vote are: >> sha1: b0521606d1df54bb425adcdecf6348f126aa352c *httpd-2.4.37.tar.gz >> sha256: >> aa97a834a32d51974be8d8a013b561e28d327387cb1da2c3c2762acd0146aabd >> *httpd-2.4.37.tar.gz > > Hello, all; > I am pleased to announce that the release vote has PASSED with the > following recorded votes. > > PMC > druggeri, jorton, jim, icing, jailletc36, ylavic, rjung > > Community > Dennis Radford > > I will begin the process of syncing the mirrors and preparing the final > Announce text. > > I'd like to give a big thank you for all the folks who put effort into > creating the code for this release and the effort spent testing this release! > > -- > Daniel Ruggeri smime.p7s Description: S/MIME cryptographic signature
Re: Bug in mod_ratelimit?
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 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 wrote:
>>
>> 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
>>>> work with HEAD requests, this is too large a change, especially when
>>>> the bug(s) being addressesed are in a single module.
>>>>
>>>> I’d recommend making mod_ratelimit do the same “optimization” hack
>>>> that other modules for HEAD requests instead, and keep the surface
>>>> area for this bug fix isolated to mod_ratelimit only.
>>>>
>>>> Something like what mod_brotli does:
>>>>
>>>>if (r->header_only && r->bytes_sent) {
>>>>ap_remove_output_filter(f);
>>>>return ap_pass_brigade(f->next, bb);
>>>>}
>>>> {quote}
>>>>
>>>> If there are any further adjustments to this patch we’d be happy to
>>>> take a look, just let us know.
>>>
>>> Sorry, I missed that proposal.
>>>
>>> So, AIUI, the above plus moving the ratelimit filter after the "CHUNK"
>>> filter, right?
>>> Otherwise I don't see where we address the "header
>>> ratelimited/retained before chunking" case (regardless of
>>> HEAD/GET/..).
>>> IOW, the patch (limited to mod_ratelimit) would be something like:
>>>
>>> @@ -123,6 +123,13 @@ rate_limit_filter(ap_filter_t *f, apr_bucket_briga
>>>APR_BRIGADE_PREPEND(bb, ctx->holdingbb);
>>>}
>>>
>>> +if (f->r->header_only && f->r->bytes_sent) {
>>> +ap_remove_output_filter(f);
>>> +rv = ap_pass_brigade(f->next, bb);
>>> +apr_brigade_cleanup(bb);
>>> +return rv;
>>> +}
>>> +
>>>while (!APR_BRIGADE_EMPTY(bb)) {
>>>apr_bucket *e;
>>>
>>> @@ -327,7 +334,7 @@ static void register_hooks(apr_pool_t *p)
>>>ap_register_output_filter(RATE_LIMIT_FILTER_NAME, rate_limit_filter,
>>> - NULL, AP_FTYPE_PROTOCOL + 3);
>>> + NULL, AP_FTYPE_CONNECTION - 1);
>>>
>>> I think it does not work for the case where a HEAD response has a
>>> large header but "Content-Length: 0", such that rate_limit_filter()
>>> retains the last buckets but is never called to release them (i.e.
>>> EOS).
>>> Really we shouldn't have any (protocol) filter that eats EOS, this is
>>> the garantee that each request filter sees when it should terminate
>>> and bail out (that's also the purpose of
>>> ap_finalize_request_protocol() for instance).
>>>
>>> r1837130 looks like the right fix to me.
>>
>> sorry for the late ping but I was on holidays. I know that you and
>> your team expressed some doubts about the fix for mod_ratelimit, but
>> it seems that Yann's fix is the correct way to go for me too. Any
>> thoughts? It would be great to reach some consensus within the
>> community before proceeding :)
>>
>> Thanks!
>>
>> Luca
>
smime.p7s
Description: S/MIME cryptographic signature
Re: Bug in mod_ratelimit?
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 wrote:
>
> 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
>>> work with HEAD requests, this is too large a change, especially when
>>> the bug(s) being addressesed are in a single module.
>>>
>>> I’d recommend making mod_ratelimit do the same “optimization” hack
>>> that other modules for HEAD requests instead, and keep the surface
>>> area for this bug fix isolated to mod_ratelimit only.
>>>
>>> Something like what mod_brotli does:
>>>
>>> if (r->header_only && r->bytes_sent) {
>>> ap_remove_output_filter(f);
>>> return ap_pass_brigade(f->next, bb);
>>> }
>>> {quote}
>>>
>>> If there are any further adjustments to this patch we’d be happy to
>>> take a look, just let us know.
>>
>> Sorry, I missed that proposal.
>>
>> So, AIUI, the above plus moving the ratelimit filter after the "CHUNK"
>> filter, right?
>> Otherwise I don't see where we address the "header
>> ratelimited/retained before chunking" case (regardless of
>> HEAD/GET/..).
>> IOW, the patch (limited to mod_ratelimit) would be something like:
>>
>> @@ -123,6 +123,13 @@ rate_limit_filter(ap_filter_t *f, apr_bucket_briga
>> APR_BRIGADE_PREPEND(bb, ctx->holdingbb);
>> }
>>
>> +if (f->r->header_only && f->r->bytes_sent) {
>> +ap_remove_output_filter(f);
>> +rv = ap_pass_brigade(f->next, bb);
>> +apr_brigade_cleanup(bb);
>> +return rv;
>> +}
>> +
>> while (!APR_BRIGADE_EMPTY(bb)) {
>> apr_bucket *e;
>>
>> @@ -327,7 +334,7 @@ static void register_hooks(apr_pool_t *p)
>> ap_register_output_filter(RATE_LIMIT_FILTER_NAME, rate_limit_filter,
>> - NULL, AP_FTYPE_PROTOCOL + 3);
>> + NULL, AP_FTYPE_CONNECTION - 1);
>>
>> I think it does not work for the case where a HEAD response has a
>> large header but "Content-Length: 0", such that rate_limit_filter()
>> retains the last buckets but is never called to release them (i.e.
>> EOS).
>> Really we shouldn't have any (protocol) filter that eats EOS, this is
>> the garantee that each request filter sees when it should terminate
>> and bail out (that's also the purpose of
>> ap_finalize_request_protocol() for instance).
>>
>> r1837130 looks like the right fix to me.
>
> sorry for the late ping but I was on holidays. I know that you and
> your team expressed some doubts about the fix for mod_ratelimit, but
> it seems that Yann's fix is the correct way to go for me too. Any
> thoughts? It would be great to reach some consensus within the
> community before proceeding :)
>
> Thanks!
>
> Luca
smime.p7s
Description: S/MIME cryptographic signature
Re: Bug in mod_ratelimit?
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 with HEAD
requests,
this is too large a change, especially when the bug(s) being addressesed are in
a single module.
I’d recommend making mod_ratelimit do the same “optimization” hack that other
modules for HEAD requests instead, and keep the surface area for this bug fix
isolated to mod_ratelimit only.
Something like what mod_brotli does:
if (r->header_only && r->bytes_sent) {
ap_remove_output_filter(f);
return ap_pass_brigade(f->next, bb);
}
{quote}
If there are any further adjustments to this patch we’d be happy to take a
look, just let us know.
Thanks,
Cory McIntire
Release Manager - EasyApache
cPanel, Inc.
> On Jul 27, 2018, at 10:46 AM, Luca Toscano wrote:
>
> 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 versions of the patch applied.
>>
>> Thanks for letting us know.
>>
>> I think the right fix is the attached patch (tested with GET/HEAD with
>> large header and/or body, seems to work).
>> If by any chance you can give it a try...
>
> In the meantime, other people are testing Yann's last patch in
> https://bz.apache.org/bugzilla/show_bug.cgi?id=62568 (it is attached
> in there). If you could chime in whenever you have time and let us
> know your thoughts it would be really great.
>
> Thanks in advance!
>
> Luca
smime.p7s
Description: S/MIME cryptographic signature
Re: Bug in mod_ratelimit?
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 wrote:
>
> 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 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
Re: Bug in mod_ratelimit?
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 it will cause the headers to be larger than
the chunk size,
and you will see an error with those responses such as this:
curl -H'Host: cptestaddon.com' http://10.215.218.12/
curl: (56) Illegal or missing hexadecimal sequence in chunked-encoding
which of course means the page doesn’t load.
Real world how often is it set that low is unknown but thought we’d share our
findings.
Cory
> On Jul 19, 2018, at 2:53 PM, Cory McIntire wrote:
>
> 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: modules/filters/mod_ratelimit.c
>> ===
>> --- modules/filters/mod_ratelimit.c(revision 1835556)
>> +++ modules/filters/mod_ratelimit.c(working copy)
>> @@ -208,7 +208,7 @@ rate_limit_filter(ap_filter_t *f, apr_bucket_briga
>>ap_remove_output_filter(f);
>>}
>>else if (!APR_BUCKET_IS_FLUSH(e)) {
>> -if (APR_BRIGADE_EMPTY(bb)) {
>> +if (ctx->do_sleep && APR_BRIGADE_EMPTY(bb)) {
>>/* Wait for more (or next call) */
>>break;
>>}
>> _
>
> Much appreciated,
> Cory
>
smime.p7s
Description: S/MIME cryptographic signature
Re: Bug in mod_ratelimit?
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: modules/filters/mod_ratelimit.c
> ===
> --- modules/filters/mod_ratelimit.c(revision 1835556)
> +++ modules/filters/mod_ratelimit.c(working copy)
> @@ -208,7 +208,7 @@ rate_limit_filter(ap_filter_t *f, apr_bucket_briga
> ap_remove_output_filter(f);
> }
> else if (!APR_BUCKET_IS_FLUSH(e)) {
> -if (APR_BRIGADE_EMPTY(bb)) {
> +if (ctx->do_sleep && APR_BRIGADE_EMPTY(bb)) {
> /* Wait for more (or next call) */
> break;
> }
> _
Much appreciated,
Cory
smime.p7s
Description: S/MIME cryptographic signature
Re: Bug in mod_ratelimit?
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 ratelimit config for the domain # restart apache # visit site, see you are getting the "redirect" content instead of actually being redirected: • curl -H'Host: cptestaddon.com' http://10.215.218.12/ • HTTP/1.1 302 Moved Temporarily • Date: Thu, 19 Jul 2018 16:47:07 GMT • Server: Apache • X-Powered-By: PHP/5.6.36 • Expires: Wed, 11 Jan 1984 05:00:00 GMT • Cache-Control: no-cache, must-revalidate, max-age=0 • Pragma: no-cache • Location: http://cptestaddon.com/wp-admin/install.php • Transfer-Encoding: chunked • Content-Type: text/html; charset=UTF-8 • 0 It is any CGI app but WP was an easy target to replicate on. If you confirm I will create a bug report for it, basically mod_ratelimit causes CGI-style apps to emit plaintext. Thanks, Cory McIntire Release Manager - EasyApache cPanel, Inc. > On Jul 19, 2018, at 10:32 AM, Luca Toscano wrote: > > 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 code… > > We haven’t found the connection beyond unloading mod_ratelimit which resolves > the issue, > and its not happening everywhere, just curious if anyone else is seeing this? > > I’ll report back once I have more info on further factors involved. > > Thanks a lot for reporting this. Can you add a bit more info about how to > reproduce (httpd config I mean)? Anything relevant in the error logs? > > Luca > smime.p7s Description: S/MIME cryptographic signature
Re: Bug in mod_ratelimit?
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 again. When in a broken state we would see things like the following when visiting the page: HTTP/1.1 200 OK Date: Thu, 19 Jul 2018 13:33:05 GMT Server: Apache X-Frame-Options: SAMEORIGIN X-Pingback: http:///xmlrpc.php Link: < http://X/wp-json/>; rel="https://api.w.org/;, <http://X/>; rel=shortlink Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/html; charset=UTF-8 …. …. We are working internally to attempt to get more of these answers.. having trouble so far reproducing in house. Sorry I don’t have more info but I will reply again if we can get it reproducible. Thanks for your quick response! Cory McIntire Release Manager - EasyApache cPanel, Inc. > On Jul 19, 2018, at 10:32 AM, Luca Toscano wrote: > > 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 code… > > We haven’t found the connection beyond unloading mod_ratelimit which resolves > the issue, > and its not happening everywhere, just curious if anyone else is seeing this? > > I’ll report back once I have more info on further factors involved. > > Thanks a lot for reporting this. Can you add a bit more info about how to > reproduce (httpd config I mean)? Anything relevant in the error logs? > > Luca > smime.p7s Description: S/MIME cryptographic signature
Bug in mod_ratelimit?
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 mod_ratelimit which resolves the issue, and its not happening everywhere, just curious if anyone else is seeing this? I’ll report back once I have more info on further factors involved. Thank you, Cory McIntire Release Manager - EasyApache cPanel, Inc. smime.p7s Description: S/MIME cryptographic signature
