Problem with pypest and pebble 2.5.1

[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 certificate
[Sun Apr 07 17:13:24.686756 2024] [md:debug] [pid 5554:tid 
140101761058560] md_acme_drive.c(115): (2)No such file or directory: 
ACME: looking at existing accounts
[Sun Apr 07 17:13:24.686925 2024] [md:debug] [pid 5554:tid 
140101761058560] 

Re: pytest results for 2.4.59

[Rainer Jung]

Am 07.04.24 um 09:42 schrieb jean-frederic clere:

On 4/6/24 20:02, Rainer Jung wrote:

Hi Jean-Frederic and all,

you didn't write at what point in time you take the thread dump. I see 
the SIGTERM messages logged during test execution always during the 
last test in each group (http2, md, ...) just because that is the time 
the logs are checked by teardown for error messages. At the time the 
test complains it already starts to kill the children and at least 
during my test runs it success with killing them (I think). So finding 
a good point in time to attach the debugger and see the right 
situation might not be easy?


I might have taken the thread dump late because I have taken it just 
after the ap_log_error("sending a SIGTERM") at that time there is only 
one thread running and it is "waiting" for the listener thread that has 
already stopped. There I have found that the behavior of pthread_kill() 
changed in "recent" fedora/rhel.


Are you suggesting I should also try to get dumps earlier in the 
shutdown process?




When you say Yann's patch helps, it means especially there are not 
more SIGTERM messages in the logs resp. no more teardown checks failing?


Yes with Yann's patch, the "AH00045: child process n still did not 
exit, sending a SIGTERM" messages are gone and teardown checks are passing.


I could now also do some tests and for me the SIGTERM messages for 
worker on RHEL 9 during pytest are also gone with Yann's woker MPM 
patch. Plus I didn't get any new failures. Perl test framework is fine 
and pytest only some of the few occasional failures and errors I had 
also seen before.


So it would be nice if we would apply Yann's patch for the worker mpm.

Thanks and best regards,

Rainer

Re: pytest results for 2.4.59

[Rainer Jung]

Hi Jean-Frederic and all,

you didn't write at what point in time you take the thread dump. I see 
the SIGTERM messages logged during test execution always during the last 
test in each group (http2, md, ...) just because that is the time the 
logs are checked by teardown for error messages. At the time the test 
complains it already starts to kill the children and at least during my 
test runs it success with killing them (I think). So finding a good 
point in time to attach the debugger and see the right situation might 
not be easy?


When you say Yann's patch helps, it means especially there are not more 
SIGTERM messages in the logs resp. no more teardown checks failing?


Best regards,

Rainer

Am 06.04.24 um 17:32 schrieb jean-frederic clere:

On 4/6/24 13:10, Yann Ylavic wrote:
On Sat, Apr 6, 2024 at 10:46 AM jean-frederic clere 
 wrote:


On 4/5/24 07:55, Ruediger Pluem wrote:


Are you able to provide a stacktrace of the hanging process (thread 
apply all bt full)?


It seems pthread_kill(t, 0) returns 0 even the thread t has exited...
older version of fedora will return 3 (I have tried fc28)


If pthread_kill() does not work we probably should use the global
"dying" variable like in mpm_event.
But it's not clear from your earlier "bt full" whether there are other
threads, could you try "thread apply all bt full" instead to show all
the threads?


(gdb) thread apply all bt full

Thread 1 (Thread 0x7ffbf3f5ad40 (LWP 2891875)):
#0  0x7ffbf429b087 in __GI___select (nfds=nfds@entry=0, 
readfds=readfds@entry=0x0, writefds=writefds@entry=0x0, 
exceptfds=exceptfds@entry=0x0, timeout=timeout@entry=0x7fff56cbb0b0) at 
../sysdeps/unix/sysv/linux/select.c:69

     sc_ret = -4
     sc_cancel_oldtype = 0
     sc_ret = 
     s = 
     us = 
     ns = 
     ts64 = {tv_sec = 0, tv_nsec = 155950744}
     pts64 = 0x7fff56cbb050
     r = 
#1  0x7ffbf43d9d92 in apr_sleep (t=t@entry=50) at 
time/unix/time.c:249

     tv = {tv_sec = 0, tv_usec = 50}
#2  0x00440733 in join_workers (listener=0x87c170, 
threads=threads@entry=0x91e150, mode=mode@entry=2) at worker.c:1069

     iter = 7
     i = 
     rv = 
     thread_rv = 0
#3  0x004412d9 in child_main 
(child_num_arg=child_num_arg@entry=0, child_bucket=child_bucket@entry=0) 
at worker.c:1310

     threads = 0x91e150
     rv = 1
     ts = 0x815a78
     thread_attr = 0x815a98
     start_thread_id = 0x815b08
     i = 
#4  0x0044161a in make_child (s=0x818d00, slot=slot@entry=0, 
bucket=0) at worker.c:1376

     pid = 0
#5  0x004416be in startup_children (number_to_start=3) at 
worker.c:1403

     i = 0
#6  0x004428f9 in worker_run (_pconf=, 
plog=0x81b998, s=0x818d00) at worker.c:1928

     listen_buckets = 0x875480
     num_buckets = 1
     remaining_children_to_start = 
     rv = 
     id = "0\000\000\000\000\000\000\000\t\000\000\000\000\000\000"
     i = 
#7  0x00456930 in ap_run_mpm (pconf=pconf@entry=0x7ec3e8, 
plog=0x81b998, s=0x818d00) at mpm_common.c:102

     pHook = 
     n = 0
     rv = -1
#8  0x0043350e in main (argc=, argv=out>) at main.c:882

     c = 102 'f'
     showcompile = 
--Type  for more, q to quit, c to continue without paging--
     showdirectives = 
     confname = 
     def_server_root = 
     temp_error_log = 
     error = 
     process = 0x7ea4c8
     pconf = 0x7ec3e8
     plog = 0x81b998
     ptemp = 0x815678
     pcommands = 
     opt = 0x810ef0
     rv = 
     mod = 
     opt_arg = 0x7fff56cbcb64 
"/home/jfclere/httpd-trunk/test/pyhttpd/../gen/apache/conf/httpd.conf"

     signal_server = 
     rc = 
(gdb)

I have added a kill(pid, SIGABRT); in server/mpm_unix.c after the 
ap_log_error() as it is not easy to get a core otherwise.




It's clear from the main thread's backtrace that it's waiting for the
listener in the "iter" loop, but nothing tells if the listener already
exited or not. The listener for instance could be waiting indefinitely
apr_pollset_poll() at this point, and since there is no pollset wakeup
in mpm_worker I don't think that wakeup_listener() can help here.


According to my tests using assert(0) in the join_workers() in different 
location, the listener thread is stopped by wakeup_listener() but the 
pthread_kill() doesn't report that.




So maybe we need to add an apr_pollset_wakeup() in wakeup_listener()
too, like in mpm_event too.

Overall something like the attached patch?


Yes the attached patch helps




Regards;
Yann.

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

[Rainer Jung]

Hi Stefan and all,

I have these additional RST in some more test cases (it seems the more 
runs I do, the more popup). Would it make sense to allow RST after EOF 
in *all* tests that look for EOF in 
modules/http2/test_800_websockets.py? WDYT?


Thanks and regards,

Rainer


Am 05.04.24 um 09:04 schrieb 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=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=1916808=1916809=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: pytest results for 2.4.59

[Rainer Jung]

I think I fixed all test failures, hopefully in the correct way. More 
eyes welcome.


I have a few additional sporadic ERRORS:

A] ERROR during teardown check for log file errors or warnings (twice):

04.04.2024 21:14:42.205465 ___ ERROR at teardown of 
TestStatus.test_md_920_020 
04.04.2024 21:14:42.205465 ERROR 
modules/md/test_920_status.py::TestStatus::test_md_920_020 - AssertionE...


04.04.2024 21:14:42.205465 E   AssertionError: apache logged 1 
errors and 0 warnings:
04.04.2024 21:14:42.205465 E [Thu Apr 04 21:12:29.381511 2024] 
[md:error] [pid 4169] (22)Invalid argument: no certificates in non-empty 
chain 
/path/to/gen/apache/md/staging/one.test.test-md-702-070-1712257797.org/pubcert.pem



04.04.2024 21:03:26.382051 ___ ERROR at teardown of 
TestStatus.test_md_920_020 
04.04.2024 21:03:26.382360 ERROR 
modules/md/test_920_status.py::TestStatus::test_md_920_020 - AssertionE...


04.04.2024 21:03:26.382051 E   AssertionError: apache logged 1 
errors and 1 warnings:
04.04.2024 21:03:26.382051 E [Thu Apr 04 21:00:48.924286 2024] 
[md:error] [pid 8717:tid 139629962274560] (20014)Internal error 
(specific information not available): test-md-702-041-1712256790.org: 
asked to retrieve chain, but no order in context
04.04.2024 21:03:26.382051 E [Thu Apr 04 21:00:48.924229 2024] 
[md:warn] [pid 8717:tid 139629962274560] error generate pkey RSA 3072


B] Hanging httpd child processes

This happens only on RHEL 9 with worker MPM and can be notices by a 
dramatic slowdown of the tests. There's a lot of messages


AH00045: child process 1067703 still did not exit, sending a SIGTERM

and

AH00276: the listener thread didn't exit

It happened in

modules/core/test_001_encoding.py::TestEncoding::test_core_001_20[test2-/10%25abnormal.txt-200]

modules/md/test_920_status.py::TestStatus::test_md_920_020

modules/proxy/test_02_unix.py::TestProxyUds::test_proxy_02_003[mixed-500]

but I don't know, whether it might happen elsewhere also, because it is 
sporadic.


What I see in the error logs for one hanging child process:

- most threads terminate with

[Thu Apr 04 22:42:59.617953 2024] [ssl:trace3] [pid 1067703:tid 
140619680433728] ssl_engine_kernel.c(2223): [client 127.0.0.1:40686] 
OpenSSL: Write: SSL negotiation finished successfully
[Thu Apr 04 22:42:59.617972 2024] [ssl:trace6] [pid 1067703:tid 
140619680433728] ssl_engine_io.c(154): [client 127.0.0.1:40686] 
bio_filter_out_write: flush
[Thu Apr 04 22:42:59.617981 2024] [ssl:debug] [pid 1067703:tid 
140619680433728] ssl_engine_io.c(1146): [client 127.0.0.1:40686] 
AH02001: Connection closed to child 0 with standard shutdown (server 
test1.tests.httpd.apache.org:443)


- watchdog thread terminates (?) with

[Thu Apr 04 22:43:00.902666 2024] [md:debug] [pid 1067703:tid 
140619697219136] md_reg.c(1163): test-md-810-003a-1712260944.org: 
staging done
[Thu Apr 04 22:43:00.903951 2024] [md:notice] [pid 1067703:tid 
140619697219136] AH10059: The Managed Domain 
test-md-810-003a-1712260944.org has been setup and changes will be 
activated on next (graceful) server restart.
[Thu Apr 04 22:43:00.904418 2024] [md:debug] [pid 1067703:tid 
140619697219136] mod_md_drive.c(229): AH10107: next run in 11 hours 59 
minutes 58 seconds
[Thu Apr 04 22:43:01.204981 2024] [md:debug] [pid 1067703:tid 
140619697219136] mod_md_drive.c(236): AH10058: md watchdog stopping
[Thu Apr 04 22:43:01.205094 2024] [watchdog:debug] [pid 1067703:tid 
140619697219136] mod_watchdog.c(257): AH02973: Singleton Watchdog 
(_md_renew_) stopping


- one worker thread seems not to stop:

[Thu Apr 04 22:42:59.768569 2024] [core:trace5] [pid 1067703:tid 
140619672041024] protocol.c(714): [client 127.0.0.1:48748] Request 
received from client: GET 
/.well-known/acme-challenge/3VAiCadJ5do2TuwIbbh3w2foMGfnCspnm0eYejBSC9E 
HTTP/1.1
[Thu Apr 04 22:42:59.768667 2024] [md:debug] [pid 1067703:tid 
140619672041024] mod_md.c(1385): [client 127.0.0.1:48748] loading 
challenge for test-md-810-003a-1712260944.org 
(/.well-known/acme-challenge/3VAiCadJ5do2TuwIbbh3w2foMGfnCspnm0eYejBSC9E)
[Thu Apr 04 22:42:59.768698 2024] [http:trace3] [pid 1067703:tid 
140619672041024] http_filters.c(1141): [client 127.0.0.1:48748] Response 
sent with status 200, headers:
[Thu Apr 04 22:42:59.768706 2024] [http:trace5] [pid 1067703:tid 
140619672041024] http_filters.c(1150): [client 127.0.0.1:48748]   Date: 
Thu, 04 Apr 2024 20:42:59 GMT
[Thu Apr 04 22:42:59.768712 2024] [http:trace5] [pid 1067703:tid 
140619672041024] http_filters.c(1153): [client 127.0.0.1:48748] 
Server: Apache/2.4.59 (Unix) OpenSSL/3.1.5
[Thu Apr 04 22:42:59.768718 2024] [http:trace4] [pid 1067703:tid 
140619672041024] http_filters.c(971): [client 127.0.0.1:48748] 
Content-Length: 88
[Thu Apr 04 22:42:59.768724 2024] [http:trace4] [pid 1067703:tid 
140619672041024] http_filters.c(971): [client 127.0.0.1:48748] 
Connection: close
[Thu Apr 04 22:42:59.769616 2024] [core:trace6] 

pytest results for 2.4.59

[Rainer Jung]

Hi there,

first although I saw very few pytest failures, I think the results are 
overall fine and good enough for release.


I first had to find out, that I need to build the h2ws websocket client 
during httpd build (for websocket tests) and use the right multipart 
python module ("python-multipart" instead of "multipart").


I see 4 failures:

A] two with "AssertionError: request not found in 
/tmp/esupport-testdir/pytest-event-310/gen/apache/logs/test_...":


__ TestTiming.test_h2_009_01 
___

self = 
env = 

def test_h2_009_01(self, env):
...

>   assert found, f'request not found in {TestTiming.LOGFILE}'
E   AssertionError: request not found in 
/tmp/esupport-testdir/pytest-event-310/gen/apache/logs/test_009

E   assert False

modules/http2/test_009_timing.py:46: AssertionError

and

__ TestTiming.test_h2_009_02 
___


self = 
env = 

def test_h2_009_02(self, env):
...
>   assert found, f'request not found in {TestTiming.LOGFILE}'
E   AssertionError: request not found in 
/tmp/esupport-testdir/pytest-event-310/gen/apache/logs/test_009

E   assert False

modules/http2/test_009_timing.py:74: AssertionError


I need to further investigate, whether the log file is missing, or does 
not have the right contents. The failure should not be critical in itself.



B] buffer test failure TestBuffering.test_h2_712_02

self = 
env = 

def test_h2_712_02(self, env):
...
>   piper.stutter_check(chunks, stutter)

modules/http2/test_712_buffering.py:48:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ _ _ _


self = CurlPiper[exitcode=0, stderr=['14:46:27.261890 == Info: Added 
cgi.tests.httpd.apache.org:5001:127.0.0.1 to DNS 
cache\ntests.httpd.apache.org left intact\n'], 
stdout=['chunk-000-0123456789\nchunk-001-0123456789\nchunk-002-0123456789\n']]
chunks = ['chunk-000-0123456789\n', 'chunk-001-0123456789\n', 
'chunk-002-0123456789\n']

stutter = datetime.timedelta(seconds=1)

def stutter_check(self, chunks: [str], stutter: datetime.timedelta):
...
# received as many chunks as we sent
>   assert len(chunks) == len(recv_times), "received response not 
in {0} chunks, but {1}".format(

len(chunks), len(recv_times))
E   AssertionError: received response not in 3 chunks, but 4

pyhttpd/curl.py:118: AssertionError
- Captured stderr call 
-
starting: ['curl', '-s', '--path-as-is', '-D', 
'/tmp/esupport-testdir/pytest-event-310/gen/curl.headers.438', 
'--cacert', 
'/tmp/esupport-testdir/pytest-event-310/gen/apache/ca/ca.rsa4096.cert.pem', 
'--resolve', 'cgi.tests.httpd.apache.org:5001:127.0.0.1', '-H', 
'AP-Test-Name: test_h2_712_02', '--connect-timeout', '5', '-T', '-', 
'-X', 'POST', '--trace-ascii', '%', '--trace-time', 
'https://cgi.tests.httpd.apache.org:5001/h2proxy/h2test/echo']



Here I have no idea where the difference in the chunk numbers come from. 
Maybe the test assumptions are to strict?



C] a single websocket test failure 
TestWebSockets.test_h2_800_04_non_ws_resource


self = 
env = , ws_server = None

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}'
E   AssertionError: ExecResult[code=0, args=['/path/to/h2ws', '-vv', 
'-c', 'localhost:5002', 
'ws://cgi.tests.httpd.apache.org:5002/alive.json', 'ws-stdin']

E stdout---
E stderr---
E
E   assert ['[1] :status...F', '[1] RST'] == ['[1] :status...2', 
'[1] EOF']

E Left contains one more item: '[1] RST'
E Full diff:
E - ['[1] :status: 502', '[1] EOF']
E + ['[1] :status: 502', '[1] EOF', '[1] RST']
E ?   + ++

modules/http2/test_800_websockets.py:178: AssertionError

All in all the results are mich better than what I achieved for the 
previous releases!


Best regards,

Rainer

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

[Rainer Jung]

Thanks!

Am 03.04.24 um 21:13 schrieb Eric Covener:

On Wed, Apr 3, 2024 at 3:03 PM Eric Covener  wrote:


On Wed, Apr 3, 2024 at 2:54 PM Rainer Jung  wrote:


Minor nit: the format of the SHA hash files has changes. Example:

2.4.58:

fa16d72a078210a54c47dd5bef2f8b9b8a01d94909a51453956b3ec6442ea4c5
*httpd-2.4.58.tar.bz2

2.4.59:

SHA2-256(httpd-2.4.59-rc1.tar.bz2)=
ec51501ec480284ff52f637258135d333230a7d229c3afa6f6c2f9040e321323


fixed and repaired the ones on dist/dev

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

[Rainer Jung]

Minor nit: the format of the SHA hash files has changes. Example:

2.4.58:

fa16d72a078210a54c47dd5bef2f8b9b8a01d94909a51453956b3ec6442ea4c5 
*httpd-2.4.58.tar.bz2


2.4.59:

SHA2-256(httpd-2.4.59-rc1.tar.bz2)= 
ec51501ec480284ff52f637258135d333230a7d229c3afa6f6c2f9040e321323


I need to see how to check scripted with commandline tools.

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

Re: Failing test t/apache/pr64339.t

[Rainer Jung]

Am 03.04.24 um 09:52 schrieb Joe Orton:

On Tue, Apr 02, 2024 at 08:46:46PM -0400, Eric Covener wrote:

This could be due to none of these happening:
- mod_mime didn't send a charset from backend
- no BOM
- no xml2EncDefault (8859-1 effectively by default) on frontend

To make the conf match the test code, this works for me to address
mod_mime on the backend:


Yup. Sorry for wasting your time on this. Thanks for the commit, I had
the same change uncommitted locally still and missed it.


Thanks Eric for analyzing and fixing and Joe for confirming. The patch 
fixes it for me as well.


Best regards,

Rainer

Failing test t/apache/pr64339.t

[Rainer Jung]

Hi there,

in preparation of the relase I am running the test framework against 
recent httpd 2.4.x head.


I am seeing test failures in t/apache/pr64339.t:

# testing : content-type header test for /doc.xml
# expected: 'application/xml; charset=utf-8'
# received: 'application/xml;charset=utf-8'
not ok 2
# testing : content test for /doc.xml
# expected: 'fóó
# '
# received: 'fÃ<83>³Ã<83>³
# '
not ok 3

and the same for tests 5 and 6.

The header differences are hopefully easy to fix, probably in adjusting 
the expected test response?


Unfortunately I have no idea, why the other test fails. Maybe related to 
the header differences, it seems the received answer has more (double?) 
bytes than expected, so might be an encoding issue? It might also be a 
question, how the local perl interpretes the bytes in the test file 
respectively received via the net.


Am I the only one seeing this issue?

Best regards,

Rainer

mod_systemd: refactor to get rid of libsystemd dependency?

[Rainer Jung]

Hi there,

in the light of the recent xz attack I was wondering, whether we should 
also reduce our library dependencies by no longer using sd_notify() in 
mod_systemd (thus loading libsystemd and all of its dependencies), but 
instead taking the approach to hard code sd_notify functionality.


I guess the Linux distributors who patched sshd to use libsystemd for 
notification are on their way to do the same for their sshd patches, so 
we might soon get an idea how to do that properly.


This is not meant to become part of out next release (this week), but 
hopefully we can manage to code it for the next one.


WDYT: does this make sense?

A little bit of technical background is contained in

https://news.ycombinator.com/item?id=39867126

Best regards,

Rainer

Re: age in proxy_balancer_method

[Rainer Jung]

I guess it could be like this: when Mladen originally implemented the by 
requests load balancing method in mod_jk he used the count and subtract 
method for the counters. He then ported this to mod_proxy_balancer and I 
think it is still, how by requests counting woorks there.


There are pros and cons, e.g. in case a worker goes down for some time. 
A bit later we switched in mod_jk to a count and divide, where division 
by 2 was done roughly every 60 seconds (configurable).


I think the idea of the age method was roughly, that you could implement 
a balanvcer method, that registers a mod_watchdog task, that regularly 
ages the balancing counters. Aging because you want to give the past a 
smaller influence on the balancing decision than the more recent activity.


I hope that's understandable and maybe Jim remembers something similar 
to that.


Best regards,

Rainer

Am 21.12.23 um 08:23 schrieb jean-frederic clere:

On 12/20/23 21:22, Jim Jagielski wrote:
I'll have to go back through my notes... I do recall adding fields 
that although
were not being used at the time, were _going to be used_ as some 
point, and

I didn't want to have to worry about ABI compatibility.


Cool I will wait before implementing something that breaks your design ;-)



On Dec 14, 2023, at 8:27 AM, jean-frederic clere  
wrote:


Hi,

Any examples or docs about:
apr_status_t (*age)(proxy_balancer *balancer, server_rec *s);

In struct proxy_balancer_method?

--
Cheers

Jean-Frederic

OpenSSL 3.0 deprecations

[Rainer Jung]

FYI: here's a list of symbols for which I get deprecation warnings when 
compiling httpd 2.4.58 (plus bundled APU) against current OpenSSL 3.1.3. 
or 3.0.11:


srclib/apr-util/crypto/apr_crypto_openssl.c:141:5: warning: 
'ENGINE_load_builtin_engines' is deprecated (declared at 
include/openssl/engine.h:358): Since OpenSSL 3.0
srclib/apr-util/crypto/apr_crypto_openssl.c:142:5: warning: 
'ENGINE_register_all_complete' is deprecated (declared at 
include/openssl/engine.h:415): Since OpenSSL 3.0
srclib/apr-util/crypto/apr_crypto_openssl.c:208:9: warning: 
'ENGINE_finish' is deprecated (declared at 
include/openssl/engine.h:628): Since OpenSSL 3.0
srclib/apr-util/crypto/apr_crypto_openssl.c:209:9: warning: 
'ENGINE_free' is deprecated (declared at include/openssl/engine.h:493): 
Since OpenSSL 3.0
srclib/apr-util/crypto/apr_crypto_openssl.c:326:9: warning: 
'ENGINE_by_id' is deprecated (declared at include/openssl/engine.h:336): 
Since OpenSSL 3.0
srclib/apr-util/crypto/apr_crypto_openssl.c:330:9: warning: 
'ENGINE_init' is deprecated (declared at include/openssl/engine.h:620): 
Since OpenSSL 3.0
srclib/apr-util/crypto/apr_crypto_openssl.c:331:13: warning: 
'ENGINE_free' is deprecated (declared at include/openssl/engine.h:493): 
Since OpenSSL 3.0


support/ab.c:769:25: warning: 'EVP_PKEY_get1_EC_KEY' is deprecated 
(declared at include/openssl/evp.h:1377): Since OpenSSL 3.0
support/ab.c:770:25: warning: 'EC_KEY_get0_group' is deprecated 
(declared at include/openssl/ec.h:1037): Since OpenSSL 3.0
support/ab.c:771:25: warning: 'EC_KEY_free' is deprecated (declared at 
include/openssl/ec.h:1006): Since OpenSSL 3.0
support/ab.c:1431:13: warning: 'BIO_set_callback' is deprecated 
(declared at include/openssl/bio.h:279): Since OpenSSL 3.0


modules/ssl/ssl_engine_config.c:611:5: warning: 'ENGINE_by_id' is 
deprecated (declared at include/openssl/engine.h:336): Since OpenSSL 3.0
modules/ssl/ssl_engine_config.c:613:9: warning: 'ENGINE_free' is 
deprecated (declared at include/openssl/engine.h:493): Since OpenSSL 3.0
modules/ssl/ssl_engine_config.c:618:9: warning: 'ENGINE_get_first' is 
deprecated (declared at include/openssl/engine.h:318): Since OpenSSL 3.0
modules/ssl/ssl_engine_config.c:620:13: warning: 'ENGINE_get_id' is 
deprecated (declared at include/openssl/engine.h:552): Since OpenSSL 3.0
modules/ssl/ssl_engine_config.c:621:42: warning: 'ENGINE_get_name' is 
deprecated (declared at include/openssl/engine.h:553): Since OpenSSL 3.0
modules/ssl/ssl_engine_config.c:624:13: warning: 'ENGINE_get_next' is 
deprecated (declared at include/openssl/engine.h:323): Since OpenSSL 3.0
modules/ssl/ssl_engine_init.c:483:9: warning: 'ENGINE_by_id' is 
deprecated (declared at include/openssl/engine.h:336): Since OpenSSL 3.0
modules/ssl/ssl_engine_init.c:493:13: warning: 'ENGINE_ctrl' is 
deprecated (declared at include/openssl/engine.h:429): Since OpenSSL 3.0
modules/ssl/ssl_engine_init.c:497:9: warning: 'ENGINE_set_default' is 
deprecated (declared at include/openssl/engine.h:708): Since OpenSSL 3.0
modules/ssl/ssl_engine_init.c:508:9: warning: 'ENGINE_free' is 
deprecated (declared at include/openssl/engine.h:493): Since OpenSSL 3.0
modules/ssl/ssl_engine_init.c:574:9: warning: 'SRP_VBASE_new' is 
deprecated (declared at include/openssl/srp.h:176): Since OpenSSL 3.0
modules/ssl/ssl_engine_init.c:583:9: warning: 'SRP_VBASE_init' is 
deprecated (declared at include/openssl/srp.h:180): Since OpenSSL 3.0
modules/ssl/ssl_engine_init.c:591:9: warning: 
'SSL_CTX_set_srp_username_callback' is deprecated (declared at 
include/openssl/ssl.h:1900): Since OpenSSL 3.0
modules/ssl/ssl_engine_init.c:593:9: warning: 'SSL_CTX_set_srp_cb_arg' 
is deprecated (declared at include/openssl/ssl.h:1902): Since OpenSSL 3.0
modules/ssl/ssl_engine_init.c:1318:5: warning: 'DH_get0_p' is deprecated 
(declared at include/openssl/dh.h:266): Since OpenSSL 3.0
modules/ssl/ssl_engine_init.c:1539:9: warning: 'DH_free' is deprecated 
(declared at include/openssl/dh.h:207): Since OpenSSL 3.0
modules/ssl/ssl_engine_init.c:1556:9: warning: 
'EC_KEY_new_by_curve_name' is deprecated (declared at 
include/openssl/ec.h:1001): Since OpenSSL 3.0
modules/ssl/ssl_engine_init.c:1578:5: warning: 'EC_KEY_free' is 
deprecated (declared at include/openssl/ec.h:1006): Since OpenSSL 3.0
modules/ssl/ssl_engine_init.c:1843:9: warning: 'SRP_VBASE_free' is 
deprecated (declared at include/openssl/srp.h:178): Since OpenSSL 3.0
modules/ssl/ssl_engine_io.c:2288:9: warning: 'BIO_set_callback' is 
deprecated (declared at include/openssl/bio.h:279): Since OpenSSL 3.0
modules/ssl/ssl_engine_io.c:2291:13: warning: 'BIO_set_callback' is 
deprecated (declared at include/openssl/bio.h:279): Since OpenSSL 3.0
modules/ssl/ssl_engine_kernel.c:545:5: warning: 'SSL_get_srp_username' 
is deprecated (declared at include/openssl/ssl.h:1914): Since OpenSSL 3.0
modules/ssl/ssl_engine_kernel.c:2594:13: warning: 'BIO_set_callback' is 
deprecated (declared at include/openssl/bio.h:279): Since OpenSSL 3.0

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

[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:

+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

Re: svn commit: r1913010 - in /httpd/httpd/branches/2.4.x: ./ CHANGES STATUS

[Rainer Jung]

Thanks for merging. I am fine with this one not making in into the final 
2.4.58 release (but of course also if it goes in in case we need a 
seconds rc).


Am 16.10.23 um 13:45 schrieb rpl...@apache.org:

Author: rpluem
Date: Mon Oct 16 11:45:19 2023
New Revision: 1913010

URL: http://svn.apache.org/viewvc?rev=1913010=rev
Log:
Merge r1912015 from trunk:

mod_ssl: Silence info log message "SSL Library Error: error:0A000126:
  SSL routines::unexpected eof while reading" when using
  OpenSSL 3 by setting SSL_OP_IGNORE_UNEXPECTED_EOF if
  available. [Rainer Jung]

Reviewed by: rjung, gbechis, rpluem

Modified:
 httpd/httpd/branches/2.4.x/   (props changed)
 httpd/httpd/branches/2.4.x/CHANGES
 httpd/httpd/branches/2.4.x/STATUS

Propchange: httpd/httpd/branches/2.4.x/
--
   Merged /httpd/httpd/trunk:r1912015

Modified: httpd/httpd/branches/2.4.x/CHANGES
URL: 
http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/CHANGES?rev=1913010=1913009=1913010=diff
==
--- httpd/httpd/branches/2.4.x/CHANGES [utf-8] (original)
+++ httpd/httpd/branches/2.4.x/CHANGES [utf-8] Mon Oct 16 11:45:19 2023
@@ -1,6 +1,11 @@
   -*- coding: utf-8 -*-
  Changes with Apache 2.4.58
  
+  *) mod_ssl: Silence info log message "SSL Library Error: error:0A000126:

+ SSL routines::unexpected eof while reading" when using
+ OpenSSL 3 by setting SSL_OP_IGNORE_UNEXPECTED_EOF if
+     available. [Rainer Jung]
+
*) mod_http2: improved early cleanup of streams.
   [Stefan Eissing]
  


Modified: httpd/httpd/branches/2.4.x/STATUS
URL: 
http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?rev=1913010=1913009=1913010=diff
==
--- httpd/httpd/branches/2.4.x/STATUS (original)
+++ httpd/httpd/branches/2.4.x/STATUS Mon Oct 16 11:45:19 2023
@@ -152,15 +152,6 @@ RELEASE SHOWSTOPPERS:
  PATCHES ACCEPTED TO BACKPORT FROM TRUNK:
[ start all new proposals below, under PATCHES PROPOSED. ]
  
-  *) mod_ssl: Silence info log message "SSL Library Error: error:0A000126:

- SSL routines::unexpected eof while reading" when using
- OpenSSL 3 by setting SSL_OP_IGNORE_UNEXPECTED_EOF if
- available. [Rainer Jung]
- Trunk version of patch:
-https://svn.apache.org/r1912015
- Backport version for 2.4.x of patch:
-svn merge -c 1912015 ^/httpd/httpd/trunk .
- +1: rjung, gbechis, rpluem
  
  PATCHES PROPOSED TO BACKPORT FROM TRUNK:

[ New proposals should be added at the end of the list ]

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

[Rainer Jung]

Am 14.09.23 um 07:44 schrieb 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?


Thank you very much for checking. I will investigate.

pytest: 3 minutes gap or long single test runtime

[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?


Thanks and regards,

Rainer

Re: mod_ssl SSL_OP_IGNORE_UNEXPECTED_EOF: "unexpected eof while reading"

[Rainer Jung]

Am 07.09.23 um 14:58 schrieb Joe Orton:

On Wed, Aug 30, 2023 at 01:21:11PM +0200, Rainer Jung wrote:

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():


Interesting! Just wondering, is there a reason why we'd only want to
enable this for server-side operation (mctx->pkp == NULL) not also for
client-side/proxy operation? Seems like it might be better to enable it
unconditionally.

Regards, Joe


Hi Joe,

I just wanted to be a bit cautious. I had observed it on the server side 
and have no real knowledge about the client side. But I am OK, to enable 
this "compatibility" flag in both cases.


I'll wait abit for more feedback and then adjust trunk and the backport 
proposal.


Thanks for the feedback,

Rainer

Re: balancers bybusyness, bytraffic and byrequest thread/process safe issues

[Rainer Jung]

Hi there,

mod_jk for example uses such aging, but only for the non busyness case. 
busyness is meant to show the number of currently in-flight requests, so 
aging isn't a good fit there. Old load numbers are never part of 
busyness. But busyness is the mode that is most sensitive to the numer 
skew effects that JFC observed. Therefore that attempt to have more 
precise counting there.


It makes sense for byrequests and bytraffic though. But in mod_jk we use 
a different byrequests algorithm. Not the original count and decrement 
system that Mladen introduced but instead a count and age system.


The aging for byrequests and bytraffic could be hooked on mod_watchdog 
which is nice, because we would not need to run it as part of normal 
request handling.


Another thing that comes to my mind is (graceful) restart handlingan 
bybusyness. It might make sense to clear the numbers in case of such an 
event.


Best regards,

Rainer

Am 31.08.23 um 18:23 schrieb Jim Jagielski:

IIRC, the goal of having an "aging" function was to handle this exact kind of 
thing, where values could be normalized over a long period of time so that old entries 
that may skew results are not weighted as heavily as new ones.


On Aug 30, 2023, at 11:19 AM, jean-frederic clere  wrote:

Hi,

All the balancers have thread/process safe issues, but with bybusyness the 
effect is worse, basically a worker may stay with a busy count greater than 
zero even no request is being processed.

busy is displayed in the balancer_handler() so users/customers will notice the 
value doesn't return to zero...

If you run a load test the value of busy will increase by time and in all the 
workers

When using bybusyness, having pics in the load and later no much load makes the 
lowest busy workers used and the ones with a wrong higher value not being used.

In a test with 3 workers, I end with busy:
worker1: 3
worker2: 0
worker3: 2
Doing the load test several time the buys values are increasing in all workers.

I am wondering is we could end with something like:
worker1: 1000
worker2: 0
worker3: 1000

in this case bybusyness will send all the load to worker2 until we reach 1000 
simultaneous request on worker2... Obvious that looks bad.

How to fix that?
1 - reset the busy using a watchdog and elected (or transferred+read) unchanged 
for some time (using one of timeout we have on workers).
2 - warn in the docs that bybusyness is not the best choice for loadbalancing.
3 - create another balancer that just choose random a worker.

--
Cheers

Jean-Frederic

´

Re: balancers bybusyness, bytraffic and byrequest thread/process safe issues

[Rainer Jung]

Hi JFC,

I have not checked ur current code, but the topic reminds me of our 
history in mod_jk land. There we switched the counters to atomics were 
available. The other problematic part could be how to handle process 
local counters versus global counters.


Busyness was especially problematic for mod_jk as well, because we never 
deremented below zero if we lost increments, but if we lost decrements 
the counters stayed elevated. I think there we now have no longer such 
problems.


Best regards,

Rainer

Am 30.08.23 um 17:19 schrieb jean-frederic clere:

Hi,

All the balancers have thread/process safe issues, but with bybusyness 
the effect is worse, basically a worker may stay with a busy count 
greater than zero even no request is being processed.


busy is displayed in the balancer_handler() so users/customers will 
notice the value doesn't return to zero...


If you run a load test the value of busy will increase by time and in 
all the workers


When using bybusyness, having pics in the load and later no much load 
makes the lowest busy workers used and the ones with a wrong higher 
value not being used.


In a test with 3 workers, I end with busy:
worker1: 3
worker2: 0
worker3: 2
Doing the load test several time the buys values are increasing in all 
workers.


I am wondering is we could end with something like:
worker1: 1000
worker2: 0
worker3: 1000

in this case bybusyness will send all the load to worker2 until we reach 
1000 simultaneous request on worker2... Obvious that looks bad.


How to fix that?
1 - reset the busy using a watchdog and elected (or transferred+read) 
unchanged for some time (using one of timeout we have on workers).
2 - warn in the docs that bybusyness is not the best choice for 
loadbalancing.

3 - create another balancer that just choose random a worker.

Re: mod_ssl SSL_OP_IGNORE_UNEXPECTED_EOF: "unexpected eof while reading"

[Rainer Jung]

Am 30.08.23 um 13:50 schrieb 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.


Thanks for your feedback. I committed it to trunk in r1912015 and can 
revert if someone thinks its premature. Will propose for backport 
probably tomorrow.


Best regards,

Rainer

mod_ssl SSL_OP_IGNORE_UNEXPECTED_EOF: "unexpected eof while reading"

[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?

Best regards,

Rainer

Re: svn commit: r1909606 - /httpd/httpd/trunk/modules/generators/mod_status.c

[Rainer Jung]

Oups and thanks!

Am 04.05.23 um 12:30 schrieb yla...@apache.org:

Author: ylavic
Date: Thu May  4 10:30:25 2023
New Revision: 1909606

URL: http://svn.apache.org/viewvc?rev=1909606=rev
Log:
Follow up to r1909429: Fix scope/block syntax.

Modified:
 httpd/httpd/trunk/modules/generators/mod_status.c

Modified: httpd/httpd/trunk/modules/generators/mod_status.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/generators/mod_status.c?rev=1909606=1909605=1909606=diff
==
--- httpd/httpd/trunk/modules/generators/mod_status.c (original)
+++ httpd/httpd/trunk/modules/generators/mod_status.c Thu May  4 10:30:25 2023
@@ -348,9 +348,9 @@ static int status_handler(request_rec *r
  else if (res != SERVER_DEAD &&
   res != SERVER_STARTING &&
   res != SERVER_IDLE_KILL) {
-if (res == SERVER_GRACEFUL)
+if (res == SERVER_GRACEFUL) {
  graceful++;
-if (is_async) {
+if (is_async)
  thread_graceful_buffer[i]++;
  } else {
  busy++;

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

[Rainer Jung]

Am 04.05.23 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


[X]: 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 and regards,

Rainer

Re: Current pytest failures

[Rainer Jung]

Am 09.03.23 um 11:29 schrieb 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),


Will do. It happens with nghttp 1.34.0 and recent 1.52.0. I took the 
header from my curl, which automatically adds it, but I think the right 
header is


Content-Type: multipart/form-data; boundary=DSAJKcd9876

That one is explicitly added in pyhttpd/nghttp.py in function 
upload_file, but not in post_name.


Skimming through the code for nghttp, it seems it dows add 
content-length (if not forbidden by a commandline flag), but I didn't 
find an explicit mentioning of content-type.


Best regards,

Rainer

Re: Current pytest failures

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


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

[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

[Rainer Jung]

I will see how to extract the test case out of pytest to be able to run 
it standalone and vary the protocol. But the connection reset plus 
second request might also be nghttp specific. I will also try running 
nghttp from remote and sniff to double check the connection reset plus 
second request.


Thanks and  regards,

Rainer

Am 09.03.23 um 09:19 schrieb Ruediger Pluem:



On 3/8/23 10:44 PM, Rainer Jung wrote:

Hi there,

I currently get three consistent pytest failures:


Do A) and B) work if you do the requests via HTTP/1.1?

Regards

Rüdiger

Re: Current pytest failures

[Rainer Jung]

Thanks for the tip. I already did the "run only one test case" and I 
fixed the LogLevel in test.conf to include trace8. So I guess there will 
not be any additional CGI logging available. But good to know the "-vvv".


Thanks and regards,

Rainer

Am 09.03.23 um 09:33 schrieb 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.

Current pytest failures

[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.py?name=X HTTP/2.0


And now we send the 500 code, probably due to the connection reset

[Wed Mar 08 22:03:35.788676 2023] [http2:debug] [pid 4606:tid 
140645720774400] h2_stream.c(1537): [client 127.0.0.1:50490] AH03073: 
h2_stream(4606-0-13,HALF_CLOSED_REMOTE): submit response 500


The access log also shows two of these requests:

127.0.0.1 - - [08/Mar/2023:22:03:35 +0100] "POST //echohd.py?name=X 
HTTP/2.0" 500 678 "-" "nghttp2/1.52.0" 1
127.0.0.1 - - [08/Mar/2023:22:03:35 +0100] "POST //echohd.py?name=X 
HTTP/2.0" 200 0 "-" "nghttp2/1.52.0" 1


And in the trace 8 error log except for the "Subsequent (No.2) HTTPS 
request received" I don't see where this would get a code 200 as 
indicated in the access log.


Client side log:

execute: nghttp --header=host: 

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

[Rainer Jung]

Not a showstopper, but: srclib/apr/configure was again generated with 
autoconf 2.70+ (2.71). This triggers a bug which is fixed in APR 1.7.x 
head, but the fix has not been released as there was not APR release vor 
almost 4 years now.


Since the bundled APR/APU are not actually part of the release, for me 
this is not a show stopper. I just wanted to note the defect in case 
others are wondering, why the bundled APR can not be build using configure.


Technical details:

configure: error: could not determine the string function for int64_t

It comes from defining some things once in conftest.c and again in the 
included confdefs.h.


Some pointers:

https://github.com/apache/apr/pull/25
https://github.com/apache/apr/commit/a15958a37a06f71c42c690278f9c958b93b7ee20
https://github.com/apache/apr/commit/e0197912a5438b3836ce2e76371f01e289d82931

https://www.mail-archive.com/bug-autoconf@gnu.org/msg04695.html

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97998

Best regards,

Rainer

Am 10.01.23 um 14:40 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.55-rc1 as 2.4.55:
[ ] +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: 5276ea8bc6fff31eed5c82132ae51a0b2ee05f9e6b61a00fa877f6cadab3b638
*httpd-2.4.55-rc1.tar.gz
sha512: 
ca0d03b5e74078977378fe711ca3ed8cf63c109b7dbe73f2c43f7f30f7e522bbe46f93189a183b7675394d57fffb0c2526facd8d40508be984a7a8f64d18f8d6
*httpd-2.4.55-rc1.tar.gz

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

Escaping double quotation marks in the error log

[Rainer Jung]

Hi there,

I looked at our escaping functions for logs due to the need of doing 
JSON logging. In principle one can output JSON by using appropriate log 
format definitions in the httpd config. Most special characters in JSON 
are already properly escaped in our output.


But there is one important difference between the escaping of access log 
items and of error log items. The escaping function for the access log 
also escapes double quotation marks as \", the one for the error log 
does not (ap_escape_errorlog_item). It contains the comment "no need for 
this in error log". This is true all the way since the time the escaping 
was introduced at all.


I wonder, whether there is a real necessity for not escaping double 
quotation marks in the error log?


Note, that I am not talking about markup that appears in the definition 
of the ErrorLogFormat itself. This is "just" about double quotation 
marks showing up in the error message itself (or logged headers, env 
vars or notes).


Unfortunately the use of ap_escape_errorlog_item() is buried deep down 
in the code levels and accessing virtual host config seems not possible, 
not even in the callers of ap_escape_errorlog_item().


If there's no other nice idea, I wonder whether:

- it would be OK, to escape double quotation marks as \" in the error 
log for trunk


- add a global config item to do this as well for 2.4.x (default off)

What do you think? Or did you find a better solution for error log json 
logging?


Best regards,

Rainer

Re: mod_proxy_http2 setting Transfer-Encoding chunked for a GET request

[Rainer Jung]

Hi Stefan,

the PR is:

https://bz.apache.org/bugzilla/show_bug.cgi?id=66282

Let me know, in case you can not reproduce it, or I should test something!

Best regards,

Rainer

mod_proxy_http2 setting Transfer-Encoding chunked for a GET request

[Rainer Jung]

Hi all,

today I stumbled into an unexpected request denial by a rule in the 
mod_security Core Rule Set 3. It denies requests without body, that have 
Transfer-Encoding chunked set.


When I send a normal GET request, without body, no Transfer-Encoding and 
no Content-Length, to httpd and proxy it via mod_proxy_http2 to the same 
server, the proxied request gets "Transfer-Encoding: chunked" added by 
mod_proxy_http2 and is then denied by mod_security on the receiving 
side. No such addition when using mod_proxy_http.


It seems to me, that "Transfer-Encoding: chunked" is not allowed for 
http/2 (due to its always streaming behavior), and at least it is 
unexpected for a GET or HEAD request.


Any chance we can get rid of it when proxying a request, that has no 
body and doesn't bring the header by its own?


Should I open a PR in our bugzilla, or on the mod_h2 Github repos?

Thanks and best regards,

Rainer

pytest for 2.4.x: crashes in mod_md during child shutdown

[Rainer Jung]

Hi there,

I ran the pytest suite on SLES 12+15 and RHEL 7+8 for 2.4.54 plus 
OpenSSL 1.1.1p. Ran it for event, worker and prefork and with OpenSSL 
1.1.1 and 3.0 in the client.


I observe sporadic segmentation faults on all of those platforms and for 
all MPMs and all OpenSSL versions in the client.


The crashes are not especially frequent and I only have backtraces on 
one platform (RHEL 8). There the pattern seems to be consistently:


- only two threads shown, also for event and worker

- one thread is in various stacks underneath clean_child_exit()

- the other thread is somewhere below

md_reg_renew()
run_renew()
acme_renew()
...

- it looks like things have already been deinitialized by the thread in 
clean_child_exit() when mod_md gets a renew job from mod_watchdog.


Before I investigate further: is there already an expectation, that 
mod_watchdog should not dispatch a job after shutdown has started and 
vice versa shutdown should wait for a running mod_watchdog job at least 
some time? Or that mod_md should not execute on such a job after 
shutdown has started?


It is probably a niche experience, but I got 20 segfaults in roughly 48 
pytest suite runs.


Test for httpd using OpenSSL 3.0.4 on the server side will run later today.

Best regards,

Rainer

Re: svn commit: r1902117 - /httpd/httpd/trunk/modules/cluster/mod_heartmonitor.c

[Rainer Jung]

Am 21.06.2022 um 07:38 schrieb Ruediger Pluem:



On 6/20/22 10:54 PM, rj...@apache.org wrote:

Author: rjung
Date: Mon Jun 20 20:54:14 2022
New Revision: 1902117

URL: http://svn.apache.org/viewvc?rev=1902117=rev
Log:
*) mod_heartmonitor: Allow "HeartbeatMaxServers 0"
to use file based storage instead of slotmem.
Needed after setting HeartbeatMaxServers default
to the documented value 10 in 2.4.54.
[Jérôme Billira

Modified:
 httpd/httpd/trunk/modules/cluster/mod_heartmonitor.c

Modified: httpd/httpd/trunk/modules/cluster/mod_heartmonitor.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/cluster/mod_heartmonitor.c?rev=1902117=1902116=1902117=diff
==
--- httpd/httpd/trunk/modules/cluster/mod_heartmonitor.c (original)
+++ httpd/httpd/trunk/modules/cluster/mod_heartmonitor.c Mon Jun 20 20:54:14 
2022
@@ -892,8 +892,9 @@ static const char *cmd_hm_maxworkers(cmd
  }
  
  maxworkers = atoi(data);

-if (maxworkers <= 10)
-return "HeartbeatMaxServers: Should be bigger than 10";
+if (maxworkers != 0 && maxworkers <= 10)


Shouldn't this be < 10, such that you can set the default value via 
HeartbeatMaxServers.
It seems strange that this can't be done. Furthermore <= 10 does not match the 
error message below.


Oups, thank you! Hopefully fixed in r1902130


+return "HeartbeatMaxServers: Should be 0 for file storage, "
+   "or greater or equal than 10 for slotmem";


Shouldn't this be documented in the documentation as well that '0' has a 
special meaning and that 1-9 are not allowed?


Done in r1902132 + r1902133

I hope I understood the correct conditions for using flat-file storage.

Best regards,

Rainer

Re: svn commit: r1901514 - in /httpd/test/framework/trunk: README t/conf/extra.conf.in t/modules/sed.t

[Rainer Jung]

I wonder, what the following test is expected to test? I can't really 
make it work reliably here. Sometimes I get an ENOMEM on the server, 
sometimes it takes a long time and much CPU, sometimes the client gets a 
596 AnyEvent::HTTP error and sometimes it runs ok.


Am 01.06.2022 um 15:03 schrieb cove...@apache.org:

Modified: httpd/test/framework/trunk/t/modules/sed.t
URL: 
http://svn.apache.org/viewvc/httpd/test/framework/trunk/t/modules/sed.t?rev=1901514=1901513=1901514=diff
==
--- httpd/test/framework/trunk/t/modules/sed.t (original)
+++ httpd/test/framework/trunk/t/modules/sed.t Wed Jun  1 13:03:08 2022
@@ -5,29 +5,44 @@ use Apache::Test;
  use Apache::TestRequest;
  use Apache::TestUtil;
  
+# Hack to allow streaming of data in/out of mod_echo

+use LWP::Protocol::AnyEvent::http;
+
  my @ts = (
 # see t/conf/extra.conf.in
-   { url => "/apache/sed/out-foo/foobar.html", content => 'barbar', msg => "sed output 
filter", code => 200 },
-   { url => "/apache/sed-echo/echo.html", content => 'barbar', msg => "sed input filter", code 
=> 200, body=>"foobar" }
+   { url => "/apache/sed/out-foo/foobar.html", content => 'barbar', msg => "sed output 
filter", code => '200' },
+   # error after status sent
+   { url => "/apache/sed-echo/out-foo-grow/foobar.html", content => "", msg => "sed output filter too 
large", code => '200', body=>"foo" x (8192*1024), resplen=>0},


I found no  other body size, that made it reliable, so therefore I am 
wondering, what it would test in an ideal world.


Thanks and regards,

Rainer

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

[Rainer Jung]

Am 06.06.2022 um 16:25 schrieb Stefan Eissing:

Here we go again! Sorry for the repeats, but that is why we build candidates, 
right?

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.54-rc3 as 2.4.54:
[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.


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


I actually used rc2 plus the one "#if" patch which got included in rc3 
to build and test, but also did the simple release checks for rc3.


! KEYS maybe missing (see other mail)
- Sigs and hashes OK
- contents of tarballs identical
- contents of tag and tarballs identical
  except for expected deltas

Built on

- Solaris 10 Sparc as 32 Bit Binaries
- SLES 11+12+15 (64 Bits)
- RHEL 6+7+8 (64 Bits)

For all platforms built

- with default (shared) and static modules
  (Solaris only shared modules)
- with module set reallyall
- using --enable-load-all-modules

- using libraries
  - APR/APU
- bundled deps tarball
- 1.7.0/1.6.1
- 1.6.5/1.6.1
- 1.7.x(r1901250)/1.7.x(r1901250) with libxml2
- 1.7.x(r1901250)/1.7.x(r1901250) with expat
- 1.6.x(r1898636)/1.6.x(r1901250)
- trunk(r1901250) with libxml2
- trunk(r1901250) with expat
  - OpenSSL 3.0.3, 1.1.1o, 1.1.1,
1.0.2u, 1.0.2, 0.9.8zh, 0.9.8b
  - expat 2.4.8
  - pcre 10.39, sometimes 10.40
  - lua 5.4.4 (compiled with LUA_COMPAT_MODULE)
  - libxml2 2.9.14
  - libnghttp2 1.47.0
  - brotli 1.0.9
  - curl 7.83.1
  - jansson 2.14
  - libldap 2.6.2 (2.5.7 with OpenSSL 1.1.1,
   2.4.59 with OpenSSL 1.0.2*,
   2.4.52 with OpenSSL 0.9.8*)
  - on Solaris also platform ldap library

- in total 96 builds per platform, 60 on Solaris

- Tool chain:
- platform gcc except on Solaris
  (gcc 9.3.0 Solaris 10)
- CFLAGS: -O2 -g -Wall -fno-strict-aliasing
  - on Solaris additionally -mpcu=v9, -D_XOPEN_SOURCE,
-D_XOPEN_SOURCE_EXTENDED=1, -D__EXTENSIONS__
and -D_XPG6

All 636 builds succeeded.

- compiler warnings:

  - only on Solaris (GCC 9.3.0):
srclib/apr/locks/unix/proc_mutex.c:979:49: warning: 
'mutex_proc_pthread_cond_methods' defined but not used 
[-Wunused-const-variable=]


  - deprecation warnings when building against OpenSSL 3.0.0, see other 
thread


Tested for

- SLES 11+12+15
- RHEL 6+7+8
- Solaris 10 Sparc
- MPMs prefork, worker, event
- log level trace8
- Perl client bundle build against OpenSSL 3.0.0, ,
  1.1.1g plus patches, 1.1.0l, 1.0.2u and 0.9.8zh

Every OpenSSL version in the client tested with every OpenSSL version in 
the server. 15 unit test runs (3 MPMS x 5 OpenSSL clients) per server build.

About 2.400 unit test runs are done, most for shared module builds.

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
  Test 4 (411 times), test 8 (217 times) and 12 (18 times)
  Not a regression
  Only on RHEL 6, SLES 11 and Solaris 10.

b Various tests in t/modules/cgi.t, mostly lines 195 and 223,
  sometimes line 167 and 252
  Not a regression
  Only on Solaris and once on RHEL 6
  110 failed test runs (out of 120 on Solaris)
  Test checks log contents. Could be false positive due to
  logs written to NFS.

c t/modules/sed.t line 37 test 3
  91 times Solaris 10, 12 times RHEL 9, 6 times SLES 11
  At least two cases I checked were
  "(12)Cannot allocate memory" (Linux) resp.
  "(12)Not enough space:" (Solaris).

d A couple of tests fail for OpenSSL 0.9.8 based server
  when tested with a OpenSSL 3.0.0 based client:
  - t/modules/proxy_websockets_ssl.t
  - t/protocol/echo.t
  - t/security/CVE-2005-2700.t
  - t/security/CVE-2009-3555.t
  - t/ssl/basicauth.t
  - t/ssl/env.t
  - t/ssl/extlookup.t
  - t/ssl/fakeauth.t
  - t/ssl/headers.t
  - t/ssl/ocsp.t
  - t/ssl/pr12355.t
  - t/ssl/pr43738.t
  - t/ssl/proxy.t
  - t/ssl/require.t
  - t/ssl/varlookup.t
  - t/ssl/verify.t
  That might be expected due to the behavior of the 3.0
  default security level (not investigated)


Regards,

Rainer

> The computed digests of the tarball up for vote are:
> sha256: 
c687b99c446c0ef345e7d86c21a8e15fc074b7d5152c4fe22b0463e2be346ffb 
*httpd-2.4.54-rc3.tar.gz
> sha512: 
e9599df48a73b07b3a11dd44db2c22a671e8a41cdd5021bb434bbcde39d6fc498d165d9b0c4ed2b66a6321d9760b031c1c1c84c23661dbf44c42c52f637ec4dd 
*httpd-2.4.54-rc3.tar.gz

>
> The SVN candidate source is found at tags/2.4.54-rc3-candidate.
>
> Kind Regards,
> Stefan

Re: release anyone?

[Rainer Jung]

Am 25.05.2022 um 14:15 schrieb Stefan Eissing:

Anyone feeling release vibes in the air?

it's been a good 2.5 months and some things have accumulated.
Maybe the start of June would be a good target?


+1 and thanks!

Rainer

Re: svn commit: r1901009 - in /httpd/httpd/branches/2.4.x: CHANGES STATUS changes-entries/md_acme_failover.txt changes-entries/mod_proxy_log_backend_port.txt modules/http2/h2_mplx.c modules/http2/h2_v

[Rainer Jung]

Hi Jim,

it looks like the unrelated file 
changes-entries/mod_proxy_log_backend_port.txt was removed by accident 
during this commit? I don't see its contents already in CHANGES.


I had not yet used the make target "update-changes" when applying the 
backend port patch, so the changes-entries file was left for final 
CHANGES consolidation in purpose. I will add it back soon.


Best regards,

Rainer

Am 17.05.2022 um 20:17 schrieb j...@apache.org:

Author: jim
Date: Tue May 17 18:17:44 2022
New Revision: 1901009

URL: http://svn.apache.org/viewvc?rev=1901009=rev
Log:
Merge r from trunk:

Submitted by: icing, rpluem, ylavic
Reviewed by: jim

Github: closes #317

Removed:
 httpd/httpd/branches/2.4.x/changes-entries/md_acme_failover.txt
 httpd/httpd/branches/2.4.x/changes-entries/mod_proxy_log_backend_port.txt

...

Re: travis CI failing in 2.4.x

[Rainer Jung]

Forget the below. The real error was already detected by others and 
25.000 lines higher in the console output:


t/modules/heartbeat.t (Wstat: 0 Tests: 1 Failed: 1)

  Failed test:  1

Files=141, Tests=7232, 130 wallclock secs ( 2.85 usr  0.26 sys + 47.35 
cusr 10.50 csys = 60.96 CPU)


Result: FAIL

Failed 1/141 test programs. 1/7232 subtests failed.

...

Am 17.05.2022 um 15:24 schrieb Rainer Jung:

Not yet a full explanation but:

- the build fails due to "The job exceeded the maximum log length, and 
has been terminated." shortly before line 30.000


- the difference to the succeeeding "Linux Ubuntu Focal, ASan" is, that 
the ErrorLog of the run is not part of this log output handled by Travis.


- the lines you saw look pretty normal to me (depending on the modules 
we build). And it is not the exact same line repeating, but just the 
same type of line for every request executed during the tests.


I guess, the build configs differ, so that travis handled the ErrorLog 
differently?


Best regards,

Rainer

Re: travis CI failing in 2.4.x

[Rainer Jung]

Not yet a full explanation but:

- the build fails due to "The job exceeded the maximum log length, and 
has been terminated." shortly before line 30.000


- the difference to the succeeeding "Linux Ubuntu Focal, ASan" is, that 
the ErrorLog of the run is not part of this log output handled by Travis.


- the lines you saw look pretty normal to me (depending on the modules 
we build). And it is not the exact same line repeating, but just the 
same type of line for every request executed during the tests.


I guess, the build configs differ, so that travis handled the ErrorLog 
differently?


Best regards,

Rainer

Re: mod_dumpio and per-dir loglevel

[Rainer Jung]

Am 10.05.2022 um 16:23 schrieb Eric Covener:

I was looking at making some tests run more quietly, but mod_dumpio
uses ap_log_cerror even though it always has a ap_filter_t when it's
doing its real work.

While this would still leave some early logging (pre-location walk)
w/o the per-dir loglevel set yet, it would kick in by the time bodies
are read/written.

Can anyone anticipate any issue/concern here with using ap_log_rerror?


Probably not what you are asking, but mod_dumpio in a (reverse) proxy 
context can log the front connection and the back connection. Maybe 
something to be aware of when switching from connection to request.


Best regards,

Rainer

Re: pytest: test_101_ssl_reneg.py with OpenSSL 3.0.2 triggers error in TestBuffering.test_h2_712_03

[Rainer Jung]

Cool, thanks for the pointer. Will report back!

Am 24.04.2022 um 22:29 schrieb Stefan Eissing:

Hi Rainer,

there is a list of patterns and APLOGNOs that are allowed to happen. In the 
http2 tests, those are defined in env.py, lines 88-97.

If we get new ones with openssl 3.0.2, we need to add them there. Could you 
give this a shot?

Kind Regards,

Stefan


Am 24.04.2022 um 22:03 schrieb Rainer Jung :

Hi all,

at the end of the test runs in the pytest suite, TestBuffering.test_h2_712_03 
checks for warnings or errors logged in the httpd error log. None are allowed, 
but test

test_101_ssl_reneg.py

[ssl:error] [pid 15298:tid 140040420189952] SSL Library Error: 
error:0AC1:SSL routines::no shared cipher -- Too restrictive SSLCipherSuite 
or using DSA server certificate?
[ssl:error] [pid 15298:tid 140040411797248] SSL Library Error: 
error:0AC7:SSL routines::peer did not return a certificate -- No CAs known 
to server for verification?
[ssl:error] [pid 15299:tid 140040378226432] SSL Library Error: 
error:0AC7:SSL routines::peer did not return a certificate -- No CAs known 
to server for verification?
[ssl:error] [pid 15299:tid 140040369833728] SSL Library Error: 
error:0AC1:SSL routines::no shared cipher -- Too restrictive SSLCipherSuite 
or using DSA server certificate?

This is with OpenSSL 3.0.2. It does not happen with OpenSSL 1.1.1n (server and 
curl, but the nghttp2 commandline tools always using 3.0.2).

I added time stamps, so I think the relevant tests, that produce the messages 
are:

24.04.2022 10:07:50.347236 
test/modules/http2/test_101_ssl_reneg.py::TestSslRenegotiation::test_h2_101_03 
PASSED:

[Sun Apr 24 10:07:50.337861 2022] [ssl:error] [pid 9912:tid 139900498208512] 
SSL Library Error: error:0AC1:SSL routines::no shared cipher -- Too 
restrictive SSLCipherSuite or using DSA server certificate?

24.04.2022 10:07:50.459491 
test/modules/http2/test_101_ssl_reneg.py::TestSslRenegotiation::test_h2_101_04 
PASSED:

[Sun Apr 24 10:07:50.451743 2022] [ssl:error] [pid 9912:tid 139900506601216] 
SSL Library Error: error:0AC7:SSL routines::peer did not return a 
certificate -- No CAs known to server for verification?

24.04.2022 10:07:50.580942 
test/modules/http2/test_101_ssl_reneg.py::TestSslRenegotiation::test_h2_101_05 
PASSED:

[Sun Apr 24 10:07:50.572229 2022] [ssl:error] [pid 9911:tid 139900473030400] 
SSL Library Error: error:0AC7:SSL routines::peer did not return a 
certificate -- No CAs known to server for verification?

24.04.2022 10:07:50.862277 
test/modules/http2/test_102_require.py::TestRequire::test_h2_102_01 PASSED:

[Sun Apr 24 10:07:50.853262 2022] [ssl:error] [pid 9912:tid 139900389103360] 
SSL Library Error: error:0AC1:SSL routines::no shared cipher -- Too 
restrictive SSLCipherSuite or using DSA server certificate?

I haven't thought about how to fix this, first wanted to make it known.

Thanks and regards,

Rainer

pytest: test_101_ssl_reneg.py with OpenSSL 3.0.2 triggers error in TestBuffering.test_h2_712_03

[Rainer Jung]

Hi all,

at the end of the test runs in the pytest suite, 
TestBuffering.test_h2_712_03 checks for warnings or errors logged in the 
httpd error log. None are allowed, but test


test_101_ssl_reneg.py

[ssl:error] [pid 15298:tid 140040420189952] SSL Library Error: 
error:0AC1:SSL routines::no shared cipher -- Too restrictive 
SSLCipherSuite or using DSA server certificate?
[ssl:error] [pid 15298:tid 140040411797248] SSL Library Error: 
error:0AC7:SSL routines::peer did not return a certificate -- No CAs 
known to server for verification?
[ssl:error] [pid 15299:tid 140040378226432] SSL Library Error: 
error:0AC7:SSL routines::peer did not return a certificate -- No CAs 
known to server for verification?
[ssl:error] [pid 15299:tid 140040369833728] SSL Library Error: 
error:0AC1:SSL routines::no shared cipher -- Too restrictive 
SSLCipherSuite or using DSA server certificate?


This is with OpenSSL 3.0.2. It does not happen with OpenSSL 1.1.1n 
(server and curl, but the nghttp2 commandline tools always using 3.0.2).


I added time stamps, so I think the relevant tests, that produce the 
messages are:


24.04.2022 10:07:50.347236 
test/modules/http2/test_101_ssl_reneg.py::TestSslRenegotiation::test_h2_101_03 
PASSED:


[Sun Apr 24 10:07:50.337861 2022] [ssl:error] [pid 9912:tid 
139900498208512] SSL Library Error: error:0AC1:SSL routines::no 
shared cipher -- Too restrictive SSLCipherSuite or using DSA server 
certificate?


24.04.2022 10:07:50.459491 
test/modules/http2/test_101_ssl_reneg.py::TestSslRenegotiation::test_h2_101_04 
PASSED:


[Sun Apr 24 10:07:50.451743 2022] [ssl:error] [pid 9912:tid 
139900506601216] SSL Library Error: error:0AC7:SSL routines::peer 
did not return a certificate -- No CAs known to server for verification?


24.04.2022 10:07:50.580942 
test/modules/http2/test_101_ssl_reneg.py::TestSslRenegotiation::test_h2_101_05 
PASSED:


[Sun Apr 24 10:07:50.572229 2022] [ssl:error] [pid 9911:tid 
139900473030400] SSL Library Error: error:0AC7:SSL routines::peer 
did not return a certificate -- No CAs known to server for verification?


24.04.2022 10:07:50.862277 
test/modules/http2/test_102_require.py::TestRequire::test_h2_102_01 PASSED:


[Sun Apr 24 10:07:50.853262 2022] [ssl:error] [pid 9912:tid 
139900389103360] SSL Library Error: error:0AC1:SSL routines::no 
shared cipher -- Too restrictive SSLCipherSuite or using DSA server 
certificate?


I haven't thought about how to fix this, first wanted to make it known.

Thanks and regards,

Rainer

Re: Adding a2md to httpd sources?

[Rainer Jung]

Thanks for all feedback. So no need to integrate.

Note that the 2.4.x pytest suite still makes heavy use of it when 
testing mod_md.


Thanks and regards,

Rainer

Am 08.04.2022 um 10:24 schrieb Steffen:


Agree no need for it anymore.

Ps.
You wrote:
I have not yet heard any questions or feedback from anyone about it….If I 
remember correctly, no one was around to make the cmake and Windows builds for 
it.

I had given feedback and was able to build it on windows in 2017. In the 
beginning some crashes, but Stefan solved.



Op 8 apr. 2022 om 09:14 heeft Stefan Eissing  het volgende 
geschreven:



Am 07.04.2022 um 13:04 schrieb Rainer Jung :

Hi there,

during my experiments with the nice pytest based test suite against 2.4.x I noticed, that 
many mod_md tests need "a2md". The sources for this commandline tool ar in 
Stefan's GitHub repos for mod_md, but not inside the httpd 2.4.x source tree.

I have not really checked, what a2md exactly does, but was wondering, how much 
sense it would make to add it to 2.4.x as another support binary?

 From the man page:

The a2md utility can be used to configure and update managed domains with the 
mod_md module for Apache HTTP Server. Managed Domains are virtual hosts which 
automatically obtain and renew TLS certificates from an ACME server.

Is it ready for prime time? Would it interact with a custom build of httpd 
(layout might differ from distros)? What's the expectation?


Some distros, who package from the github repro, seem to include a2md, but I 
have not yet heard any questions or feedback from anyone about it. We excluded 
it in the httpd build as, if I remember correctly, no one was around to make 
the cmake and Windows builds for it.

Looking back, I do not see the need to a2md any longer. All can and should be 
configured in httpd's config files and information readout is available via the 
common status handlers and mod_md's own JSON status handler.

Kind Regards,
Stefan



Thanks and regards,

Rainer

Adding a2md to httpd sources?

[Rainer Jung]

Hi there,

during my experiments with the nice pytest based test suite against 
2.4.x I noticed, that many mod_md tests need "a2md". The sources for 
this commandline tool ar in Stefan's GitHub repos for mod_md, but not 
inside the httpd 2.4.x source tree.


I have not really checked, what a2md exactly does, but was wondering, 
how much sense it would make to add it to 2.4.x as another support binary?


From the man page:

The a2md utility can be used to configure and update managed domains 
with the mod_md module for Apache HTTP Server. Managed Domains are 
virtual hosts which automatically obtain and renew TLS certificates from 
an ACME server.


Is it ready for prime time? Would it interact with a custom build of 
httpd (layout might differ from distros)? What's the expectation?


Thanks and regards,

Rainer

Re: Current status of mod_h2 test suite?

[Rainer Jung]

Thaks, will switch to that one. Should have reembered it ...

Am 05.04.2022 um 14:04 schrieb Stefan Eissing:




Am 05.04.2022 um 14:01 schrieb Rainer Jung :

Hi Stefan,

Am 05.04.2022 um 13:49 schrieb Stefan Eissing:

Which test suite, the one in trunk or the one from github? Both work best 
against the respective source.


the test suite in

https://svn.apache.org/repos/asf/httpd/test/mod_h2/trunk


Oh, forgot about that one. Should remove it.


Which one would you recommend to test http2 in a 2.4.x release (candidate)?


The one in ^/httpd/httpd/branches/2.4.x/test/modules/http2

This is the one (and the corresponding in trunk) that also runs as part of our 
travis CI.

There is a README.pytest in test with some advice to set it up and use.

Kind Regards,
Stefan



Thanks and regards,

Rainer


Am 05.04.2022 um 13:47 schrieb Rainer Jung :

I try to make the mod_h2 test suite run for me. Some difficulties are expected 
due to my non-standard setup, but the first test that seems to fail in a way I 
am not directly blaming myself is

fuzz header
* on http://test.example.org:12345: super-long...--- gen/expect_431 2022-04-05 
13:25:40.081886486 +0200
+++ gen/result  2022-04-05 13:25:40.138887222 +0200
@@ -1,2 +1,2 @@
---> 0:1 GET / -> 431 0
+--> 0:1 GET / -> 431 273
0/0/1/0/0 (2/3/4/5/0xx)

It seems the test expects 0 body bytes but the web server sends:

\n\n431 Request Header Fields Too 
Large\n\nRequest Header Fields Too Large\nThe server refused this request because\nthe request 
header fields are too large.\n\n

which doesn't look like an error. So is this test broken? Is the general 
expectation, that other fuzzing tests will succeed?

Thanks for the test suite anyways. All tests before that first fuzzing test 
work.

Best regards,

Rainer

Re: Current status of mod_h2 test suite?

[Rainer Jung]

Hi Stefan,

Am 05.04.2022 um 13:49 schrieb Stefan Eissing:

Which test suite, the one in trunk or the one from github? Both work best 
against the respective source.


the test suite in

https://svn.apache.org/repos/asf/httpd/test/mod_h2/trunk

Which one would you recommend to test http2 in a 2.4.x release (candidate)?

Thanks and regards,

Rainer


Am 05.04.2022 um 13:47 schrieb Rainer Jung :

I try to make the mod_h2 test suite run for me. Some difficulties are expected 
due to my non-standard setup, but the first test that seems to fail in a way I 
am not directly blaming myself is

fuzz header
* on http://test.example.org:12345: super-long...--- gen/expect_431 2022-04-05 
13:25:40.081886486 +0200
+++ gen/result  2022-04-05 13:25:40.138887222 +0200
@@ -1,2 +1,2 @@
---> 0:1 GET / -> 431 0
+--> 0:1 GET / -> 431 273
0/0/1/0/0 (2/3/4/5/0xx)

It seems the test expects 0 body bytes but the web server sends:

\n\n431 Request Header Fields Too 
Large\n\nRequest Header Fields Too Large\nThe server refused this request because\nthe request 
header fields are too large.\n\n

which doesn't look like an error. So is this test broken? Is the general 
expectation, that other fuzzing tests will succeed?

Thanks for the test suite anyways. All tests before that first fuzzing test 
work.

Best regards,

Rainer

Current status of mod_h2 test suite?

[Rainer Jung]

I try to make the mod_h2 test suite run for me. Some difficulties are 
expected due to my non-standard setup, but the first test that seems to 
fail in a way I am not directly blaming myself is


fuzz header
 * on http://test.example.org:12345: super-long...--- gen/expect_431 
2022-04-05 13:25:40.081886486 +0200

+++ gen/result  2022-04-05 13:25:40.138887222 +0200
@@ -1,2 +1,2 @@
---> 0:1 GET / -> 431 0
+--> 0:1 GET / -> 431 273
 0/0/1/0/0 (2/3/4/5/0xx)

It seems the test expects 0 body bytes but the web server sends:

2.0//EN">\n\n431 Request Header Fields Too 
Large\n\nRequest Header Fields Too 
Large\nThe server refused this request because\nthe request 
header fields are too large.\n\n


which doesn't look like an error. So is this test broken? Is the general 
expectation, that other fuzzing tests will succeed?


Thanks for the test suite anyways. All tests before that first fuzzing 
test work.


Best regards,

Rainer

Re: Support JSON output in mod_status and mod_info

[Rainer Jung]

Am 28.03.2022 um 15:24 schrieb Stefan Eissing:




Am 28.03.2022 um 14:28 schrieb Rainer Jung :


I am thinking about adding a JSON output format to mod_status and mod_info as 
an option controlled by a query string parameter.

Since writing simple data structures from these modules is much simpler than 
parsing and processing a JSON structure, I would expect it to be based on 
simple ap_rputs() and ap_rprintf() like we already use it for auto (text) and 
HTML output. IMHO no need for a JSON library just for this use case.

Of course, this will slightly bloat the code with "if" statements and roughly 
double the amount of ap_rputs() and ap_rprintf().

For mod_status this probably means introduction of a new AP_STATUS_JSON value, 
so that in theory other modules could in the future update their status 
extensions with JSON support. In the meantime it might mean, that if a modules 
extends mod_status output, the result when asking for JSON output is no valid 
JSON (mix between mod_status JSON and mod_something providing HTML or text). 
For our own modules, especially mod_proxy, this can of course be fixed (and I 
will fix this). For mod_info, we do not have such an extension problem wrt. 
3rd-party modules.

Any comments up-front before I try to prototype this?


+1 (a big one)

Suggestion: we could add an additional `status_hook` like `status_json_hook` so 
that existing one do not get confused?


Doh, of course, haven't thought about this degree of freedom. Makes 
sense. Need to think how to make that new registration future feature 
proof, so that we don't need a new hook for every new status feature 
which is output incompatible.


Thanks and regards,

Rainer

Support JSON output in mod_status and mod_info

[Rainer Jung]

I am thinking about adding a JSON output format to mod_status and 
mod_info as an option controlled by a query string parameter.


Since writing simple data structures from these modules is much simpler 
than parsing and processing a JSON structure, I would expect it to be 
based on simple ap_rputs() and ap_rprintf() like we already use it for 
auto (text) and HTML output. IMHO no need for a JSON library just for 
this use case.


Of course, this will slightly bloat the code with "if" statements and 
roughly double the amount of ap_rputs() and ap_rprintf().


For mod_status this probably means introduction of a new AP_STATUS_JSON 
value, so that in theory other modules could in the future update their 
status extensions with JSON support. In the meantime it might mean, that 
if a modules extends mod_status output, the result when asking for JSON 
output is no valid JSON (mix between mod_status JSON and mod_something 
providing HTML or text). For our own modules, especially mod_proxy, this 
can of course be fixed (and I will fix this). For mod_info, we do not 
have such an extension problem wrt. 3rd-party modules.


Any comments up-front before I try to prototype this?

Thanks and regards,

Rainer

About our autoconf problems

[Rainer Jung]

First thanks to Stefan for downgrading his release system. It is a good 
workaround for the observed problems.


Since downgrades are not a long term solution, here's the status info to 
avoid confusion.


We observed two problems that had to do with using a recent autoconf 
version (2.70 an above) during releasing:


- bundled APR configure broken (ongoing)

This is already fixed by adjusting one of our autoconf macros in APR 
1.7.x and trunk (I think not in 1.6.x). But we didn't have an APR 
release since a long time, so the deps tarball for httpd still contains 
the latest but unfixed APR version. Once we will have a new APR release 
und bundle that, this autoconf problem will be gone and the latest 
autoconf should again be fine.


- thread local detection broken in httpd.h (fixed)

This is not a configure time problem, but a compile time problem. But it 
is still related to configure, because since autoconf 2.70 our call to 
AC_PROG_CC also checks whether the compiler support C11. For some gcc 
versions, eg. 4.8.x, this leads in "-std=gnu11" being added to the 
compiler flags. This in combination with httpd.h in 2.4.53-rc1 lead to a 
compile time failure. That problem is now fixed by making httpd.h more 
robust, so fir that problem the downgrade is no longer needed.


Thanks and regards,

Rainer

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

[Rainer Jung]

Am 09.03.2022 um 13:58 schrieb Ruediger Pluem:



On 3/9/22 11:34 AM, Rainer Jung wrote:

Am 09.03.2022 um 08:37 schrieb Ruediger Pluem:



On 3/8/22 10:09 PM, Rainer Jung wrote:






You gcc 4.8 workaround for _Thread_local still looks good.

Solaris builds and all unit tests not yet done but compiles fine for all my 
Linuxes.

Thanks!


Thanks for testing. I committed to trunk as r1898771 to throw it into our CI. 
If we need to tweak it further we can do later.

BTW: Once we have a final patch the same needs to be done for APR trunk and APR 
1.8.x.


Interesting: I did also compile APR trunk in my httpd release preparations but 
didn't observe the failure. This probably was due
to the fact, that our APR trunk configure does not decide to add -std=gnu11, so 
the test in the header file doesn't result in
_Thread_local being used.

Of course it still makes sense to apply the same patch (and also to other APR 
branches containing the thread local code). Just
wondering, whether the different handling of the"std" compiler flag for httpd 
and apr trunk is intentional.



Weird. I don't see -std=gnu11 added at all to my httpd build on RedHat 8.

gcc --version
gcc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-4)
autoconf --version
autoconf (GNU Autoconf) 2.69

But I have tested the patch and get AP_THREAD_LOCAL set to _Thread_local as it 
should.


Good. Concerning RHEL 8: I see the flag there neither due to:

RHEl7 :
checking for gcc -specs=/shared/build/autobuild/specs/specs.rhel7 option 
to enable C11 features... -std=gnu11


RHEL 8:
checking for gcc -specs=/shared/build/autobuild/specs/specs.rhel8 option 
to enable C11 features... none needed


The check for C11 was introduced in autoconf 2.70 as a new feature of 
"AC_PROG_CC", which we have in configure.in for httpd and for APR.


The observed behavioral difference between httpd configure and (my) APR 
trunk configure is due to the fact, that I generated my APR trunk 
configure with autoconf 2.69, so the check does not run there. But it 
would, once configure would be regenerated with modern autoconf. So 
indeed the thread local detection fix should go in APR as well.


Thanks and regards,

Rainer

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

[Rainer Jung]

Am 09.03.2022 um 08:37 schrieb Ruediger Pluem:



On 3/8/22 10:09 PM, Rainer Jung wrote:






You gcc 4.8 workaround for _Thread_local still looks good.

Solaris builds and all unit tests not yet done but compiles fine for all my 
Linuxes.

Thanks!


Thanks for testing. I committed to trunk as r1898771 to throw it into our CI. 
If we need to tweak it further we can do later.

BTW: Once we have a final patch the same needs to be done for APR trunk and APR 
1.8.x.


Interesting: I did also compile APR trunk in my httpd release 
preparations but didn't observe the failure. This probably was due to 
the fact, that our APR trunk configure does not decide to add 
-std=gnu11, so the test in the header file doesn't result in 
_Thread_local being used.


Of course it still makes sense to apply the same patch (and also to 
other APR branches containing the thread local code). Just wondering, 
whether the different handling of the"std" compiler flag for httpd and 
apr trunk is intentional.


Best regards,

Rainer

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

[Rainer Jung]

Am 08.03.2022 um 18:22 schrieb Rainer Jung:

Am 08.03.2022 um 17:06 schrieb Ruediger Pluem:



On 3/8/22 4:38 PM, Rainer Jung wrote:

Am 08.03.2022 um 16:33 schrieb Rainer Jung:


Am 07.03.2022 um 16:55 schrieb Stefan Eissing:

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.53-rc1 as 2.4.53:
[ ] +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: 
7559255a37adc5cb6f568ba224e435420f0a138cd9564162c9528b8ac08737b3 
*httpd-2.4.53-rc1.tar.gz

sha512:
a7734e2fa35389678be74bbc18136eef482ff9daecc2c1ed9c2c5eb410182735a94ff6ad248d0d4b6266e90161f2f8052d4871f381723c996ace0412b0219961 
*httpd-2.4.53-rc1.tar.gz



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

Kind Regards,
Stefan


Not a vote yet, just an observation: on SLES12 (gcc 4.8.3, glibc 
2.19) and RHEL7 (gcc 4.8.2, glibc 2.19) with platform
compilers, configure detects it wants to set -std=gnu11. During make 
I get a compilation error:


server/util.c:3183:1: error: unknown type name ‘_Thread_local’

The type "_Thread_local" comes from include/httpd.h:

    2438  #if defined(__cplusplus) && __cplusplus >= 201103L
    2439  #define AP_THREAD_LOCAL thread_local
    2440  #elif defined(__STDC_VERSION__) && __STDC_VERSION__ >= 201112
    2441  #define AP_THREAD_LOCAL _Thread_local

    2442  #elif defined(__GNUC__) /* works for clang too */
    2443  #define AP_THREAD_LOCAL __thread
    2444  #elif defined(WIN32) && defined(_MSC_VER)
    2445  #define AP_THREAD_LOCAL __declspec(thread)
    2446  #endif
    2447  #endif /* ndef AP_NO_THREAD_LOCAL */

It looks like the detection is broken?


See also: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203066


Thanks for the pointer. Does the below fix it?

Index: include/httpd.h
===
--- include/httpd.h    (revision 1898730)
+++ include/httpd.h    (working copy)
@@ -2587,7 +2587,9 @@
   */
  #if defined(__cplusplus) && __cplusplus >= 201103L
  #define AP_THREAD_LOCAL thread_local
-#elif defined(__STDC_VERSION__) && __STDC_VERSION__ >= 201112
+#elif defined(__STDC_VERSION__) && __STDC_VERSION__ >= 201112 && \
+  (!defined(__GNUC__) || \
+  __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 9))
  #define AP_THREAD_LOCAL _Thread_local
  #elif defined(__GNUC__) /* works for clang too */
  #define AP_THREAD_LOCAL __thread


Regards

Rüdiger


Looks good to me from inspection. I already tested a similar but not as 
good patch. The next builds will pick up your one. Will report back in 
an hour or so, whether it works for me.


Two additional things I already saw, but which are non.critical:

- configure flag --with-pcre no longer accepts an external pcre 8 
installation directory. It seems in that case the flag must now point to 
the path of the pcre-config script instead.


- configure for APR in the dependency tarball still fails for me due to 
a bug in autoconf 2.71 used to create the configure script. That problem 
was already reported by me during another release vote. I replaced the 
changed three files in the bundled apr and apr-util with the earlier ones.


Thanks and regards,

Rainer


You gcc 4.8 workaround for _Thread_local still looks good.

Solaris builds and all unit tests not yet done but compiles fine for all 
my Linuxes.


Thanks!

Rainer

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

[Rainer Jung]

Am 08.03.2022 um 17:06 schrieb Ruediger Pluem:



On 3/8/22 4:38 PM, Rainer Jung wrote:

Am 08.03.2022 um 16:33 schrieb Rainer Jung:


Am 07.03.2022 um 16:55 schrieb Stefan Eissing:

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.53-rc1 as 2.4.53:
[ ] +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: 7559255a37adc5cb6f568ba224e435420f0a138cd9564162c9528b8ac08737b3 
*httpd-2.4.53-rc1.tar.gz
sha512:
a7734e2fa35389678be74bbc18136eef482ff9daecc2c1ed9c2c5eb410182735a94ff6ad248d0d4b6266e90161f2f8052d4871f381723c996ace0412b0219961
 *httpd-2.4.53-rc1.tar.gz


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

Kind Regards,
Stefan


Not a vote yet, just an observation: on SLES12 (gcc 4.8.3, glibc 2.19) and 
RHEL7 (gcc 4.8.2, glibc 2.19) with platform
compilers, configure detects it wants to set -std=gnu11. During make I get a 
compilation error:

server/util.c:3183:1: error: unknown type name ‘_Thread_local’

The type "_Thread_local" comes from include/httpd.h:

    2438  #if defined(__cplusplus) && __cplusplus >= 201103L
    2439  #define AP_THREAD_LOCAL thread_local
    2440  #elif defined(__STDC_VERSION__) && __STDC_VERSION__ >= 201112
    2441  #define AP_THREAD_LOCAL _Thread_local

    2442  #elif defined(__GNUC__) /* works for clang too */
    2443  #define AP_THREAD_LOCAL __thread
    2444  #elif defined(WIN32) && defined(_MSC_VER)
    2445  #define AP_THREAD_LOCAL __declspec(thread)
    2446  #endif
    2447  #endif /* ndef AP_NO_THREAD_LOCAL */

It looks like the detection is broken?


See also: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203066


Thanks for the pointer. Does the below fix it?

Index: include/httpd.h
===
--- include/httpd.h (revision 1898730)
+++ include/httpd.h (working copy)
@@ -2587,7 +2587,9 @@
   */
  #if defined(__cplusplus) && __cplusplus >= 201103L
  #define AP_THREAD_LOCAL thread_local
-#elif defined(__STDC_VERSION__) && __STDC_VERSION__ >= 201112
+#elif defined(__STDC_VERSION__) && __STDC_VERSION__ >= 201112 && \
+  (!defined(__GNUC__) || \
+  __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 9))
  #define AP_THREAD_LOCAL _Thread_local
  #elif defined(__GNUC__) /* works for clang too */
  #define AP_THREAD_LOCAL __thread


Regards

Rüdiger


Looks good to me from inspection. I already tested a similar but not as 
good patch. The next builds will pick up your one. Will report back in 
an hour or so, whether it works for me.


Two additional things I already saw, but which are non.critical:

- configure flag --with-pcre no longer accepts an external pcre 8 
installation directory. It seems in that case the flag must now point to 
the path of the pcre-config script instead.


- configure for APR in the dependency tarball still fails for me due to 
a bug in autoconf 2.71 used to create the configure script. That problem 
was already reported by me during another release vote. I replaced the 
changed three files in the bundled apr and apr-util with the earlier ones.


Thanks and regards,

Rainer

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

[Rainer Jung]

Am 08.03.2022 um 16:33 schrieb Rainer Jung:


Am 07.03.2022 um 16:55 schrieb Stefan Eissing:

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.53-rc1 as 2.4.53:
[ ] +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: 
7559255a37adc5cb6f568ba224e435420f0a138cd9564162c9528b8ac08737b3 
*httpd-2.4.53-rc1.tar.gz
sha512: 
a7734e2fa35389678be74bbc18136eef482ff9daecc2c1ed9c2c5eb410182735a94ff6ad248d0d4b6266e90161f2f8052d4871f381723c996ace0412b0219961 
*httpd-2.4.53-rc1.tar.gz


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

Kind Regards,
Stefan


Not a vote yet, just an observation: on SLES12 (gcc 4.8.3, glibc 2.19) 
and RHEL7 (gcc 4.8.2, glibc 2.19) with platform compilers, configure 
detects it wants to set -std=gnu11. During make I get a compilation error:


server/util.c:3183:1: error: unknown type name ‘_Thread_local’

The type "_Thread_local" comes from include/httpd.h:

   2438  #if defined(__cplusplus) && __cplusplus >= 201103L
   2439  #define AP_THREAD_LOCAL thread_local
   2440  #elif defined(__STDC_VERSION__) && __STDC_VERSION__ >= 201112
   2441  #define AP_THREAD_LOCAL _Thread_local

   2442  #elif defined(__GNUC__) /* works for clang too */
   2443  #define AP_THREAD_LOCAL __thread
   2444  #elif defined(WIN32) && defined(_MSC_VER)
   2445  #define AP_THREAD_LOCAL __declspec(thread)
   2446  #endif
   2447  #endif /* ndef AP_NO_THREAD_LOCAL */

It looks like the detection is broken?


See also: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203066

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

[Rainer Jung]

Am 07.03.2022 um 16:55 schrieb Stefan Eissing:

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.53-rc1 as 2.4.53:
[ ] +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: 7559255a37adc5cb6f568ba224e435420f0a138cd9564162c9528b8ac08737b3 
*httpd-2.4.53-rc1.tar.gz
sha512: 
a7734e2fa35389678be74bbc18136eef482ff9daecc2c1ed9c2c5eb410182735a94ff6ad248d0d4b6266e90161f2f8052d4871f381723c996ace0412b0219961
 *httpd-2.4.53-rc1.tar.gz

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

Kind Regards,
Stefan


Not a vote yet, just an observation: on SLES12 (gcc 4.8.3, glibc 2.19) 
and RHEL7 (gcc 4.8.2, glibc 2.19) with platform compilers, configure 
detects it wants to set -std=gnu11. During make I get a compilation error:


server/util.c:3183:1: error: unknown type name ‘_Thread_local’

The type "_Thread_local" comes from include/httpd.h:

  2438  #if defined(__cplusplus) && __cplusplus >= 201103L
  2439  #define AP_THREAD_LOCAL thread_local
  2440  #elif defined(__STDC_VERSION__) && __STDC_VERSION__ >= 201112
  2441  #define AP_THREAD_LOCAL _Thread_local

  2442  #elif defined(__GNUC__) /* works for clang too */
  2443  #define AP_THREAD_LOCAL __thread
  2444  #elif defined(WIN32) && defined(_MSC_VER)
  2445  #define AP_THREAD_LOCAL __declspec(thread)
  2446  #endif
  2447  #endif /* ndef AP_NO_THREAD_LOCAL */

It looks like the detection is broken?

Best regards,

Rainer

Re: svn commit: r1897858 - in /httpd/httpd/trunk: ./ changes-entries/

[Rainer Jung]

Small typo below ...

Am 08.02.2022 um 12:04 schrieb yla...@apache.org:

Author: ylavic
Date: Tue Feb  8 11:04:49 2022
New Revision: 1897858

URL: http://svn.apache.org/viewvc?rev=1897858=rev
Log:
Sync CHANGES entries. [skip ci]

Removed:
 httpd/httpd/trunk/changes-entries/CoreDumpDirectory-freebsd11.txt
 httpd/httpd/trunk/changes-entries/ap_regex_thread_local.txt
 httpd/httpd/trunk/changes-entries/bz_65769.txt
 httpd/httpd/trunk/changes-entries/mod_dav_memory_regresssion.txt
 httpd/httpd/trunk/changes-entries/mod_md_status_memory.txt
 httpd/httpd/trunk/changes-entries/mod_tls_link_issue_with_rust_1_56.txt
 httpd/httpd/trunk/changes-entries/reqtimeout_mode_init.txt
Modified:
 httpd/httpd/trunk/CHANGES

Modified: httpd/httpd/trunk/CHANGES
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/CHANGES?rev=1897858=1897857=1897858=diff
==
--- httpd/httpd/trunk/CHANGES [utf-8] (original)
+++ httpd/httpd/trunk/CHANGES [utf-8] Tue Feb  8 11:04:49 2022
@@ -1,6 +1,32 @@
   -*- coding: utf-8 -*-
  Changes with Apache 2.5.1
  
+  *) mod_md: the status description in MDomain's JSON, exposed in the

+ md-status handler (if configure) did sometimes not carry the correct
+ message when certificates needed renew.
+ [Stefan Eissing]
+
+  *) mod_tls: Fix a linkage issue with rustls when compiled
+ with rust 1.55, 1.56 or 1.57. This prevents the loading
+ of the module because of an undefined symbol: fmaf
+ See https://github.com/rustls/rustls-ffi/issues/133
+ [Christophe Jaillet]
+
+  *) ap_regex: Use Thread Local Storage (TLS) to recycle ap_regexec() buffers
+ when an efficient TLS implementation is available. [Yann Ylavic]
+
+  *) mom_reqtimeout: Fix missing handshake= timeout enforcement.  [Yann Ylavic]


s/mom_/mod_/

Re: announce mails

[Rainer Jung]

Aaah, sorry, it did come in now,, son't know whether via dev@ or 
announce@. Thanks.


Am 20.12.2021 um 10:53 schrieb Stefan Eissing:

The mailings to announce lists continue to bother me. The release announcement 
is the the moderation queue (hopefully) and the cveprocess mails go right 
through to the list. This is not the order I prefer.

I am holden back the send about the second CVE until I see the release 
announcement winked through.

- Stefan

Re: announce mails

[Rainer Jung]

Hmmm, still no announcement mail received, or did I miss it?

Am 20.12.2021 um 10:53 schrieb Stefan Eissing:

The mailings to announce lists continue to bother me. The release announcement 
is the the moderation queue (hopefully) and the cveprocess mails go right 
through to the list. This is not the order I prefer.

I am holden back the send about the second CVE until I see the release 
announcement winked through.

- Stefan

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

[Rainer Jung]

Am 16.12.2021 um 15:03 schrieb Stefan Eissing:


Hi all,

Please find below the proposed release tarball and signatures:

https://dist.apache.org/repos/dist/dev/httpd/

I would like to call a VOTE over the next few days to release
this candidate tarball httpd-2.4.52-rc1 as 2.4.52:
[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.


+1 to release and thanks a bunch for RM!

I didn't have time to do the full range of my usual builds and tests. 
Nevertheless:


! KEYS maybe missing (see other mail)
- Sigs and hashes OK
- contents of tarballs identical
- contents of tag and tarballs identical
  except for expected deltas

Built on

- Solaris 10 Sparc as 32 Bit Binaries
- SLES 11+12+15 (64 Bits)
- RHEL 6+7+8 (64 Bits)

For all platforms built

- with module set all plus proxy_fdpass plus proxy_http2
- using APR/APU from the 2.4.51 deps tarball
  (see separate message, why for me the 2.4.52
  tarball didn't work)
- OpenSSL linked statically

- using external libraries
  - expat 2.4.1
  - pcre 8.45
  - lua 5.4.3 (compiled with LUA_COMPAT_MODULE)
  - libxml2 2.9.12
  - libnghttp2 1.46.0
  - brotli 1.0.9
  - curl 7.80.0
  - jansson 2.14
  - libldap 2.6.0
  - openssl 1.1.1m

- Tool chain:
- platform gcc except on Solaris
  (gcc 9.3.0 Solaris 10)
- CFLAGS: -O2 -g -Wall -fno-strict-aliasing
  - on Solaris additionally -mpcu=v9, -D_XOPEN_SOURCE,
-D_XOPEN_SOURCE_EXTENDED=1, -D__EXTENSIONS__
and -D_XPG6

Tested for

- SLES 11+12+15
- RHEL 6+7+8
- Solaris 10 Sparc
- MPMs prefork, worker, event
- log level trace8
- Perl client bundle build against OpenSSL 1.1.1g plus patches,
  ´3.0.0, 1.1.0l, 1.0.2u and 0.9.8zh

All of these tests passed.


The computed digests of the tarball up for vote are:
sha256: 296c74a8adde1a8acd6617b21fc3d19719ff4fa39319b2bdbd898aca4d5df97f 
*httpd-2.4.52-rc1.tar.gz
sha512: 
b9012096d6658f7d34a3c655eac31b39ffd439c11de6f3e6e9f309d55f4186a4fb26134eb97522e416ae8ca10ed008a14e96fa01a3e3105d9e547f72e2dc3bc2
 *httpd-2.4.52-rc1.tar.gz

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

Kind Regards,
Stefan

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

[Rainer Jung]

Am 17.12.2021 um 16:45 schrieb Stefan Eissing:




Am 17.12.2021 um 16:22 schrieb Rainer Jung :

At least on Linux (SLES 11/12/15, RHEL 6/7/8) I run into a configure error for 
APR from the deps tarball due to that configure being created with autoconf 
2.70 instead of 2.69 used for 2.4.51:

configure: error: could not determine the string function for int64_t

It comes from defining some things once in conftest.c and again in the included 
confdefs.h.

The problem seems to be known and at least some changes were added to the 1.7.x 
APR branch, but we didn't have a release there for a long time ... :(

Some pointers:

https://www.mail-archive.com/bug-autoconf@gnu.org/msg04695.html

https://github.com/apache/apr/pull/25

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97998

I will check, whether combining 2.4.52 with the deps tarball from 2.4.52 fixes 
this, or whether the httpd part of configure runs into the same problem.


Thanks Rainer. There are problems with the APR build on macOS as well. A new 
release would be welcome.

Since we do not release the -dep tarballs as part of Apache httpd, this should 
not be a stopper.

There were historically added for convenience on the voting. I think we should 
change our release scripts to no longer include them, unless we are sure they 
run correctly everywhere.

Kind Regards,
Stefan


Agreed. After replacing APR/APU with the ones from the 51 deps tarball, 
configure goes through. So for me there's no configure problem in the 
main tarball, at least not on Linux.



Regards,

Rainer

Am 16.12.2021 um 15:03 schrieb Stefan Eissing:

Hi all,
Please find below the proposed release tarball and signatures:
https://dist.apache.org/repos/dist/dev/httpd/
I would like to call a VOTE over the next few days to release
this candidate tarball httpd-2.4.52-rc1 as 2.4.52:
[ ] +1: It's not just good, it's good enough!
[ ] +0: Let's have a talk.
[ ] -1: There's trouble in paradise. Here's what's wrong.
The computed digests of the tarball up for vote are:
sha256: 296c74a8adde1a8acd6617b21fc3d19719ff4fa39319b2bdbd898aca4d5df97f 
*httpd-2.4.52-rc1.tar.gz
sha512: 
b9012096d6658f7d34a3c655eac31b39ffd439c11de6f3e6e9f309d55f4186a4fb26134eb97522e416ae8ca10ed008a14e96fa01a3e3105d9e547f72e2dc3bc2
 *httpd-2.4.52-rc1.tar.gz
The SVN candidate source is found at tags/candidate-2.4.52-rc1.
Kind Regards,
Stefan

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

[Rainer Jung]

At least on Linux (SLES 11/12/15, RHEL 6/7/8) I run into a configure 
error for APR from the deps tarball due to that configure being created 
with autoconf 2.70 instead of 2.69 used for 2.4.51:


configure: error: could not determine the string function for int64_t

It comes from defining some things once in conftest.c and again in the 
included confdefs.h.


The problem seems to be known and at least some changes were added to 
the 1.7.x APR branch, but we didn't have a release there for a long time 
... :(


Some pointers:

https://www.mail-archive.com/bug-autoconf@gnu.org/msg04695.html

https://github.com/apache/apr/pull/25

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97998

I will check, whether combining 2.4.52 with the deps tarball from 2.4.52 
fixes this, or whether the httpd part of configure runs into the same 
problem.


Regards,

Rainer

Am 16.12.2021 um 15:03 schrieb Stefan Eissing:


Hi all,

Please find below the proposed release tarball and signatures:

https://dist.apache.org/repos/dist/dev/httpd/

I would like to call a VOTE over the next few days to release
this candidate tarball httpd-2.4.52-rc1 as 2.4.52:
[ ] +1: It's not just good, it's good enough!
[ ] +0: Let's have a talk.
[ ] -1: There's trouble in paradise. Here's what's wrong.

The computed digests of the tarball up for vote are:
sha256: 296c74a8adde1a8acd6617b21fc3d19719ff4fa39319b2bdbd898aca4d5df97f 
*httpd-2.4.52-rc1.tar.gz
sha512: 
b9012096d6658f7d34a3c655eac31b39ffd439c11de6f3e6e9f309d55f4186a4fb26134eb97522e416ae8ca10ed008a14e96fa01a3e3105d9e547f72e2dc3bc2
 *httpd-2.4.52-rc1.tar.gz

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

Kind Regards,
Stefan

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

[Rainer Jung]

Thanks for the cool team effort and your work as RM!

I lost track about the correct expectation but wanted to note, that

https://dist.apache.org/repos/dist/dev/httpd/

does not contain a KEYS file. IMHO it did for the previous two releases, 
but maybe the requirements changed.


Thanks!

Rainer

Am 16.12.2021 um 15:03 schrieb Stefan Eissing:


Hi all,

Please find below the proposed release tarball and signatures:

https://dist.apache.org/repos/dist/dev/httpd/

I would like to call a VOTE over the next few days to release
this candidate tarball httpd-2.4.52-rc1 as 2.4.52:
[ ] +1: It's not just good, it's good enough!
[ ] +0: Let's have a talk.
[ ] -1: There's trouble in paradise. Here's what's wrong.

The computed digests of the tarball up for vote are:
sha256: 296c74a8adde1a8acd6617b21fc3d19719ff4fa39319b2bdbd898aca4d5df97f 
*httpd-2.4.52-rc1.tar.gz
sha512: 
b9012096d6658f7d34a3c655eac31b39ffd439c11de6f3e6e9f309d55f4186a4fb26134eb97522e416ae8ca10ed008a14e96fa01a3e3105d9e547f72e2dc3bc2
 *httpd-2.4.52-rc1.tar.gz

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

Kind Regards,
Stefan

Re: svn commit: r1893977 - in /httpd/httpd/branches/2.4.x: ./ CHANGES include/ap_mmn.h include/httpd.h server/gen_test_char.c server/request.c server/util.c

[Rainer Jung]

Am 07.10.2021 um 14:27 schrieb yla...@apache.org:

Modified: httpd/httpd/branches/2.4.x/include/ap_mmn.h
URL: 
http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/include/ap_mmn.h?rev=1893977=1893976=1893977=diff
==
--- httpd/httpd/branches/2.4.x/include/ap_mmn.h (original)
+++ httpd/httpd/branches/2.4.x/include/ap_mmn.h Thu Oct  7 12:27:43 2021
@@ -579,6 +579,9 @@
   *   ap_proxy_define_worker_ex() to mod_proxy.h
   * 20120211.116 (2.4.49-dev) add conn_rec->outgoing and ap_ssl_bind_outgoing()
   * 20120211.117 (2.4.50-dev) Add ap_pre_connection
+ * 20210926.1 (2.5.1-dev)  Add ap_unescape_url_ex() and deprecate
+ * AP_NORMALIZE_DROP_PARAMETERS
+ *
   */
  
  #define MODULE_MAGIC_COOKIE 0x41503234UL /* "AP24" */


Doesn't this need (a cosmetic) adjustment for 2.4.x?

Plus: if a minor bump is needed, this commit contains only a comment change.

Thanks for your intensive work!

Rainer

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

[Rainer Jung]

Thanks for testing Dennis. We need to get this release out quick due to 
regressions, so it wasn't the right moment to apply the OpenSSL patch.


I'm confident, that Joe's OpenSSL 3.0.0 patch will be included in the 
next regular 2.4 release.


Best regards,

Rainer

Am 02.10.2021 um 13:01 schrieb Dennis Clarke:

On 10/1/21 10:40, ste...@eissing.org 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.50-rc1 as 2.4.50:
[ ] +1: It's not just good, it's good enough!
[ ] +0: Let's have a talk.
[ ] -1: There's trouble in paradise. Here's what's wrong.

The computed digests of the tarball up for vote are:
sha1: afac1bf6aaa84ea2878c56ed56a49f5efdd7ff73 *httpd-2.4.50-rc1.tar.gz
sha256: feb87f9cc60e02782d795d30cd60a36e918c82fe9a2e7363b0ae28a78be9613a 
*httpd-2.4.50-rc1.tar.gz
sha512: 
3b5e06d8428f14bae8173dbb27921496831c7c14c31850d2df0c0d6f69e931bbf0e4e71c6a250b4f5c0d646d1b7da813bbe61711f8a79ab5f80d39dfd176f57c
 *httpd-2.4.50-rc1.tar.gz



+1: It's not just good, it's good with OpenSSL 1.1.1

On ye SPARC64 Solaris 10 server here it seems to work just fine with
OpenSSL 1.1.1l and of course it does not work ( yet ) with OpenSSL 3.0.0
and we already know that :

beta # /opt/bw/bin/apachectl start
httpd: Syntax error on line 99 of /opt/bw/etc/apache/httpd/httpd.conf:
Cannot load modules/mod_ssl.so into server: ld.so.1: httpd: fatal:
relocation error: file /opt/bw/modules/mod_ssl.so: symbol ERR_GET_FUNC:
referenced symbol not found
beta #

I don't know if trunk is functional and I have not really jumped on
trunk in a few weeks and I'll give that a whirl but autoconf/autoreconf
autotools madness was giving me hardship. At least last time I looked
which was 1893292 about two weeks ago.

Anyways 2.4.50 seems to work just fine with OpenSSL 1.1.1l for me.

Re: sending announcement mail

[Rainer Jung]

Am 16.09.2021 um 13:59 schrieb ste...@eissing.org:

Am 16.09.2021 um 13:57 schrieb ste...@eissing.org:

Am 16.09.2021 um 13:50 schrieb ste...@eissing.org:

Am 16.09.2021 um 13:46 schrieb Daniel Gruno :

it's on announce@httpd.a.o already. I modded it through.

You need to send it to annou...@apache.org as well.


I got the mail from annou...@apache.org, but not from annou...@httpd.apache.org

Alternate realities?


Hmm, maybe my MacOS mail client confuses me...


I give up. Could you mail 
 to the 
list where it missing?


I think there is still no announcement on annou...@apache.org. At least 
I don't see it here


https://mail-archives.apache.org/mod_mbox/www-announce/202109.mbox/browser

and I think I also didn't get it. For the previous 2.4.48 there was one 
from Christophe on June 1st:


https://mail-archives.apache.org/mod_mbox/www-announce/202106.mbox/browser

Thanks and regards,

Rainer

Re: trunk/rc usable with OpenSSL 3.0.0 ?

[Rainer Jung]

Hi Dennis,

Am 13.09.2021 um 11:05 schrieb Dennis Clarke:

On 9/13/21 04:22, Joe Orton wrote:

On Mon, Sep 13, 2021 at 01:23:37AM -0400, Dennis Clarke wrote:


ALL :


I may receive no reply to this but in general I have been able to build
Apache httpd from any release tarball as well as from trunk. When httpd
needed to get TLS 1.3 working it was a slam dunk to get that working and
it did. However now we have OpenSSL 3.0.0 and it seems that neither the
latest RC works nor does trunk.

So then ... how to proceed ?


What fails with trunk?

It's expected that httpd 2.4 doesn't support 3.0 yet, hopefully we can
get this in for a future release but OpenSSL 3.0 has been a moving
target until just six days ago.

Regards, Joe



Why "expected" that httpd 2.4 doesn't support 3.0 ?


"expected" in the sense that the httpd project developers know about 
this. So "we" expect it.



While I realize that 3.0.0 is very shiney new and still has a green glow
to is we also know that the beta program has been in place for months
and the release candidates go back a year.


We did successfully test 3.0.0 alpha and beta in combination with the 
previous 2.4 releases. See for instance my release vote mails then.


3.0.0 use in combination with httpd 2.4.x did only break recently, due 
to changes in 3.0.0 that were not part of earlier alpha and beta 
releases. That's why we only recently got aware of needed mod_ssl 
changes to again make it work with 3.0.0. As mentioned by others the 
2.4.49 release is important for other reasons and we do not want to 
break it due to last minute mod_ssl changes, which would only be useful 
for a minority of users. Most would not yet go with OpenSSL 3.0.0.


Joe (Orton) has provided a pull request for 2.4.x based on httpd trunk 
to again support OpenSSL 3.0.0 and that's why he is interested in your 
observed httpd trunk failures with 3.0.0.



You have me at a loss.


Hopefully our situation is now understandable again?


That Apache httpd, the biggest web server on planet Earth ( let me check
mars ) has never looked at OpenSSL 3.0.0 as an event in the mail? It has
been shipped. Delivered. Done. It works. What are you saying?


We - for instance me - look at it since quite some time. The breaks were 
introduced recently in OpenSSL land. That's why we need a few weeks to 
react.


Thanks for caring about httpd in Solaris land!

Regards,

Rainer

APR 1.7.1 release?

[Rainer Jung]

Hi there,

any chance we find an RM for a APR 1.7.1 release? At least there was the 
fix for CVE-2021-35940 and CHANGES contains 15 more items (many of them 
platform specific or build improvements). Last release 1.7.0 was in 
April 2019.


For APR-util I don't know the current state and release needs for the 
1.6.x and 1.7.x branches. Last 1.6.x release was in October 2017, 1.7.x 
has never been released. CHANGES for 1.6.x only contains one 
apr_dbm_gdbm fix plus a minor libtool use improvement.


Apache httpd is planing to start a release cycle soon and it would be 
nice to have a clean APR 1.7.1 and maybe APR-util also.


Thanks and regards,

Rainer

Re: Late(r) stop of children processes on restart

[Rainer Jung]

Thanks for the headroom explanation Yann, good reading!

Rainer

Am 25.08.2021 um 13:23 schrieb Yann Ylavic:

On Tue, Jun 29, 2021 at 3:00 PM Rainer Jung  wrote:


Am 29.06.2021 um 14:31 schrieb Stefan Eissing:

Can comment really on the diff, but totally agree on the goal to minimize the 
unresponsive time and make graceful less disruptive.

So +1 for that.


+1 on the intention as well.


Checked in trunk (r1892587 + r1892595).



Not sure, whether that means people would need more headroom in the
scoreboard (which would probably warrant a sentence in CHANGES or docs
about that) or whether it just means the duration during which that
headroom is used changes (which I wouldn't care about).


The restart delay between stop and start is now minimal (no reload in
between), but the headroom needed does not change AIUI.
We still have the situation where connections (worker threads) are
active for both the new and old generations of children processes, and
its duration depends mainly on the actual lifetime of the connections.
So the current tunings still hold I think.

What changes now is that for both graceful and ungraceful restarts the
main process fully consumes one CPU (to reload) while children are
actively running (the old generation keeps accepting/processing
connections during reload), whereas before the children were tearing
down thus easing the CPUs (but filling the sockets backlogs,
potentially until exhaustion..).
So there might be a greater load spike (overall) than before on reload.

A note on the headroom while at it:
mpm_event is possibly less consumer of children (hence scoreboard
slots) on restart, because when a child is dying it stops (and thus
doesn't account for) the worker threads above the remaining number of
connections, which will accurately create children of the new
generation to scale. mpm_worker never stops threads (this improvement
never made it there AFAICT), thus by accounting for inactive threads
as active it will finally create more children of the new generation
as connections arrive (eventually reaching the limits earlier, or
blocking/waiting for worker threads in the new generation of children
overflowed by incoming connections which the main process thinks are
evenly distributed across all the children, including old
generation's).
I don't know how hard/worthy it is to align mpm_worker with mpm_event
on this, just a note..


Cheers;
Yann.

Re: Late(r) stop of children processes on restart

[Rainer Jung]

Am 29.06.2021 um 14:31 schrieb Stefan Eissing:

Can comment really on the diff, but totally agree on the goal to minimize the 
unresponsive time and make graceful less disruptive.

So +1 for that.


+1 on the intention as well.

Not sure, whether that means people would need more headroom in the 
scoreboard (which would probably warrant a sentence in CHANGES or docs 
about that) or whether it just means the duration during which that 
headroom is used changes (which I wouldn't care about).


Thanks and regards,

Rainer


Am 28.06.2021 um 16:25 schrieb Yann Ylavic :

When the MPM event/worker is restarting, it first signals the
children's processes to stop (via POD), then reload the configuration,
and finally start the new generation.

This may be problematic when the reload takes some time to complete
because incoming connections are no longer processed.
A module at day $job is loading quite some regexes and JSON schemas
for each vhost, and I have seen restarts take tens of seconds to
complete with a large number of vhosts. I suppose this can happen with
many RewriteRules too.

How about we wait for the reload to complete before stopping the old
generation, like in the attached patch (MPM event only for now,
changes in worker would be quite similar)?

This is achieved by creating the PODs and listeners buckets from a
generation pool (gen_pool), with a different lifetime than pconf.
gen_pool survives restarts and is created/cleared after the old
generation is stopped, entirely in the run_mpm hook, so the stop and
PODs and buckets handling is moved there (most changes are cut/paste).

WDYT?

Regards;
Yann.

Question about APR trunk and httpd ldap modules

[Rainer Jung]

Hi there,

is my understanding correct, that even httpd trunk (and then also 2.4.x) 
needs LDAP support in APR/APU to build mod_ldap and mod_authnz_ldap?


So since we removed LDAP support from APR trunk, that means those 
modules currently can not be build using APR trunk, neither in httpd 
trunk nor in httpd 2.4.x. Correct?


Just trying to understand the current situation about APR trunk and its 
implications.


Thanks and regards,

Rainer

Test suite using OpenSSL 0.9.8 client against OpenSSL 3.0.0 server

[Rainer Jung]

FYI: the problems I observed when running the httpd test suite using an 
OpenSSL 0.9.8zh based client against a server build using OpenSSL 3.0.0 
originated in the fact, that OpenSSL 3.0.0 by default no longer allows 
RSA SHA1 and DSA SHA1 as signature algorithms. But 0.9.8 only support 
TLS 1.0 which in turn only supports these signature algorithms. So 
although 3.0.0 still supports TLS 1.0, with a default configuration such 
handshakes no longer work (which is a good thing, except for this testing).


The fix to make the test suite pass was to add "@SECLEVEL=0" to the end 
of the CipherSuite lines in t/conf/ssl/ssl.conf and t/conf/http2.conf 
(directly attached to the end of the existing config values).


Then the handshakes complete and the tests behave as expected, e.g. the 
http2 test no longer complains about the wrong number of tests and skips 
those needing SNI and ALPN etc.


Of course this addition doesn't make sense as a general change to the 
test suite.


One remaining minor nit: 3.0.0 has narrowed down the allowed DH 
parameters. I think that's the reason I sporadically get not strictly 
reproducible faults logged in the server as:


[Mon May 24 11:15:23.944579 2021] [ssl:trace3] [pid 3787] 
ssl_engine_kernel.c(2223): [client 127.0.0.1:36883] OpenSSL: Write: error
[Mon May 24 11:15:23.944586 2021] [ssl:trace3] [pid 3787] 
ssl_engine_kernel.c(2242): [client 127.0.0.1:36883] OpenSSL: Exit: error 
in error
[Mon May 24 11:15:23.944611 2021] [ssl:info] [pid 3787] [client 
127.0.0.1:36883] AH02008: SSL library error 1 in handshake (server 
localhost:8564)
[Mon May 24 11:15:23.944635 2021] [ssl:info] [pid 3787] SSL Library 
Error: error:02800066:Diffie-Hellman routines::invalid public key ()
[Mon May 24 11:15:23.944647 2021] [ssl:info] [pid 3787] SSL Library 
Error: error:0A0C0103:SSL routines::internal error ()
[Mon May 24 11:15:23.944655 2021] [ssl:info] [pid 3787] [client 
127.0.0.1:36883] AH01998: Connection closed to child 7 with abortive 
shutdown (server localhost:8564)


Especially tests in t/ssl/proxy.t fail every now and then, because that 
test file makes a lot of connections. Very rarely also t/ssl/fakeauth.t.


These sporadic failures seem not to occur with OpenSSL up to 1.1.1k-1 in 
the server and also not with OpenSSL 1.0.1 and later in the client.


Regards,

Rainer

Re: [VOTE] Release httpd-2.4.48

[Rainer Jung]

Am 17.05.2021 um 23:36 schrieb Christophe JAILLET:

Hi, all;
    Please find below the proposed release tarball and signatures:
https://dist.apache.org/repos/dist/dev/httpd/

I would like to call a VOTE over the next few days to release this 
candidate tarball as 2.4.48:

[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:
sha1: b581bcfdd939fe77c3821f7ad3863c7307374919 *httpd-2.4.48.tar.gz
sha256: 315c0bc50206b866fb17c2cdc28c1973765a8d59ca168b80286e8cb077d0510e 
*httpd-2.4.48.tar.gz
sha512: 
91980f757fc0dede8c6cbf54ed973f82a63098aa50d0fce15fe3537687b4ffbb48ed50cdb4ae14eb4a8703450f032daf73f4f3d5e2dd0f75721948e12a9c6dfb 
*httpd-2.4.48.tar.gz


The SVN tag is '2.4.48' at r1889975.


+1 to release and thanks a bunch for RM!

Summary: all OK except for

- one single crash on SLES 11 statically linked during SSL handshake.

- two crashes on Solaris with prefork MPM during shutdown. Only with 
released APR/APU not with svn heads. Tests ongoing. I think I have seen 
such before, so not a regression.


- minor nit: The following files in the tarballs contains french date 
lines probably due to exporting them from svn with your local locale:

  - ROADMAP
  - VERSIONING
  - maybe others?
  Maybe already fixed, I saw some conversation about in the future
  using a default locale in scripts.

Detailed report:

- Sigs and hashes OK
- contents of tarballs identical
- contents of tag and tarballs identical
  except for expected deltas

Built on

- Solaris 10 Sparc as 32 Bit Binaries
- SLES 11+12+15 (64 Bits)
- RHEL 6+7+8 (64 Bits)

For all platforms built

- with default (shared) and static modules
- with module set reallyall
- using --enable-load-all-modules
- against
  - bundled APR/APU from deps tarball
  - external APR/APU 1.7.0/1.6.1 (expat)
  - APR/APU 1.6.5/1.6.1 (expat)
  - APR/APU 1.7.x r1889104/1.7.x r1889948 (expat)
  - APR/APU 1.7.x r1889104/1.7.x r1889948 (libxml2)
  - APR/APU 1.6.x r1876940/1.6.x r1889948 (expat)

- using external libraries
  - expat 2.3.0
  - pcre 8.44
  - lua 5.4.3 (compiled with LUA_COMPAT_MODULE)
  - libxml2 2.9.12
  - libnghttp2 1.43.0
  - brotli 1.0.9
  - curl 7.76.1
  - jansson 2.13.1
  - libldap 2.4.58 (resp. 2.4.52 when using OpenSSL 0.9.8)
and
  - openssl 0.9.8zh, 1.0.2, 1.0.2u, 1.1.1, 1.1.1k, 3.0.0alpha16

- Tool chain:
- platform gcc except on Solaris
  (gcc 9.3.0 Solaris 10)
- CFLAGS: -O2 -g -Wall -fno-strict-aliasing
  - on Solaris additionally -mpcu=v9, -D_XOPEN_SOURCE,
-D_XOPEN_SOURCE_EXTENDED=1, -D__EXTENSIONS__
and -D_XPG6

All of the 884 builds succeeded.

- compiler warnings: see earlier separate mail


Tested for

- SLES 11+12 done
- SLES 15 and RHEL 6+7+8 mostly done
- Solaris 10 Sparc about 12% done
- MPMs prefork, worker, event
- default and static module builds
- log level trace8
- module set reallyall (129 modules plus 3 MPMs)
- Perl client bundle build against OpenSSL 1.1.1g plus patches, 1.1.0l, 
1.0.2u and 0.9.8zh

- OpenSSL once linked statically and once as a shared library

Every OpenSSL version in the client is tested with every OpenSSL version 
in the server.


The total number of test suite runs until now is ~8000 (more still to 
come, especially most of the Solaris ones and some of those with 
statically linked OpenSSL in combination with statically linked server 
on Linux).


Some local adjustments to tests were used:

- t/modules/buffer.t: removing huge buffer tests
  -my $bigsize = 10;
  +my $bigsize = 1;

- fixing limitrequestline overwrite which does not yet really work in 
Apache-Test/lib/Apache/TestConfig.pm

87d86
 'global LimitRequestLine setting (default is 128)',
96a96
> #   limitrequestline => 'global LimitRequestLine setting (default is 
128)',

372,373c372,373
< $vars->{limitrequestline} ||= 128;
< $vars->{limitrequestlinex2} = 2 * $vars->{limitrequestline};
---
> #$vars->{limitrequestline} ||= 128;
> #$vars->{limitrequestlinex2} = 2 * $vars->{limitrequestline};

- the temporary workaround for OpenSSL 3 when using "openssl crl -hash" 
with STDIN in Apache-Test/lib/Apache/TestSSLCA.pm is no longer 
necessary, problem fixed in OpenSSL 3.0.0alpha16



The following test failures were seen:

a A single crash in SLES 11 APU 1.6.1 APR 1.7.0 OpenSSL 1.0.2u
  build statically using event.
  Crash during ssl_io_filter_handshake calling ... CRYPTO_malloc and
  finally "glibc detected *** /path/to/bin/httpd: malloc():
  memory corruption: 0x00faafe1"
  gdb data see below.

b Two crashes on Solaris 10 Sparc,
  once APU 1.6.1 APR 1.6.5 OpenSSL 3.0.0alpha16
  and once APU 1.6.1 APR 1.7.0 OpenSSL 1.1.1k
  build dynamically both using prefork.
  Crash during shutdown when apr_pool_destroy() for the
  pchild pool calls allocator_free() (invalid node->next).
  Might be fixed in svn heads. I will check, whether the ongoing
  Solaris 

Re: Build warnings in 2.4.48

[Rainer Jung]

Am 20.05.2021 um 14:07 schrieb Noel Butler:

On 20/05/2021 21:19, Rainer Jung wrote:


Hi there,

I saw the following build warnings in 2.4.48:

modules/md/md_crypt.c:1382: warning: passing argument 1 of 
‘BIO_new_mem_buf’ discards qualifiers from pointer target type

[-Wdiscarded-qualifiers]

=> happens only when building against OpenSSL 1.0.2 (initial release, 
no letter suffix).

But in openssl 1.0.2, was that not EOL'd back in late 2019?


I think until now httpd 2.4.x still officially supports being build with 
OpenSSL starting at 0.9.8.


Best Regards,

Rainer

Build warnings in 2.4.48

[Rainer Jung]

Hi there,

I saw the following build warnings in 2.4.48:

modules/md/md_crypt.c:1382: warning: passing argument 1 of 
‘BIO_new_mem_buf’ discards qualifiers from pointer target type

[-Wdiscarded-qualifiers]

=> happens only when building against OpenSSL 1.0.2 (initial release, no 
letter suffix).



modules/ssl/ssl_engine_kernel.c:2318: warning: ‘set_challenge_creds’ 
defined but not used

On SLES 11 line number is 2321 instead of 2318

=> happens only when building against 0.9.8zh-1 (other 0.9.8 versions 
not tested)



modules/ssl/ssl_util_ssl.c:531: warning: passing argument 1 of 
‘BIO_new_mem_buf’ discards qualifiers from pointer target type

[-Wdiscarded-qualifiers]

The same again on line 544.

=> happens only when building against OpenSSL 1.0.2 (initial release, no 
letter suffix) and when building against 0.9.8zh-1 (other 0.9.8 versions 
not tested)



srclib/apr/locks/unix/proc_mutex.c:979:49: warning: 
'mutex_proc_pthread_cond_methods' defined but not used 
[-Wunused-const-variable=]


=> only on Solaris 10 Sparc (GCC 9.3.0) plus APR 1.7.x
the declaration checks for APR_USE_PROC_PTHREAD_MUTEX_COND, which is 
defined on Solaris, the use in line 1437 also checks 
HAVE_PTHREAD_MUTEX_ROBUST, which is not defined on Solaris.



Best regards,

Rainer

Re: [VOTE] Release httpd-2.4.47

[Rainer Jung]

Am 22.04.2021 um 11:25 schrieb Christophe JAILLET:

Hi, all;
   Please find below the proposed release tarball and signatures:
https://dist.apache.org/repos/dist/dev/httpd/

I would like to call a VOTE over the next few days to release this 
candidate tarball as 2.4.47:

[ ] +1: It's not just good, it's good enough!
[ ] +0: Let's have a talk.
[ ] -1: There's trouble in paradise. Here's what's wrong.

The computed digests of the tarball up for vote are:
sha1: f4281be0bf08489a51d818b596a92bfcfbb2c708 *httpd-2.4.47.tar.gz
sha256: 567d5ac72ea643e3828e8e54f32e06f1fad10095d33ae4071eeaec3c78b70a34 
*httpd-2.4.47.tar.gz
sha512: 
de4c80e1ddebe3286c234179fd01d4917f479f75a7fe958032c19a8f22546e95f31e3b50073844d09f20f54894e7d511bcd9fd2f1cd2b2c71b3a182d6e62bab3 
*httpd-2.4.47.tar.gz


The SVN tag is '2.4.47' at r1889091.

--
Christophe JAILLET



+1 to release and thanks a bunch for stepping in as RM!

I think I wasn't able to import your key from a pgp key server, but 
maybe I wasn't using the right ones. Your key is in the KEYS file, 
probably just not in the network of key servers.


Summary: all OK except for

- one single crash on SLES 11 using prefork.

Detailed report:

- Sigs and hashes OK
- contents of tarballs identical
- contents of tag and tarballs identical
  except for expected deltas

Built on

- Solaris 10 Sparc as 32 Bit Binaries
- SLES 11+12+15 (64 Bits)
- RHEL 6+7+8 (64 Bits)

For all platforms built

- with default (shared) and static modules
- with module set reallyall
- using --enable-load-all-modules
- against
  - bundled APR/APU from deps tarball
  - external APR/APU 1.7.0/1.6.1 (expat)
  - APR/APU 1.6.5/1.6.1 (expat)
  - APR/APU 1.7.x r1889104/1.7.x r1884108 (expat)
  - APR/APU 1.7.x r1889104/1.7.x r1884108 (libxml2)
  - APR/APU 1.6.x r1876940/1.6.x r1876943 (expat)
  - APR/APU 1.6.x r1876940/1.6.x r1876943 (libxml2)

- using external libraries
  - expat 2.3.0
  - pcre 8.44
  - lua 5.4.3 (compiled with LUA_COMPAT_MODULE)
  - libxml2 2.9.10
  - libnghttp2 1.43.0
  - brotli 1.0.9
  - curl 7.76.1
  - jansson 2.13.1
  - libldap 2.4.58
and
  - openssl 0.9.8zh, 1.0.2, 1.0.2u, 1.1.1, 1.1.1k, 3.0.0alpha15

- Tool chain:
- platform gcc except on Solaris
  (gcc 9.3.0 Solaris 10)
- CFLAGS: -O2 -g -Wall -fno-strict-aliasing
  - on Solaris additionally -mpcu=v9, -D_XOPEN_SOURCE,
-D_XOPEN_SOURCE_EXTENDED=1, -D__EXTENSIONS__
and -D_XPG6

All of the 852 builds done until now succeeded, 32 builds on Solaris yet 
to come.


- compiler warnings:

  - only on Solaris 10 Sparc (GCC 9.3.0): APR 1.7.x
srclib/apr/locks/unix/proc_mutex.c:979:49: warning: 
'mutex_proc_pthread_cond_methods' defined but not used 
[-Wunused-const-variable=]
=> the declaration checks for APR_USE_PROC_PTHREAD_MUTEX_COND, 
which is defined on Solaris, the use in line 1437 also checks 
HAVE_PTHREAD_MUTEX_ROBUST, which is not defined on Solaris.


  - deprecation warnings when building against OpenSSL 3.0.0, see other 
mail



Tested for

- SLES 11+12+15, RHEL 6+7+8
  - Tests for Solaris 10 Sparc still to come, when builds finish there
- MPMs prefork, worker, event
- default and static module builds
- log level trace8
- module set reallyall (129 modules plus 3 MPMs)
- Perl client bundle build against OpenSSL 1.1.1g plus patches, 1.1.0l, 
1.0.2u and 0.9.8zh

- OpenSSL once linked statically and once as a shared library

Every OpenSSL version in the client is tested with every OpenSSL version 
in the server.


The total number of test suite runs until now is ~3800 (many more still 
to come, especially those with statically linked OpenSSL and most of the 
Solaris ones).


Some local adjustments to tests were used:

- t/modules/buffer.t: removing huge buffer tests
  -my $bigsize = 10;
  +my $bigsize = 1;

- fixing limitrequestline overwrite which does not yet really work in 
Apache-Test/lib/Apache/TestConfig.pm

87d86
 'global LimitRequestLine setting (default is 128)',
96a96
> #   limitrequestline => 'global LimitRequestLine setting (default is 
128)',

372,373c372,373
< $vars->{limitrequestline} ||= 128;
< $vars->{limitrequestlinex2} = 2 * $vars->{limitrequestline};
---
> #$vars->{limitrequestline} ||= 128;
> #$vars->{limitrequestlinex2} = 2 * $vars->{limitrequestline};

- temporary workaround for a OpenSSL 3 when using "openssl crl -hash" 
with STDIN in Apache-Test/lib/Apache/TestSSLCA.pm

39a40
> my $openssl_workaround = $ENV{APACHE_TEST_OPENSSL_CMD_WORKAROUND} || 
$openssl;

426c427
< chomp(my $hash = `$openssl $type -noout -hash < $file`);
---
> chomp(my $hash = `$openssl_workaround $type -noout -hash < 
$file`);


This enables to use OpenSSL 3 everywhere in test suite configuration and 
setup and override it only in the CRL hash command line, for which it is 
currently buggy.


The following test failures were seen:

a All https tests fail between OpenSSL 0.9.8zh and 3.0.0alpha15
  Not a regression.
  Probably need to figure out how 

Re: httpd 2.4.x TLS proxy and OpenSSL 3.0.0alpha15: CRL problem

[Rainer Jung]

OK, it is a bug or behavior change in the "openssl crl" command line for 
3.0.0 that leads to the CRL symlinks not being created any more.


I raised

https://github.com/openssl/openssl/issues/15031

Regards,

Rainer

Am 26.04.2021 um 15:34 schrieb Rainer Jung:
I am still investigating further, bit this is due to the fact, that the 
CRL symlink in the crl directory is missing. Might be a local 
integration issue. Will look further.


Am 26.04.2021 um 13:27 schrieb Rainer Jung:
When building 2.4.47 using OpenSSL 3.0.0alpha15 and running the test 
suite, the proxy TLS connection fails with "Certificate Verification: 
Error (3): unable to get certificate CRL":


[Mon Apr 26 10:00:50.352111 2021] [ssl:trace3] [pid 16699:tid 
140438686086912] ssl_engine_kernel.c(2213): [remote 127.0.0.1:8532] 
OpenSSL: Loop: TLSv1.3 read encrypted extensions
[Mon Apr 26 10:00:50.352449 2021] [ssl:debug] [pid 16699:tid 
140438686086912] ssl_engine_kernel.c(1762): [remote 127.0.0.1:8532] 
AH02275: Certificate Verification, depth 0, CRL checking mode: chain 
(2) [subject: 
emailAddress=test-...@httpd.apache.org,CN=localhost,OU=httpd-test/rsa-test,O=ASF,L=San 
Francisco,ST=California,C=US / issuer: 
emailAddress=test-...@httpd.apache.org,CN=ca,OU=httpd-test,O=ASF,L=San 
Francisco,ST=California,C=US / serial: 09 / notbefore: Apr 26 07:56:58 
2021 GMT / notafter: Apr 26 07:56:58 2022 GMT]
[Mon Apr 26 10:00:50.352487 2021] [ssl:info] [pid 16699:tid 
140438686086912] [remote 127.0.0.1:8532] AH02276: Certificate 
Verification: Error (3): unable to get certificate CRL [subject: 
emailAddress=test-...@httpd.apache.org,CN=localhost,OU=httpd-test/rsa-test,O=ASF,L=San 
Francisco,ST=California,C=US / issuer: 
emailAddress=test-...@httpd.apache.org,CN=ca,OU=httpd-test,O=ASF,L=San 
Francisco,ST=California,C=US / serial: 09 / notbefore: Apr 26 07:56:58 
2021 GMT / notafter: Apr 26 07:56:58 2022 GMT]
[Mon Apr 26 10:00:50.352563 2021] [ssl:trace3] [pid 16699:tid 
140438686086912] ssl_engine_kernel.c(2223): [remote 127.0.0.1:8532] 
OpenSSL: Write: error
[Mon Apr 26 10:00:50.352567 2021] [ssl:trace3] [pid 16699:tid 
140438686086912] ssl_engine_kernel.c(2242): [remote 127.0.0.1:8532] 
OpenSSL: Exit: error in error
[Mon Apr 26 10:00:50.352570 2021] [ssl:info] [pid 16699:tid 
140438686086912] [remote 127.0.0.1:8532] AH02003: SSL Proxy connect 
failed
[Mon Apr 26 10:00:50.352597 2021] [ssl:info] [pid 16699:tid 
140438686086912] SSL Library Error: error:0A86:SSL 
routines::certificate verify failed



More complete log output:

[Mon Apr 26 10:00:50.344676 2021] [proxy:trace2] [pid 16699:tid 
140438686086912] proxy_util.c(3153): https: fam 2 socket created to 
connect to localhost
[Mon Apr 26 10:00:50.344710 2021] [proxy:debug] [pid 16699:tid 
140438686086912] proxy_util.c(3187): AH02824: https: connection 
established with 127.0.0.1:8532 (localhost)
[Mon Apr 26 10:00:50.344719 2021] [example_hooks:notice] [pid 
16699:tid 140438686086912] x_create_connection()
[Mon Apr 26 10:00:50.344726 2021] [proxy:trace1] [pid 16699:tid 
140438686086912] proxy_util.c(3359): [remote 127.0.0.1:8532] https: 
set SNI to localhost for (localhost)
[Mon Apr 26 10:00:50.344729 2021] [proxy:debug] [pid 16699:tid 
140438686086912] proxy_util.c(3371): AH00962: https: connection 
complete to [::1]:8532 (localhost)
[Mon Apr 26 10:00:50.344738 2021] [ssl:info] [pid 16699:tid 
140438686086912] [remote 127.0.0.1:8532] AH01964: Connection to child 
0 established (server localhost:8561)
[Mon Apr 26 10:00:50.344822 2021] [ssl:trace2] [pid 16699:tid 
140438686086912] ssl_engine_rand.c(126): Proxy: Seeding PRNG with 144 
bytes of entropy
[Mon Apr 26 10:00:50.344875 2021] [ssl:trace3] [pid 16699:tid 
140438686086912] ssl_engine_io.c(1242): [remote 127.0.0.1:8532] SNI 
extension for SSL Proxy request set to 'localhost'
[Mon Apr 26 10:00:50.344882 2021] [ssl:trace3] [pid 16699:tid 
140438686086912] ssl_engine_kernel.c(2204): [remote 127.0.0.1:8532] 
OpenSSL: Handshake: start
[Mon Apr 26 10:00:50.344921 2021] [ssl:trace3] [pid 16699:tid 
140438686086912] ssl_engine_kernel.c(2213): [remote 127.0.0.1:8532] 
OpenSSL: Loop: before SSL initialization
[Mon Apr 26 10:00:50.345273 2021] [example_hooks:notice] [pid 
16699:tid 140438669301504] x_create_connection()
[Mon Apr 26 10:00:50.345308 2021] [ssl:info] [pid 16699:tid 
140438669301504] [client 127.0.0.1:50940] AH01964: Connection to child 
210 established (server localhost:8532)
[Mon Apr 26 10:00:50.345356 2021] [ssl:trace3] [pid 16699:tid 
140438686086912] ssl_engine_kernel.c(2213): [remote 127.0.0.1:8532] 
OpenSSL: Loop: SSLv3/TLS write client hello
[Mon Apr 26 10:00:50.345400 2021] [ssl:trace2] [pid 16699:tid 
140438669301504] ssl_engine_rand.c(126): Server: Seeding PRNG with 144 
bytes of entropy
[Mon Apr 26 10:00:50.345459 2021] [ssl:trace3] [pid 16699:tid 
140438669301504] ssl_engine_kernel.c(2204): [client 127.0.0.1:50940] 
OpenSSL: Handshake: start
[Mon Apr 26 10:00:50.345479 2021] [ssl:trace3] [pid 16699:

Re: httpd 2.4.x TLS proxy and OpenSSL 3.0.0alpha15: CRL problem

[Rainer Jung]

I am still investigating further, bit this is due to the fact, that the 
CRL symlink in the crl directory is missing. Might be a local 
integration issue. Will look further.


Am 26.04.2021 um 13:27 schrieb Rainer Jung:
When building 2.4.47 using OpenSSL 3.0.0alpha15 and running the test 
suite, the proxy TLS connection fails with "Certificate Verification: 
Error (3): unable to get certificate CRL":


[Mon Apr 26 10:00:50.352111 2021] [ssl:trace3] [pid 16699:tid 
140438686086912] ssl_engine_kernel.c(2213): [remote 127.0.0.1:8532] 
OpenSSL: Loop: TLSv1.3 read encrypted extensions
[Mon Apr 26 10:00:50.352449 2021] [ssl:debug] [pid 16699:tid 
140438686086912] ssl_engine_kernel.c(1762): [remote 127.0.0.1:8532] 
AH02275: Certificate Verification, depth 0, CRL checking mode: chain (2) 
[subject: 
emailAddress=test-...@httpd.apache.org,CN=localhost,OU=httpd-test/rsa-test,O=ASF,L=San 
Francisco,ST=California,C=US / issuer: 
emailAddress=test-...@httpd.apache.org,CN=ca,OU=httpd-test,O=ASF,L=San 
Francisco,ST=California,C=US / serial: 09 / notbefore: Apr 26 07:56:58 
2021 GMT / notafter: Apr 26 07:56:58 2022 GMT]
[Mon Apr 26 10:00:50.352487 2021] [ssl:info] [pid 16699:tid 
140438686086912] [remote 127.0.0.1:8532] AH02276: Certificate 
Verification: Error (3): unable to get certificate CRL [subject: 
emailAddress=test-...@httpd.apache.org,CN=localhost,OU=httpd-test/rsa-test,O=ASF,L=San 
Francisco,ST=California,C=US / issuer: 
emailAddress=test-...@httpd.apache.org,CN=ca,OU=httpd-test,O=ASF,L=San 
Francisco,ST=California,C=US / serial: 09 / notbefore: Apr 26 07:56:58 
2021 GMT / notafter: Apr 26 07:56:58 2022 GMT]
[Mon Apr 26 10:00:50.352563 2021] [ssl:trace3] [pid 16699:tid 
140438686086912] ssl_engine_kernel.c(2223): [remote 127.0.0.1:8532] 
OpenSSL: Write: error
[Mon Apr 26 10:00:50.352567 2021] [ssl:trace3] [pid 16699:tid 
140438686086912] ssl_engine_kernel.c(2242): [remote 127.0.0.1:8532] 
OpenSSL: Exit: error in error
[Mon Apr 26 10:00:50.352570 2021] [ssl:info] [pid 16699:tid 
140438686086912] [remote 127.0.0.1:8532] AH02003: SSL Proxy connect failed
[Mon Apr 26 10:00:50.352597 2021] [ssl:info] [pid 16699:tid 
140438686086912] SSL Library Error: error:0A86:SSL 
routines::certificate verify failed



More complete log output:

[Mon Apr 26 10:00:50.344676 2021] [proxy:trace2] [pid 16699:tid 
140438686086912] proxy_util.c(3153): https: fam 2 socket created to 
connect to localhost
[Mon Apr 26 10:00:50.344710 2021] [proxy:debug] [pid 16699:tid 
140438686086912] proxy_util.c(3187): AH02824: https: connection 
established with 127.0.0.1:8532 (localhost)
[Mon Apr 26 10:00:50.344719 2021] [example_hooks:notice] [pid 16699:tid 
140438686086912] x_create_connection()
[Mon Apr 26 10:00:50.344726 2021] [proxy:trace1] [pid 16699:tid 
140438686086912] proxy_util.c(3359): [remote 127.0.0.1:8532] https: set 
SNI to localhost for (localhost)
[Mon Apr 26 10:00:50.344729 2021] [proxy:debug] [pid 16699:tid 
140438686086912] proxy_util.c(3371): AH00962: https: connection complete 
to [::1]:8532 (localhost)
[Mon Apr 26 10:00:50.344738 2021] [ssl:info] [pid 16699:tid 
140438686086912] [remote 127.0.0.1:8532] AH01964: Connection to child 0 
established (server localhost:8561)
[Mon Apr 26 10:00:50.344822 2021] [ssl:trace2] [pid 16699:tid 
140438686086912] ssl_engine_rand.c(126): Proxy: Seeding PRNG with 144 
bytes of entropy
[Mon Apr 26 10:00:50.344875 2021] [ssl:trace3] [pid 16699:tid 
140438686086912] ssl_engine_io.c(1242): [remote 127.0.0.1:8532] SNI 
extension for SSL Proxy request set to 'localhost'
[Mon Apr 26 10:00:50.344882 2021] [ssl:trace3] [pid 16699:tid 
140438686086912] ssl_engine_kernel.c(2204): [remote 127.0.0.1:8532] 
OpenSSL: Handshake: start
[Mon Apr 26 10:00:50.344921 2021] [ssl:trace3] [pid 16699:tid 
140438686086912] ssl_engine_kernel.c(2213): [remote 127.0.0.1:8532] 
OpenSSL: Loop: before SSL initialization
[Mon Apr 26 10:00:50.345273 2021] [example_hooks:notice] [pid 16699:tid 
140438669301504] x_create_connection()
[Mon Apr 26 10:00:50.345308 2021] [ssl:info] [pid 16699:tid 
140438669301504] [client 127.0.0.1:50940] AH01964: Connection to child 
210 established (server localhost:8532)
[Mon Apr 26 10:00:50.345356 2021] [ssl:trace3] [pid 16699:tid 
140438686086912] ssl_engine_kernel.c(2213): [remote 127.0.0.1:8532] 
OpenSSL: Loop: SSLv3/TLS write client hello
[Mon Apr 26 10:00:50.345400 2021] [ssl:trace2] [pid 16699:tid 
140438669301504] ssl_engine_rand.c(126): Server: Seeding PRNG with 144 
bytes of entropy
[Mon Apr 26 10:00:50.345459 2021] [ssl:trace3] [pid 16699:tid 
140438669301504] ssl_engine_kernel.c(2204): [client 127.0.0.1:50940] 
OpenSSL: Handshake: start
[Mon Apr 26 10:00:50.345479 2021] [ssl:trace3] [pid 16699:tid 
140438669301504] ssl_engine_kernel.c(2213): [client 127.0.0.1:50940] 
OpenSSL: Loop: before SSL initialization
[Mon Apr 26 10:00:50.345680 2021] [ssl:trace3] [pid 16699:tid 
140438669301504] ssl_engine_kernel.c(2213): [client 127.0.0.1:50940] 
OpenSSL: Loop: before SSL init

httpd 2.4.x TLS proxy and OpenSSL 3.0.0alpha15: CRL problem

[Rainer Jung]

When building 2.4.47 using OpenSSL 3.0.0alpha15 and running the test 
suite, the proxy TLS connection fails with "Certificate Verification: 
Error (3): unable to get certificate CRL":


[Mon Apr 26 10:00:50.352111 2021] [ssl:trace3] [pid 16699:tid 
140438686086912] ssl_engine_kernel.c(2213): [remote 127.0.0.1:8532] 
OpenSSL: Loop: TLSv1.3 read encrypted extensions
[Mon Apr 26 10:00:50.352449 2021] [ssl:debug] [pid 16699:tid 
140438686086912] ssl_engine_kernel.c(1762): [remote 127.0.0.1:8532] 
AH02275: Certificate Verification, depth 0, CRL checking mode: chain (2) 
[subject: 
emailAddress=test-...@httpd.apache.org,CN=localhost,OU=httpd-test/rsa-test,O=ASF,L=San 
Francisco,ST=California,C=US / issuer: 
emailAddress=test-...@httpd.apache.org,CN=ca,OU=httpd-test,O=ASF,L=San 
Francisco,ST=California,C=US / serial: 09 / notbefore: Apr 26 07:56:58 
2021 GMT / notafter: Apr 26 07:56:58 2022 GMT]
[Mon Apr 26 10:00:50.352487 2021] [ssl:info] [pid 16699:tid 
140438686086912] [remote 127.0.0.1:8532] AH02276: Certificate 
Verification: Error (3): unable to get certificate CRL [subject: 
emailAddress=test-...@httpd.apache.org,CN=localhost,OU=httpd-test/rsa-test,O=ASF,L=San 
Francisco,ST=California,C=US / issuer: 
emailAddress=test-...@httpd.apache.org,CN=ca,OU=httpd-test,O=ASF,L=San 
Francisco,ST=California,C=US / serial: 09 / notbefore: Apr 26 07:56:58 
2021 GMT / notafter: Apr 26 07:56:58 2022 GMT]
[Mon Apr 26 10:00:50.352563 2021] [ssl:trace3] [pid 16699:tid 
140438686086912] ssl_engine_kernel.c(2223): [remote 127.0.0.1:8532] 
OpenSSL: Write: error
[Mon Apr 26 10:00:50.352567 2021] [ssl:trace3] [pid 16699:tid 
140438686086912] ssl_engine_kernel.c(2242): [remote 127.0.0.1:8532] 
OpenSSL: Exit: error in error
[Mon Apr 26 10:00:50.352570 2021] [ssl:info] [pid 16699:tid 
140438686086912] [remote 127.0.0.1:8532] AH02003: SSL Proxy connect failed
[Mon Apr 26 10:00:50.352597 2021] [ssl:info] [pid 16699:tid 
140438686086912] SSL Library Error: error:0A86:SSL 
routines::certificate verify failed



More complete log output:

[Mon Apr 26 10:00:50.344676 2021] [proxy:trace2] [pid 16699:tid 
140438686086912] proxy_util.c(3153): https: fam 2 socket created to 
connect to localhost
[Mon Apr 26 10:00:50.344710 2021] [proxy:debug] [pid 16699:tid 
140438686086912] proxy_util.c(3187): AH02824: https: connection 
established with 127.0.0.1:8532 (localhost)
[Mon Apr 26 10:00:50.344719 2021] [example_hooks:notice] [pid 16699:tid 
140438686086912] x_create_connection()
[Mon Apr 26 10:00:50.344726 2021] [proxy:trace1] [pid 16699:tid 
140438686086912] proxy_util.c(3359): [remote 127.0.0.1:8532] https: set 
SNI to localhost for (localhost)
[Mon Apr 26 10:00:50.344729 2021] [proxy:debug] [pid 16699:tid 
140438686086912] proxy_util.c(3371): AH00962: https: connection complete 
to [::1]:8532 (localhost)
[Mon Apr 26 10:00:50.344738 2021] [ssl:info] [pid 16699:tid 
140438686086912] [remote 127.0.0.1:8532] AH01964: Connection to child 0 
established (server localhost:8561)
[Mon Apr 26 10:00:50.344822 2021] [ssl:trace2] [pid 16699:tid 
140438686086912] ssl_engine_rand.c(126): Proxy: Seeding PRNG with 144 
bytes of entropy
[Mon Apr 26 10:00:50.344875 2021] [ssl:trace3] [pid 16699:tid 
140438686086912] ssl_engine_io.c(1242): [remote 127.0.0.1:8532] SNI 
extension for SSL Proxy request set to 'localhost'
[Mon Apr 26 10:00:50.344882 2021] [ssl:trace3] [pid 16699:tid 
140438686086912] ssl_engine_kernel.c(2204): [remote 127.0.0.1:8532] 
OpenSSL: Handshake: start
[Mon Apr 26 10:00:50.344921 2021] [ssl:trace3] [pid 16699:tid 
140438686086912] ssl_engine_kernel.c(2213): [remote 127.0.0.1:8532] 
OpenSSL: Loop: before SSL initialization
[Mon Apr 26 10:00:50.345273 2021] [example_hooks:notice] [pid 16699:tid 
140438669301504] x_create_connection()
[Mon Apr 26 10:00:50.345308 2021] [ssl:info] [pid 16699:tid 
140438669301504] [client 127.0.0.1:50940] AH01964: Connection to child 
210 established (server localhost:8532)
[Mon Apr 26 10:00:50.345356 2021] [ssl:trace3] [pid 16699:tid 
140438686086912] ssl_engine_kernel.c(2213): [remote 127.0.0.1:8532] 
OpenSSL: Loop: SSLv3/TLS write client hello
[Mon Apr 26 10:00:50.345400 2021] [ssl:trace2] [pid 16699:tid 
140438669301504] ssl_engine_rand.c(126): Server: Seeding PRNG with 144 
bytes of entropy
[Mon Apr 26 10:00:50.345459 2021] [ssl:trace3] [pid 16699:tid 
140438669301504] ssl_engine_kernel.c(2204): [client 127.0.0.1:50940] 
OpenSSL: Handshake: start
[Mon Apr 26 10:00:50.345479 2021] [ssl:trace3] [pid 16699:tid 
140438669301504] ssl_engine_kernel.c(2213): [client 127.0.0.1:50940] 
OpenSSL: Loop: before SSL initialization
[Mon Apr 26 10:00:50.345680 2021] [ssl:trace3] [pid 16699:tid 
140438669301504] ssl_engine_kernel.c(2213): [client 127.0.0.1:50940] 
OpenSSL: Loop: before SSL initialization
[Mon Apr 26 10:00:50.345702 2021] [ssl:debug] [pid 16699:tid 
140438669301504] ssl_engine_kernel.c(2374): [client 127.0.0.1:50940] 
AH02043: SSL virtual host for servername localhost found
[Mon Apr 26 10:00:50.345833 2021] 

OpenSSL 3.0.0 deprecations

[Rainer Jung]

FYI: here's a list of symbols for which I get deprecation warnings when 
compiling httpd 2.4.47 (plus bundled APU) against current OpenSSL 
3.0.0alpha15:


srclib/apr-util/crypto/apr_crypto_openssl.c:141:5 
ENGINE_load_builtin_engines
srclib/apr-util/crypto/apr_crypto_openssl.c:142:5 
ENGINE_register_all_complete

srclib/apr-util/crypto/apr_crypto_openssl.c:208:9 ENGINE_finish
srclib/apr-util/crypto/apr_crypto_openssl.c:209:9 ENGINE_free
srclib/apr-util/crypto/apr_crypto_openssl.c:326:9 ENGINE_by_id
srclib/apr-util/crypto/apr_crypto_openssl.c:330:9 ENGINE_init
srclib/apr-util/crypto/apr_crypto_openssl.c:331:13 ENGINE_free

modules/ssl/ssl_engine_config.c:610:5 ENGINE_by_id
modules/ssl/ssl_engine_config.c:612:9 ENGINE_free
modules/ssl/ssl_engine_config.c:617:9 ENGINE_get_first
modules/ssl/ssl_engine_config.c:619:13 ENGINE_get_id
modules/ssl/ssl_engine_config.c:620:42 ENGINE_get_name
modules/ssl/ssl_engine_config.c:623:13 ENGINE_get_next
modules/ssl/ssl_engine_init.c:102:5 DH_new
modules/ssl/ssl_engine_init.c:113:5 DH_set0_pqg
modules/ssl/ssl_engine_init.c:114:9 DH_free
modules/ssl/ssl_engine_init.c:1434:9 DH_bits
modules/ssl/ssl_engine_init.c:1437:9 DH_free
modules/ssl/ssl_engine_init.c:1447:9 EC_KEY_new_by_curve_name
modules/ssl/ssl_engine_init.c:1469:5 EC_KEY_free
modules/ssl/ssl_engine_init.c:152:9 DH_free
modules/ssl/ssl_engine_init.c:1722:9 SRP_VBASE_free
modules/ssl/ssl_engine_init.c:457:9 ENGINE_by_id
modules/ssl/ssl_engine_init.c:467:13 ENGINE_ctrl
modules/ssl/ssl_engine_init.c:471:9 ENGINE_set_default
modules/ssl/ssl_engine_init.c:482:9 ENGINE_free
modules/ssl/ssl_engine_init.c:548:9 SRP_VBASE_new
modules/ssl/ssl_engine_init.c:557:9 SRP_VBASE_init
modules/ssl/ssl_engine_init.c:565:9 SSL_CTX_set_srp_username_callback
modules/ssl/ssl_engine_init.c:567:9 SSL_CTX_set_srp_cb_arg
modules/ssl/ssl_engine_init.c:832:5 SSL_CTX_set_tmp_dh_callback
modules/ssl/ssl_engine_kernel.c:2632:9 HMAC_Init_ex
modules/ssl/ssl_engine_kernel.c:2653:9 HMAC_Init_ex
modules/ssl/ssl_engine_kernel.c:2781:5 SSL_get_srp_username
modules/ssl/ssl_engine_kernel.c:2788:9 SRP_VBASE_get1_by_user
modules/ssl/ssl_engine_kernel.c:2794:5 SSL_set_srp_server_param
modules/ssl/ssl_engine_kernel.c:2796:9 SRP_user_pwd_free
modules/ssl/ssl_engine_kernel.c:2804:5 SRP_user_pwd_free
modules/ssl/ssl_engine_kernel.c:545:5 SSL_get_srp_username
modules/ssl/ssl_engine_log.c:90:5 ERR_peek_error_line_data
modules/ssl/ssl_engine_pphrase.c:856:5 ENGINE_by_id
modules/ssl/ssl_engine_pphrase.c:864:5 ENGINE_init
modules/ssl/ssl_engine_pphrase.c:877:9 ENGINE_ctrl_cmd_string
modules/ssl/ssl_engine_pphrase.c:886:9 ENGINE_ctrl_cmd
modules/ssl/ssl_engine_pphrase.c:896:5 ENGINE_load_private_key
modules/ssl/ssl_engine_pphrase.c:904:5 ENGINE_finish
modules/ssl/ssl_engine_pphrase.c:905:5 ENGINE_free
modules/ssl/ssl_engine_vars.c:432:9 SSL_get_srp_username
modules/ssl/ssl_engine_vars.c:437:9 SSL_get_srp_userinfo
modules/ssl/ssl_util_ssl.c:474:5 PEM_read_bio_DHparams
modules/ssl/ssl_util_ssl.c:487:5 PEM_read_bio_ECPKParameters

support/ab.c:756:25 EVP_PKEY_get1_EC_KEY
support/ab.c:757:25 EC_KEY_get0_group
support/ab.c:758:25 EC_KEY_free

modules/http2/h2_push.c:477:5 SHA256_Update
modules/http2/h2_push.c:487:5 SHA256_Init
modules/http2/h2_push.c:492:5 SHA256_Final

modules/md/md_crypt.c:530:5 EVP_PKEY_get1_RSA
modules/md/md_crypt.c:535:5 RSA_get0_key
modules/md/md_crypt.c:542:5 EVP_PKEY_get1_RSA
modules/md/md_crypt.c:547:5 RSA_get0_key

Re: mod_http2: .gitignore contains Makefile.in

[Rainer Jung]

I just now saw, that the file only exists in the 2.4.x branch, not in 
trunk. Should we remove the .gitignore in 2.4.x? Or add in trunk? What 
would be better for your updates between your Github variant and the 
bundled one?


Regards,

Rainer

Am 10.08.2020 um 16:43 schrieb Stefan Eissing:




Am 10.08.2020 um 16:38 schrieb Rainer Jung :

Hi there,

the .gitignore file in modules/http2 contains "Makefile.in". That's probably OK 
for the upstream Github variant, which contains a Makefile.am, but in our svn repos for 
httpd the Makefile.in is needed as the source of the Makefile generation.

Of course our svn doesn't care about the .gitignore, but eg. I now locally keep 
the sources in git and thus lost the Makefile.in. I can live with local 
modifications, but I think it would be more correct to drop Makefile.in from 
the modules/http2/.gitignore in our svn repos.

WDYT?


Sounds like a plan.



Regards,

Rainer

mod_http2: .gitignore contains Makefile.in

[Rainer Jung]

Hi there,

the .gitignore file in modules/http2 contains "Makefile.in". That's 
probably OK for the upstream Github variant, which contains a 
Makefile.am, but in our svn repos for httpd the Makefile.in is needed as 
the source of the Makefile generation.


Of course our svn doesn't care about the .gitignore, but eg. I now 
locally keep the sources in git and thus lost the Makefile.in. I can 
live with local modifications, but I think it would be more correct to 
drop Makefile.in from the modules/http2/.gitignore in our svn repos.


WDYT?

Regards,

Rainer

Re: svn commit: r40863 - /dev/httpd/ /release/httpd/

[Rainer Jung]

Thanks for the explanation and sorry about the wrong alarm!

Best regards,

Rainer

Am 06.08.2020 um 00:31 schrieb Daniel Ruggeri:

Hi, Rainer;
Right - this file gets rewritten by the announce.sh script just before 
the notification goes out. This is done to ensure that the date is 
correct and to ensure the type of release (bug, security, enhancement) 
is correct. It appears as though the file was just changed, but really 
it's just because the text was bumped as-is from the 'dev' location to 
the 'dist' location.

--
Daniel Ruggeri

On August 5, 2020 7:23:33 AM CDT, Rainer Jung  
wrote:


Could you fix the date (September 21, 2018 sems wrong).

Thanks!

Rainer

Am 05.08.2020 um 13:32 schrieb drugg...@apache.org:

Author: druggeri
Date: Wed Aug 5 11:32:51 2020
New Revision: 40863

Log:
Push 2.4.46 up to the release directory

Added:
release/httpd/CHANGES_2.4.46
- copied unchanged from r40862, dev/httpd/CHANGES_2.4.46
release/httpd/httpd-2.4.46.tar.bz2
- copied unchanged from r40862, dev/httpd/httpd-2.4.46.tar.bz2
release/httpd/httpd-2.4.46.tar.bz2.asc
- copied unchanged from r40862, dev/httpd/httpd-2.4.46.tar.bz2.asc
release/httpd/httpd-2.4.46.tar.bz2.md5
- copied unchanged from r40862, dev/httpd/httpd-2.4.46.tar.bz2.md5
release/httpd/httpd-2.4.46.tar.bz2.sha1
- copied unchanged from r40862, dev/httpd/httpd-2.4.46.tar.bz2.sha1
release/httpd/httpd-2.4.46.tar.bz2.sha256
- copied unchanged from r40862,
dev/httpd/httpd-2.4.46.tar.bz2.sha256
release/httpd/httpd-2.4.46.tar.bz2.sha512
- copied unchanged from r40862,
dev/httpd/httpd-2.4.46.tar.bz2.sha512
release/httpd/httpd-2.4.46.tar.gz
- copied unchanged from r40862, dev/httpd/httpd-2.4.46.tar.gz
release/httpd/httpd-2.4.46.tar.gz.asc
- copied unchanged from r40862, dev/httpd/httpd-2.4.46.tar.gz.asc
release/httpd/httpd-2.4.46.tar.gz.md5
- copied unchanged from r40862, dev/httpd/httpd-2.4.46.tar.gz.md5
release/httpd/httpd-2.4.46.tar.gz.sha1
- copied unchanged from r40862, dev/httpd/httpd-2.4.46.tar.gz.sha1
release/httpd/httpd-2.4.46.tar.gz.sha256
- copied unchanged from r40862, dev/httpd/httpd-2.4.46.tar.gz.sha256
release/httpd/httpd-2.4.46.tar.gz.sha512
- copied unchanged from r40862, dev/httpd/httpd-2.4.46.tar.gz.sha512
Removed:
dev/httpd/CHANGES_2.4
dev/httpd/CHANGES_2.4.46
dev/httpd/httpd-2.4.46-deps.tar.bz2
dev/httpd/httpd-2.4.46-deps.tar.bz2.asc
dev/httpd/httpd-2.4.46-deps.tar.bz2.md5
dev/httpd/httpd-2.4.46-deps.tar.bz2.sha1
dev/httpd/httpd-2.4.46-deps.tar.bz2.sha256
dev/httpd/httpd-2.4.46-deps.tar.bz2.sha512
dev/httpd/httpd-2.4.46-deps.tar.gz
dev/httpd/httpd-2.4.46-deps.tar.gz.asc
dev/httpd/httpd-2.4.46-deps.tar.gz.md5
dev/httpd/httpd-2.4.46-deps.tar.gz.sha1
dev/httpd/httpd-2.4.46-deps.tar.gz.sha256
dev/httpd/httpd-2.4.46-deps.tar.gz.sha512
dev/httpd/httpd-2.4.46.tar.bz2
dev/httpd/httpd-2.4.46.tar.bz2.asc
dev/httpd/httpd-2.4.46.tar.bz2.md5
dev/httpd/httpd-2.4.46.tar.bz2.sha1
dev/httpd/httpd-2.4.46.tar.bz2.sha256
dev/httpd/httpd-2.4.46.tar.bz2.sha512
dev/httpd/httpd-2.4.46.tar.gz
dev/httpd/httpd-2.4.46.tar.gz.asc
dev/httpd/httpd-2.4.46.tar.gz.md5
dev/httpd/httpd-2.4.46.tar.gz.sha1
dev/httpd/httpd-2.4.46.tar.gz.sha256
dev/httpd/httpd-2.4.46.tar.gz.sha512
Modified:
release/httpd/Announcement2.4.html
release/httpd/Announcement2.4.txt
release/httpd/CHANGES_2.4

Modified: release/httpd/Announcement2.4.html

--- release/httpd/Announcement2.4.html (original)
+++ release/httpd/Announcement2.4.html Wed Aug 5 11:32:51 2020
@@ -49,27 +49,27 @@



- Apache HTTP Server 2.4.43 Released
+ Apache HTTP Server 2.4.46 Released


- April 01, 2020
+ September 21, 2018


The Apache Software Foundation and the Apache HTTP Server
Project are
pleased to https://www.apache.org/dist/httpd/Announcement2.4.html;>announce
- the release of version 2.4.43 of the Apache
+ the release of version 2.4.46 of the Apache
HTTP Server ("Apache"). This version of Apache is our latest GA
release of the new generation 2.4.x branch of Apache HTTPD and
represents fifteen years of innovation by the project, and is
recommended over all previous releases. This release of Apache is
- a security, feature and bug fix release.
+ a feature and bug fix release.


  

Re: svn commit: r40863 - /dev/httpd/ /release/httpd/

[Rainer Jung]

11:32:51 2020
@@ -1,19 +1,19 @@
-Apache HTTP Server 2.4.43 Released
+Apache HTTP Server 2.4.46 Released
  
-   April 01, 2020

+   September 21, 2018
  
 The Apache Software Foundation and the Apache HTTP Server Project

-   are pleased to announce the release of version 2.4.43 of the Apache
+   are pleased to announce the release of version 2.4.46 of the Apache
 HTTP Server ("Apache").  This version of Apache is our latest GA
 release of the new generation 2.4.x branch of Apache HTTPD and
 represents fifteen years of innovation by the project, and is
 recommended over all previous releases. This release of Apache is
-   a security, feature and bug fix release.
+   a feature and bug fix release.
  
 We consider this release to be the best version of Apache available, and

 encourage users of all prior versions to upgrade.
  
-   Apache HTTP Server 2.4.43 is available for download from:

+   Apache HTTP Server 2.4.46 is available for download from:
  
   https://httpd.apache.org/download.cgi
  
@@ -24,7 +24,7 @@

   https://httpd.apache.org/docs/trunk/new_features_2_4.html
  
 Please see the CHANGES_2.4 file, linked from the download page, for a

-   full list of changes. A condensed list, CHANGES_2.4.43 includes only
+   full list of changes. A condensed list, CHANGES_2.4.46 includes only
 those changes introduced since the prior 2.4 release.  A summary of all
 of the security vulnerabilities addressed in this and earlier releases
 is available:

Modified: release/httpd/CHANGES_2.4
==
--- release/httpd/CHANGES_2.4 (original)
+++ release/httpd/CHANGES_2.4 Wed Aug  5 11:32:51 2020
@@ -1,6 +1,78 @@
   -*- coding: utf-8 -*-
+Changes with Apache 2.4.46
+  *) mod_proxy_fcgi: Fix build warnings for Windows platform
+ [Eric Covener, Christophe Jaillet]
+
+Changes with Apache 2.4.45
+
+  *) mod_http2: remove support for abandoned http-wg draft
+ <https://datatracker.ietf.org/doc/draft-kazuho-h2-cache-digest/>.
+ [Stefan Eissing]
+
+Changes with Apache 2.4.44
+
+  *) mod_proxy_uwsgi: Error out on HTTP header larger than 16K (hard
+ protocol limit).  [Yann Ylavic]
+
+  *) mod_http2:
+ Fixes <https://github.com/icing/mod_h2/issues/200>:
+ "LimitRequestFields 0" now disables the limit, as documented.
+ Fixes <https://github.com/icing/mod_h2/issues/201>:
+ Do not count repeated headers with same name against the field
+ count limit. The are merged internally, as if sent in a single HTTP/1 
line.
+ [Stefan Eissing]
+
+  *) mod_http2: Avoid segfaults in case of handling certain responses for
+ already aborted connections.  [Stefan Eissing, Ruediger Pluem]
+
+  *) mod_http2: The module now handles master/secondary connections and has 
marked
+ methods according to use. [Stefan Eissing]
+
+  *) core: Drop an invalid Last-Modified header value coming
+ from a FCGI/CGI script instead of replacing it with Unix epoch.
+ [Yann Ylavic, Luca Toscano]
+
+  *) Add support for strict content-length parsing through addition of
+ ap_parse_strict_length() [Yann Ylavic]
+
+  *) mod_proxy_fcgi: ProxyFCGISetEnvIf unsets variables when expression
+ evaluates to false.  PR64365. [Michael König ]
+
+  *) mod_proxy_http: flush spooled request body in one go to avoid
+ leaking (or long lived) temporary file. PR 64452. [Yann Ylavic]
+
+  *) mod_ssl: Fix a race condition and possible crash when using a proxy client
+ certificate (SSLProxyMachineCertificateFile).
+ [Armin Abfalterer ]
+
+  *) mod_ssl: Fix memory leak in stapling code. PR63687. [Stefan Eissing]
+
+  *) mod_http2: Fixed regression that no longer set H2_STREAM_ID and 
H2_STREAM_TAG.
+ PR64330 [Stefan Eissing]
+
+  *) mod_http2: Fixed regression that caused connections to close when 
mod_reqtimeout
+ was configured with a handshake timeout. Fixes gitub issue #196.
+ [Stefan Eissing]
+
+  *) mod_proxy_http2: the "ping" proxy parameter
+ (see <https://httpd.apache.org/docs/2.4/mod/mod_proxy.html>) is now used
+ when checking the liveliness of a new or reused h2 connection to the 
backend.
+ With short durations, this makes load-balancing more responsive. The 
module
+ will hold back requests until ping conditions are met, using features of 
the
+ HTTP/2 protocol alone. [Ruediger Pluem, Stefan Eissing]
+
+  *) core: httpd is no longer linked against -lsystemd if mod_systemd
+ is enabled (and built as a DSO).  [Rainer Jung]
+
+  *) mod_proxy_http2: respect ProxyTimeout settings on backend connections
+ while waiting on incoming data. [Ruediger Pluem, Stefan Eissing]
+
  Changes with Apache 2.4.43
  
+  *) mod_ssl: Fix memory leak of OCSP stapling response. [Yann Ylavic]

+
+Changes with Apache 2.4.42
+
*

Re: First impressions from OpenSSL 3.0.0 and httpd 2.4.45

[Rainer Jung]

Concerning the failures with OpenSSL 3.0.0 in t/ssl/proxy.t, this should 
be gone with the next alpha or beta of OpenSSL 3.0.0.


The culprit is indeed:

> [ssl:info] [pid 9162:tid 140326166714128] [remote 127.0.0.1:8532]
> AH02276: Certificate Verification: Error (3): unable to get certificate
> CRL [subject:
> 
emailAddress=test-...@httpd.apache.org,CN=localhost,OU=httpd-test/rsa-test,O=ASF,L=San 


> Francisco,ST=California,C=US / issuer:
> emailAddress=test-...@httpd.apache.org,CN=ca,OU=httpd-test,O=ASF,L=San
> Francisco,ST=California,C=US / serial: 0C / notbefore: Jul 30 23:29:05
> 2020 GMT / notafter: Jul 30 23:29:05 2021 GMT]

The reason is, that lib/Apache/TestSSLCA.pm does not use the injected 
"APACHE_TEST_OPENSSL_CMD" in one line, where it uses "`openssl ...`" 
instead of "`$openssl ...`". And this happens exactly when the hash file 
for ca-bundle.crt gets created. So instead of the older 1.1.1 openssl I 
inject during configure, the new 3.0.0 gets used to create the hash 
file. That would be fine, but OpenSSL 3.0.0 has a bug just fixed very 
recently (not yet released), that "openssl crl" can not read from STDIN. 
Which is what we do.


I'll commit the "$openssl" instead of "openssl" in backticks for 
lib/Apache/TestSSLCA.pm to make its behavior more consistent.


Concerning the failures when the test client uses OpenSSL 0.9.8 I was 
able to provide OpenSSL 3.0.0 in the server with a auto-loaded 
openssl.cnf which contained the lines to load the legacy provider. The 
provider got loaded, but still the handshakes with the old OpenSSL fail. 
Don't know why. Probably not the biggest problem, because 0.9.8 based 
clients should really not matter when thinking about 3.0.0 support in 
the server.


Regards,

Rainer

Am 01.08.2020 um 17:44 schrieb Rainer Jung:

Hi there,

during release testing for 2.4.45 I also built and tested using OpenSSL 
3.0.0alpha5 on the server. Overall first results are pretty good:


- a few deprecation warnings during compilation:

modules/ssl/ssl_engine_config.c:610:5: warning: 'ENGINE_by_id' is 
deprecated [-Wdeprecated-declarations]
modules/ssl/ssl_engine_config.c:612:9: warning: 'ENGINE_free' is 
deprecated [-Wdeprecated-declarations]
modules/ssl/ssl_engine_config.c:617:9: warning: 'ENGINE_get_first' is 
deprecated [-Wdeprecated-declarations]
modules/ssl/ssl_engine_config.c:619:13: warning: 'ENGINE_get_id' is 
deprecated [-Wdeprecated-declarations]
modules/ssl/ssl_engine_config.c:620:42: warning: 'ENGINE_get_name' is 
deprecated [-Wdeprecated-declarations]
modules/ssl/ssl_engine_config.c:623:13: warning: 'ENGINE_get_next' is 
deprecated [-Wdeprecated-declarations]
modules/ssl/ssl_engine_init.c:457:9: warning: 'ENGINE_by_id' is 
deprecated [-Wdeprecated-declarations]
modules/ssl/ssl_engine_init.c:467:13: warning: 'ENGINE_ctrl' is 
deprecated [-Wdeprecated-declarations]
modules/ssl/ssl_engine_init.c:471:9: warning: 'ENGINE_set_default' is 
deprecated [-Wdeprecated-declarations]
modules/ssl/ssl_engine_init.c:482:9: warning: 'ENGINE_free' is 
deprecated [-Wdeprecated-declarations]
modules/ssl/ssl_engine_kernel.c:2611:9: warning: 'HMAC_Init_ex' is 
deprecated [-Wdeprecated-declarations]
modules/ssl/ssl_engine_kernel.c:2632:9: warning: 'HMAC_Init_ex' is 
deprecated [-Wdeprecated-declarations]
modules/ssl/ssl_engine_log.c:90:5: warning: 'ERR_peek_error_line_data' 
is deprecated [-Wdeprecated-declarations]
modules/ssl/ssl_engine_pphrase.c:856:5: warning: 'ENGINE_by_id' is 
deprecated [-Wdeprecated-declarations]
modules/ssl/ssl_engine_pphrase.c:864:5: warning: 'ENGINE_init' is 
deprecated [-Wdeprecated-declarations]
modules/ssl/ssl_engine_pphrase.c:877:9: warning: 
'ENGINE_ctrl_cmd_string' is deprecated [-Wdeprecated-declarations]
modules/ssl/ssl_engine_pphrase.c:886:9: warning: 'ENGINE_ctrl_cmd' is 
deprecated [-Wdeprecated-declarations]
modules/ssl/ssl_engine_pphrase.c:896:5: warning: 
'ENGINE_load_private_key' is deprecated [-Wdeprecated-declarations]
modules/ssl/ssl_engine_pphrase.c:904:5: warning: 'ENGINE_finish' is 
deprecated [-Wdeprecated-declarations]
modules/ssl/ssl_engine_pphrase.c:905:5: warning: 'ENGINE_free' is 
deprecated [-Wdeprecated-declarations]


- a few const warnings

modules/ssl/ssl_engine_kernel.c:608:55: warning: passing argument 2 of 
'sk_SSL_CIPHER_find' discards 'const' qualifier from pointer target type 
[-Wdiscarded-qualifiers]
modules/ssl/ssl_engine_kernel.c:627:61: warning: passing argument 2 of 
'sk_SSL_CIPHER_find' discards 'const' qualifier from pointer target type 
[-Wdiscarded-qualifiers]
modules/ssl/ssl_engine_kernel.c:638:57: warning: passing argument 2 of 
'sk_SSL_CIPHER_find' discards 'const' qualifier from pointer target type 
[-Wdiscarded-qualifiers]
modules/ssl/ssl_engine_kernel.c:1039:49: warning: passing argument 2 of 
'sk_SSL_CIPHER_find' discards 'const' qualifier from pointer target type 
[-Wdiscarded-qualifiers]


and unit tests show two prob

Re: [VOTE] Release httpd-2.4.46

[Rainer Jung]

Am 01.08.2020 um 16:13 schrieb Daniel Ruggeri:

Hi, all;
    Third time is a charm! Please find below the proposed release tarball
and signatures:
https://dist.apache.org/repos/dist/dev/httpd/

I would like to call a VOTE over the next few days to release this
candidate tarball as 2.4.46:
[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:
sha1: 15adb7eb3dc97e89c8a4237901a9d6887056ab98 *httpd-2.4.46.tar.gz
sha256: 44b759ce932dc090c0e75c0210b4485ebf6983466fb8ca1b446c8168e1a1aec2
*httpd-2.4.46.tar.gz
sha512:
5801c1dd0365f706a5e2365e58599b5adac674f3c66b0f39249909841e6cdf16bfdfe001fbd668f323bf7b6d14b116b5e7af49867d456336fad5e685ba020b15
*httpd-2.4.46.tar.gz

The SVN tag is '2.4.46' at r1880505.


+1 to release and thanks a bunch for multi-RM!

Summary: all OK except for

- 12 shutdown crashes on Solaris, all for prefork (already observed 
previously). Happens in mod_watchdog during server shutdown.

gdb info at end. Not a regression.

Detailed report:

- Sigs and hashes OK
- contents of tarballs identical
- contents of tag and tarballs identical
  except for expected deltas

Built and test results based on 2.4.45 but are valid for 2.4.46 due to 
the minimal code change between them.


Built on

- Solaris 10 Sparc as 32 Bit Binaries
- SLES 11+12+15 (64 Bits)
- RHEL 6+7+8 (64 Bits)

For all platforms built

- with default (shared) and static modules
- with module set reallyall
- using --enable-load-all-modules
- against external APR/APU 1.7.0/1.6.1
  plus APR/APU 1.6.5/1.6.1
  plus APR/APU 1.7.x r1880146/1.7.x r1880148 with expat
  plus APR/APU 1.7.x r1880146/1.7.x r1880148 with libxml2
  plus APR/APU from deps tarball

- using external libraries
  - expat 2.2.9
  - pcre 8.44
  - lua 5.3.5 (compiled with LUA_COMPAT_MODULE)
  - libxml2 2.9.10
  - libnghttp2 1.41.0
  - brotli 1.0.7
  - curl 7.71.1
  - jansson 2.13.1
  - libldap 2.4.50
and
  - openssl 0.9.8zh, 1.0.2, 1.0.2u, 1.0.1e, 1.0.1l, 1.1.1, 1.1.1g plus 
patches (head of master on 2020-07-11), 3.0.0alpha5


- Tool chain:
- platform gcc except on Solaris
  (gcc 9.3.0 Solaris 10)
- CFLAGS: -O2 -g -Wall -fno-strict-aliasing
  - on Solaris additionally -mpcu=v9, -D_XOPEN_SOURCE,
-D_XOPEN_SOURCE_EXTENDED=1, -D__EXTENSIONS__
and -D_XPG6

All of the 1064 builds succeeded.

- compiler warnings:

  - only on Solaris (GCC 9.3.0):
srclib/apr/locks/unix/proc_mutex.c:979:49: warning: 
'mutex_proc_pthread_cond_methods' defined but not used 
[-Wunused-const-variable=]


  - deprecation warnings when building against OpenSSL 3.0.0, see other 
thread



Tested for

- Solaris 10, SLES 11+12+15, RHEL 6+7+8
- MPMs prefork, worker, event
- default and static module builds
- log level trace8
- module set reallyall (128 modules plus 3 MPMs)
- Perl client bundle build against OpenSSL 1.1.1g plus patches, 1.1.0l, 
1.0.2u and 0.9.8zh

- OpenSSL once linked statically and once as a shared library

Every OpenSSL version in the client tested with every OpenSSL version in 
the server. Nearly all tests with dynamically linked OpenSSL are done.


The total number of test suite runs was 5913 (many more to come ...).

Some local adjustments to tests were used:

- t/modules/buffer.t: removing huge buffer tests
  -my $bigsize = 10;
  +my $bigsize = 1;

- fixing "sub which" in Apache-Test/lib/Apache/TestConfig.pm
  +# No need to search PATH components
  +# if $program already contains a path
  +return $program if !OSX and !WINFU and
  +$program =~ /\// and -f $program and -x $program;
  +

- fixing limitrequestline overwrite which does not yet really work

The following test failures were seen:

a Crashes only on Solaris, only with prefork MPM and
  dynamically linked builds.
  The crash seems to happen only at the end of a process during pchild
  clean up and it might be problematic, that the watchdog thread at that
  time still exists.
  gdb info see at end.

b Tests 2 of t/apache/pr35292.t
  Tests 2 at line 29
  Only once on Solaris. Unclear failure showing the socket
  was disconected, but the next test case sees correct response content.

c Tests 27 and 28 of t/modules/http2.t
  Tests 27 and 28 at lines 303 and 304
  Response status and content length undef for
  test case: TC0015, necho.pl 10x10:
  GET 
http://localhost:8536/modules/h2/necho.pl?count=10=0123456789

  Only once on Solaris.

d Tests 207 and 265 of t/ssl/proxy.t
  eat_post received "502 Proxy Error".
  Each of the two failed test cases only once on Solaris.

e OpenSSL 3.0.0 and t/ssl/proxy.t
  eat_post fails always, see other thread about OpenSSL 3.0.0

f All https tests fail between OpenSSL 0.9.8zh and 3.0.0alpha5
  Probably need to figure out how to load the legacy provider
  during the tests

g Test 5 in t/modules/dav.t line 69:
  Not a regression.
  Only once on SLES 11.
  Creation, modified and now times not in 

First impressions from OpenSSL 3.0.0 and httpd 2.4.45

[Rainer Jung]

Hi there,

during release testing for 2.4.45 I also built and tested using OpenSSL 
3.0.0alpha5 on the server. Overall first results are pretty good:


- a few deprecation warnings during compilation:

modules/ssl/ssl_engine_config.c:610:5: warning: 'ENGINE_by_id' is 
deprecated [-Wdeprecated-declarations]
modules/ssl/ssl_engine_config.c:612:9: warning: 'ENGINE_free' is 
deprecated [-Wdeprecated-declarations]
modules/ssl/ssl_engine_config.c:617:9: warning: 'ENGINE_get_first' is 
deprecated [-Wdeprecated-declarations]
modules/ssl/ssl_engine_config.c:619:13: warning: 'ENGINE_get_id' is 
deprecated [-Wdeprecated-declarations]
modules/ssl/ssl_engine_config.c:620:42: warning: 'ENGINE_get_name' is 
deprecated [-Wdeprecated-declarations]
modules/ssl/ssl_engine_config.c:623:13: warning: 'ENGINE_get_next' is 
deprecated [-Wdeprecated-declarations]
modules/ssl/ssl_engine_init.c:457:9: warning: 'ENGINE_by_id' is 
deprecated [-Wdeprecated-declarations]
modules/ssl/ssl_engine_init.c:467:13: warning: 'ENGINE_ctrl' is 
deprecated [-Wdeprecated-declarations]
modules/ssl/ssl_engine_init.c:471:9: warning: 'ENGINE_set_default' is 
deprecated [-Wdeprecated-declarations]
modules/ssl/ssl_engine_init.c:482:9: warning: 'ENGINE_free' is 
deprecated [-Wdeprecated-declarations]
modules/ssl/ssl_engine_kernel.c:2611:9: warning: 'HMAC_Init_ex' is 
deprecated [-Wdeprecated-declarations]
modules/ssl/ssl_engine_kernel.c:2632:9: warning: 'HMAC_Init_ex' is 
deprecated [-Wdeprecated-declarations]
modules/ssl/ssl_engine_log.c:90:5: warning: 'ERR_peek_error_line_data' 
is deprecated [-Wdeprecated-declarations]
modules/ssl/ssl_engine_pphrase.c:856:5: warning: 'ENGINE_by_id' is 
deprecated [-Wdeprecated-declarations]
modules/ssl/ssl_engine_pphrase.c:864:5: warning: 'ENGINE_init' is 
deprecated [-Wdeprecated-declarations]
modules/ssl/ssl_engine_pphrase.c:877:9: warning: 
'ENGINE_ctrl_cmd_string' is deprecated [-Wdeprecated-declarations]
modules/ssl/ssl_engine_pphrase.c:886:9: warning: 'ENGINE_ctrl_cmd' is 
deprecated [-Wdeprecated-declarations]
modules/ssl/ssl_engine_pphrase.c:896:5: warning: 
'ENGINE_load_private_key' is deprecated [-Wdeprecated-declarations]
modules/ssl/ssl_engine_pphrase.c:904:5: warning: 'ENGINE_finish' is 
deprecated [-Wdeprecated-declarations]
modules/ssl/ssl_engine_pphrase.c:905:5: warning: 'ENGINE_free' is 
deprecated [-Wdeprecated-declarations]


- a few const warnings

modules/ssl/ssl_engine_kernel.c:608:55: warning: passing argument 2 of 
'sk_SSL_CIPHER_find' discards 'const' qualifier from pointer target type 
[-Wdiscarded-qualifiers]
modules/ssl/ssl_engine_kernel.c:627:61: warning: passing argument 2 of 
'sk_SSL_CIPHER_find' discards 'const' qualifier from pointer target type 
[-Wdiscarded-qualifiers]
modules/ssl/ssl_engine_kernel.c:638:57: warning: passing argument 2 of 
'sk_SSL_CIPHER_find' discards 'const' qualifier from pointer target type 
[-Wdiscarded-qualifiers]
modules/ssl/ssl_engine_kernel.c:1039:49: warning: passing argument 2 of 
'sk_SSL_CIPHER_find' discards 'const' qualifier from pointer target type 
[-Wdiscarded-qualifiers]


and unit tests show two problems, one will be fixed in OpenSSL itself:

- during unit test preparation, our test script create a PKCS12 store 
with default encoding params. That's known to be broken in alpha5. So 
the "-configure" step of "t/TEST" should be run before the actual 
testing with a stable version of OpenSSL.

https://github.com/openssl/openssl/pull/12540
https://github.com/openssl/openssl/issues/11672

- independent of OpenSSL 3.0.0: to work around the previous observation 
I tried using the env var "APACHE_TEST_OPENSSL_CMD". Unfortunately this 
is slightly broken, because it tests for the existence using the "which" 
function in TestConfig.pm and that function is broken when used for a 
command containing a path component. I temporarily fixed it using:


@@ -1782,6 +1782,11 @@

 return undef unless $program;

+# No need to search PATH components
+# if $program already contains a path
+return $program if !OSX and !WINFU and
+$program =~ /\// and -f $program and -x $program;
+
 my @dirs = File::Spec->path();

 require Config;


- when testing with client >= OpenSSL 1.1.0 against 3.0.0alpha5, only 
t/ssl/proxy.t shows failures, especially in eat_post but already during 
TLS handshake:


[ssl:info] [pid 9162:tid 140326149928720] [client 127.0.0.1:56312] 
AH01964: Connection to child 82 established (server localhost:8532)


[ssl:info] [pid 9162:tid 140326166714128] [remote 127.0.0.1:8532] 
AH02276: Certificate Verification: Error (3): unable to get certificate 
CRL [subject: 
emailAddress=test-...@httpd.apache.org,CN=localhost,OU=httpd-test/rsa-test,O=ASF,L=San 
Francisco,ST=California,C=US / issuer: 
emailAddress=test-...@httpd.apache.org,CN=ca,OU=httpd-test,O=ASF,L=San 
Francisco,ST=California,C=US / serial: 0C / notbefore: Jul 30 23:29:05 
2020 GMT / notafter: Jul 30 23:29:05 2021 GMT]


[ssl:info] [pid 9162:tid 140326149928720] [client 

Re: Pending fixes or reroll? Was: [RESULT] [VOTE] Release httpd-2.4.45

[Rainer Jung]

Since here were lots of "good-to-go, let's roll" one note though: the 
current CHANGES does not yet a section for 2.4.46, cause normally 
APLOGNO doesn't get noted on CHANGES. In this case it might be something 
like


  *) mod_proxy_fcgi: Fix build on Windows.

and credits for Eric (who fixed it on trunk) oand/or Christophe, who 
backported it.


Best regards,

Rainer

Am 31.07.2020 um 15:36 schrieb Rainer Jung:
Since there wasn't yet any reaction to Daniel's question: Is anybody 
right now working on more warnings fixes for Windows?


The most prominent one (missing APLOGNo number = missing macro argument) 
IMHO was already fixed by Christophe in r1880438. Anything else worth 
waiting for or are we (is Daniel) good to go for 2.4.46?


Concerning lua I'd say the fix(es) for 5.4.0 need a bit more testing.

Regards,

Rainer

Am 30.07.2020 um 22:26 schrieb Daniel Ruggeri:

Hi, all;
    I thank everyone for their testing and quick feedback. While we had
enough votes and positive feedback, we have some easily fixable warnings
which have precedence for holding up a release.

    To that end, I will close this vote and declare 2.4.45 dead on the 
vine.


    I will roll 2.4.46 when we are all buttoned up with the warnings.

Pending fixes or reroll? Was: [RESULT] [VOTE] Release httpd-2.4.45

[Rainer Jung]

Since there wasn't yet any reaction to Daniel's question: Is anybody 
right now working on more warnings fixes for Windows?


The most prominent one (missing APLOGNo number = missing macro argument) 
IMHO was already fixed by Christophe in r1880438. Anything else worth 
waiting for or are we (is Daniel) good to go for 2.4.46?


Concerning lua I'd say the fix(es) for 5.4.0 need a bit more testing.

Regards,

Rainer

Am 30.07.2020 um 22:26 schrieb Daniel Ruggeri:

Hi, all;
    I thank everyone for their testing and quick feedback. While we had
enough votes and positive feedback, we have some easily fixable warnings
which have precedence for holding up a release.

    To that end, I will close this vote and declare 2.4.45 dead on the vine.

    I will roll 2.4.46 when we are all buttoned up with the warnings.

Re: Providing near-time averaged monitoring data for mod_systemd and mod_status

[Rainer Jung]

Am 27.04.2020 um 15:57 schrieb Joe Orton:

On Sat, Apr 25, 2020 at 08:10:40PM +0200, Rainer Jung wrote:

Patch available at

home.apache.org/~rjung/patches/httpd-trunk-mon-snaps-v1_2.patch


Very nice!  +1 from me.

Does the times_per_thread logic still make any sense?  It's always been
wrong for Linux AFAICT so maybe can just be dropped.


I will do some code archeology to find out who added it and why.


A minor nit, I think the snap_index should be read/written using
apr_atomic_t since it's going to be accessed concurrently across
threads?


Yup. Since we only have concurrent reads, it should suffice to check the 
value with apr_atomic_read32 and then use apr_atomic_set32 to set it the 
0 or 1.


I wonder how we best make sure, that the new monitor hook is not called 
from modules? Currently it is no AP_DECLARE'd but contained in httpd.h. 
And the hook registration is in server/core.c, but the implementation in 
server/scoreboard.c. No idea (not tried) whether it would be better to 
have it in server/core.c as a static function or whether that's not 
needed and it would suffice to move the function declaration to a 
private header file.


Thanks and regards,

Rainer


Some notes:

- in order to use the data from mod_systemd (monitor hook), which runs in
the maim process, and also from mod_status, so from child processes, it
needs to sit in shared memory. Since most of the data is tightly coupled to
the scoreboard, I added the new cached data to the global part of the
scoreboard.

- it was then IMHO a good fit to move the existing ap_get_sload(ap_sload_t
*ld) from server/util.c to server/scoreboard.c.

- ap_sload_t is used as a collection of data which can be used to generate
averaged data from a pair of ap_sload_t structs. It was extended to also
contain the total request duration plus total usr and sys CPU and the
timestamp when the data was taken. So it should now contain all data from
which mod-systemd and mod_status currently like to display derived averaged
values.

- busy and idle in ap_sload_t have been changed from int to float, because
they were already only used a percentages. IMHO it doesn't make sense to
express idle and busy as percentages based on a total of busy plus idle,
because that sum is not a meaningful total. The server can grow by creating
new processes and suddenly your busy percentage might shrink, although the
absolute number of busy threads increases. That's counter intuitive. So I
added the unused process slots to the total count, and we have three
counters that sum up to this total, busy, idle and dead. We need a better
name than "dead" for these unused process slots that might get used later.
"unused" is to close to "idle" and I don't have a good name yet.

- the new ap_mon_snap_t contains a pointer to an ap_sload_t, six averaged
values generated from two ap_sload_t and a member that conatins the time
delta between those two ap_sload_t. The ap_sload_t referenced by
ap_mon_snap_t contains the data at time t1. During the next monitor run, new
t1 data will be collected and the previous t1 data will be used as t0 data
to generate the new averages.

- the scoreboard contains two ap_mon_snap_t (plus the two ap_sload_t
referenced by them) to be able to update one of them without breaking access
by consumers to the other one. After the update the roles get switched.

- both structs, ap_sload_t and ap_mon_snap_t are declared in httpd.h,
because ap_sload_t already had been there. t might be a better fit to move
them to scoreboard.h, but I'm not sure about that and I don't know if that
would be allowed by the compatibility rules.

- also in httpd.h there are now three new function declarations. Two only
used by server/core.c as hook functions:

   int ap_scoreboard_monitor(apr_pool_t *p, server_rec *s);
   void ap_scoreboard_child_init(apr_pool_t *p, server_rec *s);

and one for public consumption:

   AP_DECLARE(void) ap_get_mon_snap(ap_mon_snap_t *ms);

- mod_systemd and mod_status now call ap_get_mon_snap() to retrieve the
latest averaged data. mod_status still uses the scoreboard in addition to
retrieve up-to-date current scalar metrics. Small adjustments to the
mod_status output plus additions to mod_systemd notification messages. Tne
STATUS in the notification of mod_systemd now looks liek this:

STATUS=Pct Idle workers 28.4; Pct Busy workers 10.6; Pct Dead workers 60.9;
Requests/sec: 5030; Bytes served/sec: 2.9MB/sec; Bytes served/request: 596
B/req; Avg Duration(ms): 5.78; Avg Concurrency: 29.1; Cpu Pct: 40.5

- scoreboard.c changes:

   - take over ap_get_sload(ap_sload_t *sl) from server/util.c.
 Added copied code from mod_status to that function to also add up the
request duration and the usr and sys CPU times.

   - ap_scoreboard_monitor() runs in the monitor hook. It calls
ap_get_sload() and then a static utility function calc_mon_data() to
calculate the new averages.

- Minor mmn change not yet part of the patch.

It compiles fine (mai

Re: Providing near-time averaged monitoring data for mod_systemd and mod_status

[Rainer Jung]

Am 27.04.2020 um 17:28 schrieb Yann Ylavic:

On Mon, Apr 27, 2020 at 5:18 PM Rainer Jung  wrote:


Hi Yann,

Am 27.04.2020 um 16:40 schrieb Yann Ylavic:

Hi Rainer,

On Mon, Apr 27, 2020 at 3:17 PM Rainer Jung  wrote:


Thanks for this.
Could you please create this as a PR on github as well? This ensures that all 
the Travis tests are run for your patch.


Thanks Rüdiger. Done and indeed Travis found one not that I fixed but we
need to discuss.


Thanks Rainer, looks very nice.

Could we avoid the "ap_sload_t *sload" pointer in ap_mon_snap_t somehow?
I'm asking because snap0 and snap1 in global_score (SHM) end up
containing a pointer now.


My initial version had the fields of ap_sload_t directly inside
ap_mon_snap_t instead of the pointer.

I changed it, because

- it allowed to more safely copy the whole ap_sload_t without relying on
keeping two struct definitions in sync

- it allowed to extend ap_sload_t and ap_mon_snap_t at their respective
ends and stay compatible.

You have a problem with the pointers because of possible alignment
issues or what kind of trouble might we run into? Or is it just hard to
understand (and more comments in the code will help)?


My concern is more about security, e.g. CVE-2019-0211 kind of things,
with an unprivileged user (child) playing with this pointer and making
the main process (monitor?) at best crash, at worst do anything they
want (root privilege escalation).


I see. Although I don't see a way how we would execute code at the 
derefenced address, as a safety guard for future code changes we can 
easily avoid using the pointers in the scoreboard and instead use sload0 
/ snap0 and sload1 / snap1 when doing the calculations. Since the 
pointers (after init) would have been constant, we can hard code it into 
trivial logic instead.


One could then use a separate type for snap0 and snap1 in the 
scoreboard, but I would find it better to stay with the ap_mon_snap_t 
type, even if we do not use the pointer there.


For the struct passed in from the consumer, I would still use the 
pointer as-is.


Will provide a change on top of the PR for further discussion.

Thanks for the heads up. Didn't think about using the scoreboard and the 
monitor hook running in the parent havig security implications. One 
really needs to be careful about assumptions for the scoreboard data!


Regards,

Rainer

Re: Providing near-time averaged monitoring data for mod_systemd and mod_status

[Rainer Jung]

Hi Yann,

Am 27.04.2020 um 16:40 schrieb Yann Ylavic:

Hi Rainer,

On Mon, Apr 27, 2020 at 3:17 PM Rainer Jung  wrote:


Thanks for this.
Could you please create this as a PR on github as well? This ensures that all 
the Travis tests are run for your patch.


Thanks Rüdiger. Done and indeed Travis found one not that I fixed but we
need to discuss.


Thanks Rainer, looks very nice.

Could we avoid the "ap_sload_t *sload" pointer in ap_mon_snap_t somehow?
I'm asking because snap0 and snap1 in global_score (SHM) end up
containing a pointer now.


My initial version had the fields of ap_sload_t directly inside 
ap_mon_snap_t instead of the pointer.


I changed it, because

- it allowed to more safely copy the whole ap_sload_t without relying on 
keeping two struct definitions in sync


- it allowed to extend ap_sload_t and ap_mon_snap_t at their respective 
ends and stay compatible.


You have a problem with the pointers because of possible alignment 
issues or what kind of trouble might we run into? Or is it just hard to 
understand (and more comments in the code will help)?


Or because it is harder for consumers to use the API in a correct way 
(the pointer in ap_mon_snap_t might be uninitialized)? In the latter 
case: one could also see this as a feature instead of as a bug: as long 
as one is only interested in the averaged data and not in the sload 
data, you can pass in an ap_mon_snap_t with a null pointer to the 
ap_sload_t.


Regards,

Rainer

Re: Providing near-time averaged monitoring data for mod_systemd and mod_status

[Rainer Jung]

Am 27.04.2020 um 08:57 schrieb Ruediger Pluem:



On 4/25/20 8:10 PM, Rainer Jung wrote:

Patch available at

home.apache.org/~rjung/patches/httpd-trunk-mon-snaps-v1_2.patch


Thanks for this.
Could you please create this as a PR on github as well? This ensures that all 
the Travis tests are run for your patch.


Thanks Rüdiger. Done and indeed Travis found one not that I fixed but we 
need to discuss.


I changed the data type of the idle and busy fields in the sload struct 
from int to float, because they were used as floats. But that broke 
mod_headers which uses the data and will break other consumers as well.


For compatibility reasons, we could keep the int type though.

Regards,

Rainer

Providing near-time averaged monitoring data for mod_systemd and mod_status

[Rainer Jung]

Patch available at

home.apache.org/~rjung/patches/httpd-trunk-mon-snaps-v1_2.patch

Some notes:

- in order to use the data from mod_systemd (monitor hook), which runs 
in the maim process, and also from mod_status, so from child processes, 
it needs to sit in shared memory. Since most of the data is tightly 
coupled to the scoreboard, I added the new cached data to the global 
part of the scoreboard.


- it was then IMHO a good fit to move the existing 
ap_get_sload(ap_sload_t *ld) from server/util.c to server/scoreboard.c.


- ap_sload_t is used as a collection of data which can be used to 
generate averaged data from a pair of ap_sload_t structs. It was 
extended to also contain the total request duration plus total usr and 
sys CPU and the timestamp when the data was taken. So it should now 
contain all data from which mod-systemd and mod_status currently like to 
display derived averaged values.


- busy and idle in ap_sload_t have been changed from int to float, 
because they were already only used a percentages. IMHO it doesn't make 
sense to express idle and busy as percentages based on a total of busy 
plus idle, because that sum is not a meaningful total. The server can 
grow by creating new processes and suddenly your busy percentage might 
shrink, although the absolute number of busy threads increases. That's 
counter intuitive. So I added the unused process slots to the total 
count, and we have three counters that sum up to this total, busy, idle 
and dead. We need a better name than "dead" for these unused process 
slots that might get used later. "unused" is to close to "idle" and I 
don't have a good name yet.


- the new ap_mon_snap_t contains a pointer to an ap_sload_t, six 
averaged values generated from two ap_sload_t and a member that conatins 
the time delta between those two ap_sload_t. The ap_sload_t referenced 
by ap_mon_snap_t contains the data at time t1. During the next monitor 
run, new t1 data will be collected and the previous t1 data will be used 
as t0 data to generate the new averages.


- the scoreboard contains two ap_mon_snap_t (plus the two ap_sload_t 
referenced by them) to be able to update one of them without breaking 
access by consumers to the other one. After the update the roles get 
switched.


- both structs, ap_sload_t and ap_mon_snap_t are declared in httpd.h, 
because ap_sload_t already had been there. t might be a better fit to 
move them to scoreboard.h, but I'm not sure about that and I don't know 
if that would be allowed by the compatibility rules.


- also in httpd.h there are now three new function declarations. Two 
only used by server/core.c as hook functions:


  int ap_scoreboard_monitor(apr_pool_t *p, server_rec *s);
  void ap_scoreboard_child_init(apr_pool_t *p, server_rec *s);

and one for public consumption:

  AP_DECLARE(void) ap_get_mon_snap(ap_mon_snap_t *ms);

- mod_systemd and mod_status now call ap_get_mon_snap() to retrieve 
the latest averaged data. mod_status still uses the scoreboard in 
addition to retrieve up-to-date current scalar metrics. Small 
adjustments to the mod_status output plus additions to mod_systemd 
notification messages. Tne STATUS in the notification of mod_systemd now 
looks liek this:


STATUS=Pct Idle workers 28.4; Pct Busy workers 10.6; Pct Dead workers 
60.9; Requests/sec: 5030; Bytes served/sec: 2.9MB/sec; Bytes 
served/request: 596 B/req; Avg Duration(ms): 5.78; Avg Concurrency: 
29.1; Cpu Pct: 40.5


- scoreboard.c changes:

  - take over ap_get_sload(ap_sload_t *sl) from server/util.c.
Added copied code from mod_status to that function to also add up 
the request duration and the usr and sys CPU times.


  - ap_scoreboard_monitor() runs in the monitor hook. It calls 
ap_get_sload() and then a static utility function calc_mon_data() to 
calculate the new averages.


- Minor mmn change not yet part of the patch.

It compiles fine (maintainer mode) on RHEL 7 x86_64 and on Solaris 10 
Sparc and I did some tests with mod_status and mod_systemd.


Regards,

Rainer

Am 24.04.2020 um 18:32 schrieb Rainer Jung:

Am 24.04.2020 um 16:21 schrieb Joe Orton:

On Fri, Apr 24, 2020 at 12:17:19PM +0200, Rainer Jung wrote:

Thinking further: I think it would make sense to have a module or core
implement the monitor hook to generate that derived data (requests/sec,
bytes/sec, durationMs/request, avgConcurrency) in the last monitor 
interval
and to provide that data to consumers like mod_systemd or - new - 
mod_status
- instead of the long term averages since start. It could probably be 
added
to the code that already provides "sload". That way mod_status would 
also

profit from the more precise average values (taken over the last monitor
interval).


I definitely like the patch, it has bothered me that the "per second"
stats are not very useful but wasn't sure how to make it better.

This is also an interesting idea.

So you would suggest having a new monit

Re: mod_systemd suggestion

[Rainer Jung]

Am 24.04.2020 um 16:21 schrieb Joe Orton:

On Fri, Apr 24, 2020 at 12:17:19PM +0200, Rainer Jung wrote:

Thinking further: I think it would make sense to have a module or core
implement the monitor hook to generate that derived data (requests/sec,
bytes/sec, durationMs/request, avgConcurrency) in the last monitor interval
and to provide that data to consumers like mod_systemd or - new - mod_status
- instead of the long term averages since start. It could probably be added
to the code that already provides "sload". That way mod_status would also
profit from the more precise average values (taken over the last monitor
interval).


I definitely like the patch, it has bothered me that the "per second"
stats are not very useful but wasn't sure how to make it better.

This is also an interesting idea.

So you would suggest having a new monitor hook which runs REALLY_LAST in
the order, calls ap_get_sload() and stores it in a global, and then we'd
have an ap_get_cached_sload() (or whatever) which gives you the cached
data from the last iteration?  Or are you thinking of a more
sophisticated API which does the "diff" between intervals internally?


Thanks for the positive feedback.

The averaged metrics IMHO only make sense as cached data, updated in 
regular intervals and provided for use by various modules (probably only 
mod_systemd and mod_status).


I would like to provide the already averaged data in a struct, each 
metric as a float or double. The bytes/request probably not already 
human readably scaled, because it makes its use less flexible. Since we 
already also have the absolute counters at that point, we can easily add 
them to the same struct as 32 or 64 bit counters and return a consistent 
set of data (five old values, five new values, five averages and two 
time stamps). [idle(32), busy(32), requests(64), bytes(64), 
duration(64); req/s, bytes/s, bytes/req, dur/s, dur/req]. So consumers 
needing a consistent view can get it.


Even more so since the absolute metrics are currently not cheap to 
access. We collect all of them by iterating over the scoreboard and 
summing up. By adding them to the cached data, the consuming code could 
decide, whether such near-time data is good enough or it needs to 
acquire new and curent counters. For mod_systemd, cached data (10 second 
interval) might be OK.


For some modules - like mod_status - cached averages are fine, but I 
think the counters should be correct for the point in time the status 
request was handled by the module. So the scoreboard statistics code in 
mod_status unfortunately would not go away.´, but the data quality for 
the averages would become better.


Implementation wise I am thinking about adding

  ap_hook_monitor(mon_avg_monitor, NULL, NULL, ???);

to server/util.c, which calculates the new averages and

  ap_get_mon_avg(ap_mon_avg_t *ma)

which returns the four averages in a struct similar to the existing 
ap_get_loadavg() and ap_get_sload().


We might have a little hassle to make the statistics update 
atomic/thread-safe (eg. two instances of the internal data struct, so 
that we only need to make the switch between them after the new 
calculation atomic).


About REALLY_LAST: why last? If other modules collect data via this API 
and wasn't to do it in the monitor hook as well, shouldn't run the 
caching of data REALLY_FIRST, so you get the new averages?


I'll try to draft and test something along these lines later today. Fun 
stuff. And more comments are very welcome.


And I like, that mod_status will profit by showing betrer averages as well.

Regards,

Rainer


Am 23.04.2020 um 21:29 schrieb Rainer Jung:

Hi all,

triggered by the new mod_systemd I drafted a patch to enhance the
monitoring data it provides during the monitor hook run.

Currently it publishes important data, like idle and busy slots and
total request count, but also not so useful info like requests/second
and bytes/second as a long term average (since start). These two figues
tend to become near constant after a longer time of operation.

Since the monitor hook of the module always seems to run in the same
(parent) process, it is easy to remember the previous request and byte
count data and average only over the last monitor hook interval. This
should give more meaningful data. And is a change local to mod_systemd.

In addition we have a third metric available in the scoreboard, namely
the total request duration. From that we can get the average request
duration and the average request concurrency. This part also needs a
change to the sload structure. Maybe we need a minor MMN bump for that.

I scetched a patch under

home.apache.org/~rjung/patches/httpd-trunk-mod_systemd-interval-stats.patch

Any comments, likes or dislikes?

Thanks and regards,

Rainer

Re: mod_systemd suggestion

[Rainer Jung]

Thinking further: I think it would make sense to have a module or core 
implement the monitor hook to generate that derived data (requests/sec, 
bytes/sec, durationMs/request, avgConcurrency) in the last monitor 
interval and to provide that data to consumers like mod_systemd or - new 
- mod_status - instead of the long term averages since start. It could 
probably be added to the code that already provides "sload". That way 
mod_status would also profit from the more precise average values (taken 
over the last monitor interval).


Regards,

Rainer

Am 23.04.2020 um 21:29 schrieb Rainer Jung:

Hi all,

triggered by the new mod_systemd I drafted a patch to enhance the 
monitoring data it provides during the monitor hook run.


Currently it publishes important data, like idle and busy slots and 
total request count, but also not so useful info like requests/second 
and bytes/second as a long term average (since start). These two figues 
tend to become near constant after a longer time of operation.


Since the monitor hook of the module always seems to run in the same 
(parent) process, it is easy to remember the previous request and byte 
count data and average only over the last monitor hook interval. This 
should give more meaningful data. And is a change local to mod_systemd.


In addition we have a third metric available in the scoreboard, namely 
the total request duration. From that we can get the average request 
duration and the average request concurrency. This part also needs a 
change to the sload structure. Maybe we need a minor MMN bump for that.


I scetched a patch under

home.apache.org/~rjung/patches/httpd-trunk-mod_systemd-interval-stats.patch

Any comments, likes or dislikes?

Thanks and regards,

Rainer

mod_systemd suggestion

[Rainer Jung]

Hi all,

triggered by the new mod_systemd I drafted a patch to enhance the 
monitoring data it provides during the monitor hook run.


Currently it publishes important data, like idle and busy slots and 
total request count, but also not so useful info like requests/second 
and bytes/second as a long term average (since start). These two figues 
tend to become near constant after a longer time of operation.


Since the monitor hook of the module always seems to run in the same 
(parent) process, it is easy to remember the previous request and byte 
count data and average only over the last monitor hook interval. This 
should give more meaningful data. And is a change local to mod_systemd.


In addition we have a third metric available in the scoreboard, namely 
the total request duration. From that we can get the average request 
duration and the average request concurrency. This part also needs a 
change to the sload structure. Maybe we need a minor MMN bump for that.


I scetched a patch under

home.apache.org/~rjung/patches/httpd-trunk-mod_systemd-interval-stats.patch

Any comments, likes or dislikes?

Thanks and regards,

Rainer