Planning to RM around June 21

[Eric Covener]

Please make sure your backport proposals/votes are in.

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

Json support for httpd log

[Thomas Meyer]

Hi,

Anything I can do to get this pr reviewed and merged?

https://github.com/apache/httpd/pull/429

Feedback is most welcome.


Mfg
Thomas

Bug report for Apache httpd-2 [2024/06/02]

[bugzilla]

+---+
| Bugzilla Bug ID   |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned|
| | OPN=ReopenedVER=Verified(Skipped Closed/Resolved)   |
| |   +-+
| |   | Severity: BLK=Blocker CRI=Critical  REG=Regression  MAJ=Major   |
| |   |   MIN=Minor   NOR=NormalENH=Enhancement TRV=Trivial |
| |   |   +-+
| |   |   | Date Posted |
| |   |   |  +--+
| |   |   |  | Description  |
| |   |   |  |  |
|10747|New|Maj|2002-07-12|ftp SIZE command and 'smart' ftp servers results i|
|11580|Opn|Enh|2002-08-09|generate Content-Location headers |
|12033|Opn|Nor|2002-08-26|Graceful restart immediately result in [warn] long|
|13661|Ass|Enh|2002-10-15|Apache cannot not handle dynamic IP reallocation  |
|14104|Opn|Enh|2002-10-30|not documented: must restart server to load new CR|
|16811|Ass|Maj|2003-02-05|mod_autoindex always return webpages in UTF-8.|
|17244|Ass|Nor|2003-02-20|./configure --help gives false information regardi|
|17497|Opn|Nor|2003-02-27|mod_mime_magic generates incorrect response header|
|20036|Ass|Nor|2003-05-19|Trailing Dots stripped from PATH_INFO environment |
|21260|Opn|Nor|2003-07-02|CacheMaxExpire directive not enforced !   |
|21533|Ass|Cri|2003-07-11|Multiple levels of htacces files can cause mod_aut|
|22484|Opn|Maj|2003-08-16|semaphore problem takes httpd down|
|22686|Opn|Nor|2003-08-25|ab: apr_poll: The timeout specified has expired (7|
|22898|Opn|Nor|2003-09-02|nph scripts with two HTTP header  |
|23911|Opn|Cri|2003-10-18|CGI processes left defunct/zombie under 2.0.54|
|24095|Opn|Cri|2003-10-24|ERROR "Parent: child process exited with status 32|
|24437|Opn|Nor|2003-11-05|mod_auth_ldap doubly-escapes backslash (\) charact|
|24890|Opn|Nor|2003-11-21|Apache config parser should not be local aware ( g|
|25469|Opn|Enh|2003-12-12|create AuthRoot for defining paths to auth files  |
|25484|Ass|Nor|2003-12-12|Non-service Apache cannot be stopped in WinXP |
|26153|Opn|Cri|2004-01-15|Apache cygwin directory traversal vulnerability   |
|27257|Ass|Enh|2004-02-26|rotatelogs with getopt and setuid |
|29090|Ass|Enh|2004-05-19|MultiviewsMatch NegotiatedOnly extensions not resp|
|29510|Ass|Enh|2004-06-10|ab does not support multiple cookies  |
|29644|Ver|Nor|2004-06-17|mod_proxy keeps downloading even after the client |
|30259|Ass|Enh|2004-07-22|When proxy connects to backend, a DNS lookup is do|
|30505|Ass|Enh|2004-08-05|Apache uses 'Error', and not lower level event typ|
|31302|Opn|Cri|2004-09-19|suexec doesn't execute commands if they're not in |
|31352|Ass|Enh|2004-09-21|RFE, Bind to LDAP server with browser supplier use|
|31418|Opn|Nor|2004-09-25|SSLUserName is not usable by other modules|
|32328|Opn|Enh|2004-11-19|Make mod_rewrite escaping optional / expose intern|
|32750|Ass|Maj|2004-12-17|mod_proxy + Win32DisableAcceptEx = memory leak|
|33089|New|Nor|2005-01-13|mod_include: Options +Includes (or IncludesNoExec)|
|34519|New|Enh|2005-04-19|Directory index should emit valid XHTML   |
|35098|Ver|Maj|2005-05-27|Install fails using --prefix  |
|35154|Opn|Nor|2005-06-01|Support for NID_serialNumber, etc. in SSLUserName |
|35652|Opn|Min|2005-07-07|Improve error message: "pcfg_openfile: unable to c|
|35768|Opn|Nor|2005-07-17|Missing file logs at far too high of log level|
|36676|New|Nor|2005-09-15|time() bug in httpd/os/win32/util_win32.c:wait_for|
|36710|Opn|Blk|2005-09-19|CGI output not captured   |
|37006|Ver|Reg|2005-10-11|"pthread" error when compiling under AIX 5.3 using|
|37290|Opn|Min|2005-10-28|DirectoryIndex don't work in scriptaliased directo|
|37564|New|Enh|2005-11-19|Suggestion: mod_suexec SuexecUserGroup directive i|
|38325|Opn|Nor|2006-01-20|impossible to determine AUTH_TYPE of interpreted r|
|38571|New|Enh|2006-02-08|CustomLog directive checked by apachectl configtes|
|38995|New|Nor|2006-03-16|httpd tries to communicate with the CGI daemon eve|
|39275|Opn|Nor|2006-04-11|slow child_init causes MaxClients warning |
|39287|New|Nor|2006-04-12|Incorrect If-Modified-Since validation (due to syn|
|39727|Ass|Nor|2006-06-05|Incorrect ETag on gzip:ed content |
|39748|New|Enh|2006-06-07|Header and POST support for mod_include   |
|39807|Opn|Enh|2006-06-13|large files / filesystem corruption can cause apac|

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

[Yann Ylavic]

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

Backport PR in https://github.com/apache/httpd/pull/449 ;)


Regards;
Yann.

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

[Stefan Eissing via dev]

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

Great!

> 
> Regards;
> Yann.

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

[Yann Ylavic]

On Tue, May 28, 2024 at 12:47 PM Stefan Eissing via dev
 wrote:
>
> > Am 27.05.2024 um 14:08 schrieb Yann Ylavic :
> >
> > Per our discussion the other day, if you want to avoid c1 connections
> > to be killed by mpm_event on high load in this case, I think you can
> > do this here:
> >
> > Index: modules/http2/h2_c1.c
> > ===
> > --- modules/http2/h2_c1.c(revision 1918003)
> > +++ modules/http2/h2_c1.c(working copy)
> > @@ -147,6 +147,7 @@ apr_status_t h2_c1_run(conn_rec *c)
> >  && mpm_state != AP_MPMQ_STOPPING);
> >
> > if (c->cs) {
> > +c->clogging_input_filters = 0;
> > switch (conn_ctx->session->state) {
> > case H2_SESSION_ST_INIT:
> > case H2_SESSION_ST_IDLE:
> > @@ -159,6 +160,7 @@ apr_status_t h2_c1_run(conn_rec *c)
> >  * See PR 63534.
> >  */
> > c->cs->sense = CONN_SENSE_WANT_READ;
> > +c->clogging_input_filters = 1;
> > 03465}
> > break;
> > case H2_SESSION_ST_CLEANUP:
> > --
> >
> > c->clogging_input_filters = 1 will tell the MPM to always call
> > process_connection() hooks after the WRITE_COMPLETION state did the
> > poll(), rather than entering the (killable) keepalive state.
> >
> > Looks like the correct workaround with current mpm_event..
>
> Just so I get this right. It will return to processing after the
> write is done or after a POLLIN happened? In the first case, it
> will not have really a positive effect on worker allocations,
> seems to me.

Yes, it will return to processing after POLLIN happens thanks to
CONN_SENSE_WANT_READ, even if there are pending output data.
But it's a really convoluted handling of POLLIN/POLLOUT in mpm_event,
with the need of that obscure c->clogging_input_filters..
So I just created https://github.com/apache/httpd/pull/448 to do that
better (and it includes the changes to h2_c1_run() too).
The plan could be to merge that to trunk and include it in your
backport proposal (if it works for you)?


Regards;
Yann.

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

[Stefan Eissing via dev]

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

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

Cheers,
Stefan
> 
> 
> Regards;
> Yann.

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

[Yann Ylavic]

On Mon, May 27, 2024 at 1:04 PM  wrote:
>
> Author: icing
> Date: Mon May 27 11:04:52 2024
> New Revision: 1918003
>
> URL: http://svn.apache.org/viewvc?rev=1918003=rev
> Log:
>  *) mod_http2: sync with module's github.
> - on newer HTTPD versions, return connection monitoring
>   to the event MPM when block on client updates.
>   2.4.x versions still treat connections in the event
>   MPM as KeepAlive and purge them on load in the middle
>   of response processing.
> - spelling fixes
> - support for yield calls in c2 "network" filter
[]
>
> --- httpd/httpd/trunk/modules/http2/h2_c1.c (original)
> +++ httpd/httpd/trunk/modules/http2/h2_c1.c Mon May 27 11:04:52 2024
> @@ -116,7 +116,7 @@ cleanup:
>  apr_status_t h2_c1_run(conn_rec *c)
>  {
>  apr_status_t status;
> -int mpm_state = 0;
> +int mpm_state = 0, keepalive = 0;
>  h2_conn_ctx_t *conn_ctx = h2_conn_ctx_get(c);
>
>  ap_assert(conn_ctx);
> @@ -127,7 +127,7 @@ apr_status_t h2_c1_run(conn_rec *c)
>  c->cs->state = CONN_STATE_HANDLER;
>  }
>
> -status = h2_session_process(conn_ctx->session, async_mpm);
> +status = h2_session_process(conn_ctx->session, async_mpm, 
> );
>
>  if (APR_STATUS_IS_EOF(status)) {
>  ap_log_cerror(APLOG_MARK, APLOG_DEBUG, status, c,
> @@ -153,7 +153,7 @@ apr_status_t h2_c1_run(conn_rec *c)
>  case H2_SESSION_ST_BUSY:
>  case H2_SESSION_ST_WAIT:
>  c->cs->state = CONN_STATE_WRITE_COMPLETION;
> -if (c->cs && !conn_ctx->session->remote.emitted_count) {
> +if (!keepalive) {
>  /* let the MPM know that we are not done and want
>   * the Timeout behaviour instead of a KeepAliveTimeout
>   * See PR 63534.

Per our discussion the other day, if you want to avoid c1 connections
to be killed by mpm_event on high load in this case, I think you can
do this here:

Index: modules/http2/h2_c1.c
===
--- modules/http2/h2_c1.c(revision 1918003)
+++ modules/http2/h2_c1.c(working copy)
@@ -147,6 +147,7 @@ apr_status_t h2_c1_run(conn_rec *c)
  && mpm_state != AP_MPMQ_STOPPING);

 if (c->cs) {
+c->clogging_input_filters = 0;
 switch (conn_ctx->session->state) {
 case H2_SESSION_ST_INIT:
 case H2_SESSION_ST_IDLE:
@@ -159,6 +160,7 @@ apr_status_t h2_c1_run(conn_rec *c)
  * See PR 63534.
  */
 c->cs->sense = CONN_SENSE_WANT_READ;
+c->clogging_input_filters = 1;
 }
 break;
 case H2_SESSION_ST_CLEANUP:
--

c->clogging_input_filters = 1 will tell the MPM to always call
process_connection() hooks after the WRITE_COMPLETION state did the
poll(), rather than entering the (killable) keepalive state.

Looks like the correct workaround with current mpm_event..


Regards;
Yann.

Bug report for Apache httpd-2 [2024/05/26]

[bugzilla]

+---+
| Bugzilla Bug ID   |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned|
| | OPN=ReopenedVER=Verified(Skipped Closed/Resolved)   |
| |   +-+
| |   | Severity: BLK=Blocker CRI=Critical  REG=Regression  MAJ=Major   |
| |   |   MIN=Minor   NOR=NormalENH=Enhancement TRV=Trivial |
| |   |   +-+
| |   |   | Date Posted |
| |   |   |  +--+
| |   |   |  | Description  |
| |   |   |  |  |
|10747|New|Maj|2002-07-12|ftp SIZE command and 'smart' ftp servers results i|
|11580|Opn|Enh|2002-08-09|generate Content-Location headers |
|12033|Opn|Nor|2002-08-26|Graceful restart immediately result in [warn] long|
|13661|Ass|Enh|2002-10-15|Apache cannot not handle dynamic IP reallocation  |
|14104|Opn|Enh|2002-10-30|not documented: must restart server to load new CR|
|16811|Ass|Maj|2003-02-05|mod_autoindex always return webpages in UTF-8.|
|17244|Ass|Nor|2003-02-20|./configure --help gives false information regardi|
|17497|Opn|Nor|2003-02-27|mod_mime_magic generates incorrect response header|
|20036|Ass|Nor|2003-05-19|Trailing Dots stripped from PATH_INFO environment |
|21260|Opn|Nor|2003-07-02|CacheMaxExpire directive not enforced !   |
|21533|Ass|Cri|2003-07-11|Multiple levels of htacces files can cause mod_aut|
|22484|Opn|Maj|2003-08-16|semaphore problem takes httpd down|
|22686|Opn|Nor|2003-08-25|ab: apr_poll: The timeout specified has expired (7|
|22898|Opn|Nor|2003-09-02|nph scripts with two HTTP header  |
|23911|Opn|Cri|2003-10-18|CGI processes left defunct/zombie under 2.0.54|
|24095|Opn|Cri|2003-10-24|ERROR "Parent: child process exited with status 32|
|24437|Opn|Nor|2003-11-05|mod_auth_ldap doubly-escapes backslash (\) charact|
|24890|Opn|Nor|2003-11-21|Apache config parser should not be local aware ( g|
|25469|Opn|Enh|2003-12-12|create AuthRoot for defining paths to auth files  |
|25484|Ass|Nor|2003-12-12|Non-service Apache cannot be stopped in WinXP |
|26153|Opn|Cri|2004-01-15|Apache cygwin directory traversal vulnerability   |
|27257|Ass|Enh|2004-02-26|rotatelogs with getopt and setuid |
|27715|Ass|Enh|2004-03-16|Client sending misformed Range "bytes = 0-100" ins|
|29090|Ass|Enh|2004-05-19|MultiviewsMatch NegotiatedOnly extensions not resp|
|29510|Ass|Enh|2004-06-10|ab does not support multiple cookies  |
|29644|Ver|Nor|2004-06-17|mod_proxy keeps downloading even after the client |
|30259|Ass|Enh|2004-07-22|When proxy connects to backend, a DNS lookup is do|
|30505|Ass|Enh|2004-08-05|Apache uses 'Error', and not lower level event typ|
|31302|Opn|Cri|2004-09-19|suexec doesn't execute commands if they're not in |
|31352|Ass|Enh|2004-09-21|RFE, Bind to LDAP server with browser supplier use|
|31418|Opn|Nor|2004-09-25|SSLUserName is not usable by other modules|
|32328|Opn|Enh|2004-11-19|Make mod_rewrite escaping optional / expose intern|
|32750|Ass|Maj|2004-12-17|mod_proxy + Win32DisableAcceptEx = memory leak|
|33089|New|Nor|2005-01-13|mod_include: Options +Includes (or IncludesNoExec)|
|34519|New|Enh|2005-04-19|Directory index should emit valid XHTML   |
|35098|Ver|Maj|2005-05-27|Install fails using --prefix  |
|35154|Opn|Nor|2005-06-01|Support for NID_serialNumber, etc. in SSLUserName |
|35652|Opn|Min|2005-07-07|Improve error message: "pcfg_openfile: unable to c|
|35768|Opn|Nor|2005-07-17|Missing file logs at far too high of log level|
|36676|New|Nor|2005-09-15|time() bug in httpd/os/win32/util_win32.c:wait_for|
|36710|Opn|Blk|2005-09-19|CGI output not captured   |
|37006|Ver|Reg|2005-10-11|"pthread" error when compiling under AIX 5.3 using|
|37290|Opn|Min|2005-10-28|DirectoryIndex don't work in scriptaliased directo|
|37564|New|Enh|2005-11-19|Suggestion: mod_suexec SuexecUserGroup directive i|
|38325|Opn|Nor|2006-01-20|impossible to determine AUTH_TYPE of interpreted r|
|38571|New|Enh|2006-02-08|CustomLog directive checked by apachectl configtes|
|38995|New|Nor|2006-03-16|httpd tries to communicate with the CGI daemon eve|
|39275|Opn|Nor|2006-04-11|slow child_init causes MaxClients warning |
|39287|New|Nor|2006-04-12|Incorrect If-Modified-Since validation (due to syn|
|39727|Ass|Nor|2006-06-05|Incorrect ETag on gzip:ed content |
|39748|New|Enh|2006-06-07|Header and POST support for mod_include   |

Bug report for Apache httpd-2 [2024/05/19]

[bugzilla]

+---+
| Bugzilla Bug ID   |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned|
| | OPN=ReopenedVER=Verified(Skipped Closed/Resolved)   |
| |   +-+
| |   | Severity: BLK=Blocker CRI=Critical  REG=Regression  MAJ=Major   |
| |   |   MIN=Minor   NOR=NormalENH=Enhancement TRV=Trivial |
| |   |   +-+
| |   |   | Date Posted |
| |   |   |  +--+
| |   |   |  | Description  |
| |   |   |  |  |
|10747|New|Maj|2002-07-12|ftp SIZE command and 'smart' ftp servers results i|
|11580|Opn|Enh|2002-08-09|generate Content-Location headers |
|12033|Opn|Nor|2002-08-26|Graceful restart immediately result in [warn] long|
|13661|Ass|Enh|2002-10-15|Apache cannot not handle dynamic IP reallocation  |
|14104|Opn|Enh|2002-10-30|not documented: must restart server to load new CR|
|16811|Ass|Maj|2003-02-05|mod_autoindex always return webpages in UTF-8.|
|17244|Ass|Nor|2003-02-20|./configure --help gives false information regardi|
|17497|Opn|Nor|2003-02-27|mod_mime_magic generates incorrect response header|
|20036|Ass|Nor|2003-05-19|Trailing Dots stripped from PATH_INFO environment |
|21260|Opn|Nor|2003-07-02|CacheMaxExpire directive not enforced !   |
|21533|Ass|Cri|2003-07-11|Multiple levels of htacces files can cause mod_aut|
|22484|Opn|Maj|2003-08-16|semaphore problem takes httpd down|
|22686|Opn|Nor|2003-08-25|ab: apr_poll: The timeout specified has expired (7|
|22898|Opn|Nor|2003-09-02|nph scripts with two HTTP header  |
|23911|Opn|Cri|2003-10-18|CGI processes left defunct/zombie under 2.0.54|
|24095|Opn|Cri|2003-10-24|ERROR "Parent: child process exited with status 32|
|24437|Opn|Nor|2003-11-05|mod_auth_ldap doubly-escapes backslash (\) charact|
|24890|Opn|Nor|2003-11-21|Apache config parser should not be local aware ( g|
|25469|Opn|Enh|2003-12-12|create AuthRoot for defining paths to auth files  |
|25484|Ass|Nor|2003-12-12|Non-service Apache cannot be stopped in WinXP |
|26153|Opn|Cri|2004-01-15|Apache cygwin directory traversal vulnerability   |
|27257|Ass|Enh|2004-02-26|rotatelogs with getopt and setuid |
|27715|Ass|Enh|2004-03-16|Client sending misformed Range "bytes = 0-100" ins|
|29090|Ass|Enh|2004-05-19|MultiviewsMatch NegotiatedOnly extensions not resp|
|29510|Ass|Enh|2004-06-10|ab does not support multiple cookies  |
|29644|Ver|Nor|2004-06-17|mod_proxy keeps downloading even after the client |
|30259|Ass|Enh|2004-07-22|When proxy connects to backend, a DNS lookup is do|
|30505|Ass|Enh|2004-08-05|Apache uses 'Error', and not lower level event typ|
|31302|Opn|Cri|2004-09-19|suexec doesn't execute commands if they're not in |
|31352|Ass|Enh|2004-09-21|RFE, Bind to LDAP server with browser supplier use|
|31418|Opn|Nor|2004-09-25|SSLUserName is not usable by other modules|
|32328|Opn|Enh|2004-11-19|Make mod_rewrite escaping optional / expose intern|
|32750|Ass|Maj|2004-12-17|mod_proxy + Win32DisableAcceptEx = memory leak|
|33089|New|Nor|2005-01-13|mod_include: Options +Includes (or IncludesNoExec)|
|34519|New|Enh|2005-04-19|Directory index should emit valid XHTML   |
|35098|Ver|Maj|2005-05-27|Install fails using --prefix  |
|35154|Opn|Nor|2005-06-01|Support for NID_serialNumber, etc. in SSLUserName |
|35652|Opn|Min|2005-07-07|Improve error message: "pcfg_openfile: unable to c|
|35768|Opn|Nor|2005-07-17|Missing file logs at far too high of log level|
|36676|New|Nor|2005-09-15|time() bug in httpd/os/win32/util_win32.c:wait_for|
|36710|Opn|Blk|2005-09-19|CGI output not captured   |
|37006|Ver|Reg|2005-10-11|"pthread" error when compiling under AIX 5.3 using|
|37290|Opn|Min|2005-10-28|DirectoryIndex don't work in scriptaliased directo|
|37564|New|Enh|2005-11-19|Suggestion: mod_suexec SuexecUserGroup directive i|
|38325|Opn|Nor|2006-01-20|impossible to determine AUTH_TYPE of interpreted r|
|38571|New|Enh|2006-02-08|CustomLog directive checked by apachectl configtes|
|38995|New|Nor|2006-03-16|httpd tries to communicate with the CGI daemon eve|
|39275|Opn|Nor|2006-04-11|slow child_init causes MaxClients warning |
|39287|New|Nor|2006-04-12|Incorrect If-Modified-Since validation (due to syn|
|39727|Ass|Nor|2006-06-05|Incorrect ETag on gzip:ed content |
|39748|New|Enh|2006-06-07|Header and POST support for mod_include   |

Re: [PR] Modernize HTTPD website [httpd-site]

[via GitHub]

RedYetiDev closed pull request #12: Modernize HTTPD website
URL: https://github.com/apache/httpd-site/pull/12


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@httpd.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: more async handling in mod_h2

[Yann Ylavic]

On Tue, May 14, 2024 at 12:21 PM Stefan Eissing via dev
 wrote:
>
> Tried your PR and it works nicely without any changes to current mod_h2.

Great, thanks for testing!

With the current mod_h2 I think the connections returned to mpm_event
use the KeepAliveTimeout rather than Timeout. Enough for the
WINDOW_UPDATE to arrive in your tests maybe if keepalive connections
don't get killed early by the MPM like in httpd-trunk?

>
> Made a test with `StartServers 1` opening 300 HTTP/2 connections and a
> 1KB connection window size. This means writing responses very frequently
> stalls on flow control and returns to the MPM.
>
> With plain trunk, this fails with connections being closed early. With
> PR 294 all are successful, even when throttling `MaxRequestWorkers 25`.

Yeah, the new queuing mechanism (fully nonblocking) and
connections_above_limit() heuristics in PR 294 allow for much better
scheduling with less threads from my testing (not potentially blocking
scenarios obviously).
There is even an "MaxRequestWorkers N auto" which automa[tg]ically
sets ThreadsPerChild to the number of CPUs and the rest accordingly
(Min/MaxSpareThreads, ...) for the N expected concurrent connections.
>From my testing still it seems to behave better than trunk (even with
the usual/more ThreadsPerChild there). Supposedly these heuristics and
auto settings can be improved/fixed from others' thoughts, I'm all
ears ;)

>
> Adding your proposed changes to h2_c1.c also works. Published as 
> https://github.com/icing/mod_h2/pull/281

I think this is what you want (i.e. use Timeout), while with a
min_connection_timeout() hook you could fine-grain that timeout per
h2_c1 state too if it makes sense (see reqtimeout_min_timeout() and
how CONN_STATE_PROCESS uses ap_get_connection_timeout() in mpm_event
to apply any module's min timeout of the moment eventually).

Sorry it sounds a bit like I'm trying to sell my whole PR again :)
Let me see how I can stage to trunk what's useful and meaningful
there, mod_h2 looks like a good candidate to test it after all :p

Also (or as a further note), if for anything early/full connection
level handling (like mod_ssl handshake or mod_h2 c1) the
CONN_STATE_PROCESS/AGAIN mechanism seems usable, I can't find how for
a request handler for instance we could return AGAIN, we'd need to
handle that at too many levels (everything in the call chain would
need to be adapted to recover from the process_connection hook, if
ever possible..).
So like in mod_proxy_wstunnel (or the fallback to mod_proxy_http) and
what happens already in trunk for an upgraded websocket connection,
an/my (medium/long term) plan is for mod_proxy_http's normal HTTP
traffic which would block (either on the client or backend side) to
return to the MPM by maintaining a mod_proxy internal state and using
the ap_mpm_register_poll_callback_timeout()/SUSPENDED mechanism.
Not sure how it'd work/behave for mod_h2's c2_process() though, it
would get ap_process_request() == SUSPENDED meaning that either/both
of the client/beam/pipe or the backend connection are being polled by
the MPM already, and when some event is available on either/both side
it's mod_proxy_http's callback which will be called again to continue
its read/write/forwarding work.
I think the h2 workers are not needed anymore in this scenario, but
how would mod_h2 know that h1 processing is going to be fully async?
Looks like it can't for all httpd configurations (and third party
modules), so the h2 workers would still be there but be prepared to be
SUSPENDED too (i.e. when the MPM calls back mod_proxy_http after
poll()ing it will be from a MPM worker thread, not an h2 worker)?

Well, enough (whishful?) thoughts for tonight (-_-)


Cheers;
Yann.

Community over Code EU 2024: The countdown has started!

[Ryan Skraba]

[Note: You're receiving this email because you are subscribed to one
or more project dev@ mailing lists at the Apache Software Foundation.]

We are very close to Community Over Code EU -- check out the amazing
program and the special discounts that we have for you.

Special discounts

You still have the opportunity to secure your ticket for Community
Over Code EU. Explore the various options available, including the
regular pass, the committer and groups pass, and now introducing the
one-day pass tailored for locals in Bratislava.

We also have a special discount for you to attend both Community Over
Code and Berlin Buzzwords from June 9th to 11th. Visit our website to
find out more about this opportunity and contact te...@sg.com.mx to
get the discount code.

Take advantage of the discounts and register now!
https://eu.communityovercode.org/tickets/

Check out the full program!

This year Community Over Code Europe will bring to you three days of
keynotes and sessions that cover topics of interest for ASF projects
and the greater open source ecosystem including data engineering,
performance engineering, search, Internet of Things (IoT) as well as
sessions with tips and lessons learned on building a healthy open
source community.

Check out the program: https://eu.communityovercode.org/program/

Keynote speaker highlights for Community Over Code Europe include:

* Dirk-Willem Van Gulik, VP of Public Policy at the Apache Software
Foundation, will discuss the Cyber Resiliency Act and its impact on
open source (All your code belongs to Policy Makers, Politicians, and
the Law).

* Dr. Sherae Daniel will share the results of her study on the impact
of self-promotion for open source software developers (To Toot or not
to Toot, that is the question).

* Asim Hussain, Executive Director of the Green Software Foundation
will present a framework they have developed for quantifying the
environmental impact of software (Doing for Sustainability what Open
Source did for Software).

* Ruth Ikegah will  discuss the growth of the open source movement in
Africa (From Local Roots to Global Impact: Building an Inclusive Open
Source Community in Africa)

* A discussion panel on EU policies and regulations affecting
specialists working in Open Source Program Offices

Additional activities

* Poster sessions: We invite you to stop by our poster area and see if
the ideas presented ignite a conversation within your team.

* BOF time: Don't miss the opportunity to discuss in person with your
open source colleagues on your shared interests.

* Participants reception: At the end of the first day, we will have a
reception at the event venue. All participants are welcome to attend!

* Spontaneous talks: There is a dedicated room and social space for
having spontaneous talks and sessions. Get ready to share with your
peers.

* Lighting talks: At the end of the event we will have the awaited
Lighting talks, where every participant is welcome to share and
enlighten us.

Please remember:  If you haven't applied for the visa, we will provide
the necessary letter for the process. In the unfortunate case of a
visa rejection, your ticket will be reimbursed.

See you in Bratislava,

Community Over Code EU Team

Re: more async handling in mod_h2

[Stefan Eissing via dev]

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

Tried your PR and it works nicely without any changes to current mod_h2.

Made a test with `StartServers 1` opening 300 HTTP/2 connections and a 
1KB connection window size. This means writing responses very frequently
stalls on flow control and returns to the MPM.

With plain trunk, this fails with connections being closed early. With
PR 294 all are successful, even when throttling `MaxRequestWorkers 25`.

Adding your proposed changes to h2_c1.c also works. Published as 
https://github.com/icing/mod_h2/pull/281

This looks nice.

Cheers, Stefan

>> 
>> Could you try running your mod_h2 changes on top of it and with
>> h2_c1_run() doing something like:
>>c->cs->state = CONN_STATE_PROCESS;
>>c->cs->state = CONN_SENSE_WANT_READ; /* or _WRITE */
> 
> This should be c->cs->sense = CONN_SENSE_WANT_READ of 

Re: more async handling in mod_h2

[Yann Ylavic]

On Mon, May 13, 2024 at 9:02 PM Yann Ylavic  wrote:
>
> On Mon, May 13, 2024 at 6:31 PM Stefan Eissing  wrote:
> >
> > > Am 13.05.2024 um 17:41 schrieb Yann Ylavic :
> > >
> > > On Mon, May 13, 2024 at 1:32 PM Stefan Eissing
> > >>
> > >> With the change in PR 280, we return on being flow blocked. The 
> > >> response(s) are *not* finished. If MPM now closes such a connection 
> > >> under load, the client will most likely try again. This seems counter 
> > >> productive.
> > >
> > > AFAICT the CONN_STATE_WRITE_COMPLETION state is different depending on
> > > CONN_SENSE_WANT_READ and CONN_SENSE_WANT_WRITE/DEFAULT.
> > > With CONN_SENSE_WANT_WRITE/DEFAULT, mpm_event will indeed assume flush
> > > (nonblocking) before close,
>
> It's actually a flush before *keepalive* (unless !AP_CONN_KEEPALIVE),
> though it's not what you want anyway.
>
> > > but with CONN_SENSE_WANT_READ it will poll
> > > for read on the connection and come back to the process_connection
> > > hooks when something is in.
> > >
> > > When mod_h2 waits for some WINDOW_UPDATE it wants the MPM to POLLIN
> > > (right?), h2_c1_hook_process_connection() should recover/continue with
> > > the new data from the client. And since it's a c1 connection I don't
> > > think there needs to be some new pollset/queues sizing adjustment to
> > > do either, so we should be good?
> >
> > Yes, mod_h2 does CONN_STATE_WRITE_COMPLETION and CONN_SENSE_WANT_READ and 
> > it works nicely. The only thing is that, when I open many connections, 
> > unfinished ones get dropped very fast. Like after a few milliseconds.
>
> What do you mean by unfinished ones, which state are they in (i.e. how
> do they end up in the MPM with a keepalive state which is the only one
> where connections are "early" killed under high load)?
> I think this can only happen when mpm_event gets a connection with
> c->cs->state == CONN_STATE_WRITE_COMPLETION but c->cs->sense !=
> CONN_SENSE_WANT_READ, is that a mod_h2 possible thing?

Hm, I think I figured this out by myself.
As I said above CONN_STATE_WRITE_COMPLETION leads to
CONN_STATE_CHECK_REQUEST_LINE_READABLE (i.e keepalive state) once the
completion is done (or the POLLIN with c->cs->sense ==
CONN_SENSE_WANT_READ) and if there is no input data already pending.
This is really not what mod_h2 wants but rather
ap_run_process_connection() to always be called after POLLIN.
We could handle that specifically for the CONN_SENSE_WANT_READ case
but it's yet more abuse of CONN_STATE_WRITE_COMPLETION imho.
Let's see how CONN_STATE_PROCESS (from PR 294 below) works to take the
relevant bits in trunk eventually.

>
> > >>
> > >> Therefore I am hesitant if this change is beneficial for us. It frees up 
> > >> a worker thread - that is good - but. Do we need a new "connection 
> > >> state" here?
> > >>
> > >> WDYT?
> > >
> > > I think the semantics of CONN_STATE_WRITE_COMPLETION with
> > > CONN_SENSE_WANT_* are quite unintuitive (for the least), so we
> > > probably should have different states for CONN_STATE_WRITE_COMPLETION
> > > (flush before close) and CONN_STATE_POLL_READ/POLL_WRITE/POLL_RW which
> > > would be how a process_connection hook would return to the MPM just
> > > for poll()ing.
> >
> > I think that would be excellent, yes. Trigger polling with the connection 
> > Timeout value.
>
> There is https://github.com/apache/httpd/pull/294 with quite some
> changes to mpm_event. Sorry this is still WIP and needs to be split
> more, probably in multiple PRs too, but it works for the tests I've
> done so far (I just rebased it on latest trunk).
> This change starts with Graham's AGAIN return code (from
> process_connection hooks) for letting the MPM do the polling for SSL
> handshakes that'd block for instance. It then expanded to a
> CONN_STATE_PROCESS state (renamed from CONN_STATE_READ_REQUEST_LINE)
> where mpm_event receiving AGAIN from ap_run_process_connection() will
> simply poll according to the c->cs->sense value
> (WANT_READ/WANT_WRITE).
> This PR also removes all keepalive kills, though I don't think mod_h2
> should rely on this state?
>
> Could you try running your mod_h2 changes on top of it and with
> h2_c1_run() doing something like:
> c->cs->state = CONN_STATE_PROCESS;
> c->cs->state = CONN_SENSE_WANT_READ; /* or _WRITE */

This should be c->cs->sense = CONN_SENSE_WANT_READ of course..

> return AGAIN;
> where you want mpm_event to simply poll() for read (or write)?
>
>
> Regards;
> Yann.

Re: more async handling in mod_h2

[Yann Ylavic]

On Mon, May 13, 2024 at 6:31 PM Stefan Eissing  wrote:
>
> > Am 13.05.2024 um 17:41 schrieb Yann Ylavic :
> >
> > On Mon, May 13, 2024 at 1:32 PM Stefan Eissing
> >>
> >> With the change in PR 280, we return on being flow blocked. The 
> >> response(s) are *not* finished. If MPM now closes such a connection under 
> >> load, the client will most likely try again. This seems counter productive.
> >
> > AFAICT the CONN_STATE_WRITE_COMPLETION state is different depending on
> > CONN_SENSE_WANT_READ and CONN_SENSE_WANT_WRITE/DEFAULT.
> > With CONN_SENSE_WANT_WRITE/DEFAULT, mpm_event will indeed assume flush
> > (nonblocking) before close,

It's actually a flush before *keepalive* (unless !AP_CONN_KEEPALIVE),
though it's not what you want anyway.

> > but with CONN_SENSE_WANT_READ it will poll
> > for read on the connection and come back to the process_connection
> > hooks when something is in.
> >
> > When mod_h2 waits for some WINDOW_UPDATE it wants the MPM to POLLIN
> > (right?), h2_c1_hook_process_connection() should recover/continue with
> > the new data from the client. And since it's a c1 connection I don't
> > think there needs to be some new pollset/queues sizing adjustment to
> > do either, so we should be good?
>
> Yes, mod_h2 does CONN_STATE_WRITE_COMPLETION and CONN_SENSE_WANT_READ and it 
> works nicely. The only thing is that, when I open many connections, 
> unfinished ones get dropped very fast. Like after a few milliseconds.

What do you mean by unfinished ones, which state are they in (i.e. how
do they end up in the MPM with a keepalive state which is the only one
where connections are "early" killed under high load)?
I think this can only happen when mpm_event gets a connection with
c->cs->state == CONN_STATE_WRITE_COMPLETION but c->cs->sense !=
CONN_SENSE_WANT_READ, is that a mod_h2 possible thing?

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

There is https://github.com/apache/httpd/pull/294 with quite some
changes to mpm_event. Sorry this is still WIP and needs to be split
more, probably in multiple PRs too, but it works for the tests I've
done so far (I just rebased it on latest trunk).
This change starts with Graham's AGAIN return code (from
process_connection hooks) for letting the MPM do the polling for SSL
handshakes that'd block for instance. It then expanded to a
CONN_STATE_PROCESS state (renamed from CONN_STATE_READ_REQUEST_LINE)
where mpm_event receiving AGAIN from ap_run_process_connection() will
simply poll according to the c->cs->sense value
(WANT_READ/WANT_WRITE).
This PR also removes all keepalive kills, though I don't think mod_h2
should rely on this state?

Could you try running your mod_h2 changes on top of it and with
h2_c1_run() doing something like:
c->cs->state = CONN_STATE_PROCESS;
c->cs->state = CONN_SENSE_WANT_READ; /* or _WRITE */
return AGAIN;
where you want mpm_event to simply poll() for read (or write)?


Regards;
Yann.

Re: more async handling in mod_h2

[Stefan Eissing via dev]

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

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

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

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

Cheers,
Stefan

> 
> Regards;
> Yann.

Re: more async handling in mod_h2

[Yann Ylavic]

On Mon, May 13, 2024 at 1:32 PM Stefan Eissing via dev
 wrote:
>
> I have merged https://github.com/icing/mod_h2/pull/280 to the mod-h2 on 
> github. With mpm_event, this will return HTTP/2 connections more often to the 
> mpm, thus freeing a worker.
>
> While this sounds good, I am not sure this is beneficial for a server under 
> load. The current connection state handling is designed for HTTP/1.x where a 
> connection is "given back" to the MPM at the end of a request.
>
> AFAICT, the MPM assumes that, once any pending output is written, it may 
> close the connection under load. Because in HTTP/1.x it means the connection 
> has served the last response completely. The client should be grateful and 
> cope well with the connection being closed subsequently due to other clients 
> demands.
>
> In HTTP/2 so far, we did return to the MPM only when all requests had been 
> served. The connection is therefore really in a similar state to HTTP/1.x. 
> The client has got its responses, we are free to close.
>
> With the change in PR 280, we return on being flow blocked. The response(s) 
> are *not* finished. If MPM now closes such a connection under load, the 
> client will most likely try again. This seems counter productive.

AFAICT the CONN_STATE_WRITE_COMPLETION state is different depending on
CONN_SENSE_WANT_READ and CONN_SENSE_WANT_WRITE/DEFAULT.
With CONN_SENSE_WANT_WRITE/DEFAULT, mpm_event will indeed assume flush
(nonblocking) before close, but with CONN_SENSE_WANT_READ it will poll
for read on the connection and come back to the process_connection
hooks when something is in.

When mod_h2 waits for some WINDOW_UPDATE it wants the MPM to POLLIN
(right?), h2_c1_hook_process_connection() should recover/continue with
the new data from the client. And since it's a c1 connection I don't
think there needs to be some new pollset/queues sizing adjustment to
do either, so we should be good?

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

I think the semantics of CONN_STATE_WRITE_COMPLETION with
CONN_SENSE_WANT_* are quite unintuitive (for the least), so we
probably should have different states for CONN_STATE_WRITE_COMPLETION
(flush before close) and CONN_STATE_POLL_READ/POLL_WRITE/POLL_RW which
would be how a process_connection hook would return to the MPM just
for poll()ing.


Regards;
Yann.

Re: more async handling in mod_h2

[Stefan Eissing via dev]

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

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

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

Re: more async handling in mod_h2

[Eric Covener]

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

We have CONN_STATE_SUSPENDED too.  These are all but forgotten by the
MPM until something changes their state back.
You may see some references to PT_USER that got backported in
comments, but that is trunk-only.
PT_USER is about how something gets help un-suspending. In the case of
H2, I guess the non-worker thread knows/should know when it could
resume a request already?

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

more async handling in mod_h2

[Stefan Eissing via dev]

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

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

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

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

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

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

WDYT?



Cheers,
Stefan

Bug report for Apache httpd-2 [2024/05/12]

[bugzilla]

+---+
| Bugzilla Bug ID   |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned|
| | OPN=ReopenedVER=Verified(Skipped Closed/Resolved)   |
| |   +-+
| |   | Severity: BLK=Blocker CRI=Critical  REG=Regression  MAJ=Major   |
| |   |   MIN=Minor   NOR=NormalENH=Enhancement TRV=Trivial |
| |   |   +-+
| |   |   | Date Posted |
| |   |   |  +--+
| |   |   |  | Description  |
| |   |   |  |  |
|10747|New|Maj|2002-07-12|ftp SIZE command and 'smart' ftp servers results i|
|11580|Opn|Enh|2002-08-09|generate Content-Location headers |
|12033|Opn|Nor|2002-08-26|Graceful restart immediately result in [warn] long|
|13661|Ass|Enh|2002-10-15|Apache cannot not handle dynamic IP reallocation  |
|14104|Opn|Enh|2002-10-30|not documented: must restart server to load new CR|
|16811|Ass|Maj|2003-02-05|mod_autoindex always return webpages in UTF-8.|
|17244|Ass|Nor|2003-02-20|./configure --help gives false information regardi|
|17497|Opn|Nor|2003-02-27|mod_mime_magic generates incorrect response header|
|20036|Ass|Nor|2003-05-19|Trailing Dots stripped from PATH_INFO environment |
|21260|Opn|Nor|2003-07-02|CacheMaxExpire directive not enforced !   |
|21533|Ass|Cri|2003-07-11|Multiple levels of htacces files can cause mod_aut|
|22484|Opn|Maj|2003-08-16|semaphore problem takes httpd down|
|22686|Opn|Nor|2003-08-25|ab: apr_poll: The timeout specified has expired (7|
|22898|Opn|Nor|2003-09-02|nph scripts with two HTTP header  |
|23911|Opn|Cri|2003-10-18|CGI processes left defunct/zombie under 2.0.54|
|24095|Opn|Cri|2003-10-24|ERROR "Parent: child process exited with status 32|
|24437|Opn|Nor|2003-11-05|mod_auth_ldap doubly-escapes backslash (\) charact|
|24890|Opn|Nor|2003-11-21|Apache config parser should not be local aware ( g|
|25469|Opn|Enh|2003-12-12|create AuthRoot for defining paths to auth files  |
|25484|Ass|Nor|2003-12-12|Non-service Apache cannot be stopped in WinXP |
|26153|Opn|Cri|2004-01-15|Apache cygwin directory traversal vulnerability   |
|27257|Ass|Enh|2004-02-26|rotatelogs with getopt and setuid |
|27715|Ass|Enh|2004-03-16|Client sending misformed Range "bytes = 0-100" ins|
|29090|Ass|Enh|2004-05-19|MultiviewsMatch NegotiatedOnly extensions not resp|
|29510|Ass|Enh|2004-06-10|ab does not support multiple cookies  |
|29644|Ver|Nor|2004-06-17|mod_proxy keeps downloading even after the client |
|30259|Ass|Enh|2004-07-22|When proxy connects to backend, a DNS lookup is do|
|30505|Ass|Enh|2004-08-05|Apache uses 'Error', and not lower level event typ|
|31302|Opn|Cri|2004-09-19|suexec doesn't execute commands if they're not in |
|31352|Ass|Enh|2004-09-21|RFE, Bind to LDAP server with browser supplier use|
|31418|Opn|Nor|2004-09-25|SSLUserName is not usable by other modules|
|32328|Opn|Enh|2004-11-19|Make mod_rewrite escaping optional / expose intern|
|32750|Ass|Maj|2004-12-17|mod_proxy + Win32DisableAcceptEx = memory leak|
|33089|New|Nor|2005-01-13|mod_include: Options +Includes (or IncludesNoExec)|
|34519|New|Enh|2005-04-19|Directory index should emit valid XHTML   |
|35098|Ver|Maj|2005-05-27|Install fails using --prefix  |
|35154|Opn|Nor|2005-06-01|Support for NID_serialNumber, etc. in SSLUserName |
|35652|Opn|Min|2005-07-07|Improve error message: "pcfg_openfile: unable to c|
|35768|Opn|Nor|2005-07-17|Missing file logs at far too high of log level|
|36676|New|Nor|2005-09-15|time() bug in httpd/os/win32/util_win32.c:wait_for|
|36710|Opn|Blk|2005-09-19|CGI output not captured   |
|37006|Ver|Reg|2005-10-11|"pthread" error when compiling under AIX 5.3 using|
|37290|Opn|Min|2005-10-28|DirectoryIndex don't work in scriptaliased directo|
|37564|New|Enh|2005-11-19|Suggestion: mod_suexec SuexecUserGroup directive i|
|38325|Opn|Nor|2006-01-20|impossible to determine AUTH_TYPE of interpreted r|
|38571|New|Enh|2006-02-08|CustomLog directive checked by apachectl configtes|
|38995|New|Nor|2006-03-16|httpd tries to communicate with the CGI daemon eve|
|39275|Opn|Nor|2006-04-11|slow child_init causes MaxClients warning |
|39287|New|Nor|2006-04-12|Incorrect If-Modified-Since validation (due to syn|
|39727|Ass|Nor|2006-06-05|Incorrect ETag on gzip:ed content |
|39748|New|Enh|2006-06-07|Header and POST support for mod_include   |

Bug report for Apache httpd-2 [2024/05/05]

[bugzilla]

+---+
| Bugzilla Bug ID   |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned|
| | OPN=ReopenedVER=Verified(Skipped Closed/Resolved)   |
| |   +-+
| |   | Severity: BLK=Blocker CRI=Critical  REG=Regression  MAJ=Major   |
| |   |   MIN=Minor   NOR=NormalENH=Enhancement TRV=Trivial |
| |   |   +-+
| |   |   | Date Posted |
| |   |   |  +--+
| |   |   |  | Description  |
| |   |   |  |  |
|10747|New|Maj|2002-07-12|ftp SIZE command and 'smart' ftp servers results i|
|11580|Opn|Enh|2002-08-09|generate Content-Location headers |
|12033|Opn|Nor|2002-08-26|Graceful restart immediately result in [warn] long|
|13661|Ass|Enh|2002-10-15|Apache cannot not handle dynamic IP reallocation  |
|14104|Opn|Enh|2002-10-30|not documented: must restart server to load new CR|
|16811|Ass|Maj|2003-02-05|mod_autoindex always return webpages in UTF-8.|
|17244|Ass|Nor|2003-02-20|./configure --help gives false information regardi|
|17497|Opn|Nor|2003-02-27|mod_mime_magic generates incorrect response header|
|20036|Ass|Nor|2003-05-19|Trailing Dots stripped from PATH_INFO environment |
|21260|Opn|Nor|2003-07-02|CacheMaxExpire directive not enforced !   |
|21533|Ass|Cri|2003-07-11|Multiple levels of htacces files can cause mod_aut|
|22484|Opn|Maj|2003-08-16|semaphore problem takes httpd down|
|22686|Opn|Nor|2003-08-25|ab: apr_poll: The timeout specified has expired (7|
|22898|Opn|Nor|2003-09-02|nph scripts with two HTTP header  |
|23911|Opn|Cri|2003-10-18|CGI processes left defunct/zombie under 2.0.54|
|24095|Opn|Cri|2003-10-24|ERROR "Parent: child process exited with status 32|
|24437|Opn|Nor|2003-11-05|mod_auth_ldap doubly-escapes backslash (\) charact|
|24890|Opn|Nor|2003-11-21|Apache config parser should not be local aware ( g|
|25469|Opn|Enh|2003-12-12|create AuthRoot for defining paths to auth files  |
|25484|Ass|Nor|2003-12-12|Non-service Apache cannot be stopped in WinXP |
|26153|Opn|Cri|2004-01-15|Apache cygwin directory traversal vulnerability   |
|27257|Ass|Enh|2004-02-26|rotatelogs with getopt and setuid |
|27715|Ass|Enh|2004-03-16|Client sending misformed Range "bytes = 0-100" ins|
|29090|Ass|Enh|2004-05-19|MultiviewsMatch NegotiatedOnly extensions not resp|
|29510|Ass|Enh|2004-06-10|ab does not support multiple cookies  |
|29644|Ver|Nor|2004-06-17|mod_proxy keeps downloading even after the client |
|30259|Ass|Enh|2004-07-22|When proxy connects to backend, a DNS lookup is do|
|30505|Ass|Enh|2004-08-05|Apache uses 'Error', and not lower level event typ|
|31302|Opn|Cri|2004-09-19|suexec doesn't execute commands if they're not in |
|31352|Ass|Enh|2004-09-21|RFE, Bind to LDAP server with browser supplier use|
|31418|Opn|Nor|2004-09-25|SSLUserName is not usable by other modules|
|32328|Opn|Enh|2004-11-19|Make mod_rewrite escaping optional / expose intern|
|32750|Ass|Maj|2004-12-17|mod_proxy + Win32DisableAcceptEx = memory leak|
|33089|New|Nor|2005-01-13|mod_include: Options +Includes (or IncludesNoExec)|
|34519|New|Enh|2005-04-19|Directory index should emit valid XHTML   |
|35098|Ver|Maj|2005-05-27|Install fails using --prefix  |
|35154|Opn|Nor|2005-06-01|Support for NID_serialNumber, etc. in SSLUserName |
|35652|Opn|Min|2005-07-07|Improve error message: "pcfg_openfile: unable to c|
|35768|Opn|Nor|2005-07-17|Missing file logs at far too high of log level|
|36676|New|Nor|2005-09-15|time() bug in httpd/os/win32/util_win32.c:wait_for|
|36710|Opn|Blk|2005-09-19|CGI output not captured   |
|37006|Ver|Reg|2005-10-11|"pthread" error when compiling under AIX 5.3 using|
|37290|Opn|Min|2005-10-28|DirectoryIndex don't work in scriptaliased directo|
|37564|New|Enh|2005-11-19|Suggestion: mod_suexec SuexecUserGroup directive i|
|38325|Opn|Nor|2006-01-20|impossible to determine AUTH_TYPE of interpreted r|
|38571|New|Enh|2006-02-08|CustomLog directive checked by apachectl configtes|
|38995|New|Nor|2006-03-16|httpd tries to communicate with the CGI daemon eve|
|39275|Opn|Nor|2006-04-11|slow child_init causes MaxClients warning |
|39287|New|Nor|2006-04-12|Incorrect If-Modified-Since validation (due to syn|
|39727|Ass|Nor|2006-06-05|Incorrect ETag on gzip:ed content |
|39748|New|Enh|2006-06-07|Header and POST support for mod_include   |

Bug report for Apache httpd-2 [2024/04/28]

[bugzilla]

+---+
| Bugzilla Bug ID   |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned|
| | OPN=ReopenedVER=Verified(Skipped Closed/Resolved)   |
| |   +-+
| |   | Severity: BLK=Blocker CRI=Critical  REG=Regression  MAJ=Major   |
| |   |   MIN=Minor   NOR=NormalENH=Enhancement TRV=Trivial |
| |   |   +-+
| |   |   | Date Posted |
| |   |   |  +--+
| |   |   |  | Description  |
| |   |   |  |  |
|10747|New|Maj|2002-07-12|ftp SIZE command and 'smart' ftp servers results i|
|11580|Opn|Enh|2002-08-09|generate Content-Location headers |
|12033|Opn|Nor|2002-08-26|Graceful restart immediately result in [warn] long|
|13661|Ass|Enh|2002-10-15|Apache cannot not handle dynamic IP reallocation  |
|14104|Opn|Enh|2002-10-30|not documented: must restart server to load new CR|
|16811|Ass|Maj|2003-02-05|mod_autoindex always return webpages in UTF-8.|
|17244|Ass|Nor|2003-02-20|./configure --help gives false information regardi|
|17497|Opn|Nor|2003-02-27|mod_mime_magic generates incorrect response header|
|20036|Ass|Nor|2003-05-19|Trailing Dots stripped from PATH_INFO environment |
|21260|Opn|Nor|2003-07-02|CacheMaxExpire directive not enforced !   |
|21533|Ass|Cri|2003-07-11|Multiple levels of htacces files can cause mod_aut|
|22484|Opn|Maj|2003-08-16|semaphore problem takes httpd down|
|22686|Opn|Nor|2003-08-25|ab: apr_poll: The timeout specified has expired (7|
|22898|Opn|Nor|2003-09-02|nph scripts with two HTTP header  |
|23911|Opn|Cri|2003-10-18|CGI processes left defunct/zombie under 2.0.54|
|24095|Opn|Cri|2003-10-24|ERROR "Parent: child process exited with status 32|
|24437|Opn|Nor|2003-11-05|mod_auth_ldap doubly-escapes backslash (\) charact|
|24890|Opn|Nor|2003-11-21|Apache config parser should not be local aware ( g|
|25469|Opn|Enh|2003-12-12|create AuthRoot for defining paths to auth files  |
|25484|Ass|Nor|2003-12-12|Non-service Apache cannot be stopped in WinXP |
|26153|Opn|Cri|2004-01-15|Apache cygwin directory traversal vulnerability   |
|27257|Ass|Enh|2004-02-26|rotatelogs with getopt and setuid |
|27715|Ass|Enh|2004-03-16|Client sending misformed Range "bytes = 0-100" ins|
|29090|Ass|Enh|2004-05-19|MultiviewsMatch NegotiatedOnly extensions not resp|
|29510|Ass|Enh|2004-06-10|ab does not support multiple cookies  |
|29644|Ver|Nor|2004-06-17|mod_proxy keeps downloading even after the client |
|30259|Ass|Enh|2004-07-22|When proxy connects to backend, a DNS lookup is do|
|30505|Ass|Enh|2004-08-05|Apache uses 'Error', and not lower level event typ|
|31302|Opn|Cri|2004-09-19|suexec doesn't execute commands if they're not in |
|31352|Ass|Enh|2004-09-21|RFE, Bind to LDAP server with browser supplier use|
|31418|Opn|Nor|2004-09-25|SSLUserName is not usable by other modules|
|32328|Opn|Enh|2004-11-19|Make mod_rewrite escaping optional / expose intern|
|32750|Ass|Maj|2004-12-17|mod_proxy + Win32DisableAcceptEx = memory leak|
|33089|New|Nor|2005-01-13|mod_include: Options +Includes (or IncludesNoExec)|
|34519|New|Enh|2005-04-19|Directory index should emit valid XHTML   |
|35098|Ver|Maj|2005-05-27|Install fails using --prefix  |
|35154|Opn|Nor|2005-06-01|Support for NID_serialNumber, etc. in SSLUserName |
|35652|Opn|Min|2005-07-07|Improve error message: "pcfg_openfile: unable to c|
|35768|Opn|Nor|2005-07-17|Missing file logs at far too high of log level|
|36676|New|Nor|2005-09-15|time() bug in httpd/os/win32/util_win32.c:wait_for|
|36710|Opn|Blk|2005-09-19|CGI output not captured   |
|37006|Ver|Reg|2005-10-11|"pthread" error when compiling under AIX 5.3 using|
|37290|Opn|Min|2005-10-28|DirectoryIndex don't work in scriptaliased directo|
|37564|New|Enh|2005-11-19|Suggestion: mod_suexec SuexecUserGroup directive i|
|38325|Opn|Nor|2006-01-20|impossible to determine AUTH_TYPE of interpreted r|
|38571|New|Enh|2006-02-08|CustomLog directive checked by apachectl configtes|
|38995|New|Nor|2006-03-16|httpd tries to communicate with the CGI daemon eve|
|39275|Opn|Nor|2006-04-11|slow child_init causes MaxClients warning |
|39287|New|Nor|2006-04-12|Incorrect If-Modified-Since validation (due to syn|
|39727|Ass|Nor|2006-06-05|Incorrect ETag on gzip:ed content |
|39748|New|Enh|2006-06-07|Header and POST support for mod_include   |

Re: [WIP] mod_authnz_ldap / mod_ldap support for APR v2 LDAP API

[Graham Leggett via dev]

On 19 Apr 2024, at 09:01, Ruediger Pluem  wrote:

> First of all I haven't gone through the patch. Hence I may be off below.
> 
> I think the core issue with the LDAP API we have in APR-UTIL 1.x today and 
> that let to the
> removal discussions on APR side in 2010 
> (https://lists.apache.org/thread/pz5c28g0gf248fvpds53zl1f8by9n8n4)
> and 2011 (https://lists.apache.org/thread/cslw4gj0jgx3bmr8trz0jtfq5bmv1tfl) 
> is that it is an incomplete
> abstraction of the LDAP libraries. mod_authnz_ldap and mod_ldap as consumers 
> of the current API
> have LDAP library specific code and need to link directly against the 
> specific LDAP library.

What you've described above is the exact thing that has been fixed.

This is the core of the patch:

https://github.com/apache/httpd/pull/438/files#diff-f309c2fcd650f484a21c930ddde995a646387421b671232f5b643328f7d2da06

diff --git a/modules/aaa/config.m4 b/modules/aaa/config.m4
index 1b59f99f492..b12e03b287d 100644
--- a/modules/aaa/config.m4
+++ b/modules/aaa/config.m4
@@ -49,21 +49,7 @@ APACHE_MODULE(authz_core, core authorization provider vector 
module, , , yes)
 
 dnl LDAP authentication module. This module has both the authn and authz
 dnl modules in one, so as to share the LDAP server config directives.
-APACHE_MODULE(authnz_ldap, LDAP based authentication, , , most, [
-  APACHE_CHECK_APR_HAS_LDAP
-  if test "$ac_cv_APR_HAS_LDAP" = "yes" ; then
-if test -z "$apu_config" ; then
-  LDAP_LIBS="`$apr_config --ldap-libs`"
-else
-  LDAP_LIBS="`$apu_config --ldap-libs`"
-fi
-APR_ADDTO(MOD_AUTHNZ_LDAP_LDADD, [$LDAP_LIBS])
-AC_SUBST(MOD_AUTHNZ_LDAP_LDADD)
-  else
-AC_MSG_WARN([apr/apr-util is compiled without ldap support])
-enable_authnz_ldap=no
-  fi
-])
+APACHE_MODULE(authnz_ldap, LDAP based authentication, , , most)
 
 dnl FastCGI authorizer interface, supporting authn and authz.
 APACHE_MODULE(authnz_fcgi,

LDAP is no longer special. DBD, DBM, SQL, LDAP, all the same.

> I agree that it is of limited sense to decide during runtime which LDAP 
> library to use as typically there is
> only one available on a particular system. This is substantially different 
> from the situation with databases.

This isn't the whole story.

Like databases, we have lots of different drivers with wildly different and 
incompatible implementations. Unlike databases, the majority of these drivers 
are based on a C API published as an RFC 30 years ago, and therefore are about 
80% common code / clashing symbols. It is the way that it is. The driver 
specific code involves SSL (which evolved) and SASL binding (which evolved), 
but the vast majority of the code is still standard.

For this reason it's pointless coming up with five separate drivers for five 
separate libraries. You can never load two at the same time because clashing 
symbols. This is true of all code, it has nothing to do with httpd 
specifically. Someone binds to library A in a module, and then someone else 
binds to library B in a different module, you are not loading those two modules 
into the server at the same time, it's just not happening.

A further problem is that the libraries diverged.

Many of the functions in OpenLDAP and Windows have been deprecated, replaced 
with _ext functions. The LDAP_DEPRECATED define is now gone.

Rebinding for example works totally differently if you're on IBM, or on 
OpenLDAP. One does not block, but has limited SASL capability. The other does 
SASL for you, but blocks. Windows expects you to rebind yourself.

SASL is wild west. OpenLDAP does SASL for you, but you have to do an intricate 
dance between two functions to make it work. Windows says "here you go, have a 
binary blob, pass it to the Windows specific SASL implementation will you". 
Again, different approaches, it is what it is.
 
Non-blocking behaviour is inconsistent. Some functions in some libraries block 
in some circumstances. You've got to be a masochist if every single consumer of 
LDAP has to deal with all of these inconsistencies, over and over again.

The "P" in APR stands for portability, and that is exactly what I as a consumer 
of an LDAP API want.

> The point back then on APR side was that this incomplete API should be either 
> "completed" or removed from APR
> and that its code should move to httpd which should deal then directly with 
> all the gory details of the various
> LDAP libraries not just with a subset. This happened on APR trunk side, but 
> not on httpd trunk side.

What happened in the past was that code was removed from APR without a 
replacement implementation having been provided first. The expectation was that 
other people (me) would provide free labour to replace that removed 
implementation to make the server whole again.

I have been working on this on and off for years, providing custom patched 
httpd's to get the immediate job done. It has reached the point where I can't 
be supporting custom patches and this needed finishing.

People have been very 

Bug report for Apache httpd-2 [2024/04/21]

[bugzilla]

+---+
| Bugzilla Bug ID   |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned|
| | OPN=ReopenedVER=Verified(Skipped Closed/Resolved)   |
| |   +-+
| |   | Severity: BLK=Blocker CRI=Critical  REG=Regression  MAJ=Major   |
| |   |   MIN=Minor   NOR=NormalENH=Enhancement TRV=Trivial |
| |   |   +-+
| |   |   | Date Posted |
| |   |   |  +--+
| |   |   |  | Description  |
| |   |   |  |  |
|10747|New|Maj|2002-07-12|ftp SIZE command and 'smart' ftp servers results i|
|11580|Opn|Enh|2002-08-09|generate Content-Location headers |
|12033|Opn|Nor|2002-08-26|Graceful restart immediately result in [warn] long|
|13661|Ass|Enh|2002-10-15|Apache cannot not handle dynamic IP reallocation  |
|14104|Opn|Enh|2002-10-30|not documented: must restart server to load new CR|
|16811|Ass|Maj|2003-02-05|mod_autoindex always return webpages in UTF-8.|
|17244|Ass|Nor|2003-02-20|./configure --help gives false information regardi|
|17497|Opn|Nor|2003-02-27|mod_mime_magic generates incorrect response header|
|20036|Ass|Nor|2003-05-19|Trailing Dots stripped from PATH_INFO environment |
|21260|Opn|Nor|2003-07-02|CacheMaxExpire directive not enforced !   |
|21533|Ass|Cri|2003-07-11|Multiple levels of htacces files can cause mod_aut|
|22484|Opn|Maj|2003-08-16|semaphore problem takes httpd down|
|22686|Opn|Nor|2003-08-25|ab: apr_poll: The timeout specified has expired (7|
|22898|Opn|Nor|2003-09-02|nph scripts with two HTTP header  |
|23911|Opn|Cri|2003-10-18|CGI processes left defunct/zombie under 2.0.54|
|24095|Opn|Cri|2003-10-24|ERROR "Parent: child process exited with status 32|
|24437|Opn|Nor|2003-11-05|mod_auth_ldap doubly-escapes backslash (\) charact|
|24890|Opn|Nor|2003-11-21|Apache config parser should not be local aware ( g|
|25469|Opn|Enh|2003-12-12|create AuthRoot for defining paths to auth files  |
|25484|Ass|Nor|2003-12-12|Non-service Apache cannot be stopped in WinXP |
|26153|Opn|Cri|2004-01-15|Apache cygwin directory traversal vulnerability   |
|27257|Ass|Enh|2004-02-26|rotatelogs with getopt and setuid |
|27715|Ass|Enh|2004-03-16|Client sending misformed Range "bytes = 0-100" ins|
|29090|Ass|Enh|2004-05-19|MultiviewsMatch NegotiatedOnly extensions not resp|
|29510|Ass|Enh|2004-06-10|ab does not support multiple cookies  |
|29644|Ver|Nor|2004-06-17|mod_proxy keeps downloading even after the client |
|30259|Ass|Enh|2004-07-22|When proxy connects to backend, a DNS lookup is do|
|30505|Ass|Enh|2004-08-05|Apache uses 'Error', and not lower level event typ|
|31302|Opn|Cri|2004-09-19|suexec doesn't execute commands if they're not in |
|31352|Ass|Enh|2004-09-21|RFE, Bind to LDAP server with browser supplier use|
|31418|Opn|Nor|2004-09-25|SSLUserName is not usable by other modules|
|32328|Opn|Enh|2004-11-19|Make mod_rewrite escaping optional / expose intern|
|32750|Ass|Maj|2004-12-17|mod_proxy + Win32DisableAcceptEx = memory leak|
|33089|New|Nor|2005-01-13|mod_include: Options +Includes (or IncludesNoExec)|
|34519|New|Enh|2005-04-19|Directory index should emit valid XHTML   |
|35098|Ver|Maj|2005-05-27|Install fails using --prefix  |
|35154|Opn|Nor|2005-06-01|Support for NID_serialNumber, etc. in SSLUserName |
|35652|Opn|Min|2005-07-07|Improve error message: "pcfg_openfile: unable to c|
|35768|Opn|Nor|2005-07-17|Missing file logs at far too high of log level|
|36676|New|Nor|2005-09-15|time() bug in httpd/os/win32/util_win32.c:wait_for|
|36710|Opn|Blk|2005-09-19|CGI output not captured   |
|37006|Ver|Reg|2005-10-11|"pthread" error when compiling under AIX 5.3 using|
|37290|Opn|Min|2005-10-28|DirectoryIndex don't work in scriptaliased directo|
|37564|New|Enh|2005-11-19|Suggestion: mod_suexec SuexecUserGroup directive i|
|38325|Opn|Nor|2006-01-20|impossible to determine AUTH_TYPE of interpreted r|
|38571|New|Enh|2006-02-08|CustomLog directive checked by apachectl configtes|
|38995|New|Nor|2006-03-16|httpd tries to communicate with the CGI daemon eve|
|39275|Opn|Nor|2006-04-11|slow child_init causes MaxClients warning |
|39287|New|Nor|2006-04-12|Incorrect If-Modified-Since validation (due to syn|
|39727|Ass|Nor|2006-06-05|Incorrect ETag on gzip:ed content |
|39748|New|Enh|2006-06-07|Header and POST support for mod_include   |

Re: [WIP] mod_authnz_ldap / mod_ldap support for APR v2 LDAP API

[Yann Ylavic]

On Thu, Apr 18, 2024 at 3:21 PM Joe Orton  wrote:
>
> On Thu, Apr 18, 2024 at 09:40:21AM +0100, Graham Leggett via dev wrote:
> > Hi all,
> >
> > The attached patch is a current work in progress patch for httpd-trunk to 
> > use the new apr_ldap API that just landing in APR.
> >
> > The highlights:
> >
> > - Complete replacement of the previous API.
> > - Will work against apr-2 (just landed) and apr-util-1.7 (after backport).
> > - Linking to the underlying LDAP API has been removed and is no longer 
> > needed.
>
> This design decision seems surprising to me, what does this add? Adding
> another abstraction layer to allow runtime selection of the LDAP library
> seems like a step backwards (a lot of complexity with no benefit).
>
> Unlike with e.g. a database backend selection users don't care about
> picking/configuring among many LDAP libraries.

FWIW I tried some time ago to avoid the very same kind of complexity
with apr_crypto vs TLS/SSL library but it was -1'd.
I would prefer direct linking of those libraries too, databases are a
special case which we shouldn't generalize for every library used by
APR (IMHO).


Regards;
Yann.

Re: [WIP] mod_authnz_ldap / mod_ldap support for APR v2 LDAP API

[Graham Leggett via dev]

On 19 Apr 2024, at 09:07, Ruediger Pluem  wrote:

> Would it be possible to provide this patch as a PR against trunk on Github? I 
> think that would ease reviewing it.
> I am quite aware that this moves some gory detail discussion of that patch 
> away from the dev list here and over
> to the PR where it is likely harder to find later. Nevertheless I think that 
> the easier way to review the patch combined with
> the tests applied to the PR via Github actions outweigh this drawback.

Take a look here:

https://github.com/apache/httpd/pull/438

The key change is that the new apr-ldap API is 100% asynchronous, with helpful 
patterns to make it easy to use in synchronous code like present httpd. The 
intention is that future code will allow us to have an LDAP connection 
controlled by the MPM, with "guest" requests added by httpd requests and 
removed by pool cleanups. This is useful by anybody, not just httpd.

RFC1823 is 30-ish years old, we're not exposing this old API any more.

https://www.rfc-editor.org/rfc/rfc1823.html

Regards,
Graham
--

Re: [WIP] mod_authnz_ldap / mod_ldap support for APR v2 LDAP API

[Ruediger Pluem]

On 4/18/24 10:40 AM, Graham Leggett via dev wrote:
> Hi all,
> 
> The attached patch is a current work in progress patch for httpd-trunk to use 
> the new apr_ldap API that just landing in APR.
> 
> The highlights:
> 
> - Complete replacement of the previous API.
> - Will work against apr-2 (just landed) and apr-util-1.7 (after backport).
> - Linking to the underlying LDAP API has been removed and is no longer needed.
> - New LDAP API is based on pool lifetimes.
> 
> Still to be done:
> 
> - Rebind needs doing from scratch in APR, the old way blocked on some 
> platforms.
> - Nested groups needs reimplementing, as we can now do parallel LDAP queries.

Would it be possible to provide this patch as a PR against trunk on Github? I 
think that would ease reviewing it.
I am quite aware that this moves some gory detail discussion of that patch away 
from the dev list here and over
to the PR where it is likely harder to find later. Nevertheless I think that 
the easier way to review the patch combined with
the tests applied to the PR via Github actions outweigh this drawback.

Regards

Rüdiger

Re: [WIP] mod_authnz_ldap / mod_ldap support for APR v2 LDAP API

[Ruediger Pluem]

On 4/18/24 3:21 PM, Joe Orton wrote:
> On Thu, Apr 18, 2024 at 09:40:21AM +0100, Graham Leggett via dev wrote:
>> Hi all,
>>
>> The attached patch is a current work in progress patch for httpd-trunk to 
>> use the new apr_ldap API that just landing in APR.
>>
>> The highlights:
>>
>> - Complete replacement of the previous API.
>> - Will work against apr-2 (just landed) and apr-util-1.7 (after backport).
>> - Linking to the underlying LDAP API has been removed and is no longer 
>> needed.
> 
> This design decision seems surprising to me, what does this add? Adding 
> another abstraction layer to allow runtime selection of the LDAP library 
> seems like a step backwards (a lot of complexity with no benefit). 
> Unlike with e.g. a database backend selection users don't care about 
> picking/configuring among many LDAP libraries.

First of all I haven't gone through the patch. Hence I may be off below.

I think the core issue with the LDAP API we have in APR-UTIL 1.x today and that 
let to the
removal discussions on APR side in 2010 
(https://lists.apache.org/thread/pz5c28g0gf248fvpds53zl1f8by9n8n4)
and 2011 (https://lists.apache.org/thread/cslw4gj0jgx3bmr8trz0jtfq5bmv1tfl) is 
that it is an incomplete
abstraction of the LDAP libraries. mod_authnz_ldap and mod_ldap as consumers of 
the current API
have LDAP library specific code and need to link directly against the specific 
LDAP library.
The point back then on APR side was that this incomplete API should be either 
"completed" or removed from APR
and that its code should move to httpd which should deal then directly with all 
the gory details of the various
LDAP libraries not just with a subset. This happened on APR trunk side, but not 
on httpd trunk side.

I agree that it is of limited sense to decide during runtime which LDAP library 
to use as typically there is
only one available on a particular system. This is substantially different from 
the situation with databases.
Nevertheless I think it is a good idea to concentrate the LDAP library 
abstraction in one place (either in httpd
or in APR) and don't continue the partial / mixed model we have today.
If we have further consumers of this API but httpd and APR is willing to have 
the code APR seems like to be the correct
place for it. If not we could do what we need just in httpd and decide during 
build time what library we want to build against.

Regards

Rüdiger

Reminder: Community Over Code Asia 2024 CFP closes on Apr 22nd

[Huxing Zhang]

Hi All,

The CFP for Community Over Code Asia, including the Web server and
Tomcat track, is closing very soon -  at 4:00 PM on 22 Apr 2024
Beijing time.

Details: https://sessionize.com/communityovercode-asia-2024

Please do not wait until the last minute. We hope to see you in Hangzhou!

-- 
Best Regards！
Huxing

Re: [WIP] mod_authnz_ldap / mod_ldap support for APR v2 LDAP API

[Graham Leggett via dev]

On 18 Apr 2024, at 14:21, Joe Orton  wrote:

> This design decision seems surprising to me, what does this add? Adding 
> another abstraction layer to allow runtime selection of the LDAP library 
> seems like a step backwards (a lot of complexity with no benefit). 
> Unlike with e.g. a database backend selection users don't care about 
> picking/configuring among many LDAP libraries.

Can you read through the following and confirm whether your questions are 
answered?

https://github.com/apache/apr/blob/trunk/include/apr_ldap.h#L27

If any specific questions aren't answered, can you confirm so I can make these 
clear in the docs?

Regards,
Graham
--

Re: [WIP] mod_authnz_ldap / mod_ldap support for APR v2 LDAP API

[Joe Orton]

On Thu, Apr 18, 2024 at 09:40:21AM +0100, Graham Leggett via dev wrote:
> Hi all,
> 
> The attached patch is a current work in progress patch for httpd-trunk to use 
> the new apr_ldap API that just landing in APR.
> 
> The highlights:
> 
> - Complete replacement of the previous API.
> - Will work against apr-2 (just landed) and apr-util-1.7 (after backport).
> - Linking to the underlying LDAP API has been removed and is no longer needed.

This design decision seems surprising to me, what does this add? Adding 
another abstraction layer to allow runtime selection of the LDAP library 
seems like a step backwards (a lot of complexity with no benefit). 
Unlike with e.g. a database backend selection users don't care about 
picking/configuring among many LDAP libraries.

Regards, Joe

Re: mod_tls in 2.4.x - remove?

[jean-frederic clere]

On 4/16/24 12:56, Stefan Eissing via dev wrote:

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

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

Kind Regards,
Stefan


I am +1 for that, I have looked to arrange the testsuite to test mod_ssl 
instead mod_ssl via pytest in trunk (PR: 
https://github.com/apache/httpd/pull/433) so I would like to keep 
mod_tls in trunk if possible (but I am NOT planning to work on mod_tls 
for the moment).


--
Cheers

Jean-Frederic

mod_tls in 2.4.x - remove?

[Stefan Eissing via dev]

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

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

Kind Regards,
Stefan

Json formatter support for httpd trunk

[Thomas Meyer]

Hi,

I would like to get some feedback regarding my pr:
https://github.com/apache/httpd/pull/429

Anything I can do to get this pr merged?

Mfg
Thomas
-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

mod_cgi/cgid unification for 2.4.x

[Joe Orton]

I proposed the monster mod_cgi/cgid unification backport for 2.4.x, but 
wanted to give a bit more context here rather than in STATUS. PR is 
here: https://github.com/apache/httpd/pull/209

1) stderr handling is a significant regression in mod_cgid compared to 
mod_cgi so it is worth fixing this IMO (PR 54221)

2) we have shipped this patch in Fedora for a few years, so I am 
quite confident that the file descriptor passing feature works well *on 
Linux*. I have no idea how well it works on non-Linux platforms, hence 
keeping it opt-in (./configure --enable-cgid-fdpassing).

3) there should be no behaviour changes to mod_cgi or mod_cgid if the 
fdpassing feature is not enabled, except where bug fixes to either were 
missing and are provided by the unification of common code.

4) because the bulk of the patch is de-duplication, this is a net 
reduction in lines of code shipped despite the new fd-passing code. 
diffstat:

 .github/workflows/linux.yml |8 -
 changes-entries/pr54221.txt |3 
 modules/generators/cgi_common.h |  639 
+
 modules/generators/config5.m4   |   11 +
 modules/generators/mod_cgi.c|  586 

 modules/generators/mod_cgid.c   |  642 
+-
 6 files changed, 913 insertions(+), 976 deletions(-)

Since the github PR link is a series of patches, attached the complete 
patch here as well in case that's preferred for review.

Regards, Joe
diff --git a/.github/workflows/linux.yml b/.github/workflows/linux.yml
index ddacd4af19..6d4379d165 100644
--- a/.github/workflows/linux.yml
+++ b/.github/workflows/linux.yml
@@ -48,11 +48,11 @@ jobs:
   - name: Shared MPMs, all-modules
 config: --enable-mods-shared=reallyall --enable-mpms-shared=all
   # 
-
-  - name: Event MPM, all-modules, mod_cgid only
-config: --enable-mods-shared=reallyall --with-mpm=event 
--disable-cgi
+  - name: Event MPM, all-modules, mod_cgid fdpassing
+config: --enable-mods-shared=reallyall --with-mpm=event 
--disable-cgi --enable-cgid-fdpassing
   # 
-
-  - name: Event MPM, all-modules, no CMSG_DATA
-config: --enable-mods-shared=reallyall --with-mpm=event 
ac_cv_have_decl_CMSG_DATA=no
+  - name: Event MPM, all-modules, mod_cgid w/o fdpassing
+config: --enable-mods-shared=reallyall --with-mpm=event 
--disable-cgi
   # 
-
   - name: Default, all-modules + install
 config: --enable-mods-shared=reallyall
diff --git a/changes-entries/pr54221.txt b/changes-entries/pr54221.txt
new file mode 100644
index 00..62b75ea4dd
--- /dev/null
+++ b/changes-entries/pr54221.txt
@@ -0,0 +1,3 @@
+  *) mod_cgid: Optional support for file descriptor passing, fixing
+ error log handling (configure --enable-cgid-fdpassing) on Unix
+ platforms. PR 54221.  [Joe Orton]
diff --git a/modules/generators/cgi_common.h b/modules/generators/cgi_common.h
new file mode 100644
index 00..66f9418f21
--- /dev/null
+++ b/modules/generators/cgi_common.h
@@ -0,0 +1,639 @@
+/* Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+#include "apr.h"
+#include "apr_strings.h"
+#include "apr_buckets.h"
+#include "apr_lib.h"
+#include "apr_poll.h"
+
+#define APR_WANT_STRFUNC
+#define APR_WANT_MEMFUNC
+#include "apr_want.h"
+
+#include "httpd.h"
+#include "util_filter.h"
+#include "util_script.h"
+
+static APR_OPTIONAL_FN_TYPE(ap_ssi_get_tag_and_value) *cgi_pfn_gtv;
+static APR_OPTIONAL_FN_TYPE(ap_ssi_parse_string) *cgi_pfn_ps;
+
+/* These functions provided by mod_cgi.c/mod_cgid.c still. */
+static int log_script(request_rec *r, cgi_server_conf * conf, int ret,
+  char *dbuf, const char *sbuf, 

Bug report for Apache httpd-2 [2024/04/14]

[bugzilla]

+---+
| Bugzilla Bug ID   |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned|
| | OPN=ReopenedVER=Verified(Skipped Closed/Resolved)   |
| |   +-+
| |   | Severity: BLK=Blocker CRI=Critical  REG=Regression  MAJ=Major   |
| |   |   MIN=Minor   NOR=NormalENH=Enhancement TRV=Trivial |
| |   |   +-+
| |   |   | Date Posted |
| |   |   |  +--+
| |   |   |  | Description  |
| |   |   |  |  |
|10747|New|Maj|2002-07-12|ftp SIZE command and 'smart' ftp servers results i|
|11580|Opn|Enh|2002-08-09|generate Content-Location headers |
|12033|Opn|Nor|2002-08-26|Graceful restart immediately result in [warn] long|
|13661|Ass|Enh|2002-10-15|Apache cannot not handle dynamic IP reallocation  |
|14104|Opn|Enh|2002-10-30|not documented: must restart server to load new CR|
|16811|Ass|Maj|2003-02-05|mod_autoindex always return webpages in UTF-8.|
|17244|Ass|Nor|2003-02-20|./configure --help gives false information regardi|
|17497|Opn|Nor|2003-02-27|mod_mime_magic generates incorrect response header|
|20036|Ass|Nor|2003-05-19|Trailing Dots stripped from PATH_INFO environment |
|21260|Opn|Nor|2003-07-02|CacheMaxExpire directive not enforced !   |
|21533|Ass|Cri|2003-07-11|Multiple levels of htacces files can cause mod_aut|
|22484|Opn|Maj|2003-08-16|semaphore problem takes httpd down|
|22686|Opn|Nor|2003-08-25|ab: apr_poll: The timeout specified has expired (7|
|22898|Opn|Nor|2003-09-02|nph scripts with two HTTP header  |
|23911|Opn|Cri|2003-10-18|CGI processes left defunct/zombie under 2.0.54|
|24095|Opn|Cri|2003-10-24|ERROR "Parent: child process exited with status 32|
|24437|Opn|Nor|2003-11-05|mod_auth_ldap doubly-escapes backslash (\) charact|
|24890|Opn|Nor|2003-11-21|Apache config parser should not be local aware ( g|
|25469|Opn|Enh|2003-12-12|create AuthRoot for defining paths to auth files  |
|25484|Ass|Nor|2003-12-12|Non-service Apache cannot be stopped in WinXP |
|26153|Opn|Cri|2004-01-15|Apache cygwin directory traversal vulnerability   |
|27257|Ass|Enh|2004-02-26|rotatelogs with getopt and setuid |
|27715|Ass|Enh|2004-03-16|Client sending misformed Range "bytes = 0-100" ins|
|29090|Ass|Enh|2004-05-19|MultiviewsMatch NegotiatedOnly extensions not resp|
|29510|Ass|Enh|2004-06-10|ab does not support multiple cookies  |
|29644|Ver|Nor|2004-06-17|mod_proxy keeps downloading even after the client |
|30259|Ass|Enh|2004-07-22|When proxy connects to backend, a DNS lookup is do|
|30505|Ass|Enh|2004-08-05|Apache uses 'Error', and not lower level event typ|
|31302|Opn|Cri|2004-09-19|suexec doesn't execute commands if they're not in |
|31352|Ass|Enh|2004-09-21|RFE, Bind to LDAP server with browser supplier use|
|31418|Opn|Nor|2004-09-25|SSLUserName is not usable by other modules|
|32328|Opn|Enh|2004-11-19|Make mod_rewrite escaping optional / expose intern|
|32750|Ass|Maj|2004-12-17|mod_proxy + Win32DisableAcceptEx = memory leak|
|33089|New|Nor|2005-01-13|mod_include: Options +Includes (or IncludesNoExec)|
|34519|New|Enh|2005-04-19|Directory index should emit valid XHTML   |
|35098|Ver|Maj|2005-05-27|Install fails using --prefix  |
|35154|Opn|Nor|2005-06-01|Support for NID_serialNumber, etc. in SSLUserName |
|35652|Opn|Min|2005-07-07|Improve error message: "pcfg_openfile: unable to c|
|35768|Opn|Nor|2005-07-17|Missing file logs at far too high of log level|
|36676|New|Nor|2005-09-15|time() bug in httpd/os/win32/util_win32.c:wait_for|
|36710|Opn|Blk|2005-09-19|CGI output not captured   |
|37006|Ver|Reg|2005-10-11|"pthread" error when compiling under AIX 5.3 using|
|37290|Opn|Min|2005-10-28|DirectoryIndex don't work in scriptaliased directo|
|37564|New|Enh|2005-11-19|Suggestion: mod_suexec SuexecUserGroup directive i|
|38325|Opn|Nor|2006-01-20|impossible to determine AUTH_TYPE of interpreted r|
|38571|New|Enh|2006-02-08|CustomLog directive checked by apachectl configtes|
|38995|New|Nor|2006-03-16|httpd tries to communicate with the CGI daemon eve|
|39275|Opn|Nor|2006-04-11|slow child_init causes MaxClients warning |
|39287|New|Nor|2006-04-12|Incorrect If-Modified-Since validation (due to syn|
|39727|Ass|Nor|2006-06-05|Incorrect ETag on gzip:ed content |
|39748|New|Enh|2006-06-07|Header and POST support for mod_include   |

Re: svn commit: r1916925 - /httpd/httpd/trunk/server/mpm/event/event.c

[Yann Ylavic]

On Fri, Apr 12, 2024 at 3:02 PM Ruediger Pluem  wrote:
>
> On 4/12/24 12:35 PM, yla...@apache.org wrote:
> > Author: ylavic
> > Date: Fri Apr 12 10:35:10 2024
> > New Revision: 1916925
> >
> > URL: http://svn.apache.org/viewvc?rev=1916925=rev
> > Log:
> > mpm_event: Simplify pollset "good methods" vs APR_POLLSET_WAKEABLE.
> >
> > * server/mpm/event/event.c(setup_threads_runtime):
> >   Simplify pollset creation code.
> >
> > All pollset "good methods" implement APR_POLLSET_WAKEABLE and wake-ability
> > is quite important for MPM event's correctness anyway so simplify code 
> > around
> > pollset creation so as not to suggest that APR_POLLSET_NODEFAULT if favored
> > against APR_POLLSET_WAKEABLE.
> >
> > While at it account for the wakeup pipe in the pollset_size since not all
> > pollset methods seem to do it internally in APR.
> >
> >
> > Modified:
> > httpd/httpd/trunk/server/mpm/event/event.c
> >
> > Modified: httpd/httpd/trunk/server/mpm/event/event.c
> > URL: 
> > http://svn.apache.org/viewvc/httpd/httpd/trunk/server/mpm/event/event.c?rev=1916925=1916924=1916925=diff
> > ==
> > --- httpd/httpd/trunk/server/mpm/event/event.c (original)
> > +++ httpd/httpd/trunk/server/mpm/event/event.c Fri Apr 12 10:35:10 2024
> > @@ -2630,9 +2630,9 @@ static void setup_threads_runtime(void)
> >
> >  /* Create the main pollset */
> >  pollset_flags = APR_POLLSET_THREADSAFE | APR_POLLSET_NOCOPY |
> > -APR_POLLSET_NODEFAULT | APR_POLLSET_WAKEABLE;
> > +APR_POLLSET_WAKEABLE | APR_POLLSET_NODEFAULT;
> >  for (i = 0; i < sizeof(good_methods) / sizeof(good_methods[0]); i++) {
> > -rv = apr_pollset_create_ex(_pollset, pollset_size, pruntime,
> > +rv = apr_pollset_create_ex(_pollset, pollset_size + 1, 
> > pruntime,
>
> You explained this in the commit message above (thanks), but I think it would 
> be good to add a comment
> here in the code why +1 is added to the pollset_size to have the rational at 
> hand when reading the code.

Good point, done in r1916929 for both event and worker.


Regards;
Yann.

Re: pytest results for 2.4.59

[Yann Ylavic]

On Sat, Apr 6, 2024 at 10:46 AM jean-frederic clere  wrote:
>
> 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)
>
> The small example (taken from the internet) seems to behave like httpd
> reporting running threads that have exited...
>
> I have created https://bugzilla.redhat.com/show_bug.cgi?id=2273757 in
> case it is a fedora/rhel bug.

FWIW I find the new pthread_kill() behaviour completely useless. ESRCH
was for threads that exited already but were not joined (i.e.
"inactive" per POSIX), but for threads that are joined/detached (i.e.
"dead" or "end of lifetime") as documented by POSIX it's completely
useless because any pthread_ function usage is already undefined
behaviour on those (IOW, no one should do this).
So glibc conforming to POSIX here by removing ESRCH is just pointless,
they just killed pthread_kill(, 0) for no/bad reasons..

Re: svn commit: r1916926 - in /httpd/httpd/trunk: changes-entries/worker_exit.txt server/mpm/worker/worker.c

[Ruediger Pluem]

On 4/12/24 1:02 PM, yla...@apache.org wrote:
> Author: ylavic
> Date: Fri Apr 12 11:02:31 2024
> New Revision: 1916926
> 
> URL: http://svn.apache.org/viewvc?rev=1916926=rev
> Log:
> mpm_worker: Fix AH00045 about children processes not terminating timely.
> 
> * server/mpm/worker/worker.c(setup_threads_runtime):
>   Create pollset with APR_POLLSET_WAKEABLE to be able to wake up the listener
>   when stopping.
> 
> * server/mpm/worker/worker.c(wakeup_listener):
>   Wake up the listener using the wakeup pipe (apr_pollset_wakeup).
> 
> * server/mpm/worker/worker.c(join_workers):
>   Like mpm_event, don't depend on `pthread_kill(listener_thread, 0)` to check
>   whether the listener has exited (this does not work on some systems), but 
> use
>   the "dying" global variable instead which is set by the listener just before
>   exiting.
> 
> 
> Added:
> httpd/httpd/trunk/changes-entries/worker_exit.txt
> Modified:
> httpd/httpd/trunk/server/mpm/worker/worker.c
> 

> Modified: httpd/httpd/trunk/server/mpm/worker/worker.c
> URL: 
> http://svn.apache.org/viewvc/httpd/httpd/trunk/server/mpm/worker/worker.c?rev=1916926=1916925=1916926=diff
> ==
> --- httpd/httpd/trunk/server/mpm/worker/worker.c (original)
> +++ httpd/httpd/trunk/server/mpm/worker/worker.c Fri Apr 12 11:02:31 2024

> @@ -903,8 +910,17 @@ static void setup_threads_runtime(void)
>  }
>  
>  /* Create the main pollset */
> -rv = apr_pollset_create(_pollset, num_listensocks, pruntime,
> -APR_POLLSET_NOCOPY);
> +pollset_flags = APR_POLLSET_NOCOPY | APR_POLLSET_WAKEABLE;
> +rv = apr_pollset_create(_pollset, num_listensocks + 1, pruntime,

Small comment in the code would be good why we need the +1 above.

> +pollset_flags);
> +if (rv == APR_SUCCESS) {
> +listener_is_wakeable = 1;
> +}
> +else {
> +pollset_flags &= ~APR_POLLSET_WAKEABLE;
> +rv = apr_pollset_create(_pollset, num_listensocks, pruntime,
> +pollset_flags);
> +}
>  if (rv != APR_SUCCESS) {
>  ap_log_error(APLOG_MARK, APLOG_EMERG, rv, ap_server_conf, 
> APLOGNO(03285)
>   "Couldn't create pollset in thread;"

Regards

Rüdiger

Re: svn commit: r1916925 - /httpd/httpd/trunk/server/mpm/event/event.c

[Ruediger Pluem]

On 4/12/24 12:35 PM, yla...@apache.org wrote:
> Author: ylavic
> Date: Fri Apr 12 10:35:10 2024
> New Revision: 1916925
> 
> URL: http://svn.apache.org/viewvc?rev=1916925=rev
> Log:
> mpm_event: Simplify pollset "good methods" vs APR_POLLSET_WAKEABLE.
> 
> * server/mpm/event/event.c(setup_threads_runtime):
>   Simplify pollset creation code.
> 
> All pollset "good methods" implement APR_POLLSET_WAKEABLE and wake-ability
> is quite important for MPM event's correctness anyway so simplify code around
> pollset creation so as not to suggest that APR_POLLSET_NODEFAULT if favored
> against APR_POLLSET_WAKEABLE.
> 
> While at it account for the wakeup pipe in the pollset_size since not all
> pollset methods seem to do it internally in APR.
> 
> 
> Modified:
> httpd/httpd/trunk/server/mpm/event/event.c
> 
> Modified: httpd/httpd/trunk/server/mpm/event/event.c
> URL: 
> http://svn.apache.org/viewvc/httpd/httpd/trunk/server/mpm/event/event.c?rev=1916925=1916924=1916925=diff
> ==
> --- httpd/httpd/trunk/server/mpm/event/event.c (original)
> +++ httpd/httpd/trunk/server/mpm/event/event.c Fri Apr 12 10:35:10 2024
> @@ -2630,9 +2630,9 @@ static void setup_threads_runtime(void)
>  
>  /* Create the main pollset */
>  pollset_flags = APR_POLLSET_THREADSAFE | APR_POLLSET_NOCOPY |
> -APR_POLLSET_NODEFAULT | APR_POLLSET_WAKEABLE;
> +APR_POLLSET_WAKEABLE | APR_POLLSET_NODEFAULT;
>  for (i = 0; i < sizeof(good_methods) / sizeof(good_methods[0]); i++) {
> -rv = apr_pollset_create_ex(_pollset, pollset_size, pruntime,
> +rv = apr_pollset_create_ex(_pollset, pollset_size + 1, 
> pruntime,

You explained this in the commit message above (thanks), but I think it would 
be good to add a comment
here in the code why +1 is added to the pollset_size to have the rational at 
hand when reading the code.

> pollset_flags, good_methods[i]);
>  if (rv == APR_SUCCESS) {
>  listener_is_wakeable = 1;
> @@ -2640,19 +2640,17 @@ static void setup_threads_runtime(void)
>  }
>  }
>  if (rv != APR_SUCCESS) {
> -pollset_flags &= ~APR_POLLSET_WAKEABLE;
> -for (i = 0; i < sizeof(good_methods) / sizeof(good_methods[0]); i++) 
> {
> -rv = apr_pollset_create_ex(_pollset, pollset_size, 
> pruntime,
> -   pollset_flags, good_methods[i]);
> -if (rv == APR_SUCCESS) {
> -break;
> -}
> -}
> -}
> -if (rv != APR_SUCCESS) {
>  pollset_flags &= ~APR_POLLSET_NODEFAULT;
> -rv = apr_pollset_create(_pollset, pollset_size, pruntime,
> +rv = apr_pollset_create(_pollset, pollset_size + 1, pruntime,

Same as above.

>  pollset_flags);
> +if (rv == APR_SUCCESS) {
> +listener_is_wakeable = 1;
> +}
> +else {
> +pollset_flags &= ~APR_POLLSET_WAKEABLE;
> +rv = apr_pollset_create(_pollset, pollset_size, pruntime,
> +pollset_flags);
> +}
>  }
>  if (rv != APR_SUCCESS) {
>  ap_log_error(APLOG_MARK, APLOG_ERR, rv, ap_server_conf, 
> APLOGNO(03103)
> 
> 
> 

Regards

Rüdiger

Re: pytest results for 2.4.59

[Yann Ylavic]

On Sun, Apr 7, 2024 at 2:16 PM Rainer Jung  wrote:
>
> Am 07.04.24 um 09:42 schrieb jean-frederic clere:
> > On 4/6/24 20:02, Rainer Jung wrote:
> >
> >> 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 for testing, now in r1916926.
Finally I did not use the "good methods" (APR_POLLSET_NODEFAULT) to
create the pollset (like in mpm_event) but left the pollset
implementation to be selected as before. It's now using
APR_POLLSET_WAKEABLE though to help wakeup_listener().


Regards;
Yann.

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

[jean-frederic clere]

On 4/9/24 19:06, jean-frederic clere wrote:

Hi,

Has anyone run those tests recently?

I have errors like "MD testdomain.org does not match any VirtualHost 
with ...", probably I am doing something wrong...


It seems ignoring the warnings AH10045 and AH10105 is a possible fix.

--
Cheers

Jean-Frederic

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

[Stefan Eissing via dev]

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

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

pytest test/modules/md/test_310_conf_store.py

[jean-frederic clere]

Hi,

Has anyone run those tests recently?

I have errors like "MD testdomain.org does not match any VirtualHost 
with ...", probably I am doing something wrong...

--
Cheers

Jean-Frederic

Re: Fwd: [Bug 68872] New: xmlhttprequest.onprogress behavior changed after updated to 2.4.59

[Ruediger Pluem]

On 4/8/24 1:47 PM, Eric Covener wrote:
> Any concerns with documenting the ap_trust_cgilike_cl variable in e.g.
> https://httpd.apache.org/docs/2.4/env.html ?

Not from my side.

Regards

Rüdiger

Fwd: [Bug 68872] New: xmlhttprequest.onprogress behavior changed after updated to 2.4.59

[Eric Covener]

Any concerns with documenting the ap_trust_cgilike_cl variable in e.g.
https://httpd.apache.org/docs/2.4/env.html ?



-- Forwarded message -
From: 
Date: Sun, Apr 7, 2024 at 5:49 PM
Subject: [Bug 68872] New: xmlhttprequest.onprogress behavior changed
after updated to 2.4.59
To: 


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

Bug ID: 68872
   Summary: xmlhttprequest.onprogress behavior changed after
updated to 2.4.59
   Product: Apache httpd-2
   Version: 2.4.59
  Hardware: All
OS: All
Status: NEW
  Severity: regression
  Priority: P2
 Component: All
  Assignee: b...@httpd.apache.org
  Reporter: ad...@e-blokos.com
  Target Milestone: ---

Hi Folks,

xmlhttprequest.onprogress does not work anymore since I updated to 2.4.59,
the progress bar is to zero until the end of the progress with this piece of
code in javascript that worked for more than 10 years.

xhr.onprogress = function(event){
if(responseType == "blob"){
if(downSockTab){
if(event){
bytesLoaded = event.loaded;
bytesTotal =
event.target.getResponseHeader('x-decompressed-content-length') ||
event.target.getResponseHeader('content-length') || event.total;
if(downSockBar){
downSockBar =
document.getElementById(downSockBar.id);
if(downSockBar){
downSockBar.style.width =
Math.floor(bytesLoaded / bytesTotal * 200)+"px";
}
}
}
}
}
};

any clue how to make onprogress work as before?

thanks

--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org



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

Re: Problem with pypest and pebble 2.5.1

[Stefan Eissing via dev]

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

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

Hope this works for you as well,

Stefan

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

Re: Problem with pypest and pebble 2.5.1

[Stefan Eissing via dev]

Looking into this now, see what pebble changed.

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

Problem with pypest and pebble 2.5.1

[Rainer Jung]

Hi there,

I tried to check, whether the few remaining sporadic test failures 
during pytest can be solved by updating pebble form 2.4.0 to 2.5.1 
(which seems to be the same as 2.5.0).


Unfortunately I get a lot of FAILED md tests with that version. Does 
anyone see the same?


Here's some more detailed info:

17:10:10.216348 
modules/md/test_502_acmev2_drive.py::TestDrivev2::test_md_502_100
17:10:10.216348 
modules/md/test_502_acmev2_drive.py::TestDrivev2::test_md_502_101
17:10:10.216348 
modules/md/test_502_acmev2_drive.py::TestDrivev2::test_md_502_103
17:10:10.216348 
modules/md/test_502_acmev2_drive.py::TestDrivev2::test_md_502_105
17:10:10.216348 
modules/md/test_502_acmev2_drive.py::TestDrivev2::test_md_502_107
17:10:10.216348 
modules/md/test_502_acmev2_drive.py::TestDrivev2::test_md_502_108
17:10:10.216348 
modules/md/test_502_acmev2_drive.py::TestDrivev2::test_md_502_200
17:10:10.216348 
modules/md/test_602_roundtrip.py::TestRoundtripv2::test_md_602_000
17:10:10.216348 
modules/md/test_602_roundtrip.py::TestRoundtripv2::test_md_602_001
17:10:10.216529 
modules/md/test_602_roundtrip.py::TestRoundtripv2::test_md_602_002

17:10:10.216529 modules/md/test_702_auto.py::TestAutov2::test_md_702_001
17:10:10.216529 modules/md/test_702_auto.py::TestAutov2::test_md_702_002
17:10:10.216529 modules/md/test_702_auto.py::TestAutov2::test_md_702_003
17:10:10.216529 
modules/md/test_702_auto.py::TestAutov2::test_md_702_004[tls-alpn-01]
17:10:10.216529 
modules/md/test_702_auto.py::TestAutov2::test_md_702_004[http-01]

17:10:10.216529 modules/md/test_702_auto.py::TestAutov2::test_md_702_030
17:10:10.216529 modules/md/test_702_auto.py::TestAutov2::test_md_702_031
17:10:10.216529 modules/md/test_702_auto.py::TestAutov2::test_md_702_032
17:10:10.216529 modules/md/test_702_auto.py::TestAutov2::test_md_702_040
17:10:10.216529 
modules/md/test_702_auto.py::TestAutov2::test_md_702_044[tls-alpn-01]
17:10:10.216529 
modules/md/test_720_wildcard.py::TestWildcard::test_md_720_002b
17:10:10.216529 
modules/md/test_720_wildcard.py::TestWildcard::test_md_720_004
17:10:10.216529 
modules/md/test_720_wildcard.py::TestWildcard::test_md_720_005
17:10:10.216529 
modules/md/test_720_wildcard.py::TestWildcard::test_md_720_006
17:10:10.216529 
modules/md/test_720_wildcard.py::TestWildcard::test_md_720_007

17:10:10.216529 modules/md/test_750_eab.py::TestEab::test_md_750_003
17:10:10.216529 modules/md/test_750_eab.py::TestEab::test_md_750_004
17:10:10.216529 modules/md/test_750_eab.py::TestEab::test_md_750_005
17:10:10.216529 modules/md/test_750_eab.py::TestEab::test_md_750_010
17:10:10.216529 modules/md/test_750_eab.py::TestEab::test_md_750_011
17:10:10.216529 modules/md/test_750_eab.py::TestEab::test_md_750_012
17:10:10.216529 modules/md/test_750_eab.py::TestEab::test_md_750_013
17:10:10.216529 modules/md/test_750_eab.py::TestEab::test_md_750_014
17:10:10.216529 modules/md/test_750_eab.py::TestEab::test_md_750_015
17:10:10.216529 modules/md/test_750_eab.py::TestEab::test_md_750_016
17:10:10.216529 modules/md/test_750_eab.py::TestEab::test_md_750_022

The failures in test_750_eab.py seem to be related to the following 
HS256 error messages in the httpd error log:


[Sun Apr 07 17:13:24.571712 2024] [watchdog:debug] [pid 5554:tid 
140101761058560] mod_watchdog.c(170): AH02972: Singleton Watchdog 
(_md_renew_) running
[Sun Apr 07 17:13:24.571824 2024] [md:debug] [pid 5554:tid 
140101761058560] mod_md_drive.c(203): AH10054: md watchdog start, auto 
drive 1 mds
[Sun Apr 07 17:13:24.672025 2024] [md:debug] [pid 5554:tid 
140101761058560] mod_md_drive.c(208): AH10055: md watchdog run, auto 
drive 1 mds
[Sun Apr 07 17:13:24.672112 2024] [md:debug] [pid 5554:tid 
140101761058560] mod_md_drive.c(109): AH10052: 
md(test-md-750-003-1712502785.org): state=1, driving
[Sun Apr 07 17:13:24.672491 2024] [md:debug] [pid 5554:tid 
140101761058560] md_reg.c(1112): test-md-750-003-1712502785.org: init done
[Sun Apr 07 17:13:24.672512 2024] [md:debug] [pid 5554:tid 
140101761058560] md_reg.c(1157): test-md-750-003-1712502785.org: run staging
[Sun Apr 07 17:13:24.672553 2024] [md:debug] [pid 5554:tid 
140101761058560] md_acme_drive.c(714): test-md-750-003-1712502785.org: 
staging started, state=1, attempt=0, acme=https://localhost:14000/dir, 
challenges='http-01'
[Sun Apr 07 17:13:24.672755 2024] [md:debug] [pid 5554:tid 
140101761058560] md_acme_drive.c(752): test-md-750-003-1712502785.org: 
setup staging
[Sun Apr 07 17:13:24.673058 2024] [md:debug] [pid 5554:tid 
140101761058560] md_acme.c(776): get directory from 
https://localhost:14000/dir
[Sun Apr 07 17:13:24.686700 2024] [md:debug] [pid 5554:tid 
140101761058560] md_acmev2_drive.c(101): test-md-750-003-1712502785.org: 
(ACMEv2) need certificate
[Sun Apr 07 17:13:24.686756 2024] [md:debug] [pid 5554:tid 
140101761058560] md_acme_drive.c(115): (2)No such file or directory: 
ACME: looking at existing accounts
[Sun Apr 07 17:13:24.686925 2024] [md:debug] [pid 5554:tid 
140101761058560] 

Re: pytest results for 2.4.59

[Rainer Jung]

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

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

Hi Jean-Frederic and all,

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


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


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




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


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


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


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

Thanks and best regards,

Rainer

Re: pytest results for 2.4.59

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




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 

Bug report for Apache httpd-2 [2024/04/07]

[bugzilla]

+---+
| Bugzilla Bug ID   |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned|
| | OPN=ReopenedVER=Verified(Skipped Closed/Resolved)   |
| |   +-+
| |   | Severity: BLK=Blocker CRI=Critical  REG=Regression  MAJ=Major   |
| |   |   MIN=Minor   NOR=NormalENH=Enhancement TRV=Trivial |
| |   |   +-+
| |   |   | Date Posted |
| |   |   |  +--+
| |   |   |  | Description  |
| |   |   |  |  |
|10747|New|Maj|2002-07-12|ftp SIZE command and 'smart' ftp servers results i|
|11580|Opn|Enh|2002-08-09|generate Content-Location headers |
|12033|Opn|Nor|2002-08-26|Graceful restart immediately result in [warn] long|
|13661|Ass|Enh|2002-10-15|Apache cannot not handle dynamic IP reallocation  |
|14104|Opn|Enh|2002-10-30|not documented: must restart server to load new CR|
|16811|Ass|Maj|2003-02-05|mod_autoindex always return webpages in UTF-8.|
|17244|Ass|Nor|2003-02-20|./configure --help gives false information regardi|
|17497|Opn|Nor|2003-02-27|mod_mime_magic generates incorrect response header|
|20036|Ass|Nor|2003-05-19|Trailing Dots stripped from PATH_INFO environment |
|21260|Opn|Nor|2003-07-02|CacheMaxExpire directive not enforced !   |
|21533|Ass|Cri|2003-07-11|Multiple levels of htacces files can cause mod_aut|
|22484|Opn|Maj|2003-08-16|semaphore problem takes httpd down|
|22686|Opn|Nor|2003-08-25|ab: apr_poll: The timeout specified has expired (7|
|22898|Opn|Nor|2003-09-02|nph scripts with two HTTP header  |
|23911|Opn|Cri|2003-10-18|CGI processes left defunct/zombie under 2.0.54|
|24095|Opn|Cri|2003-10-24|ERROR "Parent: child process exited with status 32|
|24437|Opn|Nor|2003-11-05|mod_auth_ldap doubly-escapes backslash (\) charact|
|24890|Opn|Nor|2003-11-21|Apache config parser should not be local aware ( g|
|25469|Opn|Enh|2003-12-12|create AuthRoot for defining paths to auth files  |
|25484|Ass|Nor|2003-12-12|Non-service Apache cannot be stopped in WinXP |
|26153|Opn|Cri|2004-01-15|Apache cygwin directory traversal vulnerability   |
|27257|Ass|Enh|2004-02-26|rotatelogs with getopt and setuid |
|27715|Ass|Enh|2004-03-16|Client sending misformed Range "bytes = 0-100" ins|
|29090|Ass|Enh|2004-05-19|MultiviewsMatch NegotiatedOnly extensions not resp|
|29510|Ass|Enh|2004-06-10|ab does not support multiple cookies  |
|29644|Ver|Nor|2004-06-17|mod_proxy keeps downloading even after the client |
|30259|Ass|Enh|2004-07-22|When proxy connects to backend, a DNS lookup is do|
|30505|Ass|Enh|2004-08-05|Apache uses 'Error', and not lower level event typ|
|31302|Opn|Cri|2004-09-19|suexec doesn't execute commands if they're not in |
|31352|Ass|Enh|2004-09-21|RFE, Bind to LDAP server with browser supplier use|
|31418|Opn|Nor|2004-09-25|SSLUserName is not usable by other modules|
|32328|Opn|Enh|2004-11-19|Make mod_rewrite escaping optional / expose intern|
|32750|Ass|Maj|2004-12-17|mod_proxy + Win32DisableAcceptEx = memory leak|
|33089|New|Nor|2005-01-13|mod_include: Options +Includes (or IncludesNoExec)|
|34519|New|Enh|2005-04-19|Directory index should emit valid XHTML   |
|35098|Ver|Maj|2005-05-27|Install fails using --prefix  |
|35154|Opn|Nor|2005-06-01|Support for NID_serialNumber, etc. in SSLUserName |
|35652|Opn|Min|2005-07-07|Improve error message: "pcfg_openfile: unable to c|
|35768|Opn|Nor|2005-07-17|Missing file logs at far too high of log level|
|36676|New|Nor|2005-09-15|time() bug in httpd/os/win32/util_win32.c:wait_for|
|36710|Opn|Blk|2005-09-19|CGI output not captured   |
|37006|Ver|Reg|2005-10-11|"pthread" error when compiling under AIX 5.3 using|
|37290|Opn|Min|2005-10-28|DirectoryIndex don't work in scriptaliased directo|
|37564|New|Enh|2005-11-19|Suggestion: mod_suexec SuexecUserGroup directive i|
|38325|Opn|Nor|2006-01-20|impossible to determine AUTH_TYPE of interpreted r|
|38571|New|Enh|2006-02-08|CustomLog directive checked by apachectl configtes|
|38995|New|Nor|2006-03-16|httpd tries to communicate with the CGI daemon eve|
|39275|Opn|Nor|2006-04-11|slow child_init causes MaxClients warning |
|39287|New|Nor|2006-04-12|Incorrect If-Modified-Since validation (due to syn|
|39727|Ass|Nor|2006-06-05|Incorrect ETag on gzip:ed content |
|39748|New|Enh|2006-06-07|Header and POST support for mod_include   |

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: pytest results for 2.4.59

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


--
Cheers

Jean-Frederic

Re: pytest results for 2.4.59

[Yann Ylavic]

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


Regards;
Yann.
Index: server/mpm/worker/worker.c
===
--- server/mpm/worker/worker.c	(revision 1916768)
+++ server/mpm/worker/worker.c	(working copy)
@@ -125,10 +125,11 @@ static int max_workers = 0;
 static int server_limit = 0;
 static int thread_limit = 0;
 static int had_healthy_child = 0;
-static int dying = 0;
+static volatile int dying = 0;
 static int workers_may_exit = 0;
 static int start_thread_may_exit = 0;
 static int listener_may_exit = 0;
+static int listener_is_wakeable = 0; /* Pollset supports APR_POLLSET_WAKEABLE */
 static int requests_this_child;
 static int num_listensocks = 0;
 static int resource_shortage = 0;
@@ -272,6 +273,15 @@ static void close_worker_sockets(void)
 static void wakeup_listener(void)
 {
 listener_may_exit = 1;
+
+/* Unblock the listener if it's poll()ing */
+if (worker_pollset && listener_is_wakeable) {
+apr_pollset_wakeup(worker_pollset);
+}
+
+/* unblock the listener if it's waiting for a worker */
+ap_queue_info_term(worker_queue_info);
+
 if (!listener_os_thread) {
 /* XXX there is an obscure path that this doesn't handle perfectly:
  * right after listener thread is created but before
@@ -280,10 +290,6 @@ static void wakeup_listener(void)
  */
 return;
 }
-
-/* unblock the listener if it's waiting for a worker */
-ap_queue_info_term(worker_queue_info);
-
 /*
  * we should just be able to "kill(ap_my_pid, LISTENER_SIGNAL)" on all
  * platforms and wake up the listener thread since it is the only thread
@@ -716,6 +722,7 @@ static void * APR_THREAD_FUNC listener_thread(apr_
 ap_close_listeners_ex(my_bucket->listeners);
 ap_queue_info_free_idle_pools(worker_queue_info);
 ap_queue_term(worker_queue);
+
 dying = 1;
 ap_scoreboard_image->parent[process_slot].quiescing = 1;
 
@@ -861,6 +868,10 @@ static void create_listener_thread(thread_starter
 static void setup_threads_runtime(void)
 {
 ap_listen_rec *lr;
+int pollset_flags, i;
+const int good_methods[] = { APR_POLLSET_KQUEUE,
+ APR_POLLSET_PORT,
+ APR_POLLSET_EPOLL };
 apr_status_t rv;
 
 /* All threads (listener, workers) and synchronization objects (queues,
@@ -894,9 +905,31 @@ static void setup_threads_runtime(void)
 }
 
 /* Create the main pollset */
-rv = apr_pollset_create(_pollset, num_listensocks, pruntime,
-APR_POLLSET_NOCOPY);
+pollset_flags = APR_POLLSET_NOCOPY | APR_POLLSET_NODEFAULT | APR_POLLSET_WAKEABLE;
+for (i = 0; i < sizeof(good_methods) / sizeof(good_methods[0]); i++) {
+rv = apr_pollset_create_ex(_pollset, num_listensocks, pruntime,
+   pollset_flags, good_methods[i]);
+if (rv == APR_SUCCESS) {
+listener_is_wakeable = 1;
+break;
+}
+}
 if (rv != APR_SUCCESS) {
+pollset_flags &= ~APR_POLLSET_WAKEABLE;
+for (i = 0; i < sizeof(good_methods) / sizeof(good_methods[0]); i++) {
+rv = apr_pollset_create_ex(_pollset, num_listensocks, pruntime,
+   pollset_flags, good_methods[i]);
+if (rv == APR_SUCCESS) {
+break;
+}
+}
+}
+if (rv != APR_SUCCESS) {
+pollset_flags &= ~APR_POLLSET_NODEFAULT;
+rv = apr_pollset_create(_pollset, num_listensocks, pruntime,
+pollset_flags);
+}
+if (rv != APR_SUCCESS) {
 ap_log_error(APLOG_MARK, APLOG_EMERG, rv, ap_server_conf, APLOGNO(03285)
  "Couldn't create pollset in thread;"
  " check system or user limits");
@@ -1031,19 +1064,17 @@ static void join_workers(apr_thread_t *listener, a
  

Re: pytest results for 2.4.59

[jean-frederic clere]

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



On 4/5/24 12:59 AM, Rainer Jung wrote:

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: 

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

[Rainer Jung]

Hi Stefan and all,

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


Thanks and regards,

Rainer


Am 05.04.24 um 09:04 schrieb Stefan Eissing via dev:

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


Am 05.04.2024 um 00:48 schrieb rj...@apache.org:

Author: rjung
Date: Thu Apr  4 22:48:03 2024
New Revision: 1916809

URL: http://svn.apache.org/viewvc?rev=1916809=rev
Log:
Fix occasional pytest failures
in modules/http2/test_800_websockets.py
(test_h2_800_04_non_ws_resource and
test_h2_800_09b_unsupported) due to
additional RST messages.

Backport of r1916808 from trunk.

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

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

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

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

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

Re: pytest results for 2.4.59

[jean-frederic clere]

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



On 4/5/24 12:59 AM, Rainer Jung wrote:

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: 

Re: pytest results for 2.4.59

[jean-frederic clere]

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



On 4/5/24 12:59 AM, Rainer Jung wrote:

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: 

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

[Stefan Eissing via dev]

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

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

Re: pytest results for 2.4.59

[jean-frederic clere]

On 4/5/24 00:59, Rainer Jung wrote:
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


I have noted those too on fedora 39, I am planning to have a look...

--
Cheers

Jean-Frederic

Re: pytest results for 2.4.59

[Ruediger Pluem]

On 4/5/24 12:59 AM, Rainer Jung wrote:
> 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): 

Re: pytest results for 2.4.59

[Rainer Jung]

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


I have a few additional sporadic ERRORS:

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

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


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



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


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


B] Hanging httpd child processes

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


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

and

AH00276: the listener thread didn't exit

It happened in

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

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

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

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


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

- most threads terminate with

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


- watchdog thread terminates (?) with

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


- one worker thread seems not to stop:

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

pytest results for 2.4.59

[Rainer Jung]

Hi there,

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


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


I see 4 failures:

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


__ TestTiming.test_h2_009_01 
___

self = 
env = 

def test_h2_009_01(self, env):
...

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

E   assert False

modules/http2/test_009_timing.py:46: AssertionError

and

__ TestTiming.test_h2_009_02 
___


self = 
env = 

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

E   assert False

modules/http2/test_009_timing.py:74: AssertionError


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



B] buffer test failure TestBuffering.test_h2_712_02

self = 
env = 

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

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


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

stutter = datetime.timedelta(seconds=1)

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

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

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



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



C] a single websocket test failure 
TestWebSockets.test_h2_800_04_non_ws_resource


self = 
env = , ws_server = None

def test_h2_800_04_non_ws_resource(self, env: H2TestEnv, ws_server):
r, infos, frames = ws_run(env, path='/alive.json')
assert r.exit_code == 0, f'{r}'
>   assert infos == ['[1] :status: 502', '[1] EOF'], f'{r}'
E   AssertionError: ExecResult[code=0, args=['/path/to/h2ws', '-vv', 
'-c', 'localhost:5002', 
'ws://cgi.tests.httpd.apache.org:5002/alive.json', 'ws-stdin']

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

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

modules/http2/test_800_websockets.py:178: AssertionError

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


Best regards,

Rainer

Re: [ANNOUNCEMENT] Apache HTTP Server 2.4.59 Released

[Eric Covener]

Resolved now, took a todo to make sure we don't get this far in the
process if the site cannot be re-built.

On Thu, Apr 4, 2024 at 11:33 AM Eric Covener  wrote:
>
> Thanks/Sorry, working on it now.
>
> On Thu, Apr 4, 2024 at 11:23 AM BUSH Steve via dev  
> wrote:
> >
> > Hi Eric,
> >
> >
> >
> > Just an FYI: The https://httpd.apache.org/security/vulnerabilities_24.html 
> > file is missing.
> >
> >
> >
> > https://httpd.apache.org/security/
> >
> >
> >
> > Thanks,
> >
> > Steve Bush
> >
> >
> >
> > From: covener 
> > Sent: Thursday, April 4, 2024 6:54 AM
> > To: annou...@httpd.apache.org
> > Subject: [ANNOUNCEMENT] Apache HTTP Server 2.4.59 Released
> >
> >
> >
> > Apache HTTP Server 2. 4. 59 Released April 04, 2024 The Apache Software 
> > Foundation and the Apache HTTP Server Project are pleased to announce the 
> > release of version 2. 4. 59 of the Apache HTTP Server ("Apache"). This 
> > version of Apache is our latest
> >
> > Apache HTTP Server 2.4.59 Released
> >
> >
> >
> >April 04, 2024
> >
> >
> >
> >The Apache Software Foundation and the Apache HTTP Server Project
> >
> >are pleased to announce the release of version 2.4.59 of the Apache
> >
> >HTTP Server ("Apache").  This version of Apache is our latest GA
> >
> >release of the new generation 2.4.x branch of Apache HTTPD and
> >
> >represents fifteen years of innovation by the project, and is
> >
> >recommended over all previous releases. This release of Apache is
> >
> >a security, feature and bug fix release.
> >
> >
> >
> >We consider this release to be the best version of Apache available, and
> >
> >encourage users of all prior versions to upgrade.
> >
> >
> >
> >Apache HTTP Server 2.4.59 is available for download from:
> >
> >
> >
> >  
> > https://urldefense.com/v3/__https://httpd.apache.org/download.cgi__;!!FbCVDoc3r24SyHFW!90aLZxJz8v9h9Kjw6c8g56Tx2CK_uJ2yN4oR-keptUBiTXodK5IUaXv6ObxDT0ah-kYLWQpXr_qL2qM7$[httpd[.]apache[.]org]
> >
> >
> >
> >Apache 2.4 offers numerous enhancements, improvements, and performance
> >
> >boosts over the 2.2 codebase.  For an overview of new features
> >
> >introduced since 2.4 please see:
> >
> >
> >
> >  
> > https://urldefense.com/v3/__https://httpd.apache.org/docs/trunk/new_features_2_4.html__;!!FbCVDoc3r24SyHFW!90aLZxJz8v9h9Kjw6c8g56Tx2CK_uJ2yN4oR-keptUBiTXodK5IUaXv6ObxDT0ah-kYLWQpXr48c1jIZ$[httpd[.]apache[.]org]
> >
> >
> >
> >Please see the CHANGES_2.4 file, linked from the download page, for a
> >
> >full list of changes. A condensed list, CHANGES_2.4.59 includes only
> >
> >those changes introduced since the prior 2.4 release.  A summary of all
> >
> >of the security vulnerabilities addressed in this and earlier releases
> >
> >is available:
> >
> >
> >
> >  
> > https://urldefense.com/v3/__https://httpd.apache.org/security/vulnerabilities_24.html__;!!FbCVDoc3r24SyHFW!90aLZxJz8v9h9Kjw6c8g56Tx2CK_uJ2yN4oR-keptUBiTXodK5IUaXv6ObxDT0ah-kYLWQpXrxf1GEXG$[httpd[.]apache[.]org]
> >
> >
> >
> >This release requires the Apache Portable Runtime (APR), minimum
> >
> >version 1.5.x, and APR-Util, minimum version 1.5.x. Some features may
> >
> >require the 1.6.x version of both APR and APR-Util. The APR libraries
> >
> >must be upgraded for all features of httpd to operate correctly.
> >
> >
> >
> >This release builds on and extends the Apache 2.2 API.  Modules written
> >
> >for Apache 2.2 will need to be recompiled in order to run with Apache
> >
> >2.4, and require minimal or no source code changes.
> >
> >
> >
> >  
> > https://urldefense.com/v3/__https://svn.apache.org/repos/asf/httpd/httpd/trunk/VERSIONING__;!!FbCVDoc3r24SyHFW!90aLZxJz8v9h9Kjw6c8g56Tx2CK_uJ2yN4oR-keptUBiTXodK5IUaXv6ObxDT0ah-kYLWQpXr6mT32m1$[svn[.]apache[.]org]
> >
> >
> >
> >When upgrading or installing this version of Apache, please bear in mind
> >
> >that if you intend to use Apache with one of the threaded MPMs (other
> >
> >than the Prefork MPM), you must ensure that any modules you will be
> >
> >using (and the libraries they depend on) are thread-safe.
> >
> >
> >
> >Please note the 2.2.x branch has now passed the end of life at the Apache
> >
> >HTTP Server project and no further activity will occur including security
> >
> >patches.  Users must promptly complete their transitions to this 2.4.x
> >
> >release of httpd to benefit from further bug fixes or new features.
> >
> >
> >
> >
> >
> > This email and any attachments are intended solely for the use of the 
> > individual or entity to whom it is addressed and may be confidential and/or 
> > privileged.
> >
> > If you are not one of the named recipients or have received this email in 
> > error,
> >
> > (i) you should not read, disclose, or copy it,
> >
> > (ii) please notify sender of your receipt by reply email and delete this 
> > email and all attachments,
> >
> > (iii) Dassault Systèmes does not accept or 

Re: [ANNOUNCEMENT] Apache HTTP Server 2.4.59 Released

[Eric Covener]

Thanks/Sorry, working on it now.

On Thu, Apr 4, 2024 at 11:23 AM BUSH Steve via dev  wrote:
>
> Hi Eric,
>
>
>
> Just an FYI: The https://httpd.apache.org/security/vulnerabilities_24.html 
> file is missing.
>
>
>
> https://httpd.apache.org/security/
>
>
>
> Thanks,
>
> Steve Bush
>
>
>
> From: covener 
> Sent: Thursday, April 4, 2024 6:54 AM
> To: annou...@httpd.apache.org
> Subject: [ANNOUNCEMENT] Apache HTTP Server 2.4.59 Released
>
>
>
> Apache HTTP Server 2. 4. 59 Released April 04, 2024 The Apache Software 
> Foundation and the Apache HTTP Server Project are pleased to announce the 
> release of version 2. 4. 59 of the Apache HTTP Server ("Apache"). This 
> version of Apache is our latest
>
> Apache HTTP Server 2.4.59 Released
>
>
>
>April 04, 2024
>
>
>
>The Apache Software Foundation and the Apache HTTP Server Project
>
>are pleased to announce the release of version 2.4.59 of the Apache
>
>HTTP Server ("Apache").  This version of Apache is our latest GA
>
>release of the new generation 2.4.x branch of Apache HTTPD and
>
>represents fifteen years of innovation by the project, and is
>
>recommended over all previous releases. This release of Apache is
>
>a security, feature and bug fix release.
>
>
>
>We consider this release to be the best version of Apache available, and
>
>encourage users of all prior versions to upgrade.
>
>
>
>Apache HTTP Server 2.4.59 is available for download from:
>
>
>
>  
> https://urldefense.com/v3/__https://httpd.apache.org/download.cgi__;!!FbCVDoc3r24SyHFW!90aLZxJz8v9h9Kjw6c8g56Tx2CK_uJ2yN4oR-keptUBiTXodK5IUaXv6ObxDT0ah-kYLWQpXr_qL2qM7$[httpd[.]apache[.]org]
>
>
>
>Apache 2.4 offers numerous enhancements, improvements, and performance
>
>boosts over the 2.2 codebase.  For an overview of new features
>
>introduced since 2.4 please see:
>
>
>
>  
> https://urldefense.com/v3/__https://httpd.apache.org/docs/trunk/new_features_2_4.html__;!!FbCVDoc3r24SyHFW!90aLZxJz8v9h9Kjw6c8g56Tx2CK_uJ2yN4oR-keptUBiTXodK5IUaXv6ObxDT0ah-kYLWQpXr48c1jIZ$[httpd[.]apache[.]org]
>
>
>
>Please see the CHANGES_2.4 file, linked from the download page, for a
>
>full list of changes. A condensed list, CHANGES_2.4.59 includes only
>
>those changes introduced since the prior 2.4 release.  A summary of all
>
>of the security vulnerabilities addressed in this and earlier releases
>
>is available:
>
>
>
>  
> https://urldefense.com/v3/__https://httpd.apache.org/security/vulnerabilities_24.html__;!!FbCVDoc3r24SyHFW!90aLZxJz8v9h9Kjw6c8g56Tx2CK_uJ2yN4oR-keptUBiTXodK5IUaXv6ObxDT0ah-kYLWQpXrxf1GEXG$[httpd[.]apache[.]org]
>
>
>
>This release requires the Apache Portable Runtime (APR), minimum
>
>version 1.5.x, and APR-Util, minimum version 1.5.x. Some features may
>
>require the 1.6.x version of both APR and APR-Util. The APR libraries
>
>must be upgraded for all features of httpd to operate correctly.
>
>
>
>This release builds on and extends the Apache 2.2 API.  Modules written
>
>for Apache 2.2 will need to be recompiled in order to run with Apache
>
>2.4, and require minimal or no source code changes.
>
>
>
>  
> https://urldefense.com/v3/__https://svn.apache.org/repos/asf/httpd/httpd/trunk/VERSIONING__;!!FbCVDoc3r24SyHFW!90aLZxJz8v9h9Kjw6c8g56Tx2CK_uJ2yN4oR-keptUBiTXodK5IUaXv6ObxDT0ah-kYLWQpXr6mT32m1$[svn[.]apache[.]org]
>
>
>
>When upgrading or installing this version of Apache, please bear in mind
>
>that if you intend to use Apache with one of the threaded MPMs (other
>
>than the Prefork MPM), you must ensure that any modules you will be
>
>using (and the libraries they depend on) are thread-safe.
>
>
>
>Please note the 2.2.x branch has now passed the end of life at the Apache
>
>HTTP Server project and no further activity will occur including security
>
>patches.  Users must promptly complete their transitions to this 2.4.x
>
>release of httpd to benefit from further bug fixes or new features.
>
>
>
>
>
> This email and any attachments are intended solely for the use of the 
> individual or entity to whom it is addressed and may be confidential and/or 
> privileged.
>
> If you are not one of the named recipients or have received this email in 
> error,
>
> (i) you should not read, disclose, or copy it,
>
> (ii) please notify sender of your receipt by reply email and delete this 
> email and all attachments,
>
> (iii) Dassault Systèmes does not accept or assume any liability or 
> responsibility for any use of or reliance on this email.
>
>
> Please be informed that your personal data are processed according to our 
> data privacy policy as described on our website. Should you have any 
> questions related to personal data protection, please contact 3DS Data 
> Protection Officer https://www.3ds.com/privacy-policy/contact/
>
>


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

RE: [ANNOUNCEMENT] Apache HTTP Server 2.4.59 Released

[BUSH Steve via dev]

Hi Eric,

Just an FYI: The https://httpd.apache.org/security/vulnerabilities_24.html file 
is missing.

https://httpd.apache.org/security/

Thanks,
Steve Bush

From: covener 
Sent: Thursday, April 4, 2024 6:54 AM
To: annou...@httpd.apache.org
Subject: [ANNOUNCEMENT] Apache HTTP Server 2.4.59 Released

Apache HTTP Server 2. 4. 59 Released April 04, 2024 The Apache Software 
Foundation and the Apache HTTP Server Project are pleased to announce the 
release of version 2. 4. 59 of the Apache HTTP Server ("Apache"). This version 
of Apache is our latest


Apache HTTP Server 2.4.59 Released



   April 04, 2024



   The Apache Software Foundation and the Apache HTTP Server Project

   are pleased to announce the release of version 2.4.59 of the Apache

   HTTP Server ("Apache").  This version of Apache is our latest GA

   release of the new generation 2.4.x branch of Apache HTTPD and

   represents fifteen years of innovation by the project, and is

   recommended over all previous releases. This release of Apache is

   a security, feature and bug fix release.



   We consider this release to be the best version of Apache available, and

   encourage users of all prior versions to upgrade.



   Apache HTTP Server 2.4.59 is available for download from:



 
https://urldefense.com/v3/__https://httpd.apache.org/download.cgi__;!!FbCVDoc3r24SyHFW!90aLZxJz8v9h9Kjw6c8g56Tx2CK_uJ2yN4oR-keptUBiTXodK5IUaXv6ObxDT0ah-kYLWQpXr_qL2qM7$[httpd[.]apache[.]org]



   Apache 2.4 offers numerous enhancements, improvements, and performance

   boosts over the 2.2 codebase.  For an overview of new features

   introduced since 2.4 please see:



 
https://urldefense.com/v3/__https://httpd.apache.org/docs/trunk/new_features_2_4.html__;!!FbCVDoc3r24SyHFW!90aLZxJz8v9h9Kjw6c8g56Tx2CK_uJ2yN4oR-keptUBiTXodK5IUaXv6ObxDT0ah-kYLWQpXr48c1jIZ$[httpd[.]apache[.]org]



   Please see the CHANGES_2.4 file, linked from the download page, for a

   full list of changes. A condensed list, CHANGES_2.4.59 includes only

   those changes introduced since the prior 2.4 release.  A summary of all

   of the security vulnerabilities addressed in this and earlier releases

   is available:



 
https://urldefense.com/v3/__https://httpd.apache.org/security/vulnerabilities_24.html__;!!FbCVDoc3r24SyHFW!90aLZxJz8v9h9Kjw6c8g56Tx2CK_uJ2yN4oR-keptUBiTXodK5IUaXv6ObxDT0ah-kYLWQpXrxf1GEXG$[httpd[.]apache[.]org]



   This release requires the Apache Portable Runtime (APR), minimum

   version 1.5.x, and APR-Util, minimum version 1.5.x. Some features may

   require the 1.6.x version of both APR and APR-Util. The APR libraries

   must be upgraded for all features of httpd to operate correctly.



   This release builds on and extends the Apache 2.2 API.  Modules written

   for Apache 2.2 will need to be recompiled in order to run with Apache

   2.4, and require minimal or no source code changes.



 
https://urldefense.com/v3/__https://svn.apache.org/repos/asf/httpd/httpd/trunk/VERSIONING__;!!FbCVDoc3r24SyHFW!90aLZxJz8v9h9Kjw6c8g56Tx2CK_uJ2yN4oR-keptUBiTXodK5IUaXv6ObxDT0ah-kYLWQpXr6mT32m1$[svn[.]apache[.]org]



   When upgrading or installing this version of Apache, please bear in mind

   that if you intend to use Apache with one of the threaded MPMs (other

   than the Prefork MPM), you must ensure that any modules you will be

   using (and the libraries they depend on) are thread-safe.



   Please note the 2.2.x branch has now passed the end of life at the Apache

   HTTP Server project and no further activity will occur including security

   patches.  Users must promptly complete their transitions to this 2.4.x

   release of httpd to benefit from further bug fixes or new features.





This email and any attachments are intended solely for the use of the 
individual or entity to whom it is addressed and may be confidential and/or 
privileged.

If you are not one of the named recipients or have received this email in error,

(i) you should not read, disclose, or copy it,

(ii) please notify sender of your receipt by reply email and delete this email 
and all attachments,

(iii) Dassault Systèmes does not accept or assume any liability or 
responsibility for any use of or reliance on this email.

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

[Stefan Eissing via dev]

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

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

> 
>> Steffen
>> On Thursday 04/04/2024 at 13:25, jean-frederic clere  wrote:
>>> On 4/4/24 12:49, Steffen Land wrote:
 
 -1
 Get an error:
 ErrorC2065'DAV_WALKTYPE_TOLERANT': undeclared identifier
 mod_dav_fsC:\VS17\Win32\httpd-2.4\modules\dav\fs\repos.c1599
>>> 
>>> I didn't see any problem while building on windows (using cmake and VS19).
>>> 
>>> +++
>>> ModeLastWriteTime Length Name
>>> - -- 
>>> -a 4/3/2024   7:56 AM 101376 mod_dav.so
>>> -a 4/3/2024   7:56 AM  51200 mod_dav_fs.so
>>> -a 4/3/2024   7:56 AM  23552 mod_dav_lock.so
>>> +++
>>> 
>>> DAV_WALKTYPE_TOLERANT is in ./modules/dav/main/mod_dav.h line 1826
>>> 
 
 Steffen
 On 2024/04/03 12:26:09 Eric Covener wrote:
> 
> Hi all,
> 
> (After only minor embarrassment of patching tags/2.4.55 instead of 
> 2.4.x...)
> 
> Please find below the proposed release tarball and signatures:
> 
> https://dist.apache.org/repos/dist/dev/httpd/
> 
> I would like to call a SHORTENED VOTE to release
> this candidate tarball httpd-2.4.59-rc1 as 2.4.59:
> [ ] +1: It's not just good, it's good enough!
> [ ] +0: Let's have a talk.
> [ ] -1: There's trouble in paradise. Here's what's wrong.
> 
> The computed digests of the tarball up for vote are:
> = e4ec4ce12c6c8f5a794dc2263d126cb1d6ef667f034c4678ec945d61286e8b0f
> = 
> baa96a7c9bba48f758ca9b3e3d63f0c65db960653618109d4d7bcbf3d4776d1d51453beb65e5af57655f0b1cfb88913842bc3a117fe7acc754ddb43d4524bc82
> 
> The SVN candidate source is found at tags/2.4.59-rc1-candidate.
> 
>>> 
>>> -- 
>>> Cheers
>>> 
>>> Jean-Frederic
>>> 
> 
> -- 
> Cheers
> 
> Jean-Frederic
> 

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

[jean-frederic clere]

On 4/4/24 13:59, SteffenAL wrote:


Thanks for the hint.
Yep, needed an extra include. Not using cmake.


mod_http2 shows still version 2.0.22 (h2_version.h).
Should it be 2.0.26 ?


or better 2.0.27? ;-)

We picked the fixes but not version...



Steffen


On Thursday 04/04/2024 at 13:25, jean-frederic clere  wrote:

On 4/4/24 12:49, Steffen Land wrote:


-1
Get an error:
Error    C2065    'DAV_WALKTYPE_TOLERANT': undeclared identifier
mod_dav_fs    C:\VS17\Win32\httpd-2.4\modules\dav\fs\repos.c    1599


I didn't see any problem while building on windows (using cmake and 
VS19).


+++
Mode    LastWriteTime Length Name
    - -- 
-a 4/3/2024   7:56 AM 101376 mod_dav.so
-a 4/3/2024   7:56 AM  51200 mod_dav_fs.so
-a 4/3/2024   7:56 AM  23552 mod_dav_lock.so
+++

DAV_WALKTYPE_TOLERANT is in ./modules/dav/main/mod_dav.h line 1826



Steffen
On 2024/04/03 12:26:09 Eric Covener wrote:


Hi all,

(After only minor embarrassment of patching tags/2.4.55 instead of 
2.4.x...)


Please find below the proposed release tarball and signatures:

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

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

The computed digests of the tarball up for vote are:
= e4ec4ce12c6c8f5a794dc2263d126cb1d6ef667f034c4678ec945d61286e8b0f
= 
baa96a7c9bba48f758ca9b3e3d63f0c65db960653618109d4d7bcbf3d4776d1d51453beb65e5af57655f0b1cfb88913842bc3a117fe7acc754ddb43d4524bc82


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



--
Cheers

Jean-Frederic







--
Cheers

Jean-Frederic

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

[Jim Jagielski]

+1: macOS 14.4.1/Xcode 15.3, CentOS8, Ubuntu 18.04LTS, 20.04LTS, 22.04LTS

> On Apr 3, 2024, at 8:26 AM, Eric Covener  wrote:
> 
> Hi all,
> 
> (After only minor embarrassment of patching tags/2.4.55 instead of 2.4.x...)
> 
> Please find below the proposed release tarball and signatures:
> 
> https://dist.apache.org/repos/dist/dev/httpd/
> 
> I would like to call a SHORTENED VOTE to release
> this candidate tarball httpd-2.4.59-rc1 as 2.4.59:
> [ ] +1: It's not just good, it's good enough!
> [ ] +0: Let's have a talk.
> [ ] -1: There's trouble in paradise. Here's what's wrong.
> 
> The computed digests of the tarball up for vote are:
> = e4ec4ce12c6c8f5a794dc2263d126cb1d6ef667f034c4678ec945d61286e8b0f
> = 
> baa96a7c9bba48f758ca9b3e3d63f0c65db960653618109d4d7bcbf3d4776d1d51453beb65e5af57655f0b1cfb88913842bc3a117fe7acc754ddb43d4524bc82
> 
> The SVN candidate source is found at tags/2.4.59-rc1-candidate.

Re: mod_systemd: refactor to get rid of libsystemd dependency?

[Jim Jagielski]

+1

> On Apr 4, 2024, at 5:43 AM, Ruediger Pluem  wrote:
> 
> 
> 
> On 4/3/24 4:32 PM, Joe Orton wrote:
>> On Tue, Apr 02, 2024 at 12:25:40PM +0200, Rainer Jung wrote:
>>> 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?
>> 
>> The trunk mod_systemd has got slightly wider library use than just 
>> sd_notify - so it is not quite that simple. If there was an alternative 
>> minimal library implementing the sd_* API parts required, that would 
>> definitely make sense. I'm not sure that reimplementing them all from 
>> scratch makes sense (especially multiplied by N projects doing this).
>> 
> 
> +1
> 
>> It looks like systemd folks have also changed the library implementation 
>> to dlopen() the various dependant libraries on demand now rather than 
>> directly linking to them, which removes the specific attack vector used 
>> here IIUC.
> +1. Unless the systemd folks show that they are unwilling to address issues
> I would stay with libsystemd.
> 
> Regards
> 
> Rüdiger

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

[Eric Covener]

On Thu, Apr 4, 2024 at 8:12 AM Eric Covener  wrote:

Proceeding with release now, thanks everyone for testing.

> FYI I plan to call this in about an hour with the following binding +1:
> covener, icing, jorton, thumbs, gbechis, jfclere, ylavic, minfrin


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

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

[Eric Covener]

FYI I plan to call this in about an hour with the following binding +1:
covener, icing, jorton, thumbs, gbechis, jfclere, ylavic, minfrin


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

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

[SteffenAL]

Thanks for the hint.
Yep, needed an extra include. Not using cmake.


mod_http2 shows still version 2.0.22 (h2_version.h).
Should it be 2.0.26 ?

Steffen


On Thursday 04/04/2024 at 13:25, jean-frederic clere  wrote:

On 4/4/24 12:49, Steffen Land wrote:


-1
Get an error:
Error	C2065	'DAV_WALKTYPE_TOLERANT': undeclared 
identifier	mod_dav_fs	C:\VS17\Win32\httpd-2.4\modules\dav\fs\repos.c	1599


I didn't see any problem while building on windows (using cmake and 
VS19).


+++
ModeLastWriteTime Length Name
- -- 
-a 4/3/2024   7:56 AM 101376 mod_dav.so
-a 4/3/2024   7:56 AM  51200 mod_dav_fs.so
-a 4/3/2024   7:56 AM  23552 mod_dav_lock.so
+++

DAV_WALKTYPE_TOLERANT is in ./modules/dav/main/mod_dav.h line 1826



Steffen
On 2024/04/03 12:26:09 Eric Covener wrote:


Hi all,

(After only minor embarrassment of patching tags/2.4.55 instead of 
2.4.x...)


Please find below the proposed release tarball and signatures:

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

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

The computed digests of the tarball up for vote are:
= e4ec4ce12c6c8f5a794dc2263d126cb1d6ef667f034c4678ec945d61286e8b0f
= 
baa96a7c9bba48f758ca9b3e3d63f0c65db960653618109d4d7bcbf3d4776d1d51453beb65e5af57655f0b1cfb88913842bc3a117fe7acc754ddb43d4524bc82


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



--
Cheers

Jean-Frederic

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

[jean-frederic clere]

On 4/4/24 12:49, Steffen Land wrote:

-1
Get an error:

Error   C2065   'DAV_WALKTYPE_TOLERANT': undeclared identifier  mod_dav_fs  
C:\VS17\Win32\httpd-2.4\modules\dav\fs\repos.c  1599


I didn't see any problem while building on windows (using cmake and VS19).

+++
ModeLastWriteTime Length Name
- -- 
-a 4/3/2024   7:56 AM 101376 mod_dav.so
-a 4/3/2024   7:56 AM  51200 mod_dav_fs.so
-a 4/3/2024   7:56 AM  23552 mod_dav_lock.so
+++

DAV_WALKTYPE_TOLERANT is in ./modules/dav/main/mod_dav.h line 1826



Steffen

On 2024/04/03 12:26:09 Eric Covener wrote:

Hi all,

(After only minor embarrassment of patching tags/2.4.55 instead of 2.4.x...)

Please find below the proposed release tarball and signatures:

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

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

The computed digests of the tarball up for vote are:
= e4ec4ce12c6c8f5a794dc2263d126cb1d6ef667f034c4678ec945d61286e8b0f
= 
baa96a7c9bba48f758ca9b3e3d63f0c65db960653618109d4d7bcbf3d4776d1d51453beb65e5af57655f0b1cfb88913842bc3a117fe7acc754ddb43d4524bc82

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



--
Cheers

Jean-Frederic

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

[Yann Ylavic]

On Thu, Apr 4, 2024 at 12:52 PM Steffen Land  wrote:
>
> -1
> Get an error:
>
> Error   C2065   'DAV_WALKTYPE_TOLERANT': undeclared identifier  mod_dav_fs
>   C:\VS17\Win32\httpd-2.4\modules\dav\fs\repos.c  1599

Are you compiling with an old "mod_dav.h" somewhere in the -I[nclude] path?
Because DAV_WALKTYPE_TOLERANT is well defined in the new "mod_dav.h"
(of 2.4.59) which is also correctly #include'd in
"modules\dav\fs\repos.c"..

Regards;
Yann.

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

[Ruediger Pluem]

Are you sure that you did not use outdated headers somehow?

DAV_WALKTYPE_TOLERANT is defined in modules/dav/main/mod_dav.h

Regards

Rüdiger

On 4/4/24 12:49 PM, Steffen Land wrote:
> -1 
> Get an error:
> 
> Error C2065   'DAV_WALKTYPE_TOLERANT': undeclared identifier  mod_dav_fs  
> C:\VS17\Win32\httpd-2.4\modules\dav\fs\repos.c  1599
> 
> Steffen 
> 
> On 2024/04/03 12:26:09 Eric Covener wrote:
>> Hi all,
>>
>> (After only minor embarrassment of patching tags/2.4.55 instead of 2.4.x...)
>>
>> Please find below the proposed release tarball and signatures:
>>
>> https://dist.apache.org/repos/dist/dev/httpd/
>>
>> I would like to call a SHORTENED VOTE to release
>> this candidate tarball httpd-2.4.59-rc1 as 2.4.59:
>> [ ] +1: It's not just good, it's good enough!
>> [ ] +0: Let's have a talk.
>> [ ] -1: There's trouble in paradise. Here's what's wrong.
>>
>> The computed digests of the tarball up for vote are:
>> = e4ec4ce12c6c8f5a794dc2263d126cb1d6ef667f034c4678ec945d61286e8b0f
>> = 
>> baa96a7c9bba48f758ca9b3e3d63f0c65db960653618109d4d7bcbf3d4776d1d51453beb65e5af57655f0b1cfb88913842bc3a117fe7acc754ddb43d4524bc82
>>
>> The SVN candidate source is found at tags/2.4.59-rc1-candidate.
>>
> 

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

[Steffen Land]

-1 
Get an error:

Error   C2065   'DAV_WALKTYPE_TOLERANT': undeclared identifier  mod_dav_fs  
C:\VS17\Win32\httpd-2.4\modules\dav\fs\repos.c  1599

Steffen 

On 2024/04/03 12:26:09 Eric Covener wrote:
> Hi all,
> 
> (After only minor embarrassment of patching tags/2.4.55 instead of 2.4.x...)
> 
> Please find below the proposed release tarball and signatures:
> 
> https://dist.apache.org/repos/dist/dev/httpd/
> 
> I would like to call a SHORTENED VOTE to release
> this candidate tarball httpd-2.4.59-rc1 as 2.4.59:
> [ ] +1: It's not just good, it's good enough!
> [ ] +0: Let's have a talk.
> [ ] -1: There's trouble in paradise. Here's what's wrong.
> 
> The computed digests of the tarball up for vote are:
> = e4ec4ce12c6c8f5a794dc2263d126cb1d6ef667f034c4678ec945d61286e8b0f
> = 
> baa96a7c9bba48f758ca9b3e3d63f0c65db960653618109d4d7bcbf3d4776d1d51453beb65e5af57655f0b1cfb88913842bc3a117fe7acc754ddb43d4524bc82
> 
> The SVN candidate source is found at tags/2.4.59-rc1-candidate.
> 

Re: mod_systemd: refactor to get rid of libsystemd dependency?

[Ruediger Pluem]

On 4/3/24 4:32 PM, Joe Orton wrote:
> On Tue, Apr 02, 2024 at 12:25:40PM +0200, Rainer Jung wrote:
>> 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?
> 
> The trunk mod_systemd has got slightly wider library use than just 
> sd_notify - so it is not quite that simple. If there was an alternative 
> minimal library implementing the sd_* API parts required, that would 
> definitely make sense. I'm not sure that reimplementing them all from 
> scratch makes sense (especially multiplied by N projects doing this).
> 

+1

> It looks like systemd folks have also changed the library implementation 
> to dlopen() the various dependant libraries on demand now rather than 
> directly linking to them, which removes the specific attack vector used 
> here IIUC.
+1. Unless the systemd folks show that they are unwilling to address issues
I would stay with libsystemd.

Regards

Rüdiger

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

[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

[Eric Covener]

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

It looks like the release tools are trying to strip that but maybe no
longer matching?
https://svn.apache.org/repos/asf/httpd/dev-tools/release/common-lib.sh

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: [VOTE] Release httpd-2.4.59-rc1 as httpd-2.4.59

[Graham Leggett via dev]

On 03 Apr 2024, at 13:26, Eric Covener  wrote:

> [ ] +1: It's not just good, it's good enough!

+1 on RHEL9.

Regards,
Graham
--

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

[Cory McIntire]

+1

CentOS 6
CentOS 7
AlmaLinux 8
AlmaLinux 9
Ubuntu 20
Ubuntu 22

Thanks for RM’n.

Regards,
Cory McIntire | Release Manager
cory.mcint...@webpros.com | cPanel – a 
webpros company



From: Eric Covener 
Date: Wednesday, April 3, 2024 at 07:26
To: Apache HTTP Server Development List 
Subject: [VOTE] Release httpd-2.4.59-rc1 as httpd-2.4.59
Hi all,

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

Community over Code EU 2024: Start planning your trip!

[Ryan Skraba]

[Note: You're receiving this email because you are subscribed to one
or more project dev@ mailing lists at the Apache Software Foundation.]

Dear community,

We hope you are doing great, are you ready for Community Over Code EU?
Check out the featured sessions, get your tickets with special
discounts and start planning your trip.

Save your spot! Take a look at our lineup of sessions, panelists and
featured speakers and make your final choice:

* EU policies and regulations affecting open source specialists working in OSPOs

The panel will discuss how EU legislation affects the daily work of
open source operations. Panelists will cover some recent policy
updates, the challenges of staying compliant when managing open source
contribution and usage within organizations, and their personal
experiences in adapting to the changing European regulatory
environment.

* Doing for sustainability, what open source did for software

In this keynote Asim Hussain will explain the history of Impact
Framework, a coalition of hundreds of software practitioners with
tangible solutions that directly foster meaningful change by measuring
the environmental impacts of a piece of software.

Don’t forget that we have special discounts for groups, students and
Apache committers. Visit the website to discover more about these
rates.[1]

It's time for you to start planning your trip. Remember that we have
prepared a “How to get there” guide that will be helpful to find out
the best transportation, either train, bus, flight or boat to
Bratislava from wherever you are coming from. Take a look at the
different options and please reach out to us if you have any
questions.

We have available rooms -with a special rate- at the Radisson Blu
Carlton Hotel, where the event will take place and at the Park Inn
Hotel which is only 5 minutes walking from the venue. [2] However, you
are free to choose any other accommodation options around the city.

See you in Bratislava,
Community Over Code EU Team

[1]: https://eu.communityovercode.org/tickets/ "Register"
[2]: https://eu.communityovercode.org/venue/ "Where to stay"

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

[Yann Ylavic]

On Wed, Apr 3, 2024 at 2:26 PM Eric Covener  wrote:
>
> I would like to call a SHORTENED VOTE to release
> this candidate tarball httpd-2.4.59-rc1 as 2.4.59:

[X] +1: It's not just good, it's good enough!

All good from my testing on debian(s).

Thanks Eric!

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

[jean-frederic clere]

On 4/3/24 14:26, Eric Covener wrote:

[X] +1: It's not just good, it's good enough!


Build and tested in fedora 39 and windows server 2019 (VS17 2022 Cmake).

--
Cheers

Jean-Frederic

Re: mod_systemd: refactor to get rid of libsystemd dependency?

[Graham Leggett via dev]

On 02 Apr 2024, at 11:25, Rainer Jung  wrote:

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

Definite +1.

The attack surface on systemd has always been too big, now is the time to fix 
that.

Regards,
Graham
--

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

[giovanni]

On 4/3/24 14:26, Eric Covener wrote:

Hi all,

(After only minor embarrassment of patching tags/2.4.55 instead of 2.4.x...)

Please find below the proposed release tarball and signatures:

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

I would like to call a SHORTENED VOTE to release
this candidate tarball httpd-2.4.59-rc1 as 2.4.59:
+1

tested on OpenBSD 7.5 (LibreSSL 3.9.0) and Fedora39

Thanks for RMing
 Giovanni


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: mod_systemd: refactor to get rid of libsystemd dependency?

[Joe Orton]

On Tue, Apr 02, 2024 at 12:25:40PM +0200, Rainer Jung wrote:
> 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?

The trunk mod_systemd has got slightly wider library use than just 
sd_notify - so it is not quite that simple. If there was an alternative 
minimal library implementing the sd_* API parts required, that would 
definitely make sense. I'm not sure that reimplementing them all from 
scratch makes sense (especially multiplied by N projects doing this).

It looks like systemd folks have also changed the library implementation 
to dlopen() the various dependant libraries on demand now rather than 
directly linking to them, which removes the specific attack vector used 
here IIUC.

Regards, Joe

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

[Frank Gingras]

On Wed, Apr 3, 2024 at 9:16 AM Stefan Eissing via dev 
wrote:

>
>
> > Am 03.04.2024 um 14:26 schrieb Eric Covener :
> >
> > Hi all,
> >
> > (After only minor embarrassment of patching tags/2.4.55 instead of
> 2.4.x...)
> >
> > Please find below the proposed release tarball and signatures:
> >
> > https://dist.apache.org/repos/dist/dev/httpd/
> >
> > I would like to call a SHORTENED VOTE to release
> > this candidate tarball httpd-2.4.59-rc1 as 2.4.59:
> > [ ] +1: It's not just good, it's good enough!
> > [ ] +0: Let's have a talk.
> > [ ] -1: There's trouble in paradise. Here's what's wrong.
> >
> > The computed digests of the tarball up for vote are:
> > = e4ec4ce12c6c8f5a794dc2263d126cb1d6ef667f034c4678ec945d61286e8b0f
> > =
> baa96a7c9bba48f758ca9b3e3d63f0c65db960653618109d4d7bcbf3d4776d1d51453beb65e5af57655f0b1cfb88913842bc3a117fe7acc754ddb43d4524bc82
> >
> > The SVN candidate source is found at tags/2.4.59-rc1-candidate.
>
> +1 (macOS, 23.4.0, x86_64)
>
> Thanks,
> Stefan


+1 here, no problem on Slackware64.

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

[Joe Orton]

On Wed, Apr 03, 2024 at 08:26:09AM -0400, Eric Covener wrote:
> 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:
> [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 from me. Passes test suite on RHEL8+9+CentOS Stream 10. Big thanks for 
RMing.

Also a CI pass: https://github.com/apache/httpd/actions/runs/8538499329

Regards, Joe

Participate in the ASF 25th Anniversary Campaign

[Brian Proffitt]

Hi everyone,

As part of The ASF’s 25th anniversary campaign[1], we will be celebrating
projects and communities in multiple ways.

We invite all projects and contributors to participate in the following
ways:

* Individuals - submit your first contribution:
https://news.apache.org/foundation/entry/the-asf-launches-firstasfcontribution-campaign
* Projects - share your public good story:
https://docs.google.com/forms/d/1vuN-tUnBwpTgOE5xj3Z5AG1hsOoDNLBmGIqQHwQT6k8/viewform?edit_requested=true
* Projects - submit a project spotlight for the blog:
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=278466116
* Projects - contact the Voice of Apache podcast (formerly Feathercast) to
be featured: https://feathercast.apache.org/help/
*  Projects - use the 25th anniversary template and the #ASF25Years hashtag
on social media:
https://docs.google.com/presentation/d/1oDbMol3F_XQuCmttPYxBIOIjRuRBksUjDApjd8Ve3L8/edit#slide=id.g26b0919956e_0_13

If you have questions, email the Marketing & Publicity team at
mark...@apache.org.

Peace,
BKP

[1] https://apache.org/asf25years/

[NOTE: You are receiving this message because you are a contributor to an
Apache Software Foundation project. The ASF will very occasionally send out
messages relating to the Foundation to contributors and members, such as
this one.]

Brian Proffitt
VP, Marketing & Publicity
VP, Conferences

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

[Stefan Eissing via dev]

> Am 03.04.2024 um 14:26 schrieb Eric Covener :
> 
> Hi all,
> 
> (After only minor embarrassment of patching tags/2.4.55 instead of 2.4.x...)
> 
> Please find below the proposed release tarball and signatures:
> 
> https://dist.apache.org/repos/dist/dev/httpd/
> 
> I would like to call a SHORTENED VOTE to release
> this candidate tarball httpd-2.4.59-rc1 as 2.4.59:
> [ ] +1: It's not just good, it's good enough!
> [ ] +0: Let's have a talk.
> [ ] -1: There's trouble in paradise. Here's what's wrong.
> 
> The computed digests of the tarball up for vote are:
> = e4ec4ce12c6c8f5a794dc2263d126cb1d6ef667f034c4678ec945d61286e8b0f
> = 
> baa96a7c9bba48f758ca9b3e3d63f0c65db960653618109d4d7bcbf3d4776d1d51453beb65e5af57655f0b1cfb88913842bc3a117fe7acc754ddb43d4524bc82
> 
> The SVN candidate source is found at tags/2.4.59-rc1-candidate.

+1 (macOS, 23.4.0, x86_64)

Thanks,
Stefan

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

[Eric Covener]

> I would like to call a SHORTENED VOTE to release
> this candidate tarball httpd-2.4.59-rc1 as 2.4.59:

my +1 (AIX/xlc/ppc64)

Only familiar t/ssl/proxy.t client auth issues with a openssl11 server

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

[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