Re: intent to rip out mod_tls

[Stefan Eissing via dev]

> Am 17.09.2024 um 15:18 schrieb Will Fatherley :
> 
> 
> I now removed mod_tls from trunk and 2.4.x.
> Mind sharing the repository link when it becomes available? Also, and 
> speaking with shallow experience, I’m happy to help set it up.

Oh, sorry, my bad. The repository is at https://github.com/icing/mod_tls

Cheers,
Stefan

> 
> Will

Re: intent to rip out mod_tls

[Stefan Eissing via dev]

I count several 0s and one +0.5, added my own +1.

I now removed mod_tls from trunk and 2.4.x. I hope I caught all place in 
source, documentation and test.

Thanks,
Stefan

PS.
@Christophe: I know you want to re-use the tests for mod_ssl. Maybe resurrect 
them in a modules/ssl directory?

> Am 13.09.2024 um 15:26 schrieb Stefan Eissing via dev :
> 
> Folks, 
> 
> the 'rustls-ffi' project <https://github.com/rustls/rustls-ffi> keeps on 
> changing their API and consider themselves "pre-1.0". The recent 0.14.0 
> release does not work with mod_tls, again. While one of their devs is willing 
> to make another PR for fixing that on heir spare time - appreciated - this 
> means our module is not just "experimental", but just "unstable".
> 
> I therefore think it should not sit in our source tree, but be a separate GH 
> project. I am willing to host that, review/merge PRs and tag v0.x releases of 
> the module there.
> 
> Would anyone object to that? Or, the other way around, does anyone here want 
> to carry the torch and maintain it in our source tree?
> 
> How about an informal vote?
> 
> +1: yes, rip it out
> +0: no opinion
> -1: no, leave it here, I'll take care of it
> 
> Cheers,
> Stefan

intent to rip out mod_tls

[Stefan Eissing via dev]

Folks, 

the 'rustls-ffi' project  keeps on 
changing their API and consider themselves "pre-1.0". The recent 0.14.0 release 
does not work with mod_tls, again. While one of their devs is willing to make 
another PR for fixing that on heir spare time - appreciated - this means our 
module is not just "experimental", but just "unstable".

I therefore think it should not sit in our source tree, but be a separate GH 
project. I am willing to host that, review/merge PRs and tag v0.x releases of 
the module there.

Would anyone object to that? Or, the other way around, does anyone here want to 
carry the torch and maintain it in our source tree?

How about an informal vote?

+1: yes, rip it out
+0: no opinion
-1: no, leave it here, I'll take care of it

Cheers,
Stefan

Re: [VOTE] Release httpd-2.4.62-rc1 as httpd-2.4.62

[Stefan Eissing via dev]

> Am 15.07.2024 um 14:13 schrieb Eric Covener :
> 
> 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.62-rc1 as 2.4.62:
> [ ] +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.
> 

+1, macOS 14.5, x86_64

Thanks for the hard work, Eric!

- Stefan

Re: Version-Info in 2.4.x modules/http2/h2_version.h

[Stefan Eissing via dev]

Yeah, tricky with out rtc patch policy. I try to make a full sync now and then. 
This time it became side tracked by Yann as he wants to make mpm:event even 
better...

- Stefan

> Am 10.07.2024 um 18:15 schrieb Rainer Jung :
> 
> Hi all,
> 
> file modules/http2/h2_version.h in 2.4.x contains
> 
> #define MOD_HTTP2_VERSION "2.0.22"
> 
> and
> 
> #define MOD_HTTP2_VERSION_NUM 0x020016
> 
> which differs from upstream
> 
> #define MOD_HTTP2_VERSION "2.0.29-git"
> 
> ...
> 
> #define MOD_HTTP2_VERSION_NUM 0x02001d
> 
> quite a bit. I think the version numbers hasn't been updated after 
> backporting changes for some time. I don't know, what a good value would be, 
> or if it would be better to drop it, but it would be nice, if we wouldn't 
> ship an mod_h2 specific but outdated version number.
> 
> Thanks and regards,
> 
> Rainer
> 

Re: svn commit: r1919087 - in /httpd/httpd/trunk/test: modules/http2/conftest.py modules/http2/env.py modules/http2/test_103_upgrade.py modules/http2/test_600_h2proxy.py modules/http2/test_700_load_ge

[Stefan Eissing via dev]

> Am 10.07.2024 um 18:12 schrieb Rainer Jung :
> 
> Hi Stefan,
> 
> is some of this test stuff ready for 2.4.x?

Synched in r1919126.

> Thanks and regards,
> 
> Rainer
> 
> Am 10.07.24 um 12:55 schrieb ic...@apache.org:
>> Author: icing
>> Date: Wed Jul 10 10:55:23 2024
>> New Revision: 1919087
>> URL: http://svn.apache.org/viewvc?rev=1919087&view=rev
>> Log:
>> sync test code with mod-h2
>> - shutdown server at end of h2 tests
>> - adapt minimum httpd versions for some tests
>> - add test_700_20 for load on blocked connections,
>>   disabled for now until mpm_event improves
>> - build websocket client automatically
>> Modified:
>> httpd/httpd/trunk/test/modules/http2/conftest.py
>> httpd/httpd/trunk/test/modules/http2/env.py
>> httpd/httpd/trunk/test/modules/http2/test_103_upgrade.py
>> httpd/httpd/trunk/test/modules/http2/test_600_h2proxy.py
>> httpd/httpd/trunk/test/modules/http2/test_700_load_get.py
>> httpd/httpd/trunk/test/modules/http2/test_800_websockets.py
>> httpd/httpd/trunk/test/pyhttpd/env.py
>> Modified: httpd/httpd/trunk/test/modules/http2/conftest.py
>> URL: 
>> http://svn.apache.org/viewvc/httpd/httpd/trunk/test/modules/http2/conftest.py?rev=1919087&r1=1919086&r2=1919087&view=diff
>> ==
>> --- httpd/httpd/trunk/test/modules/http2/conftest.py (original)
>> +++ httpd/httpd/trunk/test/modules/http2/conftest.py Wed Jul 10 10:55:23 2024
>> @@ -35,3 +35,5 @@ def _h2_package_scope(env):
>>  'AH10400',  # warning that 'enablereuse' has not effect in certain 
>> configs
>>  'AH00045',  # child did not exit in time, SIGTERM was sent
>>  ])
>> +yield
>> +assert env.apache_stop() == 0
>> Modified: httpd/httpd/trunk/test/modules/http2/env.py
>> URL: 
>> http://svn.apache.org/viewvc/httpd/httpd/trunk/test/modules/http2/env.py?rev=1919087&r1=1919086&r2=1919087&view=diff
>> ==
>> --- httpd/httpd/trunk/test/modules/http2/env.py (original)
>> +++ httpd/httpd/trunk/test/modules/http2/env.py Wed Jul 10 10:55:23 2024
>> @@ -2,6 +2,7 @@ import inspect
>>  import logging
>>  import os
>>  import subprocess
>> +from shutil import copyfile
>>  from typing import Dict, Any
>>from pyhttpd.certs import CertificateSpec
>> @@ -52,6 +53,12 @@ class H2TestSetup(HttpdTestSetup):
>>  with open(os.path.join(self.env.gen_dir, "data-1m"), 'w') as f:
>>  for i in range(1):
>>  f.write(f"{i:09d}-{s90}")
>> +test1_docs = os.path.join(self.env.server_docs_dir, 'test1')
>> +self.env.mkpath(test1_docs)
>> +for fname in ["data-1k", "data-10k", "data-100k", "data-1m"]:
>> +src = os.path.join(self.env.gen_dir, fname)
>> +dest = os.path.join(test1_docs, fname)
>> +copyfile(src, dest)
>>  class H2TestEnv(HttpdTestEnv):
>> Modified: httpd/httpd/trunk/test/modules/http2/test_103_upgrade.py
>> URL: 
>> http://svn.apache.org/viewvc/httpd/httpd/trunk/test/modules/http2/test_103_upgrade.py?rev=1919087&r1=1919086&r2=1919087&view=diff
>> ==
>> --- httpd/httpd/trunk/test/modules/http2/test_103_upgrade.py (original)
>> +++ httpd/httpd/trunk/test/modules/http2/test_103_upgrade.py Wed Jul 10 
>> 10:55:23 2024
>> @@ -90,6 +90,9 @@ class TestUpgrade:
>>  url = env.mkurl("http", "test1", "/index.html")
>>  r = env.nghttp().get(url, options=["-u"])
>>  assert r.response["status"] == 200
>> +# check issue #272
>> +assert 'date' in r.response["header"], f'{r.response}'
>> +assert r.response["header"]["date"] != 'Sun, 00 Jan 1900 00:00:00 
>> GMT', f'{r.response}'
>># upgrade to h2c for a request where http/1.1 is preferred, but the 
>> clients upgrade
>>  # wish is honored nevertheless
>> Modified: httpd/httpd/trunk/test/modules/http2/test_600_h2proxy.py
>> URL: 
>> http://svn.apache.org/viewvc/httpd/httpd/trunk/test/modules/http2/test_600_h2proxy.py?rev=1919087&r1=1919086&r2=1919087&view=diff
>> ==
>> --- httpd/httpd/trunk/test/modules/http2/test_600_h2proxy.py (original)
>> +++ httpd/httpd/trunk/test/modules/http2/test_600_h2proxy.py Wed Jul 10 
>> 10:55:23 2024
>> @@ -79,7 +79,7 @@ class TestH2Proxy:
>>  assert env.apache_restart() == 0
>>  url = env.mkurl("https", "cgi", 
>> f"/h2proxy/{env.http_port}/hello.py")
>>  # httpd 2.5.0 disables reuse, not matter the config
>> -if enable_reuse == "on" and not env.httpd_is_at_least("2.5.0"):
>> +if enable_reuse == "on" and not env.httpd_is_at_least("2.4.60"):
>>  # reuse is not guaranteed for each request, but we expect some
>>  # to do it and run on a h2 stream id > 1
>>  reused = False
>> @@ -132,7 +132,7 @@ c

Re: mod_md in 2.4.61 fails to compile with openssl < 1.1.1

[Stefan Eissing via dev]

> Am 08.07.2024 um 17:07 schrieb Yann Ylavic :
> 
> On Fri, Jul 5, 2024 at 5:59 PM Yann Ylavic  wrote:
>> 
>> On Fri, Jul 5, 2024 at 5:08 PM Ruediger Pluem  wrote:
>>> 
>>> On 7/5/24 4:09 PM, Stefan Eissing via dev wrote:
>>>> 
>>>> The patches look good to me. I have not tested them as I have no old 
>>>> openssl lying around, but I trust in your build tests.
>>> 
>>> Rebuild 2.4.61 with both patches from Yann on RedHat 7 - 9. All good now, 
>>> even on 7 with openssl 1.0.2 (means it compiles and no
>>> more implicit declaration warnings).
>>> @Yann: Care to commit the patches?
>> 
>> Will do on the weekend if/when possible, feel free to beat me to it if
>> you can ;)
> 
> r1919026.

Thanks, Yann!
> 
>> 
>> 
>> Regards;
>> Yann.

Re: mod_md in 2.4.61 fails to compile with openssl < 1.1.1

[Stefan Eissing via dev]

> Am 05.07.2024 um 15:44 schrieb Ruediger Pluem :
> 
> 
> 
> On 7/5/24 3:40 PM, Yann Ylavic wrote:
>> On Fri, Jul 5, 2024 at 3:35 PM Yann Ylavic  wrote:
>>> 
>>> On Fri, Jul 5, 2024 at 3:05 PM Ruediger Pluem  wrote:
 
 md_crypt.c: In function 'md_cert_get_ct_scts':
 md_crypt.c:2071:5: error: unknown type name 'SCT'
SCT *sct_handle;
 
 This one is caused by r1918195 in >= 2.4.60. Before r1918195 OPENSSL_NO_CT 
 was defined when openssl was < 1.1.1. Now it is not any
 longer and hence md_cert_get_ct_scts gets a real function body as
 
 #ifndef OPENSSL_NO_CT
 
 (line 2068) is now true. Hence we error out on the non presence of the SCT 
 struct (line 2071).
>>> 
>>> Maybe something like the attached patch for this one too (which could
>>> avoid configure tricks for both..).
>> 
>> Or rather this one.
>> 
> 
> 
> Looks good to me. Waiting for Stefan's feedback.

The patches look good to me. I have not tested them as I have no old openssl 
lying around, but I trust in your build tests.

Cheers,
Stefan

> 
> Regards
> 
> Rüdiger

Re: mod_md in 2.4.61 fails to compile with openssl < 1.1.1

[Stefan Eissing via dev]

> Am 05.07.2024 um 13:51 schrieb Ruediger Pluem :
> 
> I just noticed that mod_md in 2.4.61 fails to compile with openssl < 1.1.1. 
> Below is the output against openssl 1.0.2 on RedHat 7:
> 
> md_crypt.c: In function 'md_pkey_get_rsa_e64':
> md_crypt.c:982:5: warning: implicit declaration of function 
> 'EVP_PKEY_get0_RSA' [-Wimplicit-function-declaration]
> const RSA *rsa = EVP_PKEY_get0_RSA(pkey->pkey);
> ^
> md_crypt.c:982:22: warning: initialization makes pointer from integer without 
> a cast [enabled by default]
> const RSA *rsa = EVP_PKEY_get0_RSA(pkey->pkey);
>  ^
> md_crypt.c: In function 'md_pkey_get_rsa_n64':
> md_crypt.c:1002:22: warning: initialization makes pointer from integer 
> without a cast [enabled by default]
> const RSA *rsa = EVP_PKEY_get0_RSA(pkey->pkey);
>  ^
> md_crypt.c: In function 'md_cert_get_ct_scts':
> md_crypt.c:2071:5: error: unknown type name 'SCT'
> SCT *sct_handle;
> ^
> In file included from /usr/include/openssl/crypto.h:129:0,
> from /usr/include/openssl/bio.h:69,
> from /usr/include/openssl/err.h:124,
> from md_crypt.c:28:
> md_crypt.c:2084:29: error: 'SCT' undeclared (first use in this function)
>sct_handle = sk_SCT_value(sct_list, i);
> ^
> md_crypt.c:2084:29: note: each undeclared identifier is reported only once 
> for each function it appears in
> md_crypt.c:2084:29: error: expected expression before ')' token
>sct_handle = sk_SCT_value(sct_list, i);
> ^
> md_crypt.c:2087:21: warning: implicit declaration of function 
> 'SCT_get_version' [-Wimplicit-function-declaration]
> sct->version = SCT_get_version(sct_handle);
> ^
> md_crypt.c:2088:21: warning: implicit declaration of function 
> 'SCT_get_timestamp' [-Wimplicit-function-declaration]
> sct->timestamp = 
> apr_time_from_msec(SCT_get_timestamp(sct_handle));
> ^
> md_crypt.c:2089:21: warning: implicit declaration of function 
> 'SCT_get0_log_id' [-Wimplicit-function-declaration]
> len = SCT_get0_log_id(sct_handle, (unsigned char**)&data);
> ^
> md_crypt.c:2091:21: warning: implicit declaration of function 
> 'SCT_get_signature_nid' [-Wimplicit-function-declaration]
> sct->signature_type_nid = 
> SCT_get_signature_nid(sct_handle);
> ^
> md_crypt.c:2092:21: warning: implicit declaration of function 
> 'SCT_get0_signature' [-Wimplicit-function-declaration]
> len = SCT_get0_signature(sct_handle,  (unsigned 
> char**)&data);
> ^
> make[4]: *** [md_crypt.slo] Error 1
> make[4]: *** Waiting for unfinished jobs
> make[4]: Leaving directory 
> `/home/devil/rpmbuild/BUILD/WAO-apache-2.4.61/httpd-2.4.61/modules/md'
> make[3]: *** [shared-build-recursive] Error 1
> make[3]: Leaving directory 
> `/home/devil/rpmbuild/BUILD/WAO-apache-2.4.61/httpd-2.4.61/modules/md'
> make[2]: *** [shared-build-recursive] Error 1
> make[2]: Leaving directory 
> `/home/devil/rpmbuild/BUILD/WAO-apache-2.4.61/httpd-2.4.61/modules'
> make[1]: *** [shared-build-recursive] Error 1
> make[1]: Leaving directory 
> `/home/devil/rpmbuild/BUILD/WAO-apache-2.4.61/httpd-2.4.61'
> make: *** [all-recursive] Error 1
> 
> I am not sure if we can do without these functions or the SCT structure and 
> in the end mod_md is still experimental for 2.4.x.
> But if we want to keep the code of mod_md as is in 2.4.x we probably should 
> add checks in the autoconf stuff that prevents it
> from being enabled on openssl < 1.1.1.

Ok, the code is from 2019, meaning we did not have that combination working for 
a long time. I think checking the openssl version in configure seems the best 
approach.

Cheers,
Stefan

> 
> Regards
> 
> Rüdiger

Re: [VOTE] Release httpd-2.4.61-rc1 as httpd-2.4.61

[Stefan Eissing via dev]

> Am 02.07.2024 um 15:29 schrieb Eric Covener :
> 
> Hi all,
> 
> Please find below the proposed release tarball and signatures:
> 
> https://dist.apache.org/repos/dist/dev/httpd/
> 
> === Different from template ===
> I would like to call an expedited VOTE (due to regression in 2.4.60)
> over the next 1-2 days to release this candidate tarball
> httpd-2.4.61-rc1 as 2.4.61:
> 
> (sorry)
> === end not from a template
> 
> [ ] +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.

+1, macOS 14.5

Thanks for all the hard work put into this, Eric.

- Stefan

Re: [VOTE] Release httpd-2.4.60-rc4 as httpd-2.4.60

[Stefan Eissing via dev]

> Am 26.06.2024 um 19:10 schrieb Eric Covener :
> 
> 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.60-rc4 as 2.4.60:
> [ ] +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.

+1, macOS 14.5, x86_64

Re: [VOTE] Release httpd-2.4.60-rc1 as httpd-2.4.60

[Stefan Eissing via dev]

> Am 24.06.2024 um 20:28 schrieb Eric Covener :
> 
> 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.60-rc1 as 2.4.60:
> [ ] +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.

+1 on macOS 14.5.

Thanks for doing the release work!

- Stefan

Re: httpd-2.4.60-rc1: pytest http2 failures w.r.t. assets

[Stefan Eissing via dev]

> Am 25.06.2024 um 09:43 schrieb Rainer Jung :
> 
> Hi Rüdiger et al.,
> 
> Am 25.06.24 um 08:50 schrieb Ruediger Pluem:
>> On 6/25/24 1:12 AM, Rainer Jung wrote:
>>> I am getting some pytest failures when checking for assets (leading "/" 
>>> missing):
>>> 
>>> === FAILURES 
>>> ===
>>> __ TestAssets.test_h2_006_03 
>>> ___
>>> 
>>> self = 
>>> env = 
>>> 
>>> def test_h2_006_03(self, env):
>>> # create the tiles files we originally had checked in
>>> exp_assets = [
>>> {"status": 200, "size": "10K", "path": "/004.html"},
>>> {"status": 200, "size": "742", "path": "/004/gophertiles.jpg"},
>>> ]
>>> for i in range(2, 181):
>>> with 
>>> open(f"{env.server_docs_dir}/test1/004/gophertiles_{i:03d}.jpg", "w") as fd:
>>> fd.write("0123456789\n")
>>> exp_assets.append(
>>> {"status": 200, "size": "11", "path": 
>>> f"/004/gophertiles_{i:03d}.jpg"},
>>> )
>>> 
>>> url = env.mkurl("https", "test1", "/004.html")
>>> r = env.nghttp().assets(url, options=["-Haccept-encoding: none"])
>>> assert 0 == r.exit_code
>>> assert 181 == len(r.assets)
assert r.assets == exp_assets
>>> E   AssertionError: assert [{'path': '/0...s': 200}, ...] == [{'path': 
>>> '/0...s': 200}, ...]
>>> E At index 1 diff: {'path': '004/gophertiles.jpg', 'status': 200, 
>>> 'size': '742'} != {'status': 200, 'size': '742', 'path':
>>> '/004/gophertiles.jpg'}
>>> E Full diff:
>>> E   [
>>> E{'path': '/004.html', 'size': '10K', 'status': 200},
>>> E -  {'path': '/004/gophertiles.jpg', 'size': '742', 'status': 200},
>>> E ?-
>>> E +  {'path': '004/gophertiles.jpg', 'size': '742', 'status': 
>>> 200},...
>>> E
>>> E ...Full output truncated (539 lines hidden), use '-vv' to show
>>> 
>>> modules/http2/test_006_assets.py:52: AssertionError
>>> - Captured stdout call 
>>> -
>>> execute: nghttp --header=host: test1.tests.httpd.apache.org:5001 
>>> -Haccept-encoding: none -ans https://127.0.0.1:5001//004.html
>>> __ TestAssets.test_h2_006_04 
>>> ___
>>> 
>>> self = 
>>> env = 
>>> 
>>> def test_h2_006_04(self, env):
>>> url = env.mkurl("https", "test1", "/006.html")
>>> r = env.nghttp().assets(url, options=["-Haccept-encoding: none"])
>>> assert 0 == r.exit_code
>>> assert 3 == len(r.assets)
assert r.assets == [
>>> {"status": 200, "size": "543", "path": "/006.html"},
>>> {"status": 200, "size": "216", "path": "/006/006.css"},
>>> {"status": 200, "size": "839", "path": "/006/006.js"}
>>> ]
>>> E   AssertionError: assert [{'path': '/0...status': 200}] == [{'path': 
>>> '/0...status': 200}]
>>> E At index 1 diff: {'path': '006/006.css', 'status': 200, 'size': 
>>> '216'} != {'status': 200, 'size': '216', 'path':
>>> '/006/006.css'}
>>> E Full diff:
>>> E   [
>>> E{'path': '/006.html', 'size': '543', 'status': 200},
>>> E -  {'path': '/006/006.css', 'size': '216', 'status': 200},
>>> E ?-
>>> E +  {'path': '006/006.css', 'size': '216', 'status': 200},...
>>> E
>>> E ...Full output truncated (5 lines hidden), use '-vv' to show
>>> 
>>> modules/http2/test_006_assets.py:60: AssertionError
>>> - Captured stdout call 
>>> -
>>> execute: nghttp --header=host: test1.tests.httpd.apache.org:5001 
>>> -Haccept-encoding: none -ans https://127.0.0.1:5001//006.html
>>> __ TestAssets.test_h2_006_05 
>>> ___
>>> 
>>> self = 
>>> env = 
>>> 
>>> def test_h2_006_05(self, env):
>>> url = env.mkurl("https", "test1", "/003.html")
>>> r = env.nghttp().assets(url, options=["--window-bits=24", 
>>> "-Haccept-encoding: none"])
>>> assert 0 == r.exit_code
>>> assert 2 == len(r.assets)
assert r.assets == [
>>> {"status": 200, "size": "316", "path": "/003.html"},
>>> {"status": 200, "size": "88K", "path": "/003/003_img.jpg"}
>>> ]
>>> E   AssertionError: assert [{'path': '/0...status': 200}] == [{'path': 
>>> '/0...status': 200}]
>>> E At index 1 diff: {'path': '003/003_img.jpg', 'status': 200, 
>>> 'size': '88K'} != {'status': 200, 'size': '88K', 'path':
>>> '/003/003_img.jpg'}
>>> E Full diff:
>>> E   [
>>> E{'path': '/003.html', 'size': '316', 'status': 200},
>>> E -  {'path': '/003/003_img.jpg', 'size': '88K', 'status': 200},
>>> E ?-
>>> E +  {'path': '003/003_img.jpg', 'size': '88K', 's

Re: svn commit: r1918003 - in /httpd/httpd/trunk/modules/http2: h2_c1.c h2_c2.c h2_mplx.c h2_mplx.h h2_session.c h2_session.h h2_version.h

[Stefan Eissing via dev]

> Am 28.05.2024 um 15:45 schrieb Yann Ylavic :
> 
> On Tue, May 28, 2024 at 12:47 PM Stefan Eissing via dev
>  wrote:
>> 
>>> Am 27.05.2024 um 14:08 schrieb Yann Ylavic :
>>> 
>>> Per our discussion the other day, if you want to avoid c1 connections
>>> to be killed by mpm_event on high load in this case, I think you can
>>> do this here:
>>> 
>>> Index: modules/http2/h2_c1.c
>>> ===
>>> --- modules/http2/h2_c1.c(revision 1918003)
>>> +++ modules/http2/h2_c1.c(working copy)
>>> @@ -147,6 +147,7 @@ apr_status_t h2_c1_run(conn_rec *c)
>>> && mpm_state != AP_MPMQ_STOPPING);
>>> 
>>>if (c->cs) {
>>> +c->clogging_input_filters = 0;
>>>switch (conn_ctx->session->state) {
>>>case H2_SESSION_ST_INIT:
>>>case H2_SESSION_ST_IDLE:
>>> @@ -159,6 +160,7 @@ apr_status_t h2_c1_run(conn_rec *c)
>>> * See PR 63534.
>>> */
>>>c->cs->sense = CONN_SENSE_WANT_READ;
>>> +c->clogging_input_filters = 1;
>>>03465}
>>>break;
>>>case H2_SESSION_ST_CLEANUP:
>>> --
>>> 
>>> c->clogging_input_filters = 1 will tell the MPM to always call
>>> process_connection() hooks after the WRITE_COMPLETION state did the
>>> poll(), rather than entering the (killable) keepalive state.
>>> 
>>> Looks like the correct workaround with current mpm_event..
>> 
>> Just so I get this right. It will return to processing after the
>> write is done or after a POLLIN happened? In the first case, it
>> will not have really a positive effect on worker allocations,
>> seems to me.
> 
> Yes, it will return to processing after POLLIN happens thanks to
> CONN_SENSE_WANT_READ, even if there are pending output data.
> But it's a really convoluted handling of POLLIN/POLLOUT in mpm_event,
> with the need of that obscure c->clogging_input_filters..
> So I just created https://github.com/apache/httpd/pull/448 to do that
> better (and it includes the changes to h2_c1_run() too).
> The plan could be to merge that to trunk and include it in your
> backport proposal (if it works for you)?
> 

Great!

> 
> Regards;
> Yann.

Re: svn commit: r1918003 - in /httpd/httpd/trunk/modules/http2: h2_c1.c h2_c2.c h2_mplx.c h2_mplx.h h2_session.c h2_session.h h2_version.h

[Stefan Eissing via dev]

> Am 27.05.2024 um 14:08 schrieb Yann Ylavic :
> 
> On Mon, May 27, 2024 at 1:04 PM  wrote:
>> 
>> Author: icing
>> Date: Mon May 27 11:04:52 2024
>> New Revision: 1918003
>> 
>> URL: http://svn.apache.org/viewvc?rev=1918003&view=rev
>> Log:
>> *) mod_http2: sync with module's github.
>>- on newer HTTPD versions, return connection monitoring
>>  to the event MPM when block on client updates.
>>  2.4.x versions still treat connections in the event
>>  MPM as KeepAlive and purge them on load in the middle
>>  of response processing.
>>- spelling fixes
>>- support for yield calls in c2 "network" filter
> []
>> 
>> --- httpd/httpd/trunk/modules/http2/h2_c1.c (original)
>> +++ httpd/httpd/trunk/modules/http2/h2_c1.c Mon May 27 11:04:52 2024
>> @@ -116,7 +116,7 @@ cleanup:
>> apr_status_t h2_c1_run(conn_rec *c)
>> {
>> apr_status_t status;
>> -int mpm_state = 0;
>> +int mpm_state = 0, keepalive = 0;
>> h2_conn_ctx_t *conn_ctx = h2_conn_ctx_get(c);
>> 
>> ap_assert(conn_ctx);
>> @@ -127,7 +127,7 @@ apr_status_t h2_c1_run(conn_rec *c)
>> c->cs->state = CONN_STATE_HANDLER;
>> }
>> 
>> -status = h2_session_process(conn_ctx->session, async_mpm);
>> +status = h2_session_process(conn_ctx->session, async_mpm, 
>> &keepalive);
>> 
>> if (APR_STATUS_IS_EOF(status)) {
>> ap_log_cerror(APLOG_MARK, APLOG_DEBUG, status, c,
>> @@ -153,7 +153,7 @@ apr_status_t h2_c1_run(conn_rec *c)
>> case H2_SESSION_ST_BUSY:
>> case H2_SESSION_ST_WAIT:
>> c->cs->state = CONN_STATE_WRITE_COMPLETION;
>> -if (c->cs && !conn_ctx->session->remote.emitted_count) {
>> +if (!keepalive) {
>> /* let the MPM know that we are not done and want
>>  * the Timeout behaviour instead of a KeepAliveTimeout
>>  * See PR 63534.
> 
> Per our discussion the other day, if you want to avoid c1 connections
> to be killed by mpm_event on high load in this case, I think you can
> do this here:
> 
> Index: modules/http2/h2_c1.c
> ===
> --- modules/http2/h2_c1.c(revision 1918003)
> +++ modules/http2/h2_c1.c(working copy)
> @@ -147,6 +147,7 @@ apr_status_t h2_c1_run(conn_rec *c)
>  && mpm_state != AP_MPMQ_STOPPING);
> 
> if (c->cs) {
> +c->clogging_input_filters = 0;
> switch (conn_ctx->session->state) {
> case H2_SESSION_ST_INIT:
> case H2_SESSION_ST_IDLE:
> @@ -159,6 +160,7 @@ apr_status_t h2_c1_run(conn_rec *c)
>  * See PR 63534.
>  */
> c->cs->sense = CONN_SENSE_WANT_READ;
> +c->clogging_input_filters = 1;
> }
> break;
> case H2_SESSION_ST_CLEANUP:
> --
> 
> c->clogging_input_filters = 1 will tell the MPM to always call
> process_connection() hooks after the WRITE_COMPLETION state did the
> poll(), rather than entering the (killable) keepalive state.
> 
> Looks like the correct workaround with current mpm_event..

Just so I get this right. It will return to processing after the 
write is done or after a POLLIN happened? In the first case, it
will not have really a positive effect on worker allocations, 
seems to me.

Cheers,
Stefan
> 
> 
> Regards;
> Yann.

Re: more async handling in mod_h2

[Stefan Eissing via dev]

> Am 13.05.2024 um 22:49 schrieb Yann Ylavic :
> 
> On Mon, May 13, 2024 at 9:02 PM Yann Ylavic  wrote:
>> 
>> On Mon, May 13, 2024 at 6:31 PM Stefan Eissing  wrote:
>>> 
>>>> Am 13.05.2024 um 17:41 schrieb Yann Ylavic :
>>>> 
>>>> On Mon, May 13, 2024 at 1:32 PM Stefan Eissing
>>>>> 
>>>>> With the change in PR 280, we return on being flow blocked. The 
>>>>> response(s) are *not* finished. If MPM now closes such a connection under 
>>>>> load, the client will most likely try again. This seems counter 
>>>>> productive.
>>>> 
>>>> AFAICT the CONN_STATE_WRITE_COMPLETION state is different depending on
>>>> CONN_SENSE_WANT_READ and CONN_SENSE_WANT_WRITE/DEFAULT.
>>>> With CONN_SENSE_WANT_WRITE/DEFAULT, mpm_event will indeed assume flush
>>>> (nonblocking) before close,
>> 
>> It's actually a flush before *keepalive* (unless !AP_CONN_KEEPALIVE),
>> though it's not what you want anyway.
>> 
>>>> but with CONN_SENSE_WANT_READ it will poll
>>>> for read on the connection and come back to the process_connection
>>>> hooks when something is in.
>>>> 
>>>> When mod_h2 waits for some WINDOW_UPDATE it wants the MPM to POLLIN
>>>> (right?), h2_c1_hook_process_connection() should recover/continue with
>>>> the new data from the client. And since it's a c1 connection I don't
>>>> think there needs to be some new pollset/queues sizing adjustment to
>>>> do either, so we should be good?
>>> 
>>> Yes, mod_h2 does CONN_STATE_WRITE_COMPLETION and CONN_SENSE_WANT_READ and 
>>> it works nicely. The only thing is that, when I open many connections, 
>>> unfinished ones get dropped very fast. Like after a few milliseconds.
>> 
>> What do you mean by unfinished ones, which state are they in (i.e. how
>> do they end up in the MPM with a keepalive state which is the only one
>> where connections are "early" killed under high load)?
>> I think this can only happen when mpm_event gets a connection with
>> c->cs->state == CONN_STATE_WRITE_COMPLETION but c->cs->sense !=
>> CONN_SENSE_WANT_READ, is that a mod_h2 possible thing?
> 
> Hm, I think I figured this out by myself.
> As I said above CONN_STATE_WRITE_COMPLETION leads to
> CONN_STATE_CHECK_REQUEST_LINE_READABLE (i.e keepalive state) once the
> completion is done (or the POLLIN with c->cs->sense ==
> CONN_SENSE_WANT_READ) and if there is no input data already pending.
> This is really not what mod_h2 wants but rather
> ap_run_process_connection() to always be called after POLLIN.
> We could handle that specifically for the CONN_SENSE_WANT_READ case
> but it's yet more abuse of CONN_STATE_WRITE_COMPLETION imho.
> Let's see how CONN_STATE_PROCESS (from PR 294 below) works to take the
> relevant bits in trunk eventually.
> 
>> 
>>>>> 
>>>>> Therefore I am hesitant if this change is beneficial for us. It frees up 
>>>>> a worker thread - that is good - but. Do we need a new "connection state" 
>>>>> here?
>>>>> 
>>>>> WDYT?
>>>> 
>>>> I think the semantics of CONN_STATE_WRITE_COMPLETION with
>>>> CONN_SENSE_WANT_* are quite unintuitive (for the least), so we
>>>> probably should have different states for CONN_STATE_WRITE_COMPLETION
>>>> (flush before close) and CONN_STATE_POLL_READ/POLL_WRITE/POLL_RW which
>>>> would be how a process_connection hook would return to the MPM just
>>>> for poll()ing.
>>> 
>>> I think that would be excellent, yes. Trigger polling with the connection 
>>> Timeout value.
>> 
>> There is https://github.com/apache/httpd/pull/294 with quite some
>> changes to mpm_event. Sorry this is still WIP and needs to be split
>> more, probably in multiple PRs too, but it works for the tests I've
>> done so far (I just rebased it on latest trunk).
>> This change starts with Graham's AGAIN return code (from
>> process_connection hooks) for letting the MPM do the polling for SSL
>> handshakes that'd block for instance. It then expanded to a
>> CONN_STATE_PROCESS state (renamed from CONN_STATE_READ_REQUEST_LINE)
>> where mpm_event receiving AGAIN from ap_run_process_connection() will
>> simply poll according to the c->cs->sense value
>> (WANT_READ/WANT_WRITE).
>> This PR also removes all keepalive kills, though I don't think mod_h2
>> should rely 

Re: more async handling in mod_h2

[Stefan Eissing via dev]

> Am 13.05.2024 um 17:41 schrieb Yann Ylavic :
> 
> On Mon, May 13, 2024 at 1:32 PM Stefan Eissing via dev
>  wrote:
>> 
>> I have merged https://github.com/icing/mod_h2/pull/280 to the mod-h2 on 
>> github. With mpm_event, this will return HTTP/2 connections more often to 
>> the mpm, thus freeing a worker.
>> 
>> While this sounds good, I am not sure this is beneficial for a server under 
>> load. The current connection state handling is designed for HTTP/1.x where a 
>> connection is "given back" to the MPM at the end of a request.
>> 
>> AFAICT, the MPM assumes that, once any pending output is written, it may 
>> close the connection under load. Because in HTTP/1.x it means the connection 
>> has served the last response completely. The client should be grateful and 
>> cope well with the connection being closed subsequently due to other clients 
>> demands.
>> 
>> In HTTP/2 so far, we did return to the MPM only when all requests had been 
>> served. The connection is therefore really in a similar state to HTTP/1.x. 
>> The client has got its responses, we are free to close.
>> 
>> With the change in PR 280, we return on being flow blocked. The response(s) 
>> are *not* finished. If MPM now closes such a connection under load, the 
>> client will most likely try again. This seems counter productive.
> 
> AFAICT the CONN_STATE_WRITE_COMPLETION state is different depending on
> CONN_SENSE_WANT_READ and CONN_SENSE_WANT_WRITE/DEFAULT.
> With CONN_SENSE_WANT_WRITE/DEFAULT, mpm_event will indeed assume flush
> (nonblocking) before close, but with CONN_SENSE_WANT_READ it will poll
> for read on the connection and come back to the process_connection
> hooks when something is in.
> 
> When mod_h2 waits for some WINDOW_UPDATE it wants the MPM to POLLIN
> (right?), h2_c1_hook_process_connection() should recover/continue with
> the new data from the client. And since it's a c1 connection I don't
> think there needs to be some new pollset/queues sizing adjustment to
> do either, so we should be good?

Yes, mod_h2 does CONN_STATE_WRITE_COMPLETION and CONN_SENSE_WANT_READ and it 
works nicely. The only thing is that, when I open many connections, unfinished 
ones get dropped very fast. Like after a few milliseconds.

> 
>> 
>> Therefore I am hesitant if this change is beneficial for us. It frees up a 
>> worker thread - that is good - but. Do we need a new "connection state" here?
>> 
>> WDYT?
> 
> I think the semantics of CONN_STATE_WRITE_COMPLETION with
> CONN_SENSE_WANT_* are quite unintuitive (for the least), so we
> probably should have different states for CONN_STATE_WRITE_COMPLETION
> (flush before close) and CONN_STATE_POLL_READ/POLL_WRITE/POLL_RW which
> would be how a process_connection hook would return to the MPM just
> for poll()ing.

I think that would be excellent, yes. Trigger polling with the connection 
Timeout value.

Cheers,
Stefan

> 
> Regards;
> Yann.

Re: more async handling in mod_h2

[Stefan Eissing via dev]

> Am 13.05.2024 um 13:56 schrieb Eric Covener :
> 
> On Mon, May 13, 2024 at 7:32 AM Stefan Eissing via dev
>  wrote:
>> 
>> I have merged https://github.com/icing/mod_h2/pull/280 to the mod-h2 on 
>> github. With mpm_event, this will return HTTP/2 connections more often to 
>> the mpm, thus freeing a worker.
>> 
>> While this sounds good, I am not sure this is beneficial for a server under 
>> load. The current connection state handling is designed for HTTP/1.x where a 
>> connection is "given back" to the MPM at the end of a request.
>> 
>> AFAICT, the MPM assumes that, once any pending output is written, it may 
>> close the connection under load. Because in HTTP/1.x it means the connection 
>> has served the last response completely. The client should be grateful and 
>> cope well with the connection being closed subsequently due to other clients 
>> demands.
>> 
>> In HTTP/2 so far, we did return to the MPM only when all requests had been 
>> served. The connection is therefore really in a similar state to HTTP/1.x. 
>> The client has got its responses, we are free to close.
>> 
>> With the change in PR 280, we return on being flow blocked. The response(s) 
>> are *not* finished. If MPM now closes such a connection under load, the 
>> client will most likely try again. This seems counter productive.
>> 
>> Therefore I am hesitant if this change is beneficial for us. It frees up a 
>> worker thread - that is good - but. Do we need a new "connection state" here?
> 
> We have CONN_STATE_SUSPENDED too.  These are all but forgotten by the
> MPM until something changes their state back.
> You may see some references to PT_USER that got backported in
> comments, but that is trunk-only.
> PT_USER is about how something gets help un-suspending. In the case of
> H2, I guess the non-worker thread knows/should know when it could
> resume a request already?

In this case, HTTP/2 is only waiting for a POLLIN on the connection's socket. 
No progress can be made until that happens or the connections Timeout occurs.

> 
> ./modules/test/mod_dialup.c is a sample-ish program that uses
> SUSPENDED to not tie up a thread while it sleeps
> In trunk, modules/proxy/mod_proxy_wstunnel.c and mod_proxy_http use it
> to avoid an idle tunnel tieing up a thread.

more async handling in mod_h2

[Stefan Eissing via dev]

I have merged https://github.com/icing/mod_h2/pull/280 to the mod-h2 on github. 
With mpm_event, this will return HTTP/2 connections more often to the mpm, thus 
freeing a worker.

While this sounds good, I am not sure this is beneficial for a server under 
load. The current connection state handling is designed for HTTP/1.x where a 
connection is "given back" to the MPM at the end of a request.

AFAICT, the MPM assumes that, once any pending output is written, it may close 
the connection under load. Because in HTTP/1.x it means the connection has 
served the last response completely. The client should be grateful and cope 
well with the connection being closed subsequently due to other clients demands.

In HTTP/2 so far, we did return to the MPM only when all requests had been 
served. The connection is therefore really in a similar state to HTTP/1.x. The 
client has got its responses, we are free to close.

With the change in PR 280, we return on being flow blocked. The response(s) are 
*not* finished. If MPM now closes such a connection under load, the client will 
most likely try again. This seems counter productive.

Therefore I am hesitant if this change is beneficial for us. It frees up a 
worker thread - that is good - but. Do we need a new "connection state" here?

WDYT?



Cheers,
Stefan

mod_tls in 2.4.x - remove?

[Stefan Eissing via dev]

mod_tls is experimental in 2.4.x. The rustls project, initially wanting to stay 
backward compatible to the v0.10.x API, has change its mind and no longer 
guarantees any stability in future versions. In fact, they have changed the API 
already, making mod_tls no longer viable. 

I personally do not have the time to chase after this. If no one else has 
interests (and I don't know of anyone using it - else, speak up), I propose to 
remove it from the 2.4.x branch again.

Kind Regards,
Stefan

Re: pytest test/modules/md/test_310_conf_store.py

[Stefan Eissing via dev]

In trunk or 2.4.x? I trunk I thought I'd fixed that.

> Am 09.04.2024 um 19:06 schrieb jean-frederic clere :
> 
> Hi,
> 
> Has anyone run those tests recently?
> 
> I have errors like "MD testdomain.org does not match any VirtualHost with 
> ...", probably I am doing something wrong...
> -- 
> Cheers
> 
> Jean-Frederic

Re: Problem with pypest and pebble 2.5.1

[Stefan Eissing via dev]

r1916861 updates to mod_md v2.4.26 and I adapted tests for Pebble v2.5.

Sadly, this means disabling the EAB tests for now as Pebble no longer 
supports the EAB keys we test with. 
Opened issue https://github.com/letsencrypt/pebble/issues/455

Hope this works for you as well,

Stefan

> Am 08.04.2024 um 11:02 schrieb Stefan Eissing via dev :
> 
> Looking into this now, see what pebble changed.
> 
>> Am 07.04.2024 um 17:56 schrieb Rainer Jung :
>> 
>> Hi there,
>> 
>> I tried to check, whether the few remaining sporadic test failures during 
>> pytest can be solved by updating pebble form 2.4.0 to 2.5.1 (which seems to 
>> be the same as 2.5.0).
>> 
>> Unfortunately I get a lot of FAILED md tests with that version. Does anyone 
>> see the same?
>> 
>> Here's some more detailed info:
>> 
>> 17:10:10.216348 
>> modules/md/test_502_acmev2_drive.py::TestDrivev2::test_md_502_100
>> 17:10:10.216348 
>> modules/md/test_502_acmev2_drive.py::TestDrivev2::test_md_502_101
>> 17:10:10.216348 
>> modules/md/test_502_acmev2_drive.py::TestDrivev2::test_md_502_103
>> 17:10:10.216348 
>> modules/md/test_502_acmev2_drive.py::TestDrivev2::test_md_502_105
>> 17:10:10.216348 
>> modules/md/test_502_acmev2_drive.py::TestDrivev2::test_md_502_107
>> 17:10:10.216348 
>> modules/md/test_502_acmev2_drive.py::TestDrivev2::test_md_502_108
>> 17:10:10.216348 
>> modules/md/test_502_acmev2_drive.py::TestDrivev2::test_md_502_200
>> 17:10:10.216348 
>> modules/md/test_602_roundtrip.py::TestRoundtripv2::test_md_602_000
>> 17:10:10.216348 
>> modules/md/test_602_roundtrip.py::TestRoundtripv2::test_md_602_001
>> 17:10:10.216529 
>> modules/md/test_602_roundtrip.py::TestRoundtripv2::test_md_602_002
>> 17:10:10.216529 modules/md/test_702_auto.py::TestAutov2::test_md_702_001
>> 17:10:10.216529 modules/md/test_702_auto.py::TestAutov2::test_md_702_002
>> 17:10:10.216529 modules/md/test_702_auto.py::TestAutov2::test_md_702_003
>> 17:10:10.216529 
>> modules/md/test_702_auto.py::TestAutov2::test_md_702_004[tls-alpn-01]
>> 17:10:10.216529 
>> modules/md/test_702_auto.py::TestAutov2::test_md_702_004[http-01]
>> 17:10:10.216529 modules/md/test_702_auto.py::TestAutov2::test_md_702_030
>> 17:10:10.216529 modules/md/test_702_auto.py::TestAutov2::test_md_702_031
>> 17:10:10.216529 modules/md/test_702_auto.py::TestAutov2::test_md_702_032
>> 17:10:10.216529 modules/md/test_702_auto.py::TestAutov2::test_md_702_040
>> 17:10:10.216529 
>> modules/md/test_702_auto.py::TestAutov2::test_md_702_044[tls-alpn-01]
>> 17:10:10.216529 
>> modules/md/test_720_wildcard.py::TestWildcard::test_md_720_002b
>> 17:10:10.216529 
>> modules/md/test_720_wildcard.py::TestWildcard::test_md_720_004
>> 17:10:10.216529 
>> modules/md/test_720_wildcard.py::TestWildcard::test_md_720_005
>> 17:10:10.216529 
>> modules/md/test_720_wildcard.py::TestWildcard::test_md_720_006
>> 17:10:10.216529 
>> modules/md/test_720_wildcard.py::TestWildcard::test_md_720_007
>> 17:10:10.216529 modules/md/test_750_eab.py::TestEab::test_md_750_003
>> 17:10:10.216529 modules/md/test_750_eab.py::TestEab::test_md_750_004
>> 17:10:10.216529 modules/md/test_750_eab.py::TestEab::test_md_750_005
>> 17:10:10.216529 modules/md/test_750_eab.py::TestEab::test_md_750_010
>> 17:10:10.216529 modules/md/test_750_eab.py::TestEab::test_md_750_011
>> 17:10:10.216529 modules/md/test_750_eab.py::TestEab::test_md_750_012
>> 17:10:10.216529 modules/md/test_750_eab.py::TestEab::test_md_750_013
>> 17:10:10.216529 modules/md/test_750_eab.py::TestEab::test_md_750_014
>> 17:10:10.216529 modules/md/test_750_eab.py::TestEab::test_md_750_015
>> 17:10:10.216529 modules/md/test_750_eab.py::TestEab::test_md_750_016
>> 17:10:10.216529 modules/md/test_750_eab.py::TestEab::test_md_750_022
>> 
>> The failures in test_750_eab.py seem to be related to the following HS256 
>> error messages in the httpd error log:
>> 
>> [Sun Apr 07 17:13:24.571712 2024] [watchdog:debug] [pid 5554:tid 
>> 140101761058560] mod_watchdog.c(170): AH02972: Singleton Watchdog 
>> (_md_renew_) running
>> [Sun Apr 07 17:13:24.571824 2024] [md:debug] [pid 5554:tid 140101761058560] 
>> mod_md_drive.c(203): AH10054: md watchdog start, auto drive 1 mds
>> [Sun Apr 07 17:13:24.672025 2024] [md:debug] [pid 5554:tid 140101761058560] 
>> mod_md_drive.c(208): AH10055: md watchdog run, auto drive 1 mds
>> [Sun Apr 07 17:13:24.672112 2024] [md:debug] [pid 5554:tid 140101761058560] 
>> mod_md_drive.c(109): AH10052: md(test-md-750-003-1712502785.org): state=1, 
>> driving
>> [Su

Re: Problem with pypest and pebble 2.5.1

[Stefan Eissing via dev]

Looking into this now, see what pebble changed.

> Am 07.04.2024 um 17:56 schrieb Rainer Jung :
> 
> Hi there,
> 
> I tried to check, whether the few remaining sporadic test failures during 
> pytest can be solved by updating pebble form 2.4.0 to 2.5.1 (which seems to 
> be the same as 2.5.0).
> 
> Unfortunately I get a lot of FAILED md tests with that version. Does anyone 
> see the same?
> 
> Here's some more detailed info:
> 
> 17:10:10.216348 
> modules/md/test_502_acmev2_drive.py::TestDrivev2::test_md_502_100
> 17:10:10.216348 
> modules/md/test_502_acmev2_drive.py::TestDrivev2::test_md_502_101
> 17:10:10.216348 
> modules/md/test_502_acmev2_drive.py::TestDrivev2::test_md_502_103
> 17:10:10.216348 
> modules/md/test_502_acmev2_drive.py::TestDrivev2::test_md_502_105
> 17:10:10.216348 
> modules/md/test_502_acmev2_drive.py::TestDrivev2::test_md_502_107
> 17:10:10.216348 
> modules/md/test_502_acmev2_drive.py::TestDrivev2::test_md_502_108
> 17:10:10.216348 
> modules/md/test_502_acmev2_drive.py::TestDrivev2::test_md_502_200
> 17:10:10.216348 
> modules/md/test_602_roundtrip.py::TestRoundtripv2::test_md_602_000
> 17:10:10.216348 
> modules/md/test_602_roundtrip.py::TestRoundtripv2::test_md_602_001
> 17:10:10.216529 
> modules/md/test_602_roundtrip.py::TestRoundtripv2::test_md_602_002
> 17:10:10.216529 modules/md/test_702_auto.py::TestAutov2::test_md_702_001
> 17:10:10.216529 modules/md/test_702_auto.py::TestAutov2::test_md_702_002
> 17:10:10.216529 modules/md/test_702_auto.py::TestAutov2::test_md_702_003
> 17:10:10.216529 
> modules/md/test_702_auto.py::TestAutov2::test_md_702_004[tls-alpn-01]
> 17:10:10.216529 
> modules/md/test_702_auto.py::TestAutov2::test_md_702_004[http-01]
> 17:10:10.216529 modules/md/test_702_auto.py::TestAutov2::test_md_702_030
> 17:10:10.216529 modules/md/test_702_auto.py::TestAutov2::test_md_702_031
> 17:10:10.216529 modules/md/test_702_auto.py::TestAutov2::test_md_702_032
> 17:10:10.216529 modules/md/test_702_auto.py::TestAutov2::test_md_702_040
> 17:10:10.216529 
> modules/md/test_702_auto.py::TestAutov2::test_md_702_044[tls-alpn-01]
> 17:10:10.216529 
> modules/md/test_720_wildcard.py::TestWildcard::test_md_720_002b
> 17:10:10.216529 modules/md/test_720_wildcard.py::TestWildcard::test_md_720_004
> 17:10:10.216529 modules/md/test_720_wildcard.py::TestWildcard::test_md_720_005
> 17:10:10.216529 modules/md/test_720_wildcard.py::TestWildcard::test_md_720_006
> 17:10:10.216529 modules/md/test_720_wildcard.py::TestWildcard::test_md_720_007
> 17:10:10.216529 modules/md/test_750_eab.py::TestEab::test_md_750_003
> 17:10:10.216529 modules/md/test_750_eab.py::TestEab::test_md_750_004
> 17:10:10.216529 modules/md/test_750_eab.py::TestEab::test_md_750_005
> 17:10:10.216529 modules/md/test_750_eab.py::TestEab::test_md_750_010
> 17:10:10.216529 modules/md/test_750_eab.py::TestEab::test_md_750_011
> 17:10:10.216529 modules/md/test_750_eab.py::TestEab::test_md_750_012
> 17:10:10.216529 modules/md/test_750_eab.py::TestEab::test_md_750_013
> 17:10:10.216529 modules/md/test_750_eab.py::TestEab::test_md_750_014
> 17:10:10.216529 modules/md/test_750_eab.py::TestEab::test_md_750_015
> 17:10:10.216529 modules/md/test_750_eab.py::TestEab::test_md_750_016
> 17:10:10.216529 modules/md/test_750_eab.py::TestEab::test_md_750_022
> 
> The failures in test_750_eab.py seem to be related to the following HS256 
> error messages in the httpd error log:
> 
> [Sun Apr 07 17:13:24.571712 2024] [watchdog:debug] [pid 5554:tid 
> 140101761058560] mod_watchdog.c(170): AH02972: Singleton Watchdog 
> (_md_renew_) running
> [Sun Apr 07 17:13:24.571824 2024] [md:debug] [pid 5554:tid 140101761058560] 
> mod_md_drive.c(203): AH10054: md watchdog start, auto drive 1 mds
> [Sun Apr 07 17:13:24.672025 2024] [md:debug] [pid 5554:tid 140101761058560] 
> mod_md_drive.c(208): AH10055: md watchdog run, auto drive 1 mds
> [Sun Apr 07 17:13:24.672112 2024] [md:debug] [pid 5554:tid 140101761058560] 
> mod_md_drive.c(109): AH10052: md(test-md-750-003-1712502785.org): state=1, 
> driving
> [Sun Apr 07 17:13:24.672491 2024] [md:debug] [pid 5554:tid 140101761058560] 
> md_reg.c(1112): test-md-750-003-1712502785.org: init done
> [Sun Apr 07 17:13:24.672512 2024] [md:debug] [pid 5554:tid 140101761058560] 
> md_reg.c(1157): test-md-750-003-1712502785.org: run staging
> [Sun Apr 07 17:13:24.672553 2024] [md:debug] [pid 5554:tid 140101761058560] 
> md_acme_drive.c(714): test-md-750-003-1712502785.org: staging started, 
> state=1, attempt=0, acme=https://localhost:14000/dir, challenges='http-01'
> [Sun Apr 07 17:13:24.672755 2024] [md:debug] [pid 5554:tid 140101761058560] 
> md_acme_drive.c(752): test-md-750-003-1712502785.org: setup staging
> [Sun Apr 07 17:13:24.673058 2024] [md:debug] [pid 5554:tid 140101761058560] 
> md_acme.c(776): get directory from https://localhost:14000/dir
> [Sun Apr 07 17:13:24.686700 2024] [md:debug] [pid 5554:tid 140101761058560] 
> md_acmev2_drive.c(101): test-md-750-003-1712502785.org: (ACMEv2) need 
> certifica

Re: svn commit: r1916809 - in /httpd/httpd/branches/2.4.x: ./ test/modules/http2/test_800_websockets.py

[Stefan Eissing via dev]

Many thanks Rainer, for making this work in more diverse setups.

> Am 05.04.2024 um 00:48 schrieb rj...@apache.org:
> 
> Author: rjung
> Date: Thu Apr  4 22:48:03 2024
> New Revision: 1916809
> 
> URL: http://svn.apache.org/viewvc?rev=1916809&view=rev
> Log:
> Fix occasional pytest failures
> in modules/http2/test_800_websockets.py
> (test_h2_800_04_non_ws_resource and
> test_h2_800_09b_unsupported) due to
> additional RST messages.
> 
> Backport of r1916808 from trunk.
> 
> Modified:
>httpd/httpd/branches/2.4.x/   (props changed)
>httpd/httpd/branches/2.4.x/test/modules/http2/test_800_websockets.py
> 
> Propchange: httpd/httpd/branches/2.4.x/
> --
>  Merged /httpd/httpd/trunk:r1916808
> 
> Modified: httpd/httpd/branches/2.4.x/test/modules/http2/test_800_websockets.py
> URL: 
> http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/test/modules/http2/test_800_websockets.py?rev=1916809&r1=1916808&r2=1916809&view=diff
> ==
> --- httpd/httpd/branches/2.4.x/test/modules/http2/test_800_websockets.py 
> (original)
> +++ httpd/httpd/branches/2.4.x/test/modules/http2/test_800_websockets.py Thu 
> Apr  4 22:48:03 2024
> @@ -175,7 +175,7 @@ class TestWebSockets:
> def test_h2_800_04_non_ws_resource(self, env: H2TestEnv, ws_server):
> r, infos, frames = ws_run(env, path='/alive.json')
> assert r.exit_code == 0, f'{r}'
> -assert infos == ['[1] :status: 502', '[1] EOF'], f'{r}'
> +assert infos == ['[1] :status: 502', '[1] EOF'] or infos == ['[1] 
> :status: 502', '[1] EOF', '[1] RST'], f'{r}'
> assert frames == b''
> 
> # CONNECT to a URL path that sends a delayed HTTP response body
> @@ -215,7 +215,7 @@ class TestWebSockets:
> r, infos, frames = ws_run(env, path='/ws/echo/',
>   
> authority=f'test1.{env.http_tld}:{env.http_port}')
> assert r.exit_code == 0, f'{r}'
> -assert infos == ['[1] :status: 501', '[1] EOF'], f'{r}'
> +assert infos == ['[1] :status: 501', '[1] EOF'] or infos == ['[1] 
> :status: 501', '[1] EOF', '[1] RST'], f'{r}'
> 
> # CONNECT and exchange a PING
> def test_h2_800_10_ws_ping(self, env: H2TestEnv, ws_server):
> 
> 

Re: [VOTE] Release httpd-2.4.59-rc1 as httpd-2.4.59

[Stefan Eissing via dev]

> Am 04.04.2024 um 16:22 schrieb jean-frederic clere :
> 
> On 4/4/24 13:59, SteffenAL wrote:
>> Thanks for the hint.
>> Yep, needed an extra include. Not using cmake.
>> mod_http2 shows still version 2.0.22 (h2_version.h).
>> Should it be 2.0.26 ?
> 
> or better 2.0.27? ;-)
> 
> We picked the fixes but not version...

Yeah, saw that too late. But with the secret code whisking around...we'll fix 
it in the next version. No harm done really.

> 
>> Steffen
>> On Thursday 04/04/2024 at 13:25, jean-frederic clere  wrote:
>>> On 4/4/24 12:49, Steffen Land wrote:
 
 -1
 Get an error:
 ErrorC2065'DAV_WALKTYPE_TOLERANT': undeclared identifier
 mod_dav_fsC:\VS17\Win32\httpd-2.4\modules\dav\fs\repos.c1599
>>> 
>>> I didn't see any problem while building on windows (using cmake and VS19).
>>> 
>>> +++
>>> ModeLastWriteTime Length Name
>>> - -- 
>>> -a 4/3/2024   7:56 AM 101376 mod_dav.so
>>> -a 4/3/2024   7:56 AM  51200 mod_dav_fs.so
>>> -a 4/3/2024   7:56 AM  23552 mod_dav_lock.so
>>> +++
>>> 
>>> DAV_WALKTYPE_TOLERANT is in ./modules/dav/main/mod_dav.h line 1826
>>> 
 
 Steffen
 On 2024/04/03 12:26:09 Eric Covener wrote:
> 
> Hi all,
> 
> (After only minor embarrassment of patching tags/2.4.55 instead of 
> 2.4.x...)
> 
> Please find below the proposed release tarball and signatures:
> 
> https://dist.apache.org/repos/dist/dev/httpd/
> 
> 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.
> 
> The computed digests of the tarball up for vote are:
> = e4ec4ce12c6c8f5a794dc2263d126cb1d6ef667f034c4678ec945d61286e8b0f
> = 
> baa96a7c9bba48f758ca9b3e3d63f0c65db960653618109d4d7bcbf3d4776d1d51453beb65e5af57655f0b1cfb88913842bc3a117fe7acc754ddb43d4524bc82
> 
> The SVN candidate source is found at tags/2.4.59-rc1-candidate.
> 
>>> 
>>> -- 
>>> Cheers
>>> 
>>> Jean-Frederic
>>> 
> 
> -- 
> Cheers
> 
> Jean-Frederic
> 

Re: [VOTE] Release httpd-2.4.59-rc1 as httpd-2.4.59

[Stefan Eissing via dev]

> Am 03.04.2024 um 14:26 schrieb Eric Covener :
> 
> Hi all,
> 
> (After only minor embarrassment of patching tags/2.4.55 instead of 2.4.x...)
> 
> Please find below the proposed release tarball and signatures:
> 
> https://dist.apache.org/repos/dist/dev/httpd/
> 
> 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.
> 
> The computed digests of the tarball up for vote are:
> = e4ec4ce12c6c8f5a794dc2263d126cb1d6ef667f034c4678ec945d61286e8b0f
> = 
> baa96a7c9bba48f758ca9b3e3d63f0c65db960653618109d4d7bcbf3d4776d1d51453beb65e5af57655f0b1cfb88913842bc3a117fe7acc754ddb43d4524bc82
> 
> The SVN candidate source is found at tags/2.4.59-rc1-candidate.

+1 (macOS, 23.4.0, x86_64)

Thanks,
Stefan

Re: using changes-entries or write in CHANGES directly

[Stefan Eissing via dev]

> Am 14.02.2024 um 10:53 schrieb jean-frederic clere :
> 
> Hi,
> 
> Are there any rules to use changes-entries or write directly in CHANGES?

Files in changes-entries make it easier to backport, as they will be no 
conflicts.

> 
> -- 
> Cheers
> 
> Jean-Frederic

Re: svn commit: r1915387 - /httpd/httpd/trunk/README

[Stefan Eissing via dev]

Thanks!

> Am 24.01.2024 um 22:33 schrieb rbo...@apache.org:
> 
> Author: rbowen
> Date: Wed Jan 24 21:33:30 2024
> New Revision: 1915387
> 
> URL: http://svn.apache.org/viewvc?rev=1915387&view=rev
> Log:
> Converts README to markdown (no textual changes) for better display on
> Github.
> 
> Submitted by: Mayank Patil (mayank-2...@users.noreply.github.com)
> 
> Patch modified to preserve original linebreaks.
> 
> Github: closes #363
> 
> Modified:
>httpd/httpd/trunk/README
> 
> Modified: httpd/httpd/trunk/README
> URL: 
> http://svn.apache.org/viewvc/httpd/httpd/trunk/README?rev=1915387&r1=1915386&r2=1915387&view=diff
> ==
> --- httpd/httpd/trunk/README (original)
> +++ httpd/httpd/trunk/README Wed Jan 24 21:33:30 2024
> @@ -1,110 +1,106 @@
> 
> -  Apache HTTP Server
> +# Apache HTTP Server
> 
> -  What is it?
> -  ---
> +##  What is it?
> 
> -  The Apache HTTP Server is a powerful and flexible HTTP/1.1 compliant
> -  web server.  Originally designed as a replacement for the NCSA HTTP
> -  Server, it has grown to be the most popular web server on the
> -  Internet.  As a project of the Apache Software Foundation, the
> -  developers aim to collaboratively develop and maintain a robust,
> -  commercial-grade, standards-based server with freely available
> -  source code.
> -
> -  The Latest Version
> -  --
> -
> -  Details of the latest version can be found on the Apache HTTP
> -  server project page under https://httpd.apache.org/.
> -
> -  Documentation
> -  -
> -
> -  The documentation available as of the date of this release is
> -  included in HTML format in the docs/manual/ directory.  The most
> -  up-to-date documentation can be found at
> -  https://httpd.apache.org/docs/trunk/.
> -
> -  Installation
> -  
> -
> -  Please see the file called INSTALL.  Platform specific notes can be
> -  found in README.platforms.
> -
> -  Licensing
> -  -
> -
> -  Please see the file called LICENSE.
> -
> -  Cryptographic Software Notice
> -  -
> -
> -  This distribution may include software that has been designed for use
> -  with cryptographic software.  The country in which you currently reside
> -  may have restrictions on the import, possession, use, and/or re-export
> -  to another country, of encryption software.  BEFORE using any encryption
> -  software, please check your country's laws, regulations and policies
> -  concerning the import, possession, or use, and re-export of encryption
> -  software, to see if this is permitted.  See 
> -  for more information.
> -
> -  The U.S. Government Department of Commerce, Bureau of Industry and
> -  Security (BIS), has classified this software as Export Commodity 
> -  Control Number (ECCN) 5D002.C.1, which includes information security
> -  software using or performing cryptographic functions with asymmetric
> -  algorithms.  The form and manner of this Apache Software Foundation
> -  distribution makes it eligible for export under the License Exception
> -  ENC Technology Software Unrestricted (TSU) exception (see the BIS 
> -  Export Administration Regulations, Section 740.13) for both object 
> -  code and source code.
> -
> -  The following provides more details on the included files that
> -  may be subject to export controls on cryptographic software:
> -
> -Apache httpd 2.0 and later versions include the mod_ssl module under
> -   modules/ssl/
> -for configuring and listening to connections over SSL encrypted
> -network sockets by performing calls to a general-purpose encryption
> -library, such as OpenSSL or the operating system's platform-specific
> -SSL facilities.
> -
> -In addition, some versions of apr-util provide an abstract interface
> -for symmetrical cryptographic functions that make use of a
> -general-purpose encryption library, such as OpenSSL, NSS, or the
> -operating system's platform-specific facilities. This interface is
> -known as the apr_crypto interface, with implementation beneath the
> -/crypto directory. The apr_crypto interface is used by the
> -mod_session_crypto module available under
> -  modules/session
> -for optional encryption of session information.
> -
> -Some object code distributions of Apache httpd, indicated with the
> -word "crypto" in the package name, may include object code for the
> -OpenSSL encryption library as distributed in open source form from
> -.
> -
> -  The above files are optional and may be removed if the cryptographic
> -  functionality is not desired or needs to be excluded from redistribution.
> -  Distribution packages of Apache httpd that include the word "nossl"
> -  in the package name have been created without the above files and are
> -  therefore not subject to this notice

Re: [VOTE] Release httpd-2.4.58-rc3 as httpd-2.4.58

[Stefan Eissing via dev]

> Am 25.10.2023 um 16:56 schrieb David Zuelke :
> 
> FYI, the https://httpd.apache.org front page still lists 2.4.57 as the latest 
> version.

Not in my browser. And it was so already on release day. Something in your 
infrastructure delivering you old content?

> 
> - David
> 
> 
> On Wed, Oct 18, 2023 at 5:09 PM Stefan Eissing via dev  
> wrote:
> With 8 +1 votes and no counters, this seems a go. If nothing else comes up, 
> I'll do the release tomorrow noonish.
> 
> Thanks all for the testing!
> 
> Cheers,
> Stefan
> 
> > Am 16.10.2023 um 17:08 schrieb Stefan Eissing via dev 
> > :
> > 
> > Hi all,
> > 
> > after fixing my merge mistake in rc2 (sorry!), we go again:
> > 
> > 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.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: [PR] Document non-impact of CVE-2023-44487 [httpd-site]

[Stefan Eissing via dev]

My comment can be found here: 
https://github.com/icing/blog/blob/main/h2-rapid-reset.md

> Am 23.10.2023 um 14:28 schrieb DanielRuf (via GitHub) :
> 
> 
> DanielRuf commented on PR #10:
> URL: https://github.com/apache/httpd-site/pull/10#issuecomment-1775084162
> 
>   Any updates regarding this?
> 
> 
> -- 
> This is an automated message from the Apache Git Service.
> To respond to the message, please log on to GitHub and use the
> URL above to go to the specific comment.
> 
> To unsubscribe, e-mail: dev-unsubscr...@httpd.apache.org
> 
> For queries about this service, please contact Infrastructure at:
> us...@infra.apache.org
> 

Re: [VOTE] Release httpd-2.4.58-rc3 as httpd-2.4.58

[Stefan Eissing via dev]

> Am 19.10.2023 um 13:27 schrieb Rainer Jung :
> 
> Am 16.10.23 um 17:08 schrieb Stefan Eissing via dev:
>> Hi all,
>> after fixing my merge mistake in rc2 (sorry!), we go again:
>> 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.58-rc3 as 2.4.58:
>> [X] +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
> 
> I know I am late, but for the sake of completeness my test results:

I am happy nevertheless (and relieved that it went well)! Thanks for these 
awesome test coverage, Rainer.

Cheers,
Stefan

> +1 to release and thanks a bunch for RM!
> 
> The full range of unit tests is still running, but enough have completed for 
> a vote.
> 
> - Sigs and hashes OK
> - contents of tarballs identical
> - contents of tag and tarballs identical
>  except for expected deltas
> 
> Built on
> 
> - SLES 11+12+15 (64 Bits)
> - RHEL 6+7+8+9 (64 Bits)
> 
> For all platforms built
> 
> - with default (shared) and static modules
> - with module set reallyall
> - using --enable-load-all-modules
> 
> - using libraries
>  - APR/APU
>- bundled deps tarball
>- 1.7.4/1.6.3
>- 1.6.5/1.6.3
>- 1.7.x(r1911757)/1.7.x(r1911757) with libxml2
>- 1.7.x(r1911757)/1.7.x(r1911757) with expat
>- 1.6.x(r1908753)/1.6.x(r1911757)
>- trunk(r1911757) with libxml2
>- trunk(r1911757) with expat
>  - OpenSSL 3.1.3, 3.0.11, 1.1.1w,
>and for all except RHEL 9
>also 1.1.1, 1.0.2u, 1.0.2
>  - expat 2.5.0
>  - pcre 10.42
>  - lua 5.4.6 (compiled with LUA_COMPAT_MODULE)
>  - libxml2 2.11.5
>  - libnghttp2 1.57.0
>  - brotli 1.1.0
>  - curl 8.4.0
>  - jansson 2.14
>  - libldap 2.6.6 (2.5.7 with OpenSSL 1.1.1,
>   2.4.59 with OpenSSL 1.0.2*)
> 
> - in total 200 builds per platform (80 for RHEL 9)
> 
> - Tool chain:
>- platform gcc
>- CFLAGS: -O2 -g -Wall -fno-strict-aliasing
> 
> All builds succeeded.
> 
> - compiler warnings:
> 
>  - deprecation warnings when building against OpenSSL 3.1.3, see other thread
> 
> Tested for
> 
> - SLES 11+12+15
> - RHEL 6+7+8+9
> - MPMs prefork, worker, event
> - log level trace8
> - Perl client bundle build against OpenSSL 3.1.0beta1-1,
>  3.0.0, 1.1.1g plus patches, 1.1.0l, 1.0.2u and 1.1.0l-1
>  (RHEL 9 3.1.2-1, 3.0.10-1, 1.1.1w-1)
> 
> Every OpenSSL version in the client tested with every OpenSSL version in the 
> server. 18 unit test runs (3 MPMS x 6 OpenSSL clients) per server build.
> 
> About 2.400 unit test runs are done, most with server OpenSSL 3.1 and 3.0, 
> for RHEL 9 also 1.1.1.
> 
> Some local adjustments to tests were used:
> 
> - t/modules/buffer.t: removing huge buffer tests
>  -my $bigsize = 10;
>  +my $bigsize = 5;
> 
> The following test failures were seen:
> 
> a t/modules/buffer.t line 37
>  Not a regression
>  Only on RHEL 6, SLES 11.
> 
> c t/modules/sed.t line 37 test 3
>  Not a regression
>  Only on RHEL 6, SLES 11.
> 
> 
> Regards,
> 
> Rainer

my blog about h2 rapid reset and httpd

[Stefan Eissing via dev]

https://github.com/icing/blog/blob/main/h2-rapid-reset.md

Cheers,
Stefan

Re: [VOTE] Release httpd-2.4.58-rc3 as httpd-2.4.58

[Stefan Eissing via dev]

With 8 +1 votes and no counters, this seems a go. If nothing else comes up, 
I'll do the release tomorrow noonish.

Thanks all for the testing!

Cheers,
Stefan

> Am 16.10.2023 um 17:08 schrieb Stefan Eissing via dev :
> 
> Hi all,
> 
> after fixing my merge mistake in rc2 (sorry!), we go again:
> 
> 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.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.58-rc3 as httpd-2.4.58

[Stefan Eissing via dev]

> Am 17.10.2023 um 20:37 schrieb SteffenAL :
> 
> Found it. 
> 
> My error, had included  h2_ws.h as extra library (sorry!).
> 
> Vote now is +1

Thanks, Steffen. Good that you found the mistake.

> 
> Steffen
> 
>> --- Original message --- 
>> Subject: Re: [VOTE] Release httpd-2.4.58-rc3 as httpd-2.4.58 
>> From: Steffen  
>> To:  
>> Date: Tuesday, 17/10/2023 18:29
>> 
>> For me still -1. 
>> 
>>> Op 17 okt 2023 om 18:18 heeft Stefan Eissing via dev  
>>> het volgende geschreven:
>>> 
>>> Just got a reply from a contact that build rc3 on win64 and ran it 
>>> successfully. I invited him to participate here, not sure if he will feel 
>>> like it.
>>> 
>>> I count that as a +1 on win64 unless someone objects.
>>> 
>>> Cheers,
>>> Stefan
>>> 
>>> 
>>>> Am 17.10.2023 um 12:05 schrieb Stefan Eissing via dev 
>>>> :
>>>> 
>>>> I am trying to contact another person that builds regularly mod_h2 on 
>>>> Windows.
>>>> 
>>>>>> Am 17.10.2023 um 11:30 schrieb Steffen :
>>>>> 
>>>>> Same error on win64.
>>>>> Yes the reported mod_http2 errors on 32 and 64.
>>>>> Yes, I am not able to tell what is wrong, only I can report the errors. I 
>>>>> am not a developer, just building and testing.
>>>>> 
>>>>> Regards, Steffen
>>>>> 
>>>>>> Op 17 okt 2023 om 11:08 heeft Stefan Eissing via dev 
>>>>>>  het volgende geschreven:
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> Am 17.10.2023 um 08:41 schrieb Steffen :
>>>>>>> 
>>>>>>> -1 does not build on windows.
>>>>>> 
>>>>>> If I understood your reports from yesterday correctly, the situation is
>>>>>> - you can build on win64
>>>>>> - you get compiler errors on your win32 build
>>>>>> - you are not able to tell us what is wrong
>>>>>> 
>>>>>> Correct?
>>>>>> 
>>>>>> Cheers,
>>>>>> Stefan
>>>>>> 
>>>>>>> 
>>>>>>> Steffen
>>>>>>> 
>>>>>>>>> Op 16 okt 2023 om 17:10 heeft Stefan Eissing via dev 
>>>>>>>>>  het volgende geschreven:
>>>>>>>> 
>>>>>>>> Hi all,
>>>>>>>> 
>>>>>>>> after fixing my merge mistake in rc2 (sorry!), we go again:
>>>>>>>> 
>>>>>>>> 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.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
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
> 
> <1pixel.gif>

Re: [VOTE] Release httpd-2.4.58-rc3 as httpd-2.4.58

[Stefan Eissing via dev]

Just got a reply from a contact that build rc3 on win64 and ran it 
successfully. I invited him to participate here, not sure if he will feel like 
it.

I count that as a +1 on win64 unless someone objects.

Cheers,
Stefan


> Am 17.10.2023 um 12:05 schrieb Stefan Eissing via dev :
> 
> I am trying to contact another person that builds regularly mod_h2 on Windows.
> 
>> Am 17.10.2023 um 11:30 schrieb Steffen :
>> 
>> Same error on win64. 
>> Yes the reported mod_http2 errors on 32 and 64. 
>> Yes, I am not able to tell what is wrong, only I can report the errors. I am 
>> not a developer, just building and testing. 
>> 
>> Regards, Steffen
>> 
>>> Op 17 okt 2023 om 11:08 heeft Stefan Eissing via dev  
>>> het volgende geschreven:
>>> 
>>> 
>>> 
>>>> Am 17.10.2023 um 08:41 schrieb Steffen :
>>>> 
>>>> -1 does not build on windows.
>>> 
>>> If I understood your reports from yesterday correctly, the situation is
>>> - you can build on win64
>>> - you get compiler errors on your win32 build
>>> - you are not able to tell us what is wrong
>>> 
>>> Correct?
>>> 
>>> Cheers,
>>> Stefan
>>> 
>>>> 
>>>> Steffen
>>>> 
>>>>>> Op 16 okt 2023 om 17:10 heeft Stefan Eissing via dev 
>>>>>>  het volgende geschreven:
>>>>> 
>>>>> Hi all,
>>>>> 
>>>>> after fixing my merge mistake in rc2 (sorry!), we go again:
>>>>> 
>>>>> 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.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.58-rc3 as httpd-2.4.58

[Stefan Eissing via dev]

I am trying to contact another person that builds regularly mod_h2 on Windows.

> Am 17.10.2023 um 11:30 schrieb Steffen :
> 
> Same error on win64. 
> Yes the reported mod_http2 errors on 32 and 64. 
> Yes, I am not able to tell what is wrong, only I can report the errors. I am 
> not a developer, just building and testing. 
> 
> Regards, Steffen
> 
>> Op 17 okt 2023 om 11:08 heeft Stefan Eissing via dev  
>> het volgende geschreven:
>> 
>> 
>> 
>>> Am 17.10.2023 um 08:41 schrieb Steffen :
>>> 
>>> -1 does not build on windows.
>> 
>> If I understood your reports from yesterday correctly, the situation is
>> - you can build on win64
>> - you get compiler errors on your win32 build
>> - you are not able to tell us what is wrong
>> 
>> Correct?
>> 
>> Cheers,
>> Stefan
>> 
>>> 
>>> Steffen
>>> 
>>>>> Op 16 okt 2023 om 17:10 heeft Stefan Eissing via dev 
>>>>>  het volgende geschreven:
>>>> 
>>>> Hi all,
>>>> 
>>>> after fixing my merge mistake in rc2 (sorry!), we go again:
>>>> 
>>>> 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.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.58-rc3 as httpd-2.4.58

[Stefan Eissing via dev]

> Am 16.10.2023 um 17:08 schrieb Stefan Eissing via dev :
> 
> Hi all,
> 
> after fixing my merge mistake in rc2 (sorry!), we go again:
> 
> 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.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

+1 on macOS Ventura 13.5.2

- Stefan

Re: [VOTE] Release httpd-2.4.58-rc3 as httpd-2.4.58

[Stefan Eissing via dev]

> Am 17.10.2023 um 08:41 schrieb Steffen :
> 
> -1 does not build on windows. 

If I understood your reports from yesterday correctly, the situation is
- you can build on win64
- you get compiler errors on your win32 build
- you are not able to tell us what is wrong

Correct?

Cheers,
Stefan

> 
> Steffen
> 
>> Op 16 okt 2023 om 17:10 heeft Stefan Eissing via dev  
>> het volgende geschreven:
>> 
>> Hi all,
>> 
>> after fixing my merge mistake in rc2 (sorry!), we go again:
>> 
>> 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.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
> 

[VOTE] Release httpd-2.4.58-rc3 as httpd-2.4.58

[Stefan Eissing via dev]

Hi all,

after fixing my merge mistake in rc2 (sorry!), we go again:

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.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

windows block

[Stefan Eissing via dev]

Do I make an rc3 nevertheless? Do we know someone else using VC?

Advice appreciated.

- Stefan

Re: svn commit: r1913028 - /httpd/httpd/tags/2.4.58-rc2-candidate/

[Stefan Eissing via dev]

Steffen,

> Am 16.10.2023 um 15:52 schrieb SteffenAL :
> 
> No go. All other modules fine, only mod_http2 error.
> 
> Recap:
> 
> On windows 32:
> 
> Generating Code...
> h2_ws.h
> C:\VS17\Win32\httpd-2.4\modules\http2\h2.h(173,17): error C2143: syntax 
> error: missing ';' before '*'
> C:\VS17\Win32\httpd-2.4\modules\http2\h2.h(173,17): error C4430: missing type 
> specifier - int assumed. Note: C++ does not support default-int
> ...
> ...


How can we help you to fix this? Repeating the same error lines again will not 
help. Maybe you can provide more information:

- in which *.c file does the error happen?
- is a specific APR header file missing there?
- does it work if your remove the "#include "h2.h" in h2_ws.h?

- Stefan

>  On Monday 16/10/2023 at 15:45, ic...@apache.org wrote: 
>> 
>> Author: icing
>> Date: Mon Oct 16 13:43:23 2023
>> New Revision: 1913028
>> 
>> URL: http://svn.apache.org/viewvc?rev=1913028&view=rev
>> Log:
>> resetting candidate 2.4.58-rc2
>> 
>> Removed:
>>  httpd/httpd/tags/2.4.58-rc2-candidate/
>> 
> 
> 

Re: [VOTE] Release httpd-2.4.58-rc2 as httpd-2.4.58

[Stefan Eissing via dev]

> Am 16.10.2023 um 15:40 schrieb Ruediger Pluem :
> 
> I am sorry, but #include "apr_encode.h" is still unconditional in h2_ws.c in 
> 2.4.x. Fixed in r1913027.

Thanks for catching this.

> 
> Regards
> 
> Rüdiger
> 
> 
> On 10/16/23 3:31 PM, Stefan Eissing via dev wrote:
>> Hi all,
>> 
>> after some hickups with getting the new WebSockets support to
>> compile on Joe's old computers, we try again!
>> 
>> 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.58-rc2 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: e544ee225fbab4f4cdd60970dc0bbd0b74cbd331cd7a5635faca717d532d8ed6 
>> *httpd-2.4.58-rc2.tar.gz
>> sha512: 
>> d4d322300cee4899dc1671e58dd5f6b88632beae87192cde475285324b9ceda62a9200b80fdd96b928f9eade5f819fc9bc3b3563f1b7b1fb3e759fd6d5df935a
>>  *httpd-2.4.58-rc2.tar.gz
>> 
>> The SVN candidate source is found at tags/2.4.58-rc2-candidate.
>> 
>> Cheers,
>> Stefan
>> 

[VOTE] Release httpd-2.4.58-rc2 as httpd-2.4.58

[Stefan Eissing via dev]

Hi all,

after some hickups with getting the new WebSockets support to
compile on Joe's old computers, we try again!

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.58-rc2 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: e544ee225fbab4f4cdd60970dc0bbd0b74cbd331cd7a5635faca717d532d8ed6 
*httpd-2.4.58-rc2.tar.gz
sha512: 
d4d322300cee4899dc1671e58dd5f6b88632beae87192cde475285324b9ceda62a9200b80fdd96b928f9eade5f819fc9bc3b3563f1b7b1fb3e759fd6d5df935a
 *httpd-2.4.58-rc2.tar.gz

The SVN candidate source is found at tags/2.4.58-rc2-candidate.

Cheers,
Stefan

Re: svn commit: r1913006 - in /httpd/httpd/branches/2.4.x: ./modules/http2/h2.h

[Stefan Eissing via dev]

> Am 16.10.2023 um 15:12 schrieb SteffenAL :
> 
> checkout.
> 
>  Looks like h2_ws.h :
> 
> Generating Code...
> h2_ws.h
> C:\VS17\Win32\httpd-2.4\modules\http2\h2.h(173,17): error C2143: syntax 
> error: missing ';' before '*'
> C:\VS17\Win32\httpd-2.4\modules\http2\h2.h(173,17): error C4430: missing type 
> specifier - int assumed. Note: C++ does not support default-int

Very strange indeed. I have no explanation.

> 
> Steffen
>  On Monday 16/10/2023 at 14:59, Stefan Eissing via dev wrote: 
>> 
>> Steffen,
>> 
>> just to be sure: did you test a 2.4.x checkout or did you apply the patch 
>> from Joe yourself?
>> 
>> if there is not other feedback, I'll make a new candidate soon.
>> 
>>> Am 16.10.2023 um 14:06 schrieb SteffenAL :
>>> 
>>> The new h2h gives now on Windows 32 :
>>> 
>>> syntax error: identifier 'conn_rec' mod_http2 
>>> C:\VS17\Win32\httpd-2.4\modules\http2\h2_ws.h 31 syntax error: missing ';' 
>>> before '*' mod_http2 C:\VS17\Win32\httpd-2.4\modules\http2\h2.h 173 missing 
>>> type specifier - int assumed. Note: C++ does not support default-int 
>>> mod_http2 C:\VS17\Win32\httpd-2.4\modules\http2\h2.h 173 C2238 unexpected 
>>> token(s) preceding ';' mod_http2 C:\VS17\Win32\httpd-2.4\modules\http2\h2.h 
>>> 173 C3646 'request_time': unknown override specifier mod_http2 
>>> C:\VS17\Win32\httpd-2.4\modules\http2\h2.h 175 C4430 missing type specifier 
>>> - int assumed. Note: C++ does not support default-int mod_http2 
>>> C:\VS17\Win32\httpd-2.4\modules\http2\h2.h 175 C4430 missing type specifier 
>>> - int assumed. Note: C++ does not support default-int mod_http2 
>>> C:\VS17\Win32\httpd-2.4\modules\http2\h2.h 190 C2146 syntax error: missing 
>>> ';' before identifier 'h2_io_data_cb' mod_http2 
>>> C:\VS17\Win32\httpd-2.4\modules\http2\h2.h 190 C2062 type 'void' unexpected 
>>> mod_http2 C:\VS17\Win32\httpd-2.4\modu
>> les\http2\h2.h 190 
>>> Steffen
>>> 
>>> On Monday 16/10/2023 at 13:11, ic...@apache.org wrote: 
>>>> 
>>>> Author: icing
>>>> Date: Mon Oct 16 11:11:45 2023
>>>> New Revision: 1913006
>>>> 
>>>> URL: http://svn.apache.org/viewvc?rev=1913006&view=rev
>>>> Log:
>>>> Merge of /httpd/httpd/trunk:r1913005
>>>> 
>>>>  *) mod_http2: enable WebSockets only when compiling against a
>>>> recent enought nghttp2 version.
>>>> 
>>>> 
>>>> Modified:
>>>>httpd/httpd/branches/2.4.x/ (props changed)
>>>>httpd/httpd/branches/2.4.x/modules/http2/h2.h
>>>> 
>>>> Propchange: httpd/httpd/branches/2.4.x/
>>>> --
>>>>  Merged /httpd/httpd/trunk:r1913005
>>>> 
>>>> Modified: httpd/httpd/branches/2.4.x/modules/http2/h2.h
>>>> URL: 
>>>> http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/modules/http2/h2.h?rev=1913006&r1=1913005&r2=1913006&view=diff
>>>> ==
>>>> --- httpd/httpd/branches/2.4.x/modules/http2/h2.h (original)
>>>> +++ httpd/httpd/branches/2.4.x/modules/http2/h2.h Mon Oct 16 11:11:45 2023
>>>> @@ -20,6 +20,8 @@
>>>> #include 
>>>> #include 
>>>> 
>>>> +#include 
>>>> +
>>>> struct h2_session;
>>>> struct h2_stream;
>>>> 
>>>> @@ -39,7 +41,7 @@ struct h2_stream;
>>>> #define H2_USE_POLLFD_FROM_CONN 0
>>>> #endif
>>>> 
>>>> -#if H2_USE_PIPES
>>>> +#if H2_USE_PIPES && defined(NGHTTP2_VERSION_NUM) && NGHTTP2_VERSION_NUM 
>>>> >= 0x012200
>>>> #define H2_USE_WEBSOCKETS 1
>>>> #else
>>>> #define H2_USE_WEBSOCKETS 0
>>>> 
>>>> 
>>> 
>>> 
>> 
> 
> 

Re: svn commit: r1913019 - in /httpd/httpd/trunk/modules/http2: h2_session.c h2_ws.c

[Stefan Eissing via dev]

> Am 16.10.2023 um 15:12 schrieb Joe Orton :
> 
> On Mon, Oct 16, 2023 at 02:54:58PM +0200, Ruediger Pluem wrote:
>> Fails for me as well. Not sure what fails for Joe such that he removed the 
>> include, but if it fails in case H2_USE_WEBSOCKETS is
>> not 1 I guess we could move the include (or even all) below the
>> 
>> #if H2_USE_WEBSOCKETS
>> 
>> line.
> 
> Oh, sorry guys. 
> 
> I was building against APR 1.6.x here which doesn't have apr_encode.h, I 
> didn't see the apr_pencode use. So how about:
> 
> r1913019 + r1913023, +1 for 2.4.x for the pair
> 

+1

Re: svn commit: r1913006 - in /httpd/httpd/branches/2.4.x: ./ modules/http2/h2.h

[Stefan Eissing via dev]

Steffen,

just to be sure: did you test a 2.4.x checkout or did you apply the patch from 
Joe yourself?

if there is not other feedback, I'll make a new candidate soon.

> Am 16.10.2023 um 14:06 schrieb SteffenAL :
> 
> The new h2h gives now on Windows 32 :
> 
> syntax error: identifier 'conn_rec' mod_http2 
> C:\VS17\Win32\httpd-2.4\modules\http2\h2_ws.h 31 syntax error: missing ';' 
> before '*' mod_http2 C:\VS17\Win32\httpd-2.4\modules\http2\h2.h 173 missing 
> type specifier - int assumed. Note: C++ does not support default-int 
> mod_http2 C:\VS17\Win32\httpd-2.4\modules\http2\h2.h 173 C2238 unexpected 
> token(s) preceding ';' mod_http2 C:\VS17\Win32\httpd-2.4\modules\http2\h2.h 
> 173 C3646 'request_time': unknown override specifier mod_http2 
> C:\VS17\Win32\httpd-2.4\modules\http2\h2.h 175 C4430 missing type specifier - 
> int assumed. Note: C++ does not support default-int mod_http2 
> C:\VS17\Win32\httpd-2.4\modules\http2\h2.h 175 C4430 missing type specifier - 
> int assumed. Note: C++ does not support default-int mod_http2 
> C:\VS17\Win32\httpd-2.4\modules\http2\h2.h 190 C2146 syntax error: missing 
> ';' before identifier 'h2_io_data_cb' mod_http2 
> C:\VS17\Win32\httpd-2.4\modules\http2\h2.h 190 C2062 type 'void' unexpected 
> mod_http2 C:\VS17\Win32\httpd-2.4\modules\http2\h2.h 190 
> Steffen
> 
> On Monday 16/10/2023 at 13:11, ic...@apache.org wrote: 
>> 
>> Author: icing
>> Date: Mon Oct 16 11:11:45 2023
>> New Revision: 1913006
>> 
>> URL: http://svn.apache.org/viewvc?rev=1913006&view=rev
>> Log:
>> Merge of /httpd/httpd/trunk:r1913005
>> 
>>*) mod_http2: enable WebSockets only when compiling against a
>>   recent enought nghttp2 version.
>> 
>> 
>> Modified:
>>  httpd/httpd/branches/2.4.x/ (props changed)
>>  httpd/httpd/branches/2.4.x/modules/http2/h2.h
>> 
>> Propchange: httpd/httpd/branches/2.4.x/
>> --
>>Merged /httpd/httpd/trunk:r1913005
>> 
>> Modified: httpd/httpd/branches/2.4.x/modules/http2/h2.h
>> URL: 
>> http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/modules/http2/h2.h?rev=1913006&r1=1913005&r2=1913006&view=diff
>> ==
>> --- httpd/httpd/branches/2.4.x/modules/http2/h2.h (original)
>> +++ httpd/httpd/branches/2.4.x/modules/http2/h2.h Mon Oct 16 11:11:45 2023
>> @@ -20,6 +20,8 @@
>> #include 
>> #include 
>> 
>> +#include 
>> +
>> struct h2_session;
>> struct h2_stream;
>> 
>> @@ -39,7 +41,7 @@ struct h2_stream;
>> #define H2_USE_POLLFD_FROM_CONN 0
>> #endif
>> 
>> -#if H2_USE_PIPES
>> +#if H2_USE_PIPES && defined(NGHTTP2_VERSION_NUM) && NGHTTP2_VERSION_NUM >= 
>> 0x012200
>> #define H2_USE_WEBSOCKETS 1
>> #else
>> #define H2_USE_WEBSOCKETS 0
>> 
>> 
> 
> 

Re: svn commit: r1913019 - in /httpd/httpd/trunk/modules/http2: h2_session.c h2_ws.c

[Stefan Eissing via dev]

> Am 16.10.2023 um 14:54 schrieb Ruediger Pluem :
> 
> 
> 
> On 10/16/23 2:38 PM, Stefan Eissing via dev wrote:
>> 
>> 
>>> Am 16.10.2023 um 14:28 schrieb jor...@apache.org:
>>> 
>>> Author: jorton
>>> Date: Mon Oct 16 12:28:13 2023
>>> New Revision: 1913019
>>> 
>>> URL: http://svn.apache.org/viewvc?rev=1913019&view=rev
>>> Log:
>>> Further h2 compile fixes:
>>> 
>>> * modules/http2/h2_session.c (h2_session_start):
>>> Restrict WebSockets options handling to with-WS builds.
>>> 
>>> * modules/http2/h2_ws.c: Don't include apr_encode.h (not used).
>>> 
>>> Modified:
>>>   httpd/httpd/trunk/modules/http2/h2_session.c
>>>   httpd/httpd/trunk/modules/http2/h2_ws.c
>>> 
>>> Modified: httpd/httpd/trunk/modules/http2/h2_session.c
>>> URL: 
>>> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/http2/h2_session.c?rev=1913019&r1=1913018&r2=1913019&view=diff
>>> ==
>>> --- httpd/httpd/trunk/modules/http2/h2_session.c (original)
>>> +++ httpd/httpd/trunk/modules/http2/h2_session.c Mon Oct 16 12:28:13 2023
>>> @@ -1085,11 +1085,13 @@ static apr_status_t h2_session_start(h2_
>>>settings[slen].value = win_size;
>>>++slen;
>>>}
>>> +#if H2_USE_WEBSOCKETS
>>>if (h2_config_sgeti(session->s, H2_CONF_WEBSOCKETS)) {
>>>  settings[slen].settings_id = NGHTTP2_SETTINGS_ENABLE_CONNECT_PROTOCOL;
>>>  settings[slen].value = 1;
>>>  ++slen;
>>>}
>>> +#endif
>>> 
>>>ap_log_cerror(APLOG_MARK, APLOG_DEBUG, status, session->c1,
>>>  H2_SSSN_LOG(APLOGNO(03201), session, 
>>> 
>> 
>> Fine.
>> 
>>> Modified: httpd/httpd/trunk/modules/http2/h2_ws.c
>>> URL: 
>>> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/http2/h2_ws.c?rev=1913019&r1=1913018&r2=1913019&view=diff
>>> ==
>>> --- httpd/httpd/trunk/modules/http2/h2_ws.c (original)
>>> +++ httpd/httpd/trunk/modules/http2/h2_ws.c Mon Oct 16 12:28:13 2023
>>> @@ -19,7 +19,6 @@
>>> #include "apr.h"
>>> #include "apr_strings.h"
>>> #include "apr_lib.h"
>>> -#include "apr_encode.h"
>>> #include "apr_sha1.h"
>>> #include "apr_strmatch.h"
>> 
>> Not working here:
>> h2_ws.c:70:12: error: call to undeclared function 
>> 'apr_pencode_base64_binary'; ISO C99 and later do not support implicit 
>> function declarations [-Wimplicit-function-declaration]
>>return apr_pencode_base64_binary(c->pool, dgst, sizeof(dgst),
>>   ^
>> h2_ws.c:71:38: error: use of undeclared identifier 'APR_ENCODE_NONE'
>> APR_ENCODE_NONE, NULL);
>> ^
>> h2_ws.c:123:18: error: call to undeclared function 
>> 'apr_pencode_base64_binary'; ISO C99 and later do not support implicit 
>> function declarations [-Wimplicit-function-declaration]
>>key_base64 = apr_pencode_base64_binary(c2->pool, key_raw, sizeof(key_raw),
>> ^
>> h2_ws.c:124:44: error: use of undeclared identifier 'APR_ENCODE_NONE'
>>   APR_ENCODE_NONE, NULL);
> 
> Fails for me as well. Not sure what fails for Joe such that he removed the 
> include, but if it fails in case H2_USE_WEBSOCKETS is
> not 1 I guess we could move the include (or even all) below the
> 
> #if H2_USE_WEBSOCKETS

It may be unnecessary without websockets, but how could it hurt?

> 
> line.
> 
> Regards
> 
> Rüdiger

Re: [VOTE] Release httpd-2.4.58-rc1 as httpd-2.4.58

[Stefan Eissing via dev]

rc1 vote is cancelled. There will be a rc2 soon. Thanks for testing.

> Am 16.10.2023 um 12:07 schrieb Stefan Eissing via dev :
> 
> 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.58-rc1 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: 1e381c8aa2d02d323837db042109b2286370fbf20e75d3b292e31f2519599e5b 
> *httpd-2.4.58-rc1.tar.gz
> sha512: 
> dd867519c9c9317365f823c4b532fc5491536df5b4ea1ec5870571106efea89a3b81d385578c7d007f935f91b52c55c0830e2d49edcaa32478601b1c2ae6c557
>  *httpd-2.4.58-rc1.tar.gz
> 
> The SVN candidate source is found at tags/2.4.58-rc1-candidate.
> 
> Cheers,
> Stefan
> 
> *) the -deps.* archives are added only for convenience and not part of the 
> release

Re: [PATCH] fix mod_h2 with older nghttp2

[Stefan Eissing via dev]

> Am 16.10.2023 um 14:38 schrieb Joe Orton :
> 
> BTW is modules/http2 really CTR for 2.4.x? STATUS says only 
> mod_proxy_http2 is.


I have made peace with myself to spend afterlife in hell.

> Anyway: I am +1 for r1913005 and r1913019 for 2.4.x, latter was 
> sufficient to get 2.4 building on RHEL8 again (if only we had a CI to do 
> this, oh...).
> 

The apr_encode.h is needed on my machine. Leaving it in.

> Regards, Joe
> 

Re: svn commit: r1913019 - in /httpd/httpd/trunk/modules/http2: h2_session.c h2_ws.c

[Stefan Eissing via dev]

> Am 16.10.2023 um 14:28 schrieb jor...@apache.org:
> 
> Author: jorton
> Date: Mon Oct 16 12:28:13 2023
> New Revision: 1913019
> 
> URL: http://svn.apache.org/viewvc?rev=1913019&view=rev
> Log:
> Further h2 compile fixes:
> 
> * modules/http2/h2_session.c (h2_session_start):
>  Restrict WebSockets options handling to with-WS builds.
> 
> * modules/http2/h2_ws.c: Don't include apr_encode.h (not used).
> 
> Modified:
>httpd/httpd/trunk/modules/http2/h2_session.c
>httpd/httpd/trunk/modules/http2/h2_ws.c
> 
> Modified: httpd/httpd/trunk/modules/http2/h2_session.c
> URL: 
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/http2/h2_session.c?rev=1913019&r1=1913018&r2=1913019&view=diff
> ==
> --- httpd/httpd/trunk/modules/http2/h2_session.c (original)
> +++ httpd/httpd/trunk/modules/http2/h2_session.c Mon Oct 16 12:28:13 2023
> @@ -1085,11 +1085,13 @@ static apr_status_t h2_session_start(h2_
> settings[slen].value = win_size;
> ++slen;
> }
> +#if H2_USE_WEBSOCKETS
> if (h2_config_sgeti(session->s, H2_CONF_WEBSOCKETS)) {
>   settings[slen].settings_id = NGHTTP2_SETTINGS_ENABLE_CONNECT_PROTOCOL;
>   settings[slen].value = 1;
>   ++slen;
> }
> +#endif
> 
> ap_log_cerror(APLOG_MARK, APLOG_DEBUG, status, session->c1,
>   H2_SSSN_LOG(APLOGNO(03201), session, 
> 

Fine.

> Modified: httpd/httpd/trunk/modules/http2/h2_ws.c
> URL: 
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/http2/h2_ws.c?rev=1913019&r1=1913018&r2=1913019&view=diff
> ==
> --- httpd/httpd/trunk/modules/http2/h2_ws.c (original)
> +++ httpd/httpd/trunk/modules/http2/h2_ws.c Mon Oct 16 12:28:13 2023
> @@ -19,7 +19,6 @@
> #include "apr.h"
> #include "apr_strings.h"
> #include "apr_lib.h"
> -#include "apr_encode.h"
> #include "apr_sha1.h"
> #include "apr_strmatch.h"

Not working here:
h2_ws.c:70:12: error: call to undeclared function 'apr_pencode_base64_binary'; 
ISO C99 and later do not support implicit function declarations 
[-Wimplicit-function-declaration]
return apr_pencode_base64_binary(c->pool, dgst, sizeof(dgst),
   ^
h2_ws.c:71:38: error: use of undeclared identifier 'APR_ENCODE_NONE'
 APR_ENCODE_NONE, NULL);
 ^
h2_ws.c:123:18: error: call to undeclared function 'apr_pencode_base64_binary'; 
ISO C99 and later do not support implicit function declarations 
[-Wimplicit-function-declaration]
key_base64 = apr_pencode_base64_binary(c2->pool, key_raw, sizeof(key_raw),
 ^
h2_ws.c:124:44: error: use of undeclared identifier 'APR_ENCODE_NONE'
   APR_ENCODE_NONE, NULL);

Re: svn commit: r1913006 - in /httpd/httpd/branches/2.4.x: ./ modules/http2/h2.h

[Stefan Eissing via dev]

Hi Steffen,

> Am 16.10.2023 um 14:06 schrieb SteffenAL :
> 
> The new h2h gives now on Windows 32 :
> 
> syntax error: identifier 'conn_rec' mod_http2 
> C:\VS17\Win32\httpd-2.4\modules\http2\h2_ws.h 31 syntax error: missing ';' 
> before '*' mod_http2 C:\VS17\Win32\httpd-2.4\modules\http2\h2.h 173 missing 
> type specifier - int assumed. Note: C++ does not support default-int 
> mod_http2 C:\VS17\Win32\httpd-2.4\modules\http2\h2.h 173 C2238 unexpected 
> token(s) preceding ';' mod_http2 C:\VS17\Win32\httpd-2.4\modules\http2\h2.h 
> 173 C3646 'request_time': unknown override specifier mod_http2 
> C:\VS17\Win32\httpd-2.4\modules\http2\h2.h 175 C4430 missing type specifier - 
> int assumed. Note: C++ does not support default-int mod_http2 
> C:\VS17\Win32\httpd-2.4\modules\http2\h2.h 175 C4430 missing type specifier - 
> int assumed. Note: C++ does not support default-int mod_http2 
> C:\VS17\Win32\httpd-2.4\modules\http2\h2.h 190 C2146 syntax error: missing 
> ';' before identifier 'h2_io_data_cb' mod_http2 
> C:\VS17\Win32\httpd-2.4\modules\http2\h2.h 190 C2062 type 'void' unexpected 
> mod_http2 C:\VS17\Win32\httpd-2.4\modules\http2\h2.h 190 

The lines 173-175 and 190 are years old. What is going on?

The file h2_ws.h is new and included in 4 *.c files. Which one gives the 
problem?

//Stefan

> Steffen
> 
> On Monday 16/10/2023 at 13:11, ic...@apache.org wrote: 
>> 
>> Author: icing
>> Date: Mon Oct 16 11:11:45 2023
>> New Revision: 1913006
>> 
>> URL: http://svn.apache.org/viewvc?rev=1913006&view=rev
>> Log:
>> Merge of /httpd/httpd/trunk:r1913005
>> 
>>*) mod_http2: enable WebSockets only when compiling against a
>>   recent enought nghttp2 version.
>> 
>> 
>> Modified:
>>  httpd/httpd/branches/2.4.x/ (props changed)
>>  httpd/httpd/branches/2.4.x/modules/http2/h2.h
>> 
>> Propchange: httpd/httpd/branches/2.4.x/
>> --
>>Merged /httpd/httpd/trunk:r1913005
>> 
>> Modified: httpd/httpd/branches/2.4.x/modules/http2/h2.h
>> URL: 
>> http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/modules/http2/h2.h?rev=1913006&r1=1913005&r2=1913006&view=diff
>> ==
>> --- httpd/httpd/branches/2.4.x/modules/http2/h2.h (original)
>> +++ httpd/httpd/branches/2.4.x/modules/http2/h2.h Mon Oct 16 11:11:45 2023
>> @@ -20,6 +20,8 @@
>> #include 
>> #include 
>> 
>> +#include 
>> +
>> struct h2_session;
>> struct h2_stream;
>> 
>> @@ -39,7 +41,7 @@ struct h2_stream;
>> #define H2_USE_POLLFD_FROM_CONN 0
>> #endif
>> 
>> -#if H2_USE_PIPES
>> +#if H2_USE_PIPES && defined(NGHTTP2_VERSION_NUM) && NGHTTP2_VERSION_NUM >= 
>> 0x012200
>> #define H2_USE_WEBSOCKETS 1
>> #else
>> #define H2_USE_WEBSOCKETS 0
>> 
>> 
> 
> 

Re: [PATCH] fix mod_h2 with older nghttp2

[Stefan Eissing via dev]

I added that patch to trunk and merged it into 2.4.x.

I'll make another release candidate soonish. Someone wants to merge the back 
ports idling in STATUS?

Cheers,
Stefan

> Am 16.10.2023 um 12:55 schrieb Joe Orton :
> 
> Looks like this broke with the websockets backport. mod_h2 is failing to 
> compile on versions of nghttp2 without 
> NGHTTP2_SETTINGS_ENABLE_CONNECT_PROTOCOL - looks like this was added in 
> nghttp2 v1.34.0 [1] so how about something like this, or is there a 
> better way?
> 
> (configure check for a declaration is messier)
> 
> diff --git a/modules/http2/h2.h b/modules/http2/h2.h
> index cfecb3d9a3..06e7087c04 100644
> --- a/modules/http2/h2.h
> +++ b/modules/http2/h2.h
> @@ -20,6 +20,8 @@
> #include 
> #include 
> 
> +#include 
> +
> struct h2_session;
> struct h2_stream;
> 
> @@ -39,7 +41,7 @@ struct h2_stream;
> #define H2_USE_POLLFD_FROM_CONN 0
> #endif
> 
> -#if H2_USE_PIPES
> +#if H2_USE_PIPES && defined(NGHTTP2_VERSION_NUM) && NGHTTP2_VERSION_NUM >= 
> 0x012200
> #define H2_USE_WEBSOCKETS   1
> #else
> #define H2_USE_WEBSOCKETS   0
> 
> 
> 
> [1] https://github.com/nghttp2/nghttp2/milestone/30?closed=1 
> 

Re: [VOTE] Release httpd-2.4.58-rc1 as httpd-2.4.58

[Stefan Eissing via dev]

> Am 16.10.2023 um 12:28 schrieb Ruediger Pluem :
> 
> First of all thanks for RM.
> It looks to me that we have 2 accepted backports in the STATUS that have not 
> been merged.
> This seems unfortunate.

Well, I asked people to bring in the changes they want. I am not a merge 
machine for everyone. ^^

If someone wants to add them, I'll make an rc2 with it.

Cheers,
Stefan


> 
> Regards
> 
> Rüdiger
> 
> On 10/16/23 12:07 PM, Stefan Eissing via dev 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 httpd-2.4.58-rc1 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: 1e381c8aa2d02d323837db042109b2286370fbf20e75d3b292e31f2519599e5b 
>> *httpd-2.4.58-rc1.tar.gz
>> sha512: 
>> dd867519c9c9317365f823c4b532fc5491536df5b4ea1ec5870571106efea89a3b81d385578c7d007f935f91b52c55c0830e2d49edcaa32478601b1c2ae6c557
>>  *httpd-2.4.58-rc1.tar.gz
>> 
>> The SVN candidate source is found at tags/2.4.58-rc1-candidate.
>> 
>> Cheers,
>> Stefan
>> 
>> *) the -deps.* archives are added only for convenience and not part of the 
>> release
>> 

[VOTE] Release httpd-2.4.58-rc1 as httpd-2.4.58

[Stefan Eissing via dev]

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.58-rc1 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: 1e381c8aa2d02d323837db042109b2286370fbf20e75d3b292e31f2519599e5b 
*httpd-2.4.58-rc1.tar.gz
sha512: 
dd867519c9c9317365f823c4b532fc5491536df5b4ea1ec5870571106efea89a3b81d385578c7d007f935f91b52c55c0830e2d49edcaa32478601b1c2ae6c557
 *httpd-2.4.58-rc1.tar.gz

The SVN candidate source is found at tags/2.4.58-rc1-candidate.

Cheers,
Stefan

*) the -deps.* archives are added only for convenience and not part of the 
release

upcoming 2.4.58

[Stefan Eissing via dev]

Hi,

I intend to make a release candidate for v2.4.58 on Monday, 12.00h CET and put 
that up for voting. Please bring in any changes you'd like to be included in 
there before that time.

Cheers,
Stefan

Re: Please support/enable https by default in the Apache web sever.

[Stefan Eissing via dev]

Even for test setups with a few users, I recommend something like this: 


We use this method in our test and CI workflows as well. 

Cheers,
Stefan

> Am 30.09.2023 um 16:42 schrieb General Email 
> :
> 
> 
> 
> On Sat, 30 Sep, 2023, 8:00 pm Emmanuel Dreyfus,  wrote:
> On Sat, Sep 30, 2023 at 07:40:34PM +0530, General Email wrote:
> > By the way, I don't understand how the default certificate can be abused.
> 
> It is not signed by a trusted CA, hence your browser cannot tell if it
> is speaking to your legitimate web server, or to some malware lurking
> in between. Perhaps your web trafic is not worth being evesdropped, but
> consider a malware could inject an exploit against your browser in your
> web trafic. The attacker could just be an infected machine on the same
> LAN.
> 
> The security level of an untrusted ceritificate is not much better than
> plain text HTTP.
> 
> 
> Yes, I understand this.
> 
> We will not be using the default untrusted certificate when we go live.
> 
> But during development, if 10 people are working on the development of one 
> website and each of them has their own apache http installation, then we have 
> to generate 10 certificates and do a few changes or more than few changes to 
> get https enabled on each of 10 installations.
> 
> Having a default certificate (not signed by trusted CA) in official http 
> server will make enabling https on each installation much easier and we won't 
> have to generate 10 certificates, etc.
> 
> Regards,
> GE
> 

Re: Please support/enable https by default in the Apache web sever.

[Stefan Eissing via dev]

Take for example Caddy, which is https: by default and gets you a valid Let's 
Encrypt certificate (unless you configure it to do something different). You 
enter your domain in the config file and it does the rest.

Such a setup would be possible with Apache as well. It's a matter of the 
configuration files the installed package provides.

But some people do not want this. Some people prefer to use certbot or acme.sh 
or another setup. There is a large variety how this can go and no single best 
solution for everyone.

I have written several recipes for Apache ACME myself to help people with this. 
See 

Cheers,
Stefan


> Am 30.09.2023 um 16:30 schrieb Emmanuel Dreyfus :
> 
> On Sat, Sep 30, 2023 at 07:40:34PM +0530, General Email wrote:
>> By the way, I don't understand how the default certificate can be abused.
> 
> It is not signed by a trusted CA, hence your browser cannot tell if it
> is speaking to your legitimate web server, or to some malware lurking
> in between. Perhaps your web trafic is not worth being evesdropped, but
> consider a malware could inject an exploit against your browser in your
> web trafic. The attacker could just be an infected machine on the same
> LAN.
> 
> The security level of an untrusted ceritificate is not much better than
> plain text HTTP. 
> 
> -- 
> Emmanuel Dreyfus
> m...@netbsd.org

Re: Please support/enable https by default in the Apache web sever.

[Stefan Eissing via dev]

> Am 30.09.2023 um 14:04 schrieb Will Fatherley :
> 
> 
> Please support/enable https by default in the Apache web server.
> 
> HTTPS is supported already by default. I like the idea of enabling by 
> default, but as it stands now probably should not be done as the generation 
> of keying material is required; the certification of keying material, while 
> capable of being automated, may become overburdened or more easily abused; 
> and other such complications related to authentication.

The capabilities are all there. It's a matter how your Apache is configured on 
install by whatever distribution you use. Since we do not provide installation 
packages, the project can not solve this for you.

Kind Regards,
Stefan

Re: pytest: 3 minutes gap or long single test runtime

[Stefan Eissing via dev]

> Am 13.09.2023 um 22:14 schrieb Rainer Jung :
> 
> Hi all,
> 
> when running the current pytest, I see a gap between two specific test 
> outputs of more than three minutes:
> 
> ...
> 13.09.2023 21:47:46.220943 
> modules/http2/test_712_buffering.py::TestBuffering::test_h2_712_03 PASSED [ 
> 39%]
> 13.09.2023 21:50:55.456457 
> modules/md/test_001_store.py::TestStore::test_md_001_001 PASSED [ 39%]
> ...
> 
> I assume the lines are written at the end of the respective test, so either 
> modules/md/test_001_store.py::TestStore::test_md_001_001 takes so long, or 
> the teardown after the test before it or startup befor thos test.
> 
> Before I try to investigate more: is this happening only here, or does 
> someone else also see this?

I do not see any noticeable delay in starting the mod_md tests on my machine. 
The gap you see indicate to a startup problem, maybe until pebble starts 
responding?

> 
> Thanks and regards,
> 
> Rainer

Re: svn commit: r1912181 - /httpd/httpd/branches/2.4.x/STATUS

[Stefan Eissing via dev]

> Am 08.09.2023 um 14:47 schrieb Ruediger Pluem :
> 
> 
> 
> On 9/8/23 9:43 AM, ic...@apache.org wrote:
>> Author: icing
>> Date: Fri Sep  8 07:43:17 2023
>> New Revision: 1912181
>> 
>> URL: http://svn.apache.org/viewvc?rev=1912181&view=rev
>> Log:
>> back port proposal
>> 
>> Modified:
>>httpd/httpd/branches/2.4.x/STATUS
>> 
>> Modified: httpd/httpd/branches/2.4.x/STATUS
>> URL: 
>> http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?rev=1912181&r1=1912180&r2=1912181&view=diff
>> ==
>> --- httpd/httpd/branches/2.4.x/STATUS (original)
>> +++ httpd/httpd/branches/2.4.x/STATUS Fri Sep  8 07:43:17 2023
>> @@ -214,6 +214,14 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK:
>> svn merge -c 1912015 ^/httpd/httpd/trunk .
>>  +1: rjung, gbechis
>> 
>> +  *) mod_proxy_http2: fix `X-Forward-Host` header to carry the correct 
>> value.
> 
> I think mod_proxy_http2 is CTR.

Oh, thanks for the reminder. I completely forgot. -.-

> 
> Regards
> 
> Rüdiger
> 

Re: mod_ssl SSL_OP_IGNORE_UNEXPECTED_EOF: "unexpected eof while reading"

[Stefan Eissing via dev]

> Am 07.09.2023 um 18:46 schrieb Yann Ylavic :
> 
> On Thu, Sep 7, 2023 at 6:09 PM Yann Ylavic  wrote:
>> 
>> On Wed, Aug 30, 2023 at 1:22 PM Rainer Jung  wrote:
>>> 
>>> OpenSSL 3 flags some abortive shutdowns as an error different to what
>>> 1.1.1 did. This results in info log output in httpd:
>>> 
>>> [Tue Aug 29 12:33:06.787210 2023] [ssl:info] [pid 1994673:tid 1994737]
>>> SSL Library Error: error:0A000126:SSL routines::unexpected eof while reading
>>> [Tue Aug 29 12:33:06.787374 2023] [ssl:info] [pid 1994673:tid 1994737]
>>> [client 1.2.3.4:54790] AH01998: Connection closed to child 215 with
>>> abortive shutdown (server myserver:443)
>> 
>> The info looks legit to me (someone closed the connection with no
>> close_notify), possibly we want to log it at APLOG_DEBUG/TRACEx still
>> if it happens too often?
>> We don't do that though for SSL_ERROR_ZERO_RETURN in openssl < 3, but
>> maybe we should too like in the attached patch (instead of r1912015)?
> 
> Scratch that patch, SSL_ERROR_ZERO_RETURN is actually when
> close_notify was received, we'd rather need to test SSL_ERROR_SYSCALL
> && errno == 0 with openssl < 0, which is more tricky in httpd with the
> EOS bucket vs APR_EOF.
> Hm, not sure we want to complicate this more..

I never understood the use for this in http/1.1 or newer. request and responses 
have their own termination and do not need anything for that from TLS.

And if a server send a complete response, there is no guarantee that the client 
received it in full. Think intermediaries.

Am I missing something?

Cheers,
Stefan

>> 
>> Regards;
>> Yann.

Re: mod_ssl SSL_OP_IGNORE_UNEXPECTED_EOF: "unexpected eof while reading"

[Stefan Eissing via dev]

> Am 30.08.2023 um 13:21 schrieb Rainer Jung :
> 
> Hi there,
> 
> OpenSSL 3 flags some abortive shutdowns as an error different to what 1.1.1 
> did. This results in info log output in httpd:
> 
> [Tue Aug 29 12:33:06.787210 2023] [ssl:info] [pid 1994673:tid 1994737] SSL 
> Library Error: error:0A000126:SSL routines::unexpected eof while reading
> [Tue Aug 29 12:33:06.787374 2023] [ssl:info] [pid 1994673:tid 1994737] 
> [client 1.2.3.4:54790] AH01998: Connection closed to child 215 with abortive 
> shutdown (server myserver:443)
> 
> Some background is given in
> 
>  https://github.com/openssl/openssl/issues/18866
> 
> They introduced a new context option "SSL_OP_IGNORE_UNEXPECTED_EOF" to 
> suppress this. Some other software now sets it with SSL_CTX_set_options():
> 
> - nginx
> 
> https://github.com/nginx/nginx/commit/5155845ce4453a07d60e2ce43946c9181bc311fa
> 
> - PHP
> 
> https://github.com/php/php-src/pull/8558/commits/55be0f489e390d28892a07c32d45a404c62fc9f2
> 
> I suggest to adopt it, ie. set it if the option is available.
> 
> WDYT?

+1 to setting this for our users sake. I withhold my opinion about this stupid 
OpenSSL change...oops.

> 
> Best regards,
> 
> Rainer

Re: 2.4.x fails to compile

[Stefan Eissing via dev]

Nevermind, this change is already in https://github.com/apache/httpd/pull/366, 
so if we bring that in, all should be well.

> Am 22.08.2023 um 13:48 schrieb Stefan Eissing via dev :
> 
> I believe we can add that to the backport proposal without resetting the 
> votes.
> 
>> Am 22.08.2023 um 12:57 schrieb Ruediger Pluem :
>> 
>> Currently 2.4.x fails to compile for me with the following error:
>> 
>> In file included from h2_c1_io.c:24:
>> h2_c1_io.c: In function ‘pass_output’:
>> /usr/src/apache/httpd-2.4.x/include/http_log.h:495:14: warning: ‘rv’ may be 
>> used uninitialized in this function
>> [-Wmaybe-uninitialized]
>> ap_log_cerror_(file, line, mi, level, status, c, __VA_ARGS__); \
>> ^~
>> h2_c1_io.c:264:18: note: ‘rv’ was declared here
>>apr_status_t rv;
>> ^~
>> 
>> 
>> The following patch fixes this. It is part of r1910507 which is not 
>> backported yet.
>> 
>> Index: modules/http2/h2_c1_io.c
>> ===
>> --- modules/http2/h2_c1_io.c (revision 1911839)
>> +++ modules/http2/h2_c1_io.c (working copy)
>> @@ -267,7 +267,7 @@
>>/* recursive call, may be triggered by an H2EOS bucket
>> * being destroyed and triggering sending more data? */
>>AP_DEBUG_ASSERT(0);
>> -ap_log_cerror(APLOG_MARK, APLOG_ERR, rv, c, APLOGNO(10456)
>> +ap_log_cerror(APLOG_MARK, APLOG_ERR, 0, c, APLOGNO(10456)
>>  "h2_c1_io(%ld): recursive call of h2_c1_io_pass. "
>>  "Denied to prevent output corruption. This "
>>  "points to a bug in the HTTP/2 implementation.",
>> 
>> 
>> Not sure how we proceed best from here. If we commit it to 2.4.x (after 
>> appropriate voting of course) it would break the current
>> backport proposal. But as the backport proposal is a PR it might be easy to 
>> take out this small part of the proposal.
>> 
>> Regards
>> 
>> Rüdiger
> 

Re: 2.4.x fails to compile

[Stefan Eissing via dev]

I believe we can add that to the backport proposal without resetting the votes.

> Am 22.08.2023 um 12:57 schrieb Ruediger Pluem :
> 
> Currently 2.4.x fails to compile for me with the following error:
> 
> In file included from h2_c1_io.c:24:
> h2_c1_io.c: In function ‘pass_output’:
> /usr/src/apache/httpd-2.4.x/include/http_log.h:495:14: warning: ‘rv’ may be 
> used uninitialized in this function
> [-Wmaybe-uninitialized]
>  ap_log_cerror_(file, line, mi, level, status, c, __VA_ARGS__); \
>  ^~
> h2_c1_io.c:264:18: note: ‘rv’ was declared here
> apr_status_t rv;
>  ^~
> 
> 
> The following patch fixes this. It is part of r1910507 which is not 
> backported yet.
> 
> Index: modules/http2/h2_c1_io.c
> ===
> --- modules/http2/h2_c1_io.c (revision 1911839)
> +++ modules/http2/h2_c1_io.c (working copy)
> @@ -267,7 +267,7 @@
> /* recursive call, may be triggered by an H2EOS bucket
>  * being destroyed and triggering sending more data? */
> AP_DEBUG_ASSERT(0);
> -ap_log_cerror(APLOG_MARK, APLOG_ERR, rv, c, APLOGNO(10456)
> +ap_log_cerror(APLOG_MARK, APLOG_ERR, 0, c, APLOGNO(10456)
>   "h2_c1_io(%ld): recursive call of h2_c1_io_pass. "
>   "Denied to prevent output corruption. This "
>   "points to a bug in the HTTP/2 implementation.",
> 
> 
> Not sure how we proceed best from here. If we commit it to 2.4.x (after 
> appropriate voting of course) it would break the current
> backport proposal. But as the backport proposal is a PR it might be easy to 
> take out this small part of the proposal.
> 
> Regards
> 
> Rüdiger

Re: new HTTPProtocolOption for C-L+chunked?

[Stefan Eissing via dev]

> Am 21.08.2023 um 12:20 schrieb Yann Ylavic :
> 
> On Wed, Aug 16, 2023 at 1:43 PM Ruediger Pluem  wrote:
>> 
>> On 8/16/23 1:32 PM, Eric Covener wrote:
> So a few questions:
> 
> - Is it reasonable as a standalone additional HTTPProtocolOption to
> decide the behavior?
> - Thoughts on behavior change in 2.4.x?
> - 400 as a status code?
> 
> https://httpwg.org/specs/rfc9112.html#rfc.section.6.1.p.15
> 
> A server MAY reject a request that contains both Content-Length and
> Transfer-Encoding or process such a request in accordance with the
> Transfer-Encoding alone. Regardless, the server MUST close the
> connection after responding to such a request to avoid the potential
> attacks.
 
 We currently ignore the content-length header, proceed and close the 
 connection
 afterwards as suggested above. Do you suggest that we should reject such 
 requests
 based on a configuration setting?
>>> 
>>> Yes, reject when both are set.
>>> 
>> 
>> Sounds fine for me as long as we don't make it the default, at least not in 
>> 2.4
> 
> Fine by me too, likely those requests come mainly/solely from the
> usual suspects (pentesters, auditors, papers..), so I'd be fine with
> blocking by default with an opt-out too (eg. HttpProtocolOptions
> Allow_CL+TE). I've never seen a "legitimate" request with both set
> personally, if it happens for some app it might be interesting for the
> users to know it and fix their chain, we've done the same for "Strict"
> and "Allow0.9" without too much pain IIRC.

+1 as configurable with default to keep current 2.4.x behaviour.

Cheers,
Stefan

release?

[Stefan Eissing via dev]

How are people feeling about another release? 

Since I have tons of bugfixes in 2.4.x and some pending features to port back, 
I offer to RM this.

We have 5 items in 2.4.x/STATUS which lack votes. Would be nice if people could 
find time to look into those where they feel comfortable to vote on.

Cheers,
Stefan

drumming the backport drums

[Stefan Eissing via dev]

Just updated https://github.com/apache/httpd/pull/366 to tweak the MMN magic 
again. 

I could really use 2 votes on the backport of this...it even passes the empty 
ALOGNO CI test!

Thanks for the help,
Stefan

Re: svn commit: r1910828 - /httpd/httpd/branches/2.4.x/docs/manual/mod/mod_http2.xml

[Stefan Eissing via dev]

Oh, thanks!

> Am 06.07.2023 um 22:41 schrieb jaillet...@apache.org:
> 
> Author: jailletc36
> Date: Thu Jul  6 20:41:34 2023
> New Revision: 1910828
> 
> URL: http://svn.apache.org/viewvc?rev=1910828&view=rev
> Log:
> Unless I missed somthing:
>  - H2StreamTimeout has been introduced in 2.4.55
>  - H2MaxDataFrameLen and H2MaxDataFrameLen will be available in the next 
> 2.4.58.
> 
> Modified:
>httpd/httpd/branches/2.4.x/docs/manual/mod/mod_http2.xml
> 
> Modified: httpd/httpd/branches/2.4.x/docs/manual/mod/mod_http2.xml
> URL: 
> http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/docs/manual/mod/mod_http2.xml?rev=1910828&r1=1910827&r2=1910828&view=diff
> ==
> --- httpd/httpd/branches/2.4.x/docs/manual/mod/mod_http2.xml (original)
> +++ httpd/httpd/branches/2.4.x/docs/manual/mod/mod_http2.xml Thu Jul  6 
> 20:41:34 2023
> @@ -1012,7 +1012,7 @@ H2TLSCoolDownSecs 0
> virtual host
> directory
> 
> -Available in version 2.5.1 and later.
> +Available in version 2.4.55 and later.
> 
> 
> 
> @@ -1031,7 +1031,7 @@ H2TLSCoolDownSecs 0
> server config
> virtual host
> 
> -Available in version 2.5.1 and later.
> +Available in version 2.4.58 and later.
> 
> 
> 
> @@ -1057,7 +1057,7 @@ H2TLSCoolDownSecs 0
> directory
> .htaccess
> 
> -Available in version 2.5.1 and later.
> +Available in version 2.4.58 and later.
> 
> 
> 
> 
> 

Re: svn commit: r1910704 - /httpd/httpd/trunk/modules/proxy/proxy_util.c

[Stefan Eissing via dev]

> Am 03.07.2023 um 11:09 schrieb Ruediger Pluem :
> 
> 
> 
> On 7/3/23 10:17 AM, Stefan Eissing via dev wrote:
>> 
>> 
>>> Am 30.06.2023 um 17:22 schrieb Stefan Eissing via dev 
>>> :
>>> 
>>> 
>>> 
>>>> Am 30.06.2023 um 16:45 schrieb Ruediger Pluem :
>>>> 
>>>> 
>>>> 
>>>> On 6/30/23 4:15 PM, Stefan Eissing via dev wrote:
>>>>> 
>>>>> 
>>>>>> Am 30.06.2023 um 15:56 schrieb Yann Ylavic :
>>>>>> 
>>>>>> On Fri, Jun 30, 2023 at 2:44 PM Ruediger Pluem  wrote:
>>>>>>> 
>>>>>>> On 6/30/23 11:08 AM, ic...@apache.org wrote:
>>>>>>>> Author: icing
>>>>>>>> Date: Fri Jun 30 09:08:23 2023
>>>>>>>> New Revision: 1910704
>>>>>>>> 
>>>>>>>> URL: http://svn.apache.org/viewvc?rev=1910704&view=rev
>>>>>>>> Log:
>>>>>>>> proxy: in proxy tunnels, use the smaller timeout value of
>>>>>>>>client and origin as timeout for polling the tunnel.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Modified:
>>>>>>>> httpd/httpd/trunk/modules/proxy/proxy_util.c
>>>>>>>> 
>>>>>>>> Modified: httpd/httpd/trunk/modules/proxy/proxy_util.c
>>>>>>>> URL: 
>>>>>>>> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/proxy/proxy_util.c?rev=1910704&r1=1910703&r2=1910704&view=diff
>>>>>>>> ==
>>>>>>>> --- httpd/httpd/trunk/modules/proxy/proxy_util.c (original)
>>>>>>>> +++ httpd/httpd/trunk/modules/proxy/proxy_util.c Fri Jun 30 09:08:23 
>>>>>>>> 2023
>>>>>>>> @@ -4921,9 +4921,9 @@ PROXY_DECLARE(apr_status_t) ap_proxy_tun
>>>>>>>>  apr_socket_timeout_get(tunnel->origin->pfd->desc.s, &origin_timeout);
>>>>>>>>  apr_socket_opt_set(tunnel->origin->pfd->desc.s, APR_SO_NONBLOCK, 1);
>>>>>>>> 
>>>>>>>> -/* Defaults to the biggest timeout of both connections */
>>>>>>>> -tunnel->timeout = (origin_timeout >= 0 && origin_timeout > 
>>>>>>>> client_timeout)?
>>>>>>>> -  origin_timeout : client_timeout;
>>>>>>>> +/* Defaults to the smallest timeout of both connections */
>>>>>>>> +tunnel->timeout = (client_timeout >= 0 && client_timeout < 
>>>>>>>> origin_timeout ?
>>>>>>>> +   client_timeout : origin_timeout);
>>>>>>> 
>>>>>>> Why?
>>>>>> 
>>>>>> We discussed this (quickly) with Stefan on
>>>>>> https://github.com/apache/httpd/pull/366, but hey the commit is here
>>>>>> for review finally :)
>>>>>> 
>>>>>>> It was the other way round on purpose, e.g. if Timeout is set to 5 for 
>>>>>>> a small front end timeout and ProxyTimeout is set to
>>>>>>> e.g. 600 to keep Websockets open for 10 minutes.
>>>>>> 
>>>>>> It seems to me that using Timeout (5s) here is a valid case too if
>>>>>> Timeout < ProxyTimeout (as in your example) is a way to limit how long
>>>>>> a client can consume httpd resources.
>>>>>> So maybe we should only use the backend timeout which is an easy(er)
>>>>>> way for the user to control this?
>>>>> 
>>>>> So, the goal is to allow someone keeping the websocket open for longer
>>>>> than we usually allow for HTTP requests, to set a long ProxyTimeout or
>>>>> timeout parameter to ProxyPass.
>>>>> 
>>>>> For HTTP/1.1 that would override the connection Timeout, since the tunnel
>>>>> poll would only use the largest value.
>>>>> 
>>>>> For HTTP/2 I have to check how that how to accomplish that. The working
>>>>> there is different.
>>>> 
>>>> Sorry for being a bit grumpy above, but this came out of the blue for me. 
>>>> It breaks an important use case for me an

Re: svn commit: r1910704 - /httpd/httpd/trunk/modules/proxy/proxy_util.c

[Stefan Eissing via dev]

> Am 30.06.2023 um 17:22 schrieb Stefan Eissing via dev :
> 
> 
> 
>> Am 30.06.2023 um 16:45 schrieb Ruediger Pluem :
>> 
>> 
>> 
>> On 6/30/23 4:15 PM, Stefan Eissing via dev wrote:
>>> 
>>> 
>>>> Am 30.06.2023 um 15:56 schrieb Yann Ylavic :
>>>> 
>>>> On Fri, Jun 30, 2023 at 2:44 PM Ruediger Pluem  wrote:
>>>>> 
>>>>> On 6/30/23 11:08 AM, ic...@apache.org wrote:
>>>>>> Author: icing
>>>>>> Date: Fri Jun 30 09:08:23 2023
>>>>>> New Revision: 1910704
>>>>>> 
>>>>>> URL: http://svn.apache.org/viewvc?rev=1910704&view=rev
>>>>>> Log:
>>>>>> proxy: in proxy tunnels, use the smaller timeout value of
>>>>>> client and origin as timeout for polling the tunnel.
>>>>>> 
>>>>>> 
>>>>>> Modified:
>>>>>>  httpd/httpd/trunk/modules/proxy/proxy_util.c
>>>>>> 
>>>>>> Modified: httpd/httpd/trunk/modules/proxy/proxy_util.c
>>>>>> URL: 
>>>>>> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/proxy/proxy_util.c?rev=1910704&r1=1910703&r2=1910704&view=diff
>>>>>> ==
>>>>>> --- httpd/httpd/trunk/modules/proxy/proxy_util.c (original)
>>>>>> +++ httpd/httpd/trunk/modules/proxy/proxy_util.c Fri Jun 30 09:08:23 2023
>>>>>> @@ -4921,9 +4921,9 @@ PROXY_DECLARE(apr_status_t) ap_proxy_tun
>>>>>>   apr_socket_timeout_get(tunnel->origin->pfd->desc.s, &origin_timeout);
>>>>>>   apr_socket_opt_set(tunnel->origin->pfd->desc.s, APR_SO_NONBLOCK, 1);
>>>>>> 
>>>>>> -/* Defaults to the biggest timeout of both connections */
>>>>>> -tunnel->timeout = (origin_timeout >= 0 && origin_timeout > 
>>>>>> client_timeout)?
>>>>>> -  origin_timeout : client_timeout;
>>>>>> +/* Defaults to the smallest timeout of both connections */
>>>>>> +tunnel->timeout = (client_timeout >= 0 && client_timeout < 
>>>>>> origin_timeout ?
>>>>>> +   client_timeout : origin_timeout);
>>>>> 
>>>>> Why?
>>>> 
>>>> We discussed this (quickly) with Stefan on
>>>> https://github.com/apache/httpd/pull/366, but hey the commit is here
>>>> for review finally :)
>>>> 
>>>>> It was the other way round on purpose, e.g. if Timeout is set to 5 for a 
>>>>> small front end timeout and ProxyTimeout is set to
>>>>> e.g. 600 to keep Websockets open for 10 minutes.
>>>> 
>>>> It seems to me that using Timeout (5s) here is a valid case too if
>>>> Timeout < ProxyTimeout (as in your example) is a way to limit how long
>>>> a client can consume httpd resources.
>>>> So maybe we should only use the backend timeout which is an easy(er)
>>>> way for the user to control this?
>>> 
>>> So, the goal is to allow someone keeping the websocket open for longer
>>> than we usually allow for HTTP requests, to set a long ProxyTimeout or
>>> timeout parameter to ProxyPass.
>>> 
>>> For HTTP/1.1 that would override the connection Timeout, since the tunnel
>>> poll would only use the largest value.
>>> 
>>> For HTTP/2 I have to check how that how to accomplish that. The working
>>> there is different.
>> 
>> Sorry for being a bit grumpy above, but this came out of the blue for me. It 
>> breaks an important use case for me and the use case
>> for the other way round was not clear to me. Maybe we can find a solution 
>> that addresses both use cases at best by default and
>> automatically. Any pointers for your use case such that I can have a look 
>> and be more constructive :-).
>> 
> 
> Thanks that you spoke up! I heard no grumpiness. ;)

Ok, testing how things *REALLY* work here, I stumbled upon:

mod_proxy_http.c:1570
/* Let proxy tunnel forward everything within this thread */
req->tunnel->timeout = req->idle_timeout;
status = ap_proxy_tunnel_run(req->tunnel);

which overrides everything we discussed. So, how do we want this to work and 
who has the final say?

- Stefan

Re: svn commit: r1910704 - /httpd/httpd/trunk/modules/proxy/proxy_util.c

[Stefan Eissing via dev]

> Am 30.06.2023 um 16:45 schrieb Ruediger Pluem :
> 
> 
> 
> On 6/30/23 4:15 PM, Stefan Eissing via dev wrote:
>> 
>> 
>>> Am 30.06.2023 um 15:56 schrieb Yann Ylavic :
>>> 
>>> On Fri, Jun 30, 2023 at 2:44 PM Ruediger Pluem  wrote:
>>>> 
>>>> On 6/30/23 11:08 AM, ic...@apache.org wrote:
>>>>> Author: icing
>>>>> Date: Fri Jun 30 09:08:23 2023
>>>>> New Revision: 1910704
>>>>> 
>>>>> URL: http://svn.apache.org/viewvc?rev=1910704&view=rev
>>>>> Log:
>>>>> proxy: in proxy tunnels, use the smaller timeout value of
>>>>>  client and origin as timeout for polling the tunnel.
>>>>> 
>>>>> 
>>>>> Modified:
>>>>>   httpd/httpd/trunk/modules/proxy/proxy_util.c
>>>>> 
>>>>> Modified: httpd/httpd/trunk/modules/proxy/proxy_util.c
>>>>> URL: 
>>>>> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/proxy/proxy_util.c?rev=1910704&r1=1910703&r2=1910704&view=diff
>>>>> ==
>>>>> --- httpd/httpd/trunk/modules/proxy/proxy_util.c (original)
>>>>> +++ httpd/httpd/trunk/modules/proxy/proxy_util.c Fri Jun 30 09:08:23 2023
>>>>> @@ -4921,9 +4921,9 @@ PROXY_DECLARE(apr_status_t) ap_proxy_tun
>>>>>apr_socket_timeout_get(tunnel->origin->pfd->desc.s, &origin_timeout);
>>>>>apr_socket_opt_set(tunnel->origin->pfd->desc.s, APR_SO_NONBLOCK, 1);
>>>>> 
>>>>> -/* Defaults to the biggest timeout of both connections */
>>>>> -tunnel->timeout = (origin_timeout >= 0 && origin_timeout > 
>>>>> client_timeout)?
>>>>> -  origin_timeout : client_timeout;
>>>>> +/* Defaults to the smallest timeout of both connections */
>>>>> +tunnel->timeout = (client_timeout >= 0 && client_timeout < 
>>>>> origin_timeout ?
>>>>> +   client_timeout : origin_timeout);
>>>> 
>>>> Why?
>>> 
>>> We discussed this (quickly) with Stefan on
>>> https://github.com/apache/httpd/pull/366, but hey the commit is here
>>> for review finally :)
>>> 
>>>> It was the other way round on purpose, e.g. if Timeout is set to 5 for a 
>>>> small front end timeout and ProxyTimeout is set to
>>>> e.g. 600 to keep Websockets open for 10 minutes.
>>> 
>>> It seems to me that using Timeout (5s) here is a valid case too if
>>> Timeout < ProxyTimeout (as in your example) is a way to limit how long
>>> a client can consume httpd resources.
>>> So maybe we should only use the backend timeout which is an easy(er)
>>> way for the user to control this?
>> 
>> So, the goal is to allow someone keeping the websocket open for longer
>> than we usually allow for HTTP requests, to set a long ProxyTimeout or
>> timeout parameter to ProxyPass.
>> 
>> For HTTP/1.1 that would override the connection Timeout, since the tunnel
>> poll would only use the largest value.
>> 
>> For HTTP/2 I have to check how that how to accomplish that. The working
>> there is different.
> 
> Sorry for being a bit grumpy above, but this came out of the blue for me. It 
> breaks an important use case for me and the use case
> for the other way round was not clear to me. Maybe we can find a solution 
> that addresses both use cases at best by default and
> automatically. Any pointers for your use case such that I can have a look and 
> be more constructive :-).
> 

Thanks that you spoke up! I heard no grumpiness. ;)

Re: svn commit: r1910704 - /httpd/httpd/trunk/modules/proxy/proxy_util.c

[Stefan Eissing via dev]

> Am 30.06.2023 um 15:56 schrieb Yann Ylavic :
> 
> On Fri, Jun 30, 2023 at 2:44 PM Ruediger Pluem  wrote:
>> 
>> On 6/30/23 11:08 AM, ic...@apache.org wrote:
>>> Author: icing
>>> Date: Fri Jun 30 09:08:23 2023
>>> New Revision: 1910704
>>> 
>>> URL: http://svn.apache.org/viewvc?rev=1910704&view=rev
>>> Log:
>>> proxy: in proxy tunnels, use the smaller timeout value of
>>>   client and origin as timeout for polling the tunnel.
>>> 
>>> 
>>> Modified:
>>>httpd/httpd/trunk/modules/proxy/proxy_util.c
>>> 
>>> Modified: httpd/httpd/trunk/modules/proxy/proxy_util.c
>>> URL: 
>>> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/proxy/proxy_util.c?rev=1910704&r1=1910703&r2=1910704&view=diff
>>> ==
>>> --- httpd/httpd/trunk/modules/proxy/proxy_util.c (original)
>>> +++ httpd/httpd/trunk/modules/proxy/proxy_util.c Fri Jun 30 09:08:23 2023
>>> @@ -4921,9 +4921,9 @@ PROXY_DECLARE(apr_status_t) ap_proxy_tun
>>> apr_socket_timeout_get(tunnel->origin->pfd->desc.s, &origin_timeout);
>>> apr_socket_opt_set(tunnel->origin->pfd->desc.s, APR_SO_NONBLOCK, 1);
>>> 
>>> -/* Defaults to the biggest timeout of both connections */
>>> -tunnel->timeout = (origin_timeout >= 0 && origin_timeout > 
>>> client_timeout)?
>>> -  origin_timeout : client_timeout;
>>> +/* Defaults to the smallest timeout of both connections */
>>> +tunnel->timeout = (client_timeout >= 0 && client_timeout < 
>>> origin_timeout ?
>>> +   client_timeout : origin_timeout);
>> 
>> Why?
> 
> We discussed this (quickly) with Stefan on
> https://github.com/apache/httpd/pull/366, but hey the commit is here
> for review finally :)
> 
>> It was the other way round on purpose, e.g. if Timeout is set to 5 for a 
>> small front end timeout and ProxyTimeout is set to
>> e.g. 600 to keep Websockets open for 10 minutes.
> 
> It seems to me that using Timeout (5s) here is a valid case too if
> Timeout < ProxyTimeout (as in your example) is a way to limit how long
> a client can consume httpd resources.
> So maybe we should only use the backend timeout which is an easy(er)
> way for the user to control this?

So, the goal is to allow someone keeping the websocket open for longer
than we usually allow for HTTP requests, to set a long ProxyTimeout or
timeout parameter to ProxyPass.

For HTTP/1.1 that would override the connection Timeout, since the tunnel
poll would only use the largest value.

For HTTP/2 I have to check how that how to accomplish that. The working
there is different.

Re: http2 backports need one vote

[Stefan Eissing via dev]

Thanks, Yann!

Merged into 2.4.x as r1910699.

> Am 29.06.2023 um 10:30 schrieb Stefan Eissing via dev :
> 
> The cumulative mod_http2 backport proposal via PR 
> https://github.com/apache/httpd/pull/364 needs one more vote.
> 
> I appreciate if someone could add his vote to this.
> 
> Kind Regards,
> Stefan

http2 backports need one vote

[Stefan Eissing via dev]

The cumulative mod_http2 backport proposal via PR 
https://github.com/apache/httpd/pull/364 needs one more vote.

I appreciate if someone could add his vote to this.

Kind Regards,
Stefan

Re: svn commit: r1910649 - in /httpd/httpd/trunk/test: clients/h2ws.c modules/http2/test_800_websockets.py modules/http2/ws_server.py

[Stefan Eissing via dev]

Hi Yann,

> Am 28.06.2023 um 11:34 schrieb Yann Ylavic :
> 
> Hi Stefan,
> 
>> 
>> Modified:
>>httpd/httpd/trunk/test/clients/h2ws.c
>>httpd/httpd/trunk/test/modules/http2/test_800_websockets.py
>>httpd/httpd/trunk/test/modules/http2/ws_server.py
> 
> Are the ws tests supposed to run/pass in ci? They don't currently, and
> ISTR from the PR that some python libs versions prevent them from
> passing so I'm wondering if disabing isn't working there or if it's a
> real failure..

Ah, forgot to merge those checks from the PR into trunk. Thanks for the 
reminder.

Added in r1910654. Let's see if CI will be happy.

> 
> 
> Regards;
> Yann.

Re: HTTP/2 WebSockets, PR

[Stefan Eissing via dev]

This has been reviewed by Master Yann (many thanks!) and, with changes based on 
that, been merged in r1910507 to trunk.

RFC 8441 now supported by Apache httpd dev on non-Windows platforms.

Kind Regards,
Stefan

> Am 15.06.2023 um 15:15 schrieb Stefan Eissing via dev :
> 
> Adding HTTP/2 WebSockets support to the server.
> 
> See: https://github.com/apache/httpd/pull/362
> 
> Status:
> 
> Works for the test cases I came up with so far. Will do more testing in the 
> next weeks.
> 
> What are the main changes?
> 
> core:
> - addition of 
> 
>  ap_get_conn_in_pollfd(
>conn_rec *c, 
>apr_pollfd_t *pfd,
>apr_interval_time_t *ptimeout);
> 
>  implemented as a hook. core provides it socket and timeout on "main" 
> connections. mod_http2 provides its input pipe fd on "secondary" connections 
> that were made for it.
> 
> mod_http2:
> - handling of CONNECT for WebSockets, check of correct headers
> - announce WebSockets support in HTTP/2 settings sent to the client
> - transform HTTP/2 WebSocket CONNECTs to internal GET requests with generated 
> "Sec-WebSocket-Key" headers, so that it appears internally as if it came via 
> HTTP/1.1.
> - check for 101 response or fail the CONNECT. Check the 101 for a matching 
> "Sec-WebSocket-Accept" header or fail.
> 
> mod_proxy:
> - make the proxy_tunnel code in proxy_util.c work in case it only has a 
> APR_POLL_FILE for the client side.
>  (Yann, please have a look and find my stupid mistakes!)
> 
> test
> - added test cases in pytest for mod_http2 (needs python3-websockets 
> installed)
>  The tests use a "ProxyPass xxx upgrade=websocket" configuration to a local 
> python websockets server that can perform a set of traffic cases.
> - added test/clients directory to build "h2ws", the client used in the new 
> tests
> 
> 
> Cheers,
> Stefan

Re: svn commit: r1910449 - /httpd/httpd/branches/2.4.x/STATUS

[Stefan Eissing via dev]

Cumulative patch for the outstanding backports of mod_http2 and mod_proxy_http2 
at https://github.com/apache/httpd/pull/364.

Added in 2.4.x STATUS for voting

> Am 16.06.2023 um 13:28 schrieb Stefan Eissing via dev :
> 
> Yeah, need to fold all these into a PR for 2.4.x probably.
> 
>> Am 16.06.2023 um 13:04 schrieb rpl...@apache.org:
>> 
>> Author: rpluem
>> Date: Fri Jun 16 11:04:17 2023
>> New Revision: 1910449
>> 
>> URL: http://svn.apache.org/viewvc?rev=1910449&view=rev
>> Log:
>> * Add comment [skip ci]
>> 
>> Modified:
>>   httpd/httpd/branches/2.4.x/STATUS
>> 
>> Modified: httpd/httpd/branches/2.4.x/STATUS
>> URL: 
>> http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?rev=1910449&r1=1910448&r2=1910449&view=diff
>> ==
>> --- httpd/httpd/branches/2.4.x/STATUS (original)
>> +++ httpd/httpd/branches/2.4.x/STATUS Fri Jun 16 11:04:17 2023
>> @@ -296,6 +296,9 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK:
>>svn merge -c 1910331,1910441 ^/httpd/httpd/trunk .
>> +1: icing
>> # reset vote due to addition of r1910441
>> + rpluem says: r1910441 has a conflict in modules/http2/h2_version.h
>> + and the patch for PR 66646 needs to go in before this one to avoid 
>> further
>> + conflicts.
>> 
>>  *) mod_http2: Fix for PR 66646.
>> Trunk version of patch:
>> 
>> 
> 

Re: svn commit: r1910449 - /httpd/httpd/branches/2.4.x/STATUS

[Stefan Eissing via dev]

Yeah, need to fold all these into a PR for 2.4.x probably.

> Am 16.06.2023 um 13:04 schrieb rpl...@apache.org:
> 
> Author: rpluem
> Date: Fri Jun 16 11:04:17 2023
> New Revision: 1910449
> 
> URL: http://svn.apache.org/viewvc?rev=1910449&view=rev
> Log:
> * Add comment [skip ci]
> 
> Modified:
>httpd/httpd/branches/2.4.x/STATUS
> 
> Modified: httpd/httpd/branches/2.4.x/STATUS
> URL: 
> http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?rev=1910449&r1=1910448&r2=1910449&view=diff
> ==
> --- httpd/httpd/branches/2.4.x/STATUS (original)
> +++ httpd/httpd/branches/2.4.x/STATUS Fri Jun 16 11:04:17 2023
> @@ -296,6 +296,9 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK:
> svn merge -c 1910331,1910441 ^/httpd/httpd/trunk .
>  +1: icing
>  # reset vote due to addition of r1910441
> + rpluem says: r1910441 has a conflict in modules/http2/h2_version.h
> + and the patch for PR 66646 needs to go in before this one to avoid 
> further
> + conflicts.
> 
>   *) mod_http2: Fix for PR 66646.
>  Trunk version of patch:
> 
> 

HTTP/2 WebSockets, PR

[Stefan Eissing via dev]

Adding HTTP/2 WebSockets support to the server.

See: https://github.com/apache/httpd/pull/362

Status:

Works for the test cases I came up with so far. Will do more testing in the 
next weeks.

What are the main changes?

core:
- addition of 

  ap_get_conn_in_pollfd(
conn_rec *c, 
apr_pollfd_t *pfd,
apr_interval_time_t *ptimeout);

  implemented as a hook. core provides it socket and timeout on "main" 
connections. mod_http2 provides its input pipe fd on "secondary" connections 
that were made for it.

mod_http2:
- handling of CONNECT for WebSockets, check of correct headers
- announce WebSockets support in HTTP/2 settings sent to the client
- transform HTTP/2 WebSocket CONNECTs to internal GET requests with generated 
"Sec-WebSocket-Key" headers, so that it appears internally as if it came via 
HTTP/1.1.
- check for 101 response or fail the CONNECT. Check the 101 for a matching 
"Sec-WebSocket-Accept" header or fail.

mod_proxy:
- make the proxy_tunnel code in proxy_util.c work in case it only has a 
APR_POLL_FILE for the client side.
  (Yann, please have a look and find my stupid mistakes!)

test
- added test cases in pytest for mod_http2 (needs python3-websockets installed)
  The tests use a "ProxyPass xxx upgrade=websocket" configuration to a local 
python websockets server that can perform a set of traffic cases.
- added test/clients directory to build "h2ws", the client used in the new tests


Cheers,
Stefan

Re: build trunk in windows

[Stefan Eissing via dev]

> Am 12.06.2023 um 15:33 schrieb jean-frederic clere :
> 
> On 5/4/23 11:31, Yann Ylavic wrote:
>> On Wed, May 3, 2023 at 2:54 PM jean-frederic clere  wrote:
>>> 
>>> On 4/24/23 18:25, Steffen wrote:
 There is a howto Building Apache and dependencies using CMake at
 
 https://www.apachelounge.com/viewtopic.php?t=8609
 
 
 
>>> 
>>> I ended fixing include/http_protocol.h see patch, did I miss something?
>> Looks like ap_h1_response_out_filter() is declared in
>> "include/mod_core.h" already, but without AP_CORE_DECLARE_NONSTD().
>> Not sure if we should remove the AP_CORE_DECLARE_NONSTD() in
>> "modules/http/http_filters.c" (where it's implemented) or add it in
>> the declaration. For instance ap_http_outerror_filter() has no
>> AP_CORE_DECLARE_NONSTD() anywhere..
> 
> OK I have fixed ap_h1_response_out_filter() to follow include/http_protocol.h


\o/

> 
>> Regards;
>> Yann.
> 
> -- 
> Cheers
> 
> Jean-Frederic
> 

Re: svn commit: r1910161 - in /httpd/httpd/trunk: changes-entries/ include/ modules/http/ test/modules/http2/

[Stefan Eissing via dev]

> Am 01.06.2023 um 15:21 schrieb Ruediger Pluem :
> 
> 
> 
> On 6/1/23 2:21 PM, ic...@apache.org wrote:
>> Author: icing
>> Date: Thu Jun  1 12:21:03 2023
>> New Revision: 1910161
>> 
>> URL: http://svn.apache.org/viewvc?rev=1910161&view=rev
>> Log:
>>  *) core: add `final_resp_passed` flag to request_rec to allow
>> ap_die() to judge if it can send out a response. Bump mmn.
>> Enable test cases that check errors during response body to
>> appear as error on client side.
>> 
>> 
>> Added:
>>httpd/httpd/trunk/changes-entries/resp_passed.txt
>> Modified:
>>httpd/httpd/trunk/include/ap_mmn.h
>>httpd/httpd/trunk/include/httpd.h
>>httpd/httpd/trunk/modules/http/http_filters.c
>>httpd/httpd/trunk/modules/http/http_request.c
>>httpd/httpd/trunk/test/modules/http2/test_008_ranges.py
>>httpd/httpd/trunk/test/modules/http2/test_500_proxy.py
>>httpd/httpd/trunk/test/modules/http2/test_601_h2proxy_twisted.py
>> 
> 
> 
>> Modified: httpd/httpd/trunk/modules/http/http_filters.c
>> URL: 
>> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/http/http_filters.c?rev=1910161&r1=1910160&r2=1910161&view=diff
>> ==
>> --- httpd/httpd/trunk/modules/http/http_filters.c (original)
>> +++ httpd/httpd/trunk/modules/http/http_filters.c Thu Jun  1 12:21:03 2023
>> @@ -1265,7 +1265,7 @@ AP_CORE_DECLARE_NONSTD(apr_status_t) ap_
>> 
>> if (ctx->final_status && ctx->final_header_only) {
>> /* The final RESPONSE has already been sent or is in front of 
>> `bcontent`
>> - * in the brigade. For a header_only respsone, remove all content 
>> buckets
>> + * in the brigade. For a header_only respone, remove all content 
>> buckets
> 
> Now the typo is different :-)

Spelling error forever! \o/

> 
>>  * up to the first EOS. On seeing EOS, we remove ourself and are 
>> done.
>>  * NOTE that `header_only` responses never generate trailes.
>>  */
> 
>> Modified: httpd/httpd/trunk/modules/http/http_request.c
>> URL: 
>> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/http/http_request.c?rev=1910161&r1=1910160&r2=1910161&view=diff
>> ==
>> --- httpd/httpd/trunk/modules/http/http_request.c (original)
>> +++ httpd/httpd/trunk/modules/http/http_request.c Thu Jun  1 12:21:03 2023
>> @@ -84,38 +84,25 @@ static void ap_die_r(int type, request_r
>> return;
>> }
>> 
>> -if (!ap_is_HTTP_VALID_RESPONSE(type)) {
>> -ap_filter_t *next;
>> -
>> -/*
>> - * Check if we still have the ap_http_header_filter in place. If
>> - * this is the case we should not ignore the error here because
>> - * it means that we have not sent any response at all and never
>> - * will. This is bad. Sent an internal server error instead.
>> - */
>> -next = r->output_filters;
>> -while (next && (next->frec != ap_http_header_filter_handle)) {
>> -   next = next->next;
>> -}
> 
> Out of curiosity: You changed to using the flag instead as the above did not 
> detect all cases correctly or because it is not
> performance optimal?

It did not catch all cases any longer since the httpd header filter does not 
remove itself any longer. This is a result of the RESPONSE buckets changes in 
trunk. So when ap_die() was called during response body processing, it added a 
500 body content to the response.

Instead of fiddling here with filter chain expectations, I found it more sane 
to keep the bit at request_rec. But it can be discussed if there is a better 
choice.

Cheers,
Stefan

> 
>> +/*
>> + * if we have already passed the final response down the
>> + * output filter chain, we cannot generate a second final
>> + * response here.
>> + */
>> +if (r->final_resp_passed) {
>> +return;
>> +}
>> 
>> -/*
>> - * If next != NULL then we left the while above because of
>> - * next->frec == ap_http_header_filter
>> - */
>> -if (next) {
>> -if (type != AP_FILTER_ERROR) {
>> -ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r, APLOGNO(01579)
>> -  "Invalid response status %i", type);
>> -}
>> -else {
>> -ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r, APLOGNO(02831)
>> -  "Response from AP_FILTER_ERROR");
>> -}
>> -type = HTTP_INTERNAL_SERVER_ERROR;
>> +if (!ap_is_HTTP_VALID_RESPONSE(type)) {
>> +if (type != AP_FILTER_ERROR) {
>> +ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r, APLOGNO(01579)
>> +  "Invalid response status %i", type);
>> }
>> else {
>> -return;
>> +ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r, APLOGNO(02831)
>> + 

Re: PR 66499

[Stefan Eissing via dev]

> Am 15.05.2023 um 09:31 schrieb Stefan Eissing via dev :
> 
> 
> 
>> Am 14.05.2023 um 21:27 schrieb Yann Ylavic :
>> 
>> On Fri, May 12, 2023 at 6:35 PM Stefan Eissing via dev
>>  wrote:
>>> 
>>> Regarding https://bz.apache.org/bugzilla/show_bug.cgi?id=66499 I have a 
>>> question.
>>> 
>>> When using httpd in a forward proxy setup ("ProxyRequests On"), we expect 
>>> absolute URLs in HTTP/1.1 requests. Fine.
>>> 
>>> When accessing such a setup via HTTP/2, we get :scheme, :auhority and :path 
>>> and, usually, do NOT want to convert that to absolute URIs in the reuqest 
>>> line. That is what 66499 complained about. However, in the forward proxy 
>>> case, we need it.
>>> 
>>> How is mod_http2 supposed to know which case is in play? Any ideas?
>> 
>> It can't know I agree, but possibly mod_h2 could fill in r->parsed_uri
>> when creating the request_rec (as if a full uri-path were received),
>> that's what proxy_detect() needs to allow forward-proxying (in
>> addition to ProxyRequests on). Reverse-proxying won't use
>> r->parsed_uri.{scheme,hostname} anyway so ProxyRequests on/off would
>> be the only criteria, which seems fine?
> 
> Hmm, sounds hacky. I think I'd rather add a directive like `H2ForwardProxy 
> on`.

Or `H2ProxyRequests` for consistency.

> 
>> PS: Since we are discussing PRs, maybe we can talk about PR 66597 :p
>> There it seems that in 2.4.x (i.e. !AP_HAS_RESPONSE_BUCKETS), the
>> H2_C2_REQUEST_IN filter will insert chunk encoding (via
>> read_and_chunk()) at AP_FTYPE_PROTOCOL, which is the same level as the
>> HTTP_IN filter supposed to consume this chunking (IIUC).
>> Could it be possible that H2_C2_REQUEST_IN gets added earlier than
>> HTTP_IN such that the order of the two is backward (i.e. the chunk
>> encoding is never consumed), which is why mod_proxy ends up
>> reading/forwarding chunked encoding as if HTTP_IN was not called?
> 
> Maybe, but I do not understand the difference between mod_proxy_* and 
> mod_cgid in chunked input processing. For the latter I have test cases that 
> work.
> 
> -Stefan
> 
>> So maybe the below patch would make the ordering more robust:
>> 
>> Index: modules/http2/h2_c2.c
>> ===
>> --- modules/http2/h2_c2.c(revision 1909607)
>> +++ modules/http2/h2_c2.c(working copy)
>> @@ -854,7 +854,7 @@ void h2_c2_register_hooks(void)
>>  NULL, AP_FTYPE_NETWORK);
>> 
>>ap_register_input_filter("H2_C2_REQUEST_IN", h2_c2_filter_request_in,
>> - NULL, AP_FTYPE_PROTOCOL);
>> + NULL, AP_FTYPE_PROTOCOL - 1);
>>ap_register_output_filter("H2_C2_RESPONSE_OUT", h2_c2_filter_response_out,
>>  NULL, AP_FTYPE_PROTOCOL);
>>ap_register_output_filter("H2_C2_TRAILERS_OUT", h2_c2_filter_trailers_out,
>> ?
>> 
>> 
>> Regards;
>> Yann.

Re: PR 66499

[Stefan Eissing via dev]

> Am 14.05.2023 um 21:27 schrieb Yann Ylavic :
> 
> On Fri, May 12, 2023 at 6:35 PM Stefan Eissing via dev
>  wrote:
>> 
>> Regarding https://bz.apache.org/bugzilla/show_bug.cgi?id=66499 I have a 
>> question.
>> 
>> When using httpd in a forward proxy setup ("ProxyRequests On"), we expect 
>> absolute URLs in HTTP/1.1 requests. Fine.
>> 
>> When accessing such a setup via HTTP/2, we get :scheme, :auhority and :path 
>> and, usually, do NOT want to convert that to absolute URIs in the reuqest 
>> line. That is what 66499 complained about. However, in the forward proxy 
>> case, we need it.
>> 
>> How is mod_http2 supposed to know which case is in play? Any ideas?
> 
> It can't know I agree, but possibly mod_h2 could fill in r->parsed_uri
> when creating the request_rec (as if a full uri-path were received),
> that's what proxy_detect() needs to allow forward-proxying (in
> addition to ProxyRequests on). Reverse-proxying won't use
> r->parsed_uri.{scheme,hostname} anyway so ProxyRequests on/off would
> be the only criteria, which seems fine?

Hmm, sounds hacky. I think I'd rather add a directive like `H2ForwardProxy on`.

> PS: Since we are discussing PRs, maybe we can talk about PR 66597 :p
> There it seems that in 2.4.x (i.e. !AP_HAS_RESPONSE_BUCKETS), the
> H2_C2_REQUEST_IN filter will insert chunk encoding (via
> read_and_chunk()) at AP_FTYPE_PROTOCOL, which is the same level as the
> HTTP_IN filter supposed to consume this chunking (IIUC).
> Could it be possible that H2_C2_REQUEST_IN gets added earlier than
> HTTP_IN such that the order of the two is backward (i.e. the chunk
> encoding is never consumed), which is why mod_proxy ends up
> reading/forwarding chunked encoding as if HTTP_IN was not called?

Maybe, but I do not understand the difference between mod_proxy_* and mod_cgid 
in chunked input processing. For the latter I have test cases that work.

-Stefan

> So maybe the below patch would make the ordering more robust:
> 
> Index: modules/http2/h2_c2.c
> ===
> --- modules/http2/h2_c2.c(revision 1909607)
> +++ modules/http2/h2_c2.c(working copy)
> @@ -854,7 +854,7 @@ void h2_c2_register_hooks(void)
>   NULL, AP_FTYPE_NETWORK);
> 
> ap_register_input_filter("H2_C2_REQUEST_IN", h2_c2_filter_request_in,
> - NULL, AP_FTYPE_PROTOCOL);
> + NULL, AP_FTYPE_PROTOCOL - 1);
> ap_register_output_filter("H2_C2_RESPONSE_OUT", h2_c2_filter_response_out,
>   NULL, AP_FTYPE_PROTOCOL);
> ap_register_output_filter("H2_C2_TRAILERS_OUT", h2_c2_filter_trailers_out,
> ?
> 
> 
> Regards;
> Yann.

PR 66499

[Stefan Eissing via dev]

Regarding https://bz.apache.org/bugzilla/show_bug.cgi?id=66499 I have a 
question.

When using httpd in a forward proxy setup ("ProxyRequests On"), we expect 
absolute URLs in HTTP/1.1 requests. Fine.

When accessing such a setup via HTTP/2, we get :scheme, :auhority and :path 
and, usually, do NOT want to convert that to absolute URIs in the reuqest line. 
That is what 66499 complained about. However, in the forward proxy case, we 
need it.

How is mod_http2 supposed to know which case is in play? Any ideas?

Cheers,
Stefan

http2 proxy_fcgi interop issue

[Stefan Eissing via dev]

Regarding https://bz.apache.org/bugzilla/show_bug.cgi?id=66597
I am unable to figure out what is going wrong there.

It seems mod_proxy_fcgi is not de-chunking request bodies and collecting them 
raw. Which *should* also be problematic in HTTP/1.1, but I have no test setup 
to verify this, really.

- Stefan

Re: [VOTE] Switch read/write repository from Subversion to Git

[Stefan Eissing via dev]

> Am 04.05.2023 um 10:34 schrieb Ruediger Pluem :
> 
> This is a formal vote on whether we should move our read/write repository 
> from Subversion to Git.
> This means that our latest read/write repository will be no longer available 
> via svn.apache.org. It
> will be available via Git at 
> https://gitbox.apache.org/repos/asf/httpd-site.git and 
> https://github.com/apache/httpd.git.
> Github also offers the possibility to use a Subversion client:
> https://docs.github.com/en/get-started/working-with-subversion-on-github/support-for-subversion-clients
> 
> 
> [ ]: Move the read/write repository from Subversion to Git and leverage the 
> features of Github (for now Actions and PR).
> [ ]: Move the read/write repository from Subversion to Git, but I don't want 
> to work with Github and I will only work with
> what gitbox.apache.org offers.
> [ ]: Leave everything as is.
> 

Thanks for calling this vote.

> [x]: Move the read/write repository from Subversion to Git and leverage the 
> features of Github (for now Actions and PR).

cheers, 
Stefan

Re: ci vs PR approvals? (was: [apache/httpd] Fix a possible NULL pointer dereference in hook_uri2file (PR #355))

[Stefan Eissing via dev]

> Am 03.05.2023 um 23:03 schrieb Christophe JAILLET 
> :
> 
> Le 03/05/2023 à 21:12, Eric Covener a écrit :
>> On Tue, Apr 25, 2023 at 2:45 PM Graham Leggett via dev
>>  wrote:
>>> 
>>> On 25 Apr 2023, at 07:45, Ruediger Pluem  wrote:
>>> 
>>> 2. Switching from Subversion to Git is mostly an emotional problem for me. 
>>> We have some closer ties to Subversion by some
>>>   overlaps in the community and via mod_dav_svn we kind of partially eat 
>>> our very own dogfood here by using Subversion.
>>>   We wouldn't do that any longer with Git. Plus it would switch another of 
>>> our development tools from an Apache license to GPL.
>>>   Apart from technical aspects that this change would create we should 
>>> check if all of the current active committers are fine
>>>   using Github. While people could use Gitbox and thus avoid Github when we 
>>> use Git I would like us to leverage the features of
>>>   Github when we would do this switch and I think this cannot be done if 
>>> active committers would have issues with Github.
>>> 
>>> 
>>> +1.
>>> 
>>> I've always found the fight about “must be git” to be really tedious. 
>>> Github supports both git and svn to this day, and people are free to use 
>>> what they prefer by using the interface they are most familiar with.
>>> 
>>> While Github is popular today, this is only because the goals of the owners 
>>> of Github are presently aligned with our goals. As Twitter has taught us, 
>>> goals change at any time and without warning.
>> Hi Graham -- it's a little unclear to me where this would put you
>> "vote" wise about moving to read/write Git.
>> Anyone else with a stake have an opinion? It has been since about 2019
>> since we last discussed it here, I am hoping people have warmed up to
>> it.
> 
> svn or git both fit my needs.
> 
> git would be slightly easier for me because of the feature to easily commit 
> only parts of changes of files (I think that some svn clients also support 
> it, but not the one I use)
> 
> github is great because it can be used for code review without the need to 
> commit something. A patch can be discussed, updated, improved, ... cleanly 
> before being merged. That's a great feature IMHO.
> 
> git/github would also make the project more attractive for others 
> contributions I think.
> 
> So, even if I personality really don't care for myself, I would +1 the sake 
> of the project.

Many +1s

> 
> Just my 2c,
> 
> CJ

ci jobs

[Stefan Eissing via dev]

FYI, github workflows: mod_http2 and mod_tls CI jobs are re-enabled in trunk 
and 2.4.x

Cheers,
Stefan

Re: pytest in trunk

[Stefan Eissing via dev]

Got pytest working again in trunk.

> Am 27.04.2023 um 09:25 schrieb Stefan Eissing via dev :
> 
> ...is no longer working for me since r1908574 by Yann.
> 
> Yann, you changed the cgi implementations. Some do no even run on my machine 
> due to wrong var names. What was the idea behind the changes? I assume they 
> are working on your system?

pytest in trunk

[Stefan Eissing via dev]

...is no longer working for me since r1908574 by Yann.

Yann, you changed the cgi implementations. Some do no even run on my machine 
due to wrong var names. What was the idea behind the changes? I assume they are 
working on your system?

Re: Question about 2.4.56 "client resets of HTTP/2 streams led to unwanted 500 errors" fix

[Stefan Eissing via dev]

> Am 31.03.2023 um 02:48 schrieb Jan Ehrhardt :
> 
> Stefan Eissing via dev in gmane.comp.apache.devel (Tue, 28 Mar 2023
> 10:16:34 +0200):
>> Am 28.03.2023 um 01:21 schrieb Robert L Mathews : 
>>> On 3/16/23 5:38 AM, Stefan Eissing via dev wrote:
>>> 
>>>> I am not familiar enough with mod_fcgi's operation to make a judgement on 
>>>> that.
>>> 
>>> As a followup to this, it turned out it was caused by the problem fixed 
>>> here:
>>> 
>>> https://github.com/apache/httpd/commit/d6a9e4
>>> 
>>> When the httpd parent process crashes, it cannot run the mod_fcgid code
>>> that marks any of its "busy" child processes as "ready" for new
>>> connections. That patch fixes it.
> 
> @Robert L Mathews: good find.
> 
>> Ah, very nice! Thanks for investigating and reporting it here.
> 
> @Stefan Eissing: I suppose this will be backported to the 2.4.x branch?

Yes, the votes are already in. Just need to merge it.

> -- 
> Jan
> 

Re: I plan to RM some time this weekend

[Stefan Eissing via dev]

> Am 30.03.2023 um 23:29 schrieb Eric Covener :
> 
> Primarily to pick up PR66547 and the rewrite improvements, but I also
> seen an h2 crash addressed.

\o/

> 
> -- 
> Eric Covener
> cove...@gmail.com

Re: Question about 2.4.56 "client resets of HTTP/2 streams led to unwanted 500 errors" fix

[Stefan Eissing via dev]

> Am 28.03.2023 um 01:21 schrieb Robert L Mathews :
> 
> On 3/16/23 5:38 AM, Stefan Eissing via dev wrote:
> 
>> I am not familiar enough with mod_fcgi's operation to make a judgement on 
>> that.
> 
> As a followup to this, it turned out it was caused by the problem fixed here:
> 
> https://github.com/apache/httpd/commit/d6a9e4
> 
> When the httpd parent process crashes, it cannot run the mod_fcgid code that 
> marks any of its "busy" child processes as "ready" for new connections. That 
> patch fixes it.
> 
> Thanks!

Ah, very nice! Thanks for investigating and reporting it here.

- Stefan
> 
> -- 
> Robert L Mathews

Re: Question about 2.4.56 "client resets of HTTP/2 streams led to unwanted 500 errors" fix

[Stefan Eissing via dev]

> Am 15.03.2023 um 17:27 schrieb Robert L Mathews :
> 
> [I sent this message to the users list but there were no replies; trying here 
> instead.]
> 
> After upgrading from httpd 2.4.54 to 2.4.55, I noticed that mod_fcgid scripts 
> would sometimes get "stuck" in the "working" state, rather than the "ready" 
> state, even though the script associated with the mod_fcgid slot was idle and 
> waiting for a new request.
> 
> While investigating, I noticed this usually happened after a stray HTTP/2 
> "500" error in the logs that I couldn't match up to a real error. This was 
> puzzling, so I downgraded back to 2.4.54 while thinking about it.
> 
> Now in the 2.4.56 update, I see:
> 
> *) mod_http2: client resets of HTTP/2 streams led to unwanted 500 errors
>   reported in access logs and error documents. The processing of the
>   reset was correct, only unneccesary reporting was caused.
> 
> The "unwanted 500 errors" sounds like it might be related, except that it 
> says the processing was correct, implying that this problem would not affect 
> anything other than the logging.
> 
> Is it possible that it actually *did* affect the processing of mod_fcgid 
> requests –- that the bug could have prevented mod_fcgid from switching a 
> child process from "working" back to "ready" after the client reset?

I am not familiar enough with mod_fcgi's operation to make a judgement on that.

> 
> -- 
> Robert L Mathews

Re: Current pytest failures

[Stefan Eissing via dev]

> Am 09.03.2023 um 11:22 schrieb Rainer Jung :
> 
> Puzzle partially solved: once I add "--header 'content-type: 
> application/x-www-form-urlencoded'" to the nghttp call, the problem seems 
> fixed - with and without deflate. No more hang, no more status 500, no double 
> requests. I still don't know, which side is influenced, nghttp or http, so I 
> am still not sure, whether the odd behavior without the header is a bug.

Hmm, never seen that. Is this a current nghttp? Normally, calling "nghttp 
--data=file" will do all that.

I think, since it stabilizes the test, please add the forced content-type 
header to the test suite. It should do no harm (famous last words),

- Stefan

> 
> Am 09.03.23 um 11:03 schrieb Rainer Jung:
>> OK, I can test in a standalone situation now.
>> The problem goes away, once I use curl, even with h2.
>> The problem also goes away, once I disable deflate compression for the 
>> response. But curl and nghttp behave different: nghttp hangs after receiving 
>> the response body (no deflate), curl normally terminates. nghttp does not 
>> hang if I call some normal production site.
>> Will investigate further.
>> Thanks and regards,
>> Rainer

Re: Current pytest failures

[Stefan Eissing via dev]

One tip, if you call "pytest -vvv -k test_h2_202_03b", it will run just that 
test and raise LogLevel for several "interesting" modules.

The error log in test/gen/apache/logs/error_log will then show just that one 
test case. It's a convenient way to get more information without meddling with 
the test case configs.

The list of modules for which the log level is raised on "-vvv" is found in 
test/modules/http2/env.py:73

self.add_httpd_log_modules(["http2", "proxy_http2", "h2test", "proxy", 
"proxy_http"])

we can add "cgi" or others if those are of interest.

> Am 08.03.2023 um 22:44 schrieb Rainer Jung :
> 
> Hi there,
> 
> I currently get three consistent pytest failures:
> 
> 
> A) FAILED modules/http2/test_202_trailer.py::TestTrailers::test_h2_202_03b
> 
> Response code is 500 and trace 8 server log shows:
> 
> - we see the right request
> 
> [Wed Mar 08 22:03:35.699234 2023] [aptest:info] [pid 4606:tid 
> 140645737559808] [remote 127.0.0.1:50490] test[test_h2_202_03b]: POST 
> //echohd.py?name=X HTTP/2.0
> [Wed Mar 08 22:03:35.699247 2023] [http:trace4] [pid 4606:tid 
> 140645737559808] http_request.c(436): [remote 127.0.0.1:50490] Headers 
> received from client:
> [Wed Mar 08 22:03:35.699254 2023] [http:trace4] [pid 4606:tid 
> 140645737559808] http_request.c(440): [remote 127.0.0.1:50490]   Accept: */*
> [Wed Mar 08 22:03:35.699259 2023] [http:trace4] [pid 4606:tid 
> 140645737559808] http_request.c(440): [remote 127.0.0.1:50490] 
> Accept-Encoding: gzip, deflate
> [Wed Mar 08 22:03:35.699264 2023] [http:trace4] [pid 4606:tid 
> 140645737559808] http_request.c(440): [remote 127.0.0.1:50490] User-Agent: 
> nghttp2/1.52.0
> [Wed Mar 08 22:03:35.699268 2023] [http:trace4] [pid 4606:tid 
> 140645737559808] http_request.c(440): [remote 127.0.0.1:50490] 
> Content-Length: 119
> [Wed Mar 08 22:03:35.699273 2023] [http:trace4] [pid 4606:tid 
> 140645737559808] http_request.c(440): [remote 127.0.0.1:50490]   Host: 
> 127.0.0.1:5001
> [Wed Mar 08 22:03:35.699277 2023] [http:trace4] [pid 4606:tid 
> 140645737559808] http_request.c(440): [remote 127.0.0.1:50490] Ap-Test-Name: 
> test_h2_202_03b
> [Wed Mar 08 22:03:35.699282 2023] [http:trace4] [pid 4606:tid 
> 140645737559808] http_request.c(440): [remote 127.0.0.1:50490]   X: 3b
> 
> [Wed Mar 08 22:03:35.699425 2023] [authz_core:debug] [pid 4606:tid 
> 140645737559808] mod_authz_core.c(818): [remote 127.0.0.1:50490] AH01626: 
> authorization result of Require all granted: granted
> [Wed Mar 08 22:03:35.699440 2023] [authz_core:debug] [pid 4606:tid 
> 140645737559808] mod_authz_core.c(818): [remote 127.0.0.1:50490] AH01626: 
> authorization result of : granted
> [Wed Mar 08 22:03:35.699446 2023] [core:trace3] [pid 4606:tid 
> 140645737559808] request.c(362): [remote 127.0.0.1:50490] request authorized 
> without authentication by access_checker_ex hook: /echohd.py
> 
> We get the right response from the python CGI script:
> 
> [Wed Mar 08 22:03:35.784148 2023] [cgid:trace4] [pid 4606:tid 
> 140645737559808] util_script.c(576): [remote 127.0.0.1:50490] Headers from 
> script 'echohd.py':
> [Wed Mar 08 22:03:35.784206 2023] [cgid:trace4] [pid 4606:tid 
> 140645737559808] util_script.c(577): [remote 127.0.0.1:50490]   Status: 200
> [Wed Mar 08 22:03:35.784219 2023] [cgid:trace1] [pid 4606:tid 
> 140645737559808] util_script.c(658): [remote 127.0.0.1:50490] Status line 
> from script 'echohd.py': 200
> [Wed Mar 08 22:03:35.784234 2023] [cgid:trace4] [pid 4606:tid 
> 140645737559808] util_script.c(577): [remote 127.0.0.1:50490] Content-Type: 
> text/plain
> [Wed Mar 08 22:03:35.784255 2023] [filter:trace4] [pid 4606:tid 
> 140645737559808] mod_filter.c(169): [remote 127.0.0.1:50490] Content-Type 
> 'text/plain' ...
> [Wed Mar 08 22:03:35.784268 2023] [filter:trace4] [pid 4606:tid 
> 140645737559808] mod_filter.c(181): [remote 127.0.0.1:50490] ... did not 
> match 'text/html'
> [Wed Mar 08 22:03:35.784278 2023] [filter:trace4] [pid 4606:tid 
> 140645737559808] mod_filter.c(175): [remote 127.0.0.1:50490] ... matched 
> 'text/plain'
> 
> deflate compression wants to kick in (no idea whether that's part of the 
> problem)
> 
> [Wed Mar 08 22:03:35.784288 2023] [filter:trace2] [pid 4606:tid 
> 140645737559808] mod_filter.c(188): [remote 127.0.0.1:50490] Content-Type 
> condition for 'deflate' matched
> 
> and now a connection reset!
> 
> [Wed Mar 08 22:03:35.788364 2023] [cgid:trace1] [pid 4606:tid 
> 140645737559808] mod_cgid.c(1686): (104)Connection reset by peer: [remote 
> 127.0.0.1:50490] Failed to flush CGI output to client
> 
> and another request for that URL comes in:
> 
> [Wed Mar 08 22:03:35.788486 2023] [ssl:debug] [pid 4606:tid 140645737559808] 
> ssl_engine_kernel.c(422): [remote 127.0.0.1:50490] AH02034: Subsequent (No.2) 
> HTTPS request received for child 0 (server cgi.tests.httpd.apache.org:443)
> [Wed Mar 08 22:03:35.788500 2023] [aptest:info] [pid 4606:tid 
> 140645737559808] [remote 127.0.0.1:50490] test[test_h2_202_03b]: POST 
> //echohd

Re: [VOTE] [VOTE] Release httpd-2.4.56-rc1 as httpd-2.4.56

[Stefan Eissing via dev]

> Am 08.03.2023 um 23:38 schrieb Eric Covener :
> 
> On Wed, Mar 8, 2023 at 4:57 PM BUSH Steve  wrote:
> 
>> Please remember to send the release announcement to annou...@httpd.apache.org
> 
> Maybe a moderation issue? Can anyone with the proper hat help check it
> out please?

In the releases I did, announce@ did *always* show delayed/lost processing of 
messages. It's not one of infras better services...

Re: svn commit: r1908060 - in /httpd/httpd/trunk/test/modules: http1/htdocs/cgi/ http2/ http2/htdocs/cgi/ md/ tls/ tls/htdocs/a.mod-tls.test/ tls/htdocs/b.mod-tls.test/

[Stefan Eissing via dev]

> Am 06.03.2023 um 17:53 schrieb Joe Orton :
> 
> [resent to dev@]
> 
> On Sat, Mar 04, 2023 at 01:40:39PM -, ic...@apache.org wrote:
>> Author: icing
>> Date: Sat Mar  4 13:40:38 2023
>> New Revision: 1908060
>> 
>> URL: http://svn.apache.org/viewvc?rev=1908060&view=rev
>> Log:
>> Test case updates related to macOS ventura changes:
>> 
>> - python 3.11 deprecates the `cg` module, replacing
>>  url query and multipart form-data handling with new code
>> - adaptions to changes in openssl/curl behaviours
>> - all mod_tls test cases now have prefix `test_tls_` for
>>  easier scoping.
> 
> This seems to be failing:
> 
> https://github.com/apache/httpd/actions/runs/4341851149/jobs/7581956398
> 
> 1) Maybe some new pypi requirement or something?  Looks like the CGI 
> scripts are now giving 500 errors.

Yes, for the deprecated `cgi` python module, the `multipart` module
is recommended by the PyGods to replace parts of it. I have no idea
how that is named on ubuntu-latest.


> 2) What is the path to the relevant error_log when running those tests, 
> we can tweak the config to grab that file and upload it for easy 
> diagnosis.

The server error log on all pytests is found in test/gen/apache/logs/error_log. 
It is cleared on test start.

Kind Regards,
Stefan

Re: svn commit: r1908116 - in /httpd/httpd/trunk: docs/log-message-tags/next-number modules/http2/mod_proxy_http2.c

[Stefan Eissing via dev]

> Am 06.03.2023 um 10:37 schrieb Yann Ylavic :
> 
> On Mon, Mar 6, 2023 at 10:28 AM Ruediger Pluem  wrote:
>> 
>> Thanks. Should we roll a new rc with this being backported and included?
> 
> I don't think so, the ci failure is caused by an explicit script/check
> but the build works fine while runtime will only log an empty "AH"
> number, not a show stopper IMO.

Agreed, not a stopper.

And we can always find the one code line with an empty AH! ;)

> 
> Regards;
> Yann.

Re: [VOTE] [VOTE] Release httpd-2.4.56-rc1 as httpd-2.4.56

[Stefan Eissing via dev]

> Am 05.03.2023 um 22:31 schrieb Eric Covener :
> 
> 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.56-rc1 as 2.4.56:
> [ ] +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: db0d4c76007b231fd3ab41b580548dc798ae3844bb7c3d5ce1e4174ca2364698
> *httpd-2.4.56-rc1.tar.gz
> sha512: 
> 68b1e8c3e3436e6947c0ccfeee6fea83254560e4d43bddbc79a4206d804a6dda6662cf5734e0b2f4019ab5c1fff40141a16dd7698e8fe72b7fd343fbebd42724
> *httpd-2.4.56-rc1.tar.gz
> 
> The SVN candidate source is found at tags/2.4.56-rc1-candidate.

+1 

Darwin xxx 22.3.0 Darwin Kernel Version 22.3.0 (macOS ventura x86_64)

Thanks for RMing,

Stefan


> 
> -- 
> Eric Covener
> cove...@gmail.com