httpd proxy heartbeat-Loadbalacing

[Rainer Jung]

Hi there,

I had a look at mod_lbmethod_heartbeat and want to suggest some changes 
or improvements.


How does it work currently:

- module mod_heartmonitor opens a port and listens for incoming UDP messages

- a balancing backend can send UDP packets with a string content of the 
form "v=1&busy=&idle=" (NUMBER1 and NUMBER2 are 
numbers) to that UDP port.


  - an example would be mod_heartbeat, which can be used as a sender on 
an httpd backend. But one can implement such a simple UDP sender per 
backend oneself.


- mod_heartmonitor puts the information per sender into a shared memory

- when a proxy balancer uses lbmethod=heartbeat, module 
mod_lbmethod_heartbeat makes the balancing decisions based on the shared 
memory contents. Data older than 10 seconds is discarded.


Now how does it make this decision? Since the busy/idle information can 
not be updated by the balancer itself on a continuous basis, it does not 
simply use e.g. the backend with the smallest busy value. If it would 
do, it would send all requests there until an update UDP message changes 
the busy values.


Instead it wants to distribute on all backends based on weights it gives 
them calculated via busy and idle.


Currently it does not use the busy value at all and instead simply uses 
the idle values as the weights.


Now often we deploy httpd with a lot of spare thread capacity. That 
means idle values are often relatively high unless we have a traffic jam 
(httpd or more likely something behind it got stuck). But high idle 
values mean, that the weights are not differentiating much between the 
backends. The more spare threads we configure for them the more the 
balancing ends up roughly being round-robin, at least between all 
backends that do not get stuck.


Example: all backends having 1000 max threads configured, current 
busyness being 10, 15, 20 and 5. So idleness is 990, 985, 980 and 995. 
That leads almost to a round-robin distribution.


So I was thinking about a balancing focusing more on busyness instead of 
the often high idleness and finding more differentiating weights. 
Changes could be mad configurable though for compatibility reasons. I 
would expect not many users using the heartbeat based balancing, but as 
often we don't actually know.


First approximation would be to use MAX(busy)-busy_i as the weight for 
backend i. It is almost like idle, but doesn't use the probably 
configured high max idleness but instead the maximum observed busyness 
as the capacity limit. That would be much more differentiating.


A problem would be, if some backends get stuck. Then they push this 
fictitious idleness again to high numbers for any other backends. So I 
would introduce a configurable limit above which we ignore the busy 
counts of targets when determining the max. One would eg. set this limit 
as an optimization to double the max busyness that one would expect 
during normal operations.


Finally one has to make sure, that one doesn't end up in a corner case. 
E.g. every node has the same busy value, so all weights would be 
MAX-busy = 0. So end up one to all weights or similar.


Another configurable item could be a fixed number which gets added to 
each weight. That would level a bit the strong differentiating when busy 
numbers are very small. The desired behavior of course depends on what 
busyness means to the application and how sensitive it is.


Finally the current idleness based approach handles backends special, 
that show up for the first time in order to not overwhelm them. One 
would adjust the new approach for them as well (have not yet thought 
about it in detail).


Any thoughts on such a change in concept?

I guess we want to keep the current idleness based approach as the 
default in 2.4.x. For trunk I would think we could drop it.


Of course the concept needs an appropriate explanation in the docs, 
that's missing currently for the idleness based balancing.


By the way: I'd like to also make the 10 seconds "timeout" for data 
configurable. Some situations might be fine with less frequent updates 
and measuring the busy count might be a bit to expensive to do it every 
5 seconds or so. Thinking about other application specific senders than 
just mod_heartbeat.


Thanks for following my thoughts! Feel free to ask or correct me!

Best regards,

Rainer

pytest failure test_tls_11_get_base

[Rainer Jung]

Hi there,

I started to run pytest also on modules/tls, now that it also supports 
mod_ssl. It works pretty well, but one test is failing: test_tls_11_get_base


The httpd error log mentions a config error:

[Mon Jul 15 23:22:33.210906 2024] [md:debug] [pid 27612:tid 27612] 
mod_md.c(612): AH10041: Server a.mod-tls.test:0 matches md 
a.mod-tls.test (config srv[default], match-mode=0) for domain 
a.mod-tls.test, has now 1 MDs
[Mon Jul 15 23:22:33.210933 2024] [md:debug] [pid 27612:tid 27612] 
mod_md.c(612): AH10041: Server a.mod-tls.test:0 matches md 
a.mod-tls.test (config a.mod-tls.test[default, default], match-mode=0) 
for domain a.mod-tls.test, has now 1 MDs
[Mon Jul 15 23:22:33.210950 2024] [md:debug] [pid 27612:tid 27612] 
md_reg.c(842): sync MDs, start
[Mon Jul 15 23:22:33.211083 2024] [md:debug] [pid 27612:tid 27612] 
md_reg.c(905): sync MDs, 1 existing, 0 moved, 0 new.
[Mon Jul 15 23:22:33.211126 2024] [ssl:info] [pid 27612:tid 27612] 
AH01883: Init: Initialized OpenSSL library
[Mon Jul 15 23:22:33.213227 2024] [ssl:debug] [pid 27612:tid 27612] 
ssl_engine_init.c(365): AH01886: OpenSSL has FIPS mode disabled
[Mon Jul 15 23:22:33.213322 2024] [ssl:info] [pid 27612:tid 27612] 
AH01887: Init: Initializing (virtual) servers for SSL
[Mon Jul 15 23:22:33.213344 2024] [ssl:info] [pid 27612:tid 27612] 
AH01914: Configuring server a.mod-tls.test:443 for SSL protocol
[Mon Jul 15 23:22:33.213351 2024] [md:debug] [pid 27612:tid 27612] 
mod_md.c(1130): AH10113: get_certificates called for vhost a.mod-tls.test.
[Mon Jul 15 23:22:33.213357 2024] [md:debug] [pid 27612:tid 27612] 
mod_md.c(1225): AH10077: a.mod-tls.test[state=0]: providing certificates 
for server a.mod-tls.test
[Mon Jul 15 23:22:33.214481 2024] [ssl:debug] [pid 27612:tid 27612] 
ssl_engine_init.c(537): AH01893: Configuring TLS extension handling
[Mon Jul 15 23:22:33.215615 2024] [ssl:debug] [pid 27612:tid 27612] 
ssl_util_ssl.c(451): AH02412: [a.mod-tls.test:443] Cert matches for name 
'a.mod-tls.test' [subject: O=tests.httpd.apache.org,CN=a.mod-tls.test / 
issuer: O=tests.httpd.apache.org / serial: 
67FB2E0AAA0B3201399C3332D4729AC1E06C9EF3 / notbefore: Jul 14 22:55:14 
2024 GMT / notafter: Oct 12 22:55:14 2024 GMT]
[Mon Jul 15 23:22:33.215638 2024] [ssl:info] [pid 27612:tid 27612] 
AH02568: Certificate and private key a.mod-tls.test:443:0 configured 
from 
/tmp/esupport-testdir/pytest-worker-330/gen/apache/ca/a.mod-tls.test.rsa4096.cert.pem 
and 
/tmp/esupport-testdir/pytest-worker-330/gen/apache/ca/a.mod-tls.test.rsa4096.pkey.pem
[Mon Jul 15 23:22:33.215950 2024] [ssl:info] [pid 27612:tid 27612] 
AH01914: Configuring server b.mod-tls.test:443 for SSL protocol
[Mon Jul 15 23:22:33.215964 2024] [md:debug] [pid 27612:tid 27612] 
mod_md.c(1130): AH10113: get_certificates called for vhost b.mod-tls.test.
[Mon Jul 15 23:22:33.215972 2024] [md:debug] [pid 27612:tid 27612] 
mod_md.c(1130): AH10113: get_certificates called for vhost b.mod-tls.test.
[Mon Jul 15 23:22:33.216449 2024] [ssl:debug] [pid 27612:tid 27612] 
ssl_engine_init.c(537): AH01893: Configuring TLS extension handling
[Mon Jul 15 23:22:33.216474 2024] [ssl:emerg] [pid 27612:tid 27612] 
AH02572: Failed to configure at least one certificate and key for 
b.mod-tls.test:443
[Mon Jul 15 23:22:33.216507 2024] [ssl:emerg] [pid 27612:tid 27612] SSL 
Library Error: error:1E08010C:DECODER routines::unsupported (No 
supported data to decode. Input type: PEM)
[Mon Jul 15 23:22:33.216521 2024] [ssl:emerg] [pid 27612:tid 27612] SSL 
Library Error: error:0480006C:PEM routines::no start line -- Bad file 
contents or format - or even just a forgotten SSLCertificateKeyFile?
[Mon Jul 15 23:22:33.216534 2024] [ssl:emerg] [pid 27612:tid 27612] SSL 
Library Error: error:0AB1:SSL routines::no certificate assigned
[Mon Jul 15 23:22:33.216540 2024] [ssl:emerg] [pid 27612:tid 27612] 
AH02312: Fatal error initialising mod_ssl, exiting.

AH00016: Configuration Failed

I am not sure, how to repair this, but for now I assume it is just a bug 
in the test (or my setup).


Best regards,

Rainer

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

[Rainer Jung]

Am 15.07.24 um 18:35 schrieb Rainer Jung:

Am 15.07.24 um 14:13 schrieb Eric Covener:

Hi all,

Please find below the proposed release tarball and signatures:

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

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

The computed digests of the tarball up for vte are:
sha256: 3e2404d762a2da03560d7ada379ba1599d32f04a0d70ad6ff86f44325f2f062d
*httpd-2.4.62-rc1.tar.gz
sha512: 
daf66daf1012c6df6266e13a743cabf6ac8b6552b83d3a2db89eb491813ba5acd28e4149e5abe5a03f10677f23b74ae6a319e3c69dd6d223ca8269751960818a

*httpd-2.4.62-rc1.tar.gz

The candidate source is found at
<https://svn.apache.org/repos/asf/httpd/httpd/tags/2.4.62-rc1-candidate>
and at <https://github.com/apache/httpd/tree/2.4.62-rc1-candidate>.


I need to check further, but on my setup the web server does not shut 
down at the end of pytest with event MPM. It is just an early heads up, 
it might also happen for other MPMs and it might be a local problem.


Will report back after investigating later.


It is a bug in the pytest framework, not shutting down the web server 
after each package or at the end of the session. I am testing a fix and 
will commit, hoping it is the right way to do it (additional package 
fixtures).


Best regards,

Rainer

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

[Rainer Jung]

Am 15.07.24 um 14:13 schrieb Eric Covener:

Hi all,

Please find below the proposed release tarball and signatures:

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

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

The computed digests of the tarball up for vte are:
sha256: 3e2404d762a2da03560d7ada379ba1599d32f04a0d70ad6ff86f44325f2f062d
*httpd-2.4.62-rc1.tar.gz
sha512: 
daf66daf1012c6df6266e13a743cabf6ac8b6552b83d3a2db89eb491813ba5acd28e4149e5abe5a03f10677f23b74ae6a319e3c69dd6d223ca8269751960818a
*httpd-2.4.62-rc1.tar.gz

The candidate source is found at

and at .


I need to check further, but on my setup the web server does not shut 
down at the end of pytest with event MPM. It is just an early heads up, 
it might also happen for other MPMs and it might be a local problem.


Will report back after investigating later.

Best regards,

Rainer

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

[Rainer Jung]

Hi all,

file modules/http2/h2_version.h in 2.4.x contains

#define MOD_HTTP2_VERSION "2.0.22"

and

#define MOD_HTTP2_VERSION_NUM 0x020016

which differs from upstream

#define MOD_HTTP2_VERSION "2.0.29-git"

...

#define MOD_HTTP2_VERSION_NUM 0x02001d

quite a bit. I think the version numbers hasn't been updated after 
backporting changes for some time. I don't know, what a good value would 
be, or if it would be better to drop it, but it would be nice, if we 
wouldn't ship an mod_h2 specific but outdated version number.


Thanks and regards,

Rainer

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

[Rainer Jung]

Hi Stefan,

is some of this test stuff ready for 2.4.x?

Thanks and regards,

Rainer

Am 10.07.24 um 12:55 schrieb ic...@apache.org:

Author: icing
Date: Wed Jul 10 10:55:23 2024
New Revision: 1919087

URL: http://svn.apache.org/viewvc?rev=1919087&view=rev
Log:
sync test code with mod-h2

- shutdown server at end of h2 tests
- adapt minimum httpd versions for some tests
- add test_700_20 for load on blocked connections,
   disabled for now until mpm_event improves
- build websocket client automatically


Modified:
 httpd/httpd/trunk/test/modules/http2/conftest.py
 httpd/httpd/trunk/test/modules/http2/env.py
 httpd/httpd/trunk/test/modules/http2/test_103_upgrade.py
 httpd/httpd/trunk/test/modules/http2/test_600_h2proxy.py
 httpd/httpd/trunk/test/modules/http2/test_700_load_get.py
 httpd/httpd/trunk/test/modules/http2/test_800_websockets.py
 httpd/httpd/trunk/test/pyhttpd/env.py

Modified: httpd/httpd/trunk/test/modules/http2/conftest.py
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/test/modules/http2/conftest.py?rev=1919087&r1=1919086&r2=1919087&view=diff
==
--- httpd/httpd/trunk/test/modules/http2/conftest.py (original)
+++ httpd/httpd/trunk/test/modules/http2/conftest.py Wed Jul 10 10:55:23 2024
@@ -35,3 +35,5 @@ def _h2_package_scope(env):
  'AH10400',  # warning that 'enablereuse' has not effect in certain 
configs
  'AH00045',  # child did not exit in time, SIGTERM was sent
  ])
+yield
+assert env.apache_stop() == 0

Modified: httpd/httpd/trunk/test/modules/http2/env.py
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/test/modules/http2/env.py?rev=1919087&r1=1919086&r2=1919087&view=diff
==
--- httpd/httpd/trunk/test/modules/http2/env.py (original)
+++ httpd/httpd/trunk/test/modules/http2/env.py Wed Jul 10 10:55:23 2024
@@ -2,6 +2,7 @@ import inspect
  import logging
  import os
  import subprocess
+from shutil import copyfile
  from typing import Dict, Any
  
  from pyhttpd.certs import CertificateSpec

@@ -52,6 +53,12 @@ class H2TestSetup(HttpdTestSetup):
  with open(os.path.join(self.env.gen_dir, "data-1m"), 'w') as f:
  for i in range(1):
  f.write(f"{i:09d}-{s90}")
+test1_docs = os.path.join(self.env.server_docs_dir, 'test1')
+self.env.mkpath(test1_docs)
+for fname in ["data-1k", "data-10k", "data-100k", "data-1m"]:
+src = os.path.join(self.env.gen_dir, fname)
+dest = os.path.join(test1_docs, fname)
+copyfile(src, dest)
  
  
  class H2TestEnv(HttpdTestEnv):


Modified: httpd/httpd/trunk/test/modules/http2/test_103_upgrade.py
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/test/modules/http2/test_103_upgrade.py?rev=1919087&r1=1919086&r2=1919087&view=diff
==
--- httpd/httpd/trunk/test/modules/http2/test_103_upgrade.py (original)
+++ httpd/httpd/trunk/test/modules/http2/test_103_upgrade.py Wed Jul 10 
10:55:23 2024
@@ -90,6 +90,9 @@ class TestUpgrade:
  url = env.mkurl("http", "test1", "/index.html")
  r = env.nghttp().get(url, options=["-u"])
  assert r.response["status"] == 200
+# check issue #272
+assert 'date' in r.response["header"], f'{r.response}'
+assert r.response["header"]["date"] != 'Sun, 00 Jan 1900 00:00:00 
GMT', f'{r.response}'
  
  # upgrade to h2c for a request where http/1.1 is preferred, but the clients upgrade

  # wish is honored nevertheless

Modified: httpd/httpd/trunk/test/modules/http2/test_600_h2proxy.py
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/test/modules/http2/test_600_h2proxy.py?rev=1919087&r1=1919086&r2=1919087&view=diff
==
--- httpd/httpd/trunk/test/modules/http2/test_600_h2proxy.py (original)
+++ httpd/httpd/trunk/test/modules/http2/test_600_h2proxy.py Wed Jul 10 
10:55:23 2024
@@ -79,7 +79,7 @@ class TestH2Proxy:
  assert env.apache_restart() == 0
  url = env.mkurl("https", "cgi", f"/h2proxy/{env.http_port}/hello.py")
  # httpd 2.5.0 disables reuse, not matter the config
-if enable_reuse == "on" and not env.httpd_is_at_least("2.5.0"):
+if enable_reuse == "on" and not env.httpd_is_at_least("2.4.60"):
  # reuse is not guaranteed for each request, but we expect some
  # to do it and run on a h2 stream id > 1
  reused = False
@@ -132,7 +132,7 @@ class TestH2Proxy:
  assert int(r.json[0]["port"]) == env.http_port
  assert r.response["status"] == 200
  exp_port = env.http_port if enable_reuse == "on" \
-and not env.httpd_is_at_least("2.5.0")\
+and not env.httpd_is_at_le

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

[Rainer Jung]

Am 02.07.24 um 15:29 schrieb Eric Covener:

Hi all,

Please find below the proposed release tarball and signatures:

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

=== Different from template ===
I would like to call an expedited VOTE (due to regression in 2.4.60)
over the next 1-2 days to release this candidate tarball
httpd-2.4.61-rc1 as 2.4.61:

(sorry)
=== end not from a template

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


+1 and many thanks for the hard work of all who contributed to this 
complex release and especially Eric.


Build and tested on RHEL 6, 7, 8 and 9 plus SLES 11, 12 and 15 plus 
Solaris 10 Sparc using OpenSSL 3.1.6.

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

[Rainer Jung]

Am 02.07.24 um 15:29 schrieb Eric Covener:

Hi all,

Please find below the proposed release tarball and signatures:

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


No signatures yet ...

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

[Rainer Jung]

Small correction below (broken URL) ...

Am 02.07.24 um 15:29 schrieb Eric Covener:

Hi all,

Please find below the proposed release tarball and signatures:

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

=== Different from template ===
I would like to call an expedited VOTE (due to regression in 2.4.60)
over the next 1-2 days to release this candidate tarball
httpd-2.4.61-rc1 as 2.4.61:

(sorry)
=== end not from a template

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

The computed digests of the tarball up for vote are:
sha256: ccdc02f78ebf615002dbcab19c8dd9e124b99207b6fed4eecce7562e64c647c9
*httpd-2.4.61-rc1.tar.gz
sha512: 
ad5894ff83f06a8a39bedb26e32a4381ac6806ae0c8624c0dbf631781eb59431cef37af0e459dff0f5618628ed06adbee013a7a714447ed1de4542294e62b885
*httpd-2.4.61-rc1.tar.gz

The candidate source is found at





(strip one "tags")


and at .

Re: svn commit: r1918845 - /httpd/httpd/tags/2.4.61-rc1-candidate/

[Rainer Jung]

Are we missing a CHANGES entry for the ct fixes?

Re: svn commit: r1915618 - /httpd/test/framework/trunk/t/conf/extra.conf.in

[Rainer Jung]

Am 07.02.24 um 11:31 schrieb jor...@apache.org:

Author: jorton
Date: Wed Feb  7 10:31:56 2024
New Revision: 1915618

URL: http://svn.apache.org/viewvc?rev=1915618&view=rev
Log:
Missed in r1915617 - updated test case for PR 64339.

Modified:
 httpd/test/framework/trunk/t/conf/extra.conf.in

Modified: httpd/test/framework/trunk/t/conf/extra.conf.in
URL: 
http://svn.apache.org/viewvc/httpd/test/framework/trunk/t/conf/extra.conf.in?rev=1915618&r1=1915617&r2=1915618&view=diff
==
--- httpd/test/framework/trunk/t/conf/extra.conf.in (original)
+++ httpd/test/framework/trunk/t/conf/extra.conf.in Wed Feb  7 10:31:56 2024
@@ -1518,17 +1518,22 @@ LimitRequestFields32
  
 

- ProxyPass /modules/xml2enc/front 
http://@SERVERNAME@:@PORT@/modules/xml2enc/back
   Alias /modules/xml2enc/back @SERVERROOT@/htdocs/modules/xml2enc
+ Alias /modules/xml2enc/back/iso @SERVERROOT@/htdocs/modules/xml2enc


I get

AH00671: The Alias directive in t/conf/extra.conf at line 1605 will 
probably never match because it overlaps an earlier Alias.


for every unit test run. And it seems the URI with /iso at the end is 
not being used currently? Maybe unfinished work or we might remove the 
additional Alias line?



   
- AddType application/notreallyxml notml
+ AddType application/foo+xml fooxml
+ AddType application/notreallyxml notxml
   AddType application/xml xml
- AddType application/foo+xml foo
+ AddType text/html isohtml
+ AddCharset ISO-8859-1 .isoxml
+ AddCharset ISO-8859-1 .isohtml
   
   
   ProxyHTMLEnable on
   # mod_proxy_html needs some configuration.
- ProxyHTMLURLMap /foo /bar
+ ProxyHTMLURLMap / /blah
+ ProxyHTMLLinks a href
+ ProxyPass http://@SERVERNAME@:@PORT@/modules/xml2enc/back
   

 




Best regards,

Rainer

Re: svn commit: r1918685 - in /httpd/test/framework/trunk/t: conf/proxy.conf.in modules/proxy_fcgi.t

[Rainer Jung]

Am 27.06.24 um 03:15 schrieb Eric Covener:

On Wed, Jun 26, 2024 at 8:59 PM Rainer Jung  wrote:


Am 26.06.24 um 23:31 schrieb cove...@apache.org:

Author: covener
Date: Wed Jun 26 21:31:37 2024
New Revision: 1918685

URL: http://svn.apache.org/viewvc?rev=1918685&view=rev
Log:
use t/logs/ for socket


I ran into path length restrictions for UDS. Other than normal path
lengths, UDS seem to be restricted to 108 chars, at least that's what
internet wisdom claims.

In my setup, I have a lot of library version in my install path and the
socket path gets too long. As a result the web server does not start for
unit tests.

I switched back to a fixed tmp path locally, so not a problem here. In
most cases the 108 chars will suffice.


That's interesting, I wonder if I setup Yann for the same as he hit a
similar limit earlier.  That would make a big % of people running
tests!

Anyone hate the use of /tmp/ here? Otherwise I would just put it back.
AFAICT It is not left around during the normal course of testing.


For me /tmp is fine, since I do not run multiple servers with the unit 
tests in parallel on the same machine. I am not actually sure, whether 
it is possible to run the test suite multiple times in parallel (ports 
etc.). If not, then a fixed /tmp path might be fine. I am not totally 
sure about containers and such though.


Best regards,

Rainer

Re: svn commit: r1918685 - in /httpd/test/framework/trunk/t: conf/proxy.conf.in modules/proxy_fcgi.t

[Rainer Jung]

Am 26.06.24 um 23:31 schrieb cove...@apache.org:

Author: covener
Date: Wed Jun 26 21:31:37 2024
New Revision: 1918685

URL: http://svn.apache.org/viewvc?rev=1918685&view=rev
Log:
use t/logs/ for socket


I ran into path length restrictions for UDS. Other than normal path 
lengths, UDS seem to be restricted to 108 chars, at least that's what 
internet wisdom claims.


In my setup, I have a lot of library version in my install path and the 
socket path gets too long. As a result the web server does not start for 
unit tests.


I switched back to a fixed tmp path locally, so not a problem here. In 
most cases the 108 chars will suffice.


Best regards and many thanks for doing all the complex release work!

Rainer


Modified:
 httpd/test/framework/trunk/t/conf/proxy.conf.in
 httpd/test/framework/trunk/t/modules/proxy_fcgi.t

Modified: httpd/test/framework/trunk/t/conf/proxy.conf.in
URL: 
http://svn.apache.org/viewvc/httpd/test/framework/trunk/t/conf/proxy.conf.in?rev=1918685&r1=1918684&r2=1918685&view=diff
==
--- httpd/test/framework/trunk/t/conf/proxy.conf.in (original)
+++ httpd/test/framework/trunk/t/conf/proxy.conf.in Wed Jun 26 21:31:37 2024
@@ -193,10 +193,10 @@

  
  
-ProxyPass /modules/proxy/fcgi-uds "unix:/tmp/apache-test-builtinfcgi.sock|fcgi://unused"

+ProxyPass /modules/proxy/fcgi-uds 
"unix:@SERVERROOT@/logs/fcgi.sock|fcgi://unused"
  Alias /modules/proxy/fcgi-uds-sethandler 
@SERVERROOT@/htdocs/modules/proxy/fcgi
  
-SetHandler "proxy:unix:/tmp/apache-test-builtinfcgi.sock|fcgi://unused"
+SetHandler "proxy:unix:@SERVERROOT@/logs/fcgi.sock|fcgi://unused"
  
  
  


Modified: httpd/test/framework/trunk/t/modules/proxy_fcgi.t
URL: 
http://svn.apache.org/viewvc/httpd/test/framework/trunk/t/modules/proxy_fcgi.t?rev=1918685&r1=1918684&r2=1918685&view=diff
==
--- httpd/test/framework/trunk/t/modules/proxy_fcgi.t (original)
+++ httpd/test/framework/trunk/t/modules/proxy_fcgi.t Wed Jun 26 21:31:37 2024
@@ -315,7 +315,8 @@ if (have_module('actions')) {
  $envs = run_fcgi_envvar_request($fcgi_port, "/modules/proxy/fcgi/index.php");
  ok t_cmp($envs->{'SCRIPT_NAME'}, '/modules/proxy/fcgi/index.php', "Server sets 
correct SCRIPT_NAME by default");
  
+my $uds_sock = Apache::Test::vars('serverroot')."/logs/fcgi.sock";

  foreach my $url (@udstests) {
-$envs = run_fcgi_envvar_request("/tmp/apache-test-builtinfcgi.sock", 
"$url");
+$envs = run_fcgi_envvar_request($uds_sock, $url);
  ok t_cmp($envs->{'SCRIPT_NAME'}, "$url", "Server sets correct SCRIPT_NAME by 
default");
  }

Re: svn commit: r1918555 - in /httpd/test/framework/trunk/t: htdocs/modules/cgi/action.sh modules/actions.t

[Rainer Jung]

Am 24.06.24 um 19:34 schrieb cove...@apache.org:

Author: covener
Date: Mon Jun 24 17:34:10 2024
New Revision: 1918555

URL: http://svn.apache.org/viewvc?rev=1918555&view=rev
Log:
test for 1918551

Added:
 httpd/test/framework/trunk/t/htdocs/modules/cgi/action.sh   (with props)
Modified:
 httpd/test/framework/trunk/t/modules/actions.t

Added: httpd/test/framework/trunk/t/htdocs/modules/cgi/action.sh
URL: 
http://svn.apache.org/viewvc/httpd/test/framework/trunk/t/htdocs/modules/cgi/action.sh?rev=1918555&view=auto
==
--- httpd/test/framework/trunk/t/htdocs/modules/cgi/action.sh (added)
+++ httpd/test/framework/trunk/t/htdocs/modules/cgi/action.sh Mon Jun 24 
17:34:10 2024
@@ -0,0 +1,18 @@
+#!/bin/sh
+
+CT=$(echo ${QUERY_STRING}|awk -F: '{print $1'})
+LOC=$(echo ${QUERY_STRING}|awk  -F: '{print $2'})
+
+echo Content-type: ${CT}
+echo Location: ${LOC}
+echo
+echo "this is action.sh"
+#!/bin/sh
+
+CT=$(echo ${QUERY_STRING}|awk -F: '{print $1'})
+LOC=$(echo ${QUERY_STRING}|awk  -F: '{print $2'})
+
+echo Content-type: ${CT}
+echo Location: ${LOC}
+echo
+echo "this is action.sh"


Is this a copy and double paste error? The script contents are contained 
twice in the file.


Best regards,

Rainer

Backport worker listener wakeup from trunk?

[Rainer Jung]

Hi there,

Yann implemented an improvement for the listener wakeup when stopping in 
the worker MPM. This was a fix for observed pytest failures, at least on 
RHEL 9.


The change was not yet proposed for backport. I think it would be good 
to propose it, once 2.4.60 is shipped.


The changes are:

- 1916925 (event, preparatory)
- 1916926 (worker)
- 1916929 (comment added)

Best regards,

Rainer

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

[Rainer Jung]

Am 25.06.24 um 08:50 schrieb Ruediger Pluem:



On 6/25/24 1:12 AM, Rainer Jung wrote:

I am getting some pytest failures when checking for assets (leading "/" 
missing):

=== FAILURES ===
__ TestAssets.test_h2_006_03 ___

self = 
env = 

     def test_h2_006_03(self, env):
     # create the tiles files we originally had checked in
     exp_assets = [
     {"status": 200, "size": "10K", "path": "/004.html"},
     {"status": 200, "size": "742", "path": "/004/gophertiles.jpg"},
     ]
     for i in range(2, 181):
     with open(f"{env.server_docs_dir}/test1/004/gophertiles_{i:03d}.jpg", 
"w") as fd:
     fd.write("0123456789\n")
     exp_assets.append(
     {"status": 200, "size": "11", "path": 
f"/004/gophertiles_{i:03d}.jpg"},
     )

     url = env.mkurl("https", "test1", "/004.html")
     r = env.nghttp().assets(url, options=["-Haccept-encoding: none"])
     assert 0 == r.exit_code
     assert 181 == len(r.assets)

    assert r.assets == exp_assets

E   AssertionError: assert [{'path': '/0...s': 200}, ...] == [{'path': 
'/0...s': 200}, ...]
E At index 1 diff: {'path': '004/gophertiles.jpg', 'status': 200, 
'size': '742'} != {'status': 200, 'size': '742', 'path':
'/004/gophertiles.jpg'}
E Full diff:
E   [
E    {'path': '/004.html', 'size': '10K', 'status': 200},
E -  {'path': '/004/gophertiles.jpg', 'size': '742', 'status': 200},
E ?    -
E +  {'path': '004/gophertiles.jpg', 'size': '742', 'status': 200},...
E
E ...Full output truncated (539 lines hidden), use '-vv' to show

modules/http2/test_006_assets.py:52: AssertionError
- Captured stdout call -
execute: nghttp --header=host: test1.tests.httpd.apache.org:5001 
-Haccept-encoding: none -ans https://127.0.0.1:5001//004.html
__ TestAssets.test_h2_006_04 ___

self = 
env = 

     def test_h2_006_04(self, env):
     url = env.mkurl("https", "test1", "/006.html")
     r = env.nghttp().assets(url, options=["-Haccept-encoding: none"])
     assert 0 == r.exit_code
     assert 3 == len(r.assets)

    assert r.assets == [

     {"status": 200, "size": "543", "path": "/006.html"},
     {"status": 200, "size": "216", "path": "/006/006.css"},
     {"status": 200, "size": "839", "path": "/006/006.js"}
     ]
E   AssertionError: assert [{'path': '/0...status': 200}] == [{'path': 
'/0...status': 200}]
E At index 1 diff: {'path': '006/006.css', 'status': 200, 'size': 
'216'} != {'status': 200, 'size': '216', 'path':
'/006/006.css'}
E Full diff:
E   [
E    {'path': '/006.html', 'size': '543', 'status': 200},
E -  {'path': '/006/006.css', 'size': '216', 'status': 200},
E ?    -
E +  {'path': '006/006.css', 'size': '216', 'status': 200},...
E
E ...Full output truncated (5 lines hidden), use '-vv' to show

modules/http2/test_006_assets.py:60: AssertionError
- Captured stdout call -
execute: nghttp --header=host: test1.tests.httpd.apache.org:5001 
-Haccept-encoding: none -ans https://127.0.0.1:5001//006.html
__ TestAssets.test_h2_006_05 ___

self = 
env = 

     def test_h2_006_05(self, env):
     url = env.mkurl("https", "test1", "/003.html")
     r = env.nghttp().assets(url, options=["--window-bits=24", 
"-Haccept-encoding: none"])
     assert 0 == r.exit_code
     assert 2 == len(r.assets)

    assert r.assets == [

     {"status": 200, "size": "316", &qu

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

[Rainer Jung]

Hi Rüdiger et al.,

Am 25.06.24 um 08:50 schrieb Ruediger Pluem:



On 6/25/24 1:12 AM, Rainer Jung wrote:

I am getting some pytest failures when checking for assets (leading "/" 
missing):

=== FAILURES ===
__ TestAssets.test_h2_006_03 ___

self = 
env = 

     def test_h2_006_03(self, env):
     # create the tiles files we originally had checked in
     exp_assets = [
     {"status": 200, "size": "10K", "path": "/004.html"},
     {"status": 200, "size": "742", "path": "/004/gophertiles.jpg"},
     ]
     for i in range(2, 181):
     with open(f"{env.server_docs_dir}/test1/004/gophertiles_{i:03d}.jpg", 
"w") as fd:
     fd.write("0123456789\n")
     exp_assets.append(
     {"status": 200, "size": "11", "path": 
f"/004/gophertiles_{i:03d}.jpg"},
     )

     url = env.mkurl("https", "test1", "/004.html")
     r = env.nghttp().assets(url, options=["-Haccept-encoding: none"])
     assert 0 == r.exit_code
     assert 181 == len(r.assets)

    assert r.assets == exp_assets

E   AssertionError: assert [{'path': '/0...s': 200}, ...] == [{'path': 
'/0...s': 200}, ...]
E At index 1 diff: {'path': '004/gophertiles.jpg', 'status': 200, 
'size': '742'} != {'status': 200, 'size': '742', 'path':
'/004/gophertiles.jpg'}
E Full diff:
E   [
E    {'path': '/004.html', 'size': '10K', 'status': 200},
E -  {'path': '/004/gophertiles.jpg', 'size': '742', 'status': 200},
E ?    -
E +  {'path': '004/gophertiles.jpg', 'size': '742', 'status': 200},...
E
E ...Full output truncated (539 lines hidden), use '-vv' to show

modules/http2/test_006_assets.py:52: AssertionError
- Captured stdout call -
execute: nghttp --header=host: test1.tests.httpd.apache.org:5001 
-Haccept-encoding: none -ans https://127.0.0.1:5001//004.html
__ TestAssets.test_h2_006_04 ___

self = 
env = 

     def test_h2_006_04(self, env):
     url = env.mkurl("https", "test1", "/006.html")
     r = env.nghttp().assets(url, options=["-Haccept-encoding: none"])
     assert 0 == r.exit_code
     assert 3 == len(r.assets)

    assert r.assets == [

     {"status": 200, "size": "543", "path": "/006.html"},
     {"status": 200, "size": "216", "path": "/006/006.css"},
     {"status": 200, "size": "839", "path": "/006/006.js"}
     ]
E   AssertionError: assert [{'path': '/0...status': 200}] == [{'path': 
'/0...status': 200}]
E At index 1 diff: {'path': '006/006.css', 'status': 200, 'size': 
'216'} != {'status': 200, 'size': '216', 'path':
'/006/006.css'}
E Full diff:
E   [
E    {'path': '/006.html', 'size': '543', 'status': 200},
E -  {'path': '/006/006.css', 'size': '216', 'status': 200},
E ?    -
E +  {'path': '006/006.css', 'size': '216', 'status': 200},...
E
E ...Full output truncated (5 lines hidden), use '-vv' to show

modules/http2/test_006_assets.py:60: AssertionError
- Captured stdout call -
execute: nghttp --header=host: test1.tests.httpd.apache.org:5001 
-Haccept-encoding: none -ans https://127.0.0.1:5001//006.html
__ TestAssets.test_h2_006_05 ___

self = 
env = 

     def test_h2_006_05(self, env):
     url = env.mkurl("https", "test1", "/003.html")
     r = env.nghttp().assets(url, options=["--window-bits=24", 
"-Haccept-encoding: none"])
     assert 0 == r.exit_code
     assert 2 == len(r.assets)

    assert r.assets == [

     {"status": 200, "size"

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

[Rainer Jung]

I am getting some pytest failures when checking for assets (leading "/" 
missing):


=== FAILURES 
===
__ TestAssets.test_h2_006_03 
___


self = 
env = 

def test_h2_006_03(self, env):
# create the tiles files we originally had checked in
exp_assets = [
{"status": 200, "size": "10K", "path": "/004.html"},
{"status": 200, "size": "742", "path": "/004/gophertiles.jpg"},
]
for i in range(2, 181):
with 
open(f"{env.server_docs_dir}/test1/004/gophertiles_{i:03d}.jpg", "w") as fd:

fd.write("0123456789\n")
exp_assets.append(
{"status": 200, "size": "11", "path": 
f"/004/gophertiles_{i:03d}.jpg"},

)

url = env.mkurl("https", "test1", "/004.html")
r = env.nghttp().assets(url, options=["-Haccept-encoding: none"])
assert 0 == r.exit_code
assert 181 == len(r.assets)
>   assert r.assets == exp_assets
E   AssertionError: assert [{'path': '/0...s': 200}, ...] == 
[{'path': '/0...s': 200}, ...]
E At index 1 diff: {'path': '004/gophertiles.jpg', 'status': 
200, 'size': '742'} != {'status': 200, 'size': '742', 'path': 
'/004/gophertiles.jpg'}

E Full diff:
E   [
E{'path': '/004.html', 'size': '10K', 'status': 200},
E -  {'path': '/004/gophertiles.jpg', 'size': '742', 'status': 200},
E ?-
E +  {'path': '004/gophertiles.jpg', 'size': '742', 'status': 
200},...

E
E ...Full output truncated (539 lines hidden), use '-vv' to show

modules/http2/test_006_assets.py:52: AssertionError
- Captured stdout call 
-
execute: nghttp --header=host: test1.tests.httpd.apache.org:5001 
-Haccept-encoding: none -ans https://127.0.0.1:5001//004.html
__ TestAssets.test_h2_006_04 
___


self = 
env = 

def test_h2_006_04(self, env):
url = env.mkurl("https", "test1", "/006.html")
r = env.nghttp().assets(url, options=["-Haccept-encoding: none"])
assert 0 == r.exit_code
assert 3 == len(r.assets)
>   assert r.assets == [
{"status": 200, "size": "543", "path": "/006.html"},
{"status": 200, "size": "216", "path": "/006/006.css"},
{"status": 200, "size": "839", "path": "/006/006.js"}
]
E   AssertionError: assert [{'path': '/0...status': 200}] == 
[{'path': '/0...status': 200}]
E At index 1 diff: {'path': '006/006.css', 'status': 200, 
'size': '216'} != {'status': 200, 'size': '216', 'path': '/006/006.css'}

E Full diff:
E   [
E{'path': '/006.html', 'size': '543', 'status': 200},
E -  {'path': '/006/006.css', 'size': '216', 'status': 200},
E ?-
E +  {'path': '006/006.css', 'size': '216', 'status': 200},...
E
E ...Full output truncated (5 lines hidden), use '-vv' to show

modules/http2/test_006_assets.py:60: AssertionError
- Captured stdout call 
-
execute: nghttp --header=host: test1.tests.httpd.apache.org:5001 
-Haccept-encoding: none -ans https://127.0.0.1:5001//006.html
__ TestAssets.test_h2_006_05 
___


self = 
env = 

def test_h2_006_05(self, env):
url = env.mkurl("https", "test1", "/003.html")
r = env.nghttp().assets(url, options=["--window-bits=24", 
"-Haccept-encoding: none"])

assert 0 == r.exit_code
assert 2 == len(r.assets)
>   assert r.assets == [
{"status": 200, "size": "316", "path": "/003.html"},
{"status": 200, "size": "88K", "path": "/003/003_img.jpg"}
]
E   AssertionError: assert [{'path': '/0...status': 200}] == 
[{'path': '/0...status': 200}]
E At index 1 diff: {'path': '003/003_img.jpg', 'status': 200, 
'size': '88K'} != {'status': 200, 'size': '88K', 'path': '/003/003_img.jpg'}

E Full diff:
E   [
E{'path': '/003.html', 'size': '316', 'status': 200},
E -  {'path': '/003/003_img.jpg', 'size': '88K', 'status': 200},
E ?-
E +  {'path': '003/003_img.jpg', 'size': '88K', 'status': 200},...
E
E ...Full output truncated (2 lines hidden), use '-vv' to show

modules/http2/test_006_assets.py:72: AssertionError
- Captured stdout call 
-
execute: nghttp --header=host: test1.tests.httpd.apache.org:5001 
--window-bits=24 -Haccept-encoding: none -ans 
https://127.0.0.1:5001//003.html



These seem to happen consistently.

Currently I don't know, whether it is a problem with the test, or a real 
problem.


If it isn't reproducible for others, I can try to investigate deeper.

Best Regards,

Rainer

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] md_acme_acct.c(3

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&view=rev
Log:
Fix occasional pytest failures
in modules/http2/test_800_websockets.py
(test_h2_800_04_non_ws_resource and
test_h2_800_09b_unsupported) due to
additional RST messages.

Backport of r1916808 from trunk.

Modified:
httpd/httpd/branches/2.4.x/   (props changed)
httpd/httpd/branches/2.4.x/test/modules/http2/test_800_websockets.py

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

Modified: httpd/httpd/branches/2.4.x/test/modules/http2/test_800_websockets.py
URL: 
http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/test/modules/http2/test_800_websockets.py?rev=1916809&r1=1916808&r2=1916809&view=diff
==
--- httpd/httpd/branches/2.4.x/test/modules/http2/test_800_websockets.py 
(original)
+++ httpd/httpd/branches/2.4.x/test/modules/http2/test_800_websockets.py Thu 
Apr  4 22:48:03 2024
@@ -175,7 +175,7 @@ class TestWebSockets:
 def test_h2_800_04_non_ws_resource(self, env: H2TestEnv, ws_server):
 r, infos, frames = ws_run(env, path='/alive.json')
 assert r.exit_code == 0, f'{r}'
-assert infos == ['[1] :status: 502', '[1] EOF'], f'{r}'
+assert infos == ['[1] :status: 502', '[1] EOF'] or infos == ['[1] 
:status: 502', '[1] EOF', '[1] RST'], f'{r}'
 assert frames == b''

 # CONNECT to a URL path that sends a delayed HTTP response body
@@ -215,7 +215,7 @@ class TestWebSockets:
 r, infos, frames = ws_run(env, path='/ws/echo/',
   
authority=f'test1.{env.http_tld}:{env.http_port}')
 assert r.exit_code == 0, f'{r}'
-assert infos == ['[1] :status: 501', '[1] EOF'], f'{r}'
+assert infos == ['[1] :status: 501', '[1] EOF'] or infos == ['[1] 
:status: 501', '[1] EOF', '[1] RST'], f'{r}'

 # CONNECT and exchange a PING
 def test_h2_800_10_ws_ping(self, env: H2TestEnv, ws_server):

Re: 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] [pid

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
mod

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&view=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&r1=1913009&r2=1913010&view=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&r1=1913009&r2=1913010&view=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&view=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&r1=1909605&r2=1909606&view=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: cgi.tests.httpd.apache.org:5

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&view=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&r1=1902116&r2=1902117&view=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&r1=1901513&r2=1901514&view=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&view=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&view=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&r1=1897857&r2=1897858&view=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&r1=1893976&r2=1893977&view=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 te

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 to

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

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

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]