Re: svn commit: r1915740 - in /httpd/httpd/branches/2.4.x: ./ changes-entries/pr61574.txt modules/ssl/ssl_engine_init.c

[Christophe JAILLET]

Le 12/02/2024 à 09:37, jor...@apache.org a écrit :

Author: jorton
Date: Mon Feb 12 08:37:35 2024
New Revision: 1915740

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

* modules/ssl/ssl_engine_init.c (ssl_init_PushCAList): Remove function.
   (ssl_init_ca_cert_path): Use SSL_add_file_cert_subjects_to_stack()
   instead.

[Edit: This does change behaviour: the acceptable client CA list is now
  always be sent in sorted order rather than configured/file order.
  In the case of SSLCACertificatePath and SSLCADNRequestPath, the
  order will be stable rather than non-determistic as previously.]

PR: 61574
Github: closes #406
Reviewed by: jorton, jfclere, covener

Added:
 httpd/httpd/branches/2.4.x/changes-entries/pr61574.txt
Modified:
 httpd/httpd/branches/2.4.x/   (props changed)
 httpd/httpd/branches/2.4.x/modules/ssl/ssl_engine_init.c

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



r1825124 was a follow-up of this patch.
Should it be backported as well?

CJ

Re: svn commit: r1589993 - in /httpd/httpd/trunk: CHANGES docs/manual/expr.xml docs/manual/mod/mod_authnz_ldap.xml modules/aaa/mod_authnz_ldap.c

[Christophe JAILLET]

Le 18/11/2023 à 20:52, Yann Ylavic a écrit :

On Wed, Apr 30, 2014 at 1:02 AM Yann Ylavic  wrote:


On Tue, Apr 29, 2014 at 10:54 PM, Christophe JAILLET
 wrote:

Hi,

doc does not build because of  below:

CJ

Le 25/04/2014 13:14, minf...@apache.org a écrit :

+
+LocationMatch ^/dav/(?[^/]+)/


   ^ There



Hmm, won't LocationMatch itself be broken by the inner <>s ?


Wow, fortunately I didn't hold my breath on this one :)
Someone needs to answer to this former/younger/naive me though and
since I'm on this commit again: look Yann, this match is double-quoted
now so we should be fine!



In fact, at that time, another solution was provided in r1591113.

But what you propose above, should have worked as well, I guess. :).

CJ

Re: release?

[Christophe JAILLET]

Le 17/08/2023 à 13:42, Stefan Eissing via dev a écrit :

How are people feeling about another release?

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

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

Cheers,
Stefan




I canhave some cycles in the coing days/weeks, so +1.

Thx for the proposal.

CJ

Re: svn commit: r1910820 - in /httpd/httpd/branches/2.4.x: ./ changes-entries/pr60182.txt modules/ssl/ssl_util_stapling.c

[Christophe JAILLET]

Le 06/07/2023 à 18:11, jor...@apache.org a écrit :

Author: jorton
Date: Thu Jul  6 16:11:56 2023
New Revision: 1910820

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

* modules/ssl/ssl_util_stapling.c (stapling_check_response) Don't stop
   Certificate Revoked messages.

   Certificate Revoked Responder messages don't belong to 'error' class.
   When the server receives one, it MUST be passed on to the client.
   And stored for the normal period of basic responses.

   Also don't log an error each time it is retrieved from cache,
   only once when it is retrieved from the OCSP responder.

PR: 60182
Obtained from: 
https://github.com/apache/httpd/commit/7db9795f45fd4688ceb13ee36090e4e2becbc709.diff
Submitted by: 
Reviewed by: gbechis, icing, ylavic


Hi,

I've not seen it in STATUS.

I'm a bit distant this days, so I may have missed something, but usually 
STATUS is updated just before or after a commit, and I don't see it either.




Added:
 httpd/httpd/branches/2.4.x/changes-entries/pr60182.txt
Modified:
 httpd/httpd/branches/2.4.x/   (props changed)
 httpd/httpd/branches/2.4.x/modules/ssl/ssl_util_stapling.c

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

Added: httpd/httpd/branches/2.4.x/changes-entries/pr60182.txt
URL: 
http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/changes-entries/pr60182.txt?rev=1910820=auto
==
--- httpd/httpd/branches/2.4.x/changes-entries/pr60182.txt (added)
+++ httpd/httpd/branches/2.4.x/changes-entries/pr60182.txt Thu Jul  6 16:11:56 
2023
@@ -0,0 +1,2 @@
+  *) mod_ssl: Fix handling of of Certificate Revoked messags
+ in OCSP stapling. PR 60182 []


Unless I missed something, this CHANGES entry is not in trunk. Should it 
be added?




Modified: httpd/httpd/branches/2.4.x/modules/ssl/ssl_util_stapling.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/modules/ssl/ssl_util_stapling.c?rev=1910820=1910819=1910820=diff
==
--- httpd/httpd/branches/2.4.x/modules/ssl/ssl_util_stapling.c (original)
+++ httpd/httpd/branches/2.4.x/modules/ssl/ssl_util_stapling.c Thu Jul  6 
16:11:56 2023
@@ -445,7 +445,7 @@ static int stapling_check_response(serve
  rv = SSL_TLSEXT_ERR_NOACK;
  }
  
-if (status != V_OCSP_CERTSTATUS_GOOD) {

+if (status != V_OCSP_CERTSTATUS_GOOD && pok) {
  char snum[MAX_STRING_LEN] = { '\0' };
  BIO *bio = BIO_new(BIO_s_mem());
  
@@ -466,12 +466,6 @@ static int stapling_check_response(serve

   (reason != OCSP_REVOKED_STATUS_NOSTATUS) ?
   OCSP_crl_reason_str(reason) : "n/a",
   snum[0] ? snum : "[n/a]");
-
-if (mctx->stapling_return_errors == FALSE) {
-if (pok)
-*pok = FALSE;
-rv = SSL_TLSEXT_ERR_NOACK;
-}
  }
  }
  


PR 60182 was about r1875355 and r1875356.
This backport in only for r1875355.

Is it done on purpose or is the 2nd commit missing?

CJ

Re: svn commit: r1892450 - /httpd/httpd/trunk/server/core_filters.c

[Christophe JAILLET]

Le 21/05/2023 à 17:50, Yann Ylavic a écrit :

On Sun, May 21, 2023 at 4:22 PM Yann Ylavic  wrote:


On Sun, May 21, 2023 at 2:07 PM Christophe JAILLET
 wrote:


Le 19/08/2021 à 15:43, yla...@apache.org a écrit :


@@ -604,7 +604,7 @@ static apr_status_t send_brigade_nonbloc
*/
   if (nbytes > sconf->flush_max_threshold
   && next != APR_BRIGADE_SENTINEL(bb)
-&& !is_in_memory_bucket(next)) {
+&& next->length && !is_in_memory_bucket(next)) {
   (void)apr_socket_opt_set(s, APR_TCP_NOPUSH, 1);
   rv = writev_nonblocking(s, bb, ctx, nbytes, nvec, c);
   if (rv != APR_SUCCESS) {


The comment above this code is:
  /* Flush above max threshold, unless the brigade still contains in
   * memory buckets which we want to try writing in the same pass (if
   * we are at the end of the brigade, the write will happen outside
   * the loop anyway).
   */

With the added next->length, IIUC, we will *also* process the bucket
*after* the metadata. So we could accumulate above flush_max_threshold
for no good reason (i.e. not processing data already in memory).

Is it what is expected?


Buckets with ->length == 0 don't contain data (in memory or not), as
opposed to ->length == -1 (unknown/on-read data length) for instance.
No special action is needed for empty buckets at the network level,
they just need to be destroyed when consumed (e.g. for EOR buckets to
terminate/cleanup the underlying request), so the loop simply ignores
them until the flush (i.e. writev/sendfile will delete them finally).
So presumably we can't accumulate above flush_max_threshold by not
flushing before empty buckets? More exactly we won't continue to
accumulate once flush_max_threshold is reached, but we might flush
more than that if the last accumulated bucket crosses the threshold
(that's independent from empty buckets though).


Hm, re-reading your question and the code I think I replied
orthogonally (and not accurately) here.
What the code does actually is coalescing in memory buckets (including
empty ones, barely) regardless of flush_max_threshold, precisely
because they are in memory already and we want to try sending them on
the network (up to its actual capacity) to release memory on httpd as
much as possible. Ignoring ->length == 0 barely means that metadata
buckets are in memory buckets (which they really are actually), maybe
it would be clearer to add the ->length == 0 test directly in
is_in_memory_bucket() after all..

Anyway I see what you mean now, when we are at flush_max_threshold and
the next bucket is a metadata, ignoring/continuing on that next bucket
in the next loop without re-checking for flush_max_threshold is bad.


Yes, that's my point.

I'll apply my patch and propose both for backport.

Thanks for the review and feedback.

CJ


And you are very right, good catch! Your patch looks good to me too.

This commit (r1892450) did not make it to 2.4.x it seems, maybe with
your fix it could now :) That's a good optimization I think..


Regards;
Yann.

Re: svn commit: r1892450 - /httpd/httpd/trunk/server/core_filters.c

[Christophe JAILLET]

Le 19/08/2021 à 15:43, yla...@apache.org a écrit :

Author: ylavic
Date: Thu Aug 19 13:43:23 2021
New Revision: 1892450

URL: http://svn.apache.org/viewvc?rev=1892450=rev
Log:
core: don't break out iovec coalescing for metadata in ap_core_output_filter().

* server/core_filters.c (send_brigade_nonblocking):
   Keep filling in the iovec when the next bucket has no ->length.

Modified:
 httpd/httpd/trunk/server/core_filters.c

Modified: httpd/httpd/trunk/server/core_filters.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/server/core_filters.c?rev=1892450=1892449=1892450=diff
==
--- httpd/httpd/trunk/server/core_filters.c (original)
+++ httpd/httpd/trunk/server/core_filters.c Thu Aug 19 13:43:23 2021
@@ -604,7 +604,7 @@ static apr_status_t send_brigade_nonbloc
   */
  if (nbytes > sconf->flush_max_threshold
  && next != APR_BRIGADE_SENTINEL(bb)
-&& !is_in_memory_bucket(next)) {
+&& next->length && !is_in_memory_bucket(next)) {
  (void)apr_socket_opt_set(s, APR_TCP_NOPUSH, 1);
  rv = writev_nonblocking(s, bb, ctx, nbytes, nvec, c);
  if (rv != APR_SUCCESS) {





Hi,

The comment above this code is:
/* Flush above max threshold, unless the brigade still contains in
 * memory buckets which we want to try writing in the same pass (if
 * we are at the end of the brigade, the write will happen outside
 * the loop anyway).
 */

With the added next->length, IIUC, we will *also* process the bucket 
*after* the metadata. So we could accumulate above flush_max_threshold 
for no good reason (i.e. not processing data already in memory).


Is it what is expected?


Maybe we should:
  - remove the continue around line 728  AND
  - the whole block between "/* Make sure that these new data fit in 
our iovec. */" and "nvec++;" be inside a "if (bucket->length)"



This way, when above the limit, we would check if the bucket is metadata 
or already in memory, one by one.



Something like: (with svn diff -x -w to skip whitespace changes)


Index: server/core_filters.c
===
--- server/core_filters.c   (révision 1909955)
+++ server/core_filters.c   (copie de travail)
@@ -719,10 +719,9 @@
 if (!nvec) {
 apr_bucket_delete(bucket);
 }
-continue;
 }
-
 /* Make sure that these new data fit in our iovec. */
+else {
 if (nvec == ctx->nvec) {
 if (nvec == NVEC_MAX) {
 sock_nopush(s, 1);
@@ -754,6 +753,7 @@
 ctx->vec[nvec].iov_base = (void *)data;
 ctx->vec[nvec].iov_len = length;
 nvec++;
+}

 /* Flush above max threshold, unless the brigade still contains in
  * memory buckets which we want to try writing in the same 
pass (if



CJ

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

[Christophe JAILLET]

Le 04/05/2023 à 10:34, Ruediger Pluem a écrit :

This is a formal vote on whether we should move our read/write repository from 
Subversion to Git.
This means that our latest read/write repository will be no longer available 
via svn.apache.org. It
will be available via Git at https://gitbox.apache.org/repos/asf/httpd-site.git 
and https://github.com/apache/httpd.git.
Github also offers the possibility to use a Subversion client:
https://docs.github.com/en/get-started/working-with-subversion-on-github/support-for-subversion-clients


[ ]: Move the read/write repository from Subversion to Git and leverage the 
features of Github (for now Actions and PR).
[ ]: Move the read/write repository from Subversion to Git, but I don't want to 
work with Github and I will only work with
  what gitbox.apache.org offers.
[ ]: Leave everything as is.


Regards

Rüdiger



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


CJ

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

[Christophe JAILLET]

Le 03/05/2023 à 21:12, Eric Covener a écrit :

On Tue, Apr 25, 2023 at 2:45 PM Graham Leggett via dev
 wrote:


On 25 Apr 2023, at 07:45, Ruediger Pluem  wrote:

2. Switching from Subversion to Git is mostly an emotional problem for me. We 
have some closer ties to Subversion by some
   overlaps in the community and via mod_dav_svn we kind of partially eat our 
very own dogfood here by using Subversion.
   We wouldn't do that any longer with Git. Plus it would switch another of our 
development tools from an Apache license to GPL.
   Apart from technical aspects that this change would create we should check 
if all of the current active committers are fine
   using Github. While people could use Gitbox and thus avoid Github when we 
use Git I would like us to leverage the features of
   Github when we would do this switch and I think this cannot be done if 
active committers would have issues with Github.


+1.

I've always found the fight about “must be git” to be really tedious. Github 
supports both git and svn to this day, and people are free to use what they 
prefer by using the interface they are most familiar with.

While Github is popular today, this is only because the goals of the owners of 
Github are presently aligned with our goals. As Twitter has taught us, goals 
change at any time and without warning.


Hi Graham -- it's a little unclear to me where this would put you
"vote" wise about moving to read/write Git.

Anyone else with a stake have an opinion? It has been since about 2019
since we last discussed it here, I am hoping people have warmed up to
it.



svn or git both fit my needs.

git would be slightly easier for me because of the feature to easily 
commit only parts of changes of files (I think that some svn clients 
also support it, but not the one I use)


github is great because it can be used for code review without the need 
to commit something. A patch can be discussed, updated, improved, ... 
cleanly before being merged. That's a great feature IMHO.


git/github would also make the project more attractive for others 
contributions I think.


So, even if I personality really don't care for myself, I would +1 the 
sake of the project.


Just my 2c,

CJ

Re: [RFC] JSON logging support for httpd 2.4.x

[Christophe JAILLET]

Le 31/03/2023 à 09:04, Thomas Meyer a écrit :

Hi,

Sadly I got no feedback at all.

What is the preferred way for contributions?


Hi,

mailing list is fine.
You can also use github if it is easier for you.



I also did raise a PR here with some fixes on top of this patch series:

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



Mfg
Thomas

Am 24. März 2023 22:54:08 MEZ schrieb Thomas Meyer :


Hi,

please have a look at this preliminarily work to support JSON output in 
mod_log_config.

It's still unfinished and has probably a lot of bugs, but this is to show 
the general idea
of my solution.

Help and feedback is most welcome.

Mfg
thomas


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


As you have already notices, there is already a mod_log_json in trunk 
(see [1])


AFAIK, it is not documented.

Have you looked at it first?
Does it match your needs?

There is also an old WiP related to make ErrorLog logging modular.
I've not looked at it since a LNG time. But do you think it would help?


CJ


[1]: 
https://svn.apache.org/viewvc/httpd/httpd/trunk/modules/loggers/mod_log_json.c?view=markup=date


[2]: 
http://people.apache.org/~jkaluza/patches/httpd-2.4.x-errorlog_provider.patch

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

[Marion & Christophe JAILLET]

Le 03/04/2023 à 21:44, Christophe JAILLET a écrit :

Le 02/04/2023 à 18:10, Eric Covener a écrit :

Hi all,

Please find below the proposed release tarball and signatures:

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

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

The computed digests of the tarball up for vote are:
sha256: bc3e7e540b83ec24f9b847c6b4d7148c55b79b27d102e21227eb65f7183d6b45
*httpd-2.4.57-rc1.tar.gz
sha512: 
730560d4aab3699aa59716bb75858f8432a902aeab3c380b4d3e0f6813e9ae4e278d3b7fdf63a4e94c07b5100933d8684d76f6095f3d60d48ea0f1458c9ed0b4

*httpd-2.4.57-rc1.tar.gz

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



+1

Tested only with event.

Tested with:
Linux pop-os 6.2.0
gcc (Ubuntu 12.1.0-2ubuntu1~22.04) 12.1.0
OpenSSL 3.0.2 15 Mar 2022 (Library: OpenSSL 3.0.2 15 Mar 2022)
   libssl-dev 3.0.2
   libbrotli-dev 1.0.9
   libjansson-dev 2.13.1
   libnghttp2-dev 1.43.0
   libpcre2-dev 10.39
   liblua5.3-dev 5.3.6
   libsystemd-dev 249.11
   libldap2-dev 2.5.14+dfsg
   libxml2-dev 2.9.13+dfsg
   libcurl4-openssl-dev 7.81.0


Still can't get the pytest run correctly.
I've tried to make some clean-ups. Should have a real look at it one day :(


> pip install -U multipart
did the trick. (thanks error.log!)

I don't know if it is a new requirement or if I did something wrong on 
my setup.


Does is worth mentioning in README.pytest?



Another point, when building mod_tls.
After upgrading to latest github rustls-ffi, I now get:

tls_core.c: In function ‘extract_client_hello_values’:
tls_core.c:510:14: error: ‘rustls_client_hello’ has no member named 
‘sni_name’

  510 | if (hello->sni_name.len > 0) {
  |  ^~
tls_core.c:511:55: error: ‘rustls_client_hello’ has no member named 
‘sni_name’
  511 | cc->sni_hostname = apr_pstrndup(c->pool, 
hello->sni_name.data, hello->sni_name.len);

  |   ^~
tls_core.c:511:77: error: ‘rustls_client_hello’ has no member named 
‘sni_name’
  511 | cc->sni_hostname = apr_pstrndup(c->pool, 
hello->sni_name.data, hello->sni_name.len);



Apparently related to:

https://github.com/rustls/rustls-ffi/commit/ed82a03f2481095f251e7aee604a2ca29b8c1c5e#diff-6f7bcae64b59e4d5ad181e43c27a22088434c36827db05f8767e00dabcd7973eR426


So, maybe some trouble and conditional compilation to come in a close 
future.




This module is tagged as experimental, so from my POV it can't be a show 
stopper.


CJ

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

[Christophe JAILLET]

Le 02/04/2023 à 18:10, Eric Covener a écrit :

Hi all,

Please find below the proposed release tarball and signatures:

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

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

The computed digests of the tarball up for vote are:
sha256: bc3e7e540b83ec24f9b847c6b4d7148c55b79b27d102e21227eb65f7183d6b45
*httpd-2.4.57-rc1.tar.gz
sha512: 
730560d4aab3699aa59716bb75858f8432a902aeab3c380b4d3e0f6813e9ae4e278d3b7fdf63a4e94c07b5100933d8684d76f6095f3d60d48ea0f1458c9ed0b4
*httpd-2.4.57-rc1.tar.gz

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



+1

Tested only with event.

Tested with:
Linux pop-os 6.2.0
gcc (Ubuntu 12.1.0-2ubuntu1~22.04) 12.1.0
OpenSSL 3.0.2 15 Mar 2022 (Library: OpenSSL 3.0.2 15 Mar 2022)
  libssl-dev 3.0.2
  libbrotli-dev 1.0.9
  libjansson-dev 2.13.1
  libnghttp2-dev 1.43.0
  libpcre2-dev 10.39
  liblua5.3-dev 5.3.6
  libsystemd-dev 249.11
  libldap2-dev 2.5.14+dfsg
  libxml2-dev 2.9.13+dfsg
  libcurl4-openssl-dev 7.81.0


Still can't get the pytest run correctly.
I've tried to make some clean-ups. Should have a real look at it one day :(

CJ

Re: svn commit: r1907980 - in /httpd/httpd/trunk: changes-entries/proxy_uwsgi_response_validation.txt modules/proxy/mod_proxy_uwsgi.c

[Christophe JAILLET]

Le 02/03/2023 à 16:10, yla...@apache.org a écrit :

Author: ylavic
Date: Thu Mar  2 15:10:30 2023
New Revision: 1907980

URL: http://svn.apache.org/viewvc?rev=1907980=rev
Log:
mod_proxy_uwsgi: Stricter backend HTTP response parsing/validation


Added:
 httpd/httpd/trunk/changes-entries/proxy_uwsgi_response_validation.txt
Modified:
 httpd/httpd/trunk/modules/proxy/mod_proxy_uwsgi.c

Added: httpd/httpd/trunk/changes-entries/proxy_uwsgi_response_validation.txt
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/changes-entries/proxy_uwsgi_response_validation.txt?rev=1907980=auto
==
--- httpd/httpd/trunk/changes-entries/proxy_uwsgi_response_validation.txt 
(added)
+++ httpd/httpd/trunk/changes-entries/proxy_uwsgi_response_validation.txt Thu 
Mar  2 15:10:30 2023
@@ -0,0 +1,2 @@
+  *) mod_proxy_uwsgi: Stricter backend HTTP response parsing/validation.
+ [Yann Ylavic]

Modified: httpd/httpd/trunk/modules/proxy/mod_proxy_uwsgi.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/proxy/mod_proxy_uwsgi.c?rev=1907980=1907979=1907980=diff
==
--- httpd/httpd/trunk/modules/proxy/mod_proxy_uwsgi.c (original)
+++ httpd/httpd/trunk/modules/proxy/mod_proxy_uwsgi.c Thu Mar  2 15:10:30 2023
@@ -313,18 +313,16 @@ static int uwsgi_response(request_rec *r
  pass_bb = apr_brigade_create(r->pool, c->bucket_alloc);
  
  len = ap_getline(buffer, sizeof(buffer), rp, 1);

-
  if (len <= 0) {
-/* oops */
+/* invalid or empty */
  return HTTP_INTERNAL_SERVER_ERROR;
  }
-
  backend->worker->s->read += len;
-
-if (len >= sizeof(buffer) - 1) {
-/* oops */
+if ((apr_size_t)len >= sizeof(buffer)) {


Hi Yann,

Why removing the -1?

My understading is that it is there in case of:
  uwsgi_response()
ap_getline()
  ap_rgetline()
ap_fgetline_core()
  code around cleanup:

In this path, IIUC, sizeof(buffer) - 1 is returned.
Can this happen?

CJ


+/* too long */
  return HTTP_INTERNAL_SERVER_ERROR;
  }
+


[...]

Re: *** SPAM *** [VOTE] broader RTC exception for 2.4.x CI changes

[Christophe JAILLET]

Le 15/02/2023 à 14:48, Joe Orton a écrit :

Per my previous Travis is dead, long live GitHub actions.

I propose to broaden the RTC exception in 2.4.x/STATUS to allow CI
config changes and scripts to be merged from trunk:

Index: STATUS
===
--- STATUS  (revision 1907679)
+++ STATUS  (working copy)
@@ -141,7 +141,7 @@
  . non-Unix, single-platform code
  . routine APLOGNO() backports
  . .gdbinit
-. Travis integration: .travis.yml and test/travis*.sh
+. CI configuration and scripts
  . mod_tls
  
  RELEASE SHOWSTOPPERS:




+1

Re: svn commit: r1907608 - in /httpd/httpd/trunk: CMakeLists.txt modules/dav/main/NWGNUmakefile modules/dav/main/config5.m4 modules/dav/main/mod_dav.c modules/dav/main/mod_dav.dsp modules/dav/main/mod

[Christophe JAILLET]

Le 13/02/2023 à 17:48, m...@apache.org a écrit :

Author: manu
Date: Mon Feb 13 16:48:35 2023
New Revision: 1907608

URL: http://svn.apache.org/viewvc?rev=1907608=rev
Log:
Add MS-WDV support

MS-WDV specification:
https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-wdv

The changes introduces the DAVMSext directive, which is used to
enable MS-WDV: DAVMSext +WDV

dav_get_timeout_string() is introduced as a variant of dav_get_timeout().
The former parses a string, the later parse the Timeout HTTP header.


Added:
 httpd/httpd/trunk/modules/dav/main/ms_wdv.c
Modified:
 httpd/httpd/trunk/CMakeLists.txt
 httpd/httpd/trunk/modules/dav/main/NWGNUmakefile
 httpd/httpd/trunk/modules/dav/main/config5.m4
 httpd/httpd/trunk/modules/dav/main/mod_dav.c
 httpd/httpd/trunk/modules/dav/main/mod_dav.dsp
 httpd/httpd/trunk/modules/dav/main/mod_dav.h
 httpd/httpd/trunk/modules/dav/main/util.c



[...]


  /*
+ * Command handler for the DAVmsExt directive, which is RAW
+ */
+static const char *dav_cmd_davmsext(cmd_parms *cmd, void *config, const char 
*w)
+{
+dav_dir_conf *conf = (dav_dir_conf *)config;
+
+if (!ap_cstr_casecmp(w, "None"))
+conf->msext_opts = DAV_MSEXT_NONE;
+else if (!ap_cstr_casecmp(w, "Off"))
+conf->msext_opts = DAV_MSEXT_NONE;


Hi, I think that:
if (!ap_cstr_casecmp(w, "None") ||
!ap_cstr_casecmp(w, "Off"))
conf->msext_opts = DAV_MSEXT_NONE;

would be more readable. It is easier to see that both are the same.
But it is mostly a matter of taste :).

(same below when setting DAV_MSEXT_ALL)


+else if (!ap_cstr_casecmp(w, "+WDV"))
+conf->msext_opts |= DAV_MSEXT_WDV;
+else if (!ap_cstr_casecmp(w, "WDV"))
+conf->msext_opts |= DAV_MSEXT_WDV;


is |= expected here?


+else if (!ap_cstr_casecmp(w, "-WDV"))
+conf->msext_opts &= ~DAV_MSEXT_WDV;
+else if (!ap_cstr_casecmp(w, "All"))
+conf->msext_opts = DAV_MSEXT_ALL;
+else if (!ap_cstr_casecmp(w, "On"))
+conf->msext_opts = DAV_MSEXT_ALL;
+else
+return "DAVMSext values can be None | [+|-]WDV | All";
+
+return NULL;
+}
+

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

[Christophe JAILLET]

Le 11/01/2023 à 10:05, Stefan Eissing via dev a écrit :

Nearly all mod_tls in error (likely something missing in my conf)


Not here. Do you have any more information on those failures?



Still don't have time to spend some minutes on it, but:
  configure:35461: checking whether to enable mod_tls
  configure:35521: result: checking dependencies
  configure:35526: checking for rustls
  configure:35538: checking for user-provided rustls base directory
  configure:35552: result: none

looks a good starting point for: (likely something missing in my conf*)

CJ

(* conf being whatever from *.conf, --configure, apt install 
, ...)

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

[Christophe JAILLET]

Le 10/01/2023 à 14:40, Eric Covener a écrit :

Hi all,

Please find below the proposed release tarball and signatures:

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

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

The computed digests of the tarball up for vote are:
sha256: 5276ea8bc6fff31eed5c82132ae51a0b2ee05f9e6b61a00fa877f6cadab3b638
*httpd-2.4.55-rc1.tar.gz
sha512: 
ca0d03b5e74078977378fe711ca3ed8cf63c109b7dbe73f2c43f7f30f7e522bbe46f93189a183b7675394d57fffb0c2526facd8d40508be984a7a8f64d18f8d6
*httpd-2.4.55-rc1.tar.gz

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



+0


Tested only with event.

All good, as usual with the perl framework


1 issue with pytest:
   test/modules/http2/test_600_h2proxy.py .F
(details at the end of the mail)

Don't know if expected or not. Some pytest commits are only in trunk and 
have not been backported to 2.4.x. I don't know if it is linked to this 
failing test.


Most of mod_md tests skippep (likely something missing in my conf)
Nearly all mod_tls in error (likely something missing in my conf)

I won't have time to investigate further, but only the failure in 
test_600_h2proxy looks odd to me.

So I just report it and vote +0.



Tested with:
Linux pop-os 6.0.6
gcc (Ubuntu 11.3.0-1ubuntu1~22.04) 11.3.0
OpenSSL 3.0.2 15 Mar 2022 (Library: OpenSSL 3.0.2 15 Mar 2022)
  libssl-dev 3.0.2
  libbrotli-dev 1.0.9
  libjansson-dev 2.13.1
  libnghttp2-dev 1.43.0
  libpcre2-dev 10.39
  liblua5.3-dev 5.3.6
  libsystemd-dev 249.11
  libldap-dev 2.5.13+dfsg
  libldap2-dev 2.5.13+dfsg
  libxml2-dev 2.9.13+dfsg
  libcurl4-openssl-dev 7.81.0



__ 
TestH2Proxy.test_h2_600_05[on] 
___


self = , 
env = , enable_reuse = 'on'


@pytest.mark.parametrize("enable_reuse", [ "on", "off" ])
def test_h2_600_05(self, env, enable_reuse):
conf = H2Conf(env, extras={
f'cgi.{env.http_tld}': [
f"ProxyPassMatch ^/h2proxy/([0-9]+)/(.*)$ "
f"  h2c://127.0.0.1:$1/$2 enablereuse={enable_reuse} 
keepalive=on",

]
})
conf.add_vhost_cgi()
conf.add([
f'Listen {env.http_port2}',
'UseCanonicalName On',
'UseCanonicalPhysicalPort On'
])
conf.start_vhost(domains=[f'cgi.{env.http_tld}'],
 port=5004, doc_root="htdocs/cgi")
conf.add("AddHandler cgi-script .py")
conf.end_vhost()
conf.install()
assert env.apache_restart() == 0
url = env.mkurl("https", "cgi", 
f"/h2proxy/{env.http_port}/hello.py")

r = env.curl_get(url, 5)
assert r.response["status"] == 200
assert int(r.json["port"]) == env.http_port
# going to another backend port must create a new connection and
# we should see stream id one again
url = env.mkurl("https", "cgi", 
f"/h2proxy/{env.http_port2}/hello.py")

r = env.curl_get(url, 5)
assert r.response["status"] == 200
exp_port = env.http_port if enable_reuse == "on" else 
env.http_port2

>   assert int(r.json["port"]) == exp_port
E   AssertionError: assert 5004 == 5002
E+  where 5004 = int('5004')

Re: svn commit: r1903677 - in /httpd/httpd/trunk: changes-entries/ docs/manual/mod/ modules/md/ test/modules/md/

[Christophe JAILLET]

Le 25/08/2022 à 16:00, ic...@apache.org a écrit :

Author: icing
Date: Thu Aug 25 14:00:13 2022
New Revision: 1903677

URL: http://svn.apache.org/viewvc?rev=1903677=rev
Log:
mod_md v2.4.19 from github sync

   *) mod_md: a new directive `MDStoreLocks` can be used on cluster
  setups with a shared file system for `MDStoreDir` to order
  activation of renewed certificates when several cluster nodes are
  restarted at the same time. Store locks are not enabled by default.

  Restored curl_easy cleanup behaviour from v2.4.14 and refactored
  the use of curl_multi for OCSP requests to work with that.
  Fixes .


Added:
 httpd/httpd/trunk/changes-entries/md_locks_and_fix.txt
 httpd/httpd/trunk/test/modules/md/test_820_locks.py
Modified:
 httpd/httpd/trunk/docs/manual/mod/mod_md.xml
 httpd/httpd/trunk/modules/md/md_curl.c
 httpd/httpd/trunk/modules/md/md_http.c
 httpd/httpd/trunk/modules/md/md_http.h
 httpd/httpd/trunk/modules/md/md_log.h
 httpd/httpd/trunk/modules/md/md_reg.c
 httpd/httpd/trunk/modules/md/md_reg.h
 httpd/httpd/trunk/modules/md/md_store.c
 httpd/httpd/trunk/modules/md/md_store.h
 httpd/httpd/trunk/modules/md/md_store_fs.c
 httpd/httpd/trunk/modules/md/md_version.h
 httpd/httpd/trunk/modules/md/mod_md.c
 httpd/httpd/trunk/modules/md/mod_md_config.c
 httpd/httpd/trunk/modules/md/mod_md_config.h
 httpd/httpd/trunk/test/modules/md/conftest.py

Added: httpd/httpd/trunk/changes-entries/md_locks_and_fix.txt
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/changes-entries/md_locks_and_fix.txt?rev=1903677=auto
==
--- httpd/httpd/trunk/changes-entries/md_locks_and_fix.txt (added)
+++ httpd/httpd/trunk/changes-entries/md_locks_and_fix.txt Thu Aug 25 14:00:13 
2022
@@ -0,0 +1,8 @@
+  *) mod_md: a new directive `MDStoreLocks` can be used on cluster
+ setups with a shared file system for `MDStoreDir` to order
+ activation of renewed certificates when several cluster nodes are
+ restarted at the same time. Store locks are not enabled by default.
+
+ Restored curl_easy cleanup behaviour from v2.4.14 and refactored
+ the use of curl_multi for OCSP requests to work with that.
+ Fixes .

Modified: httpd/httpd/trunk/docs/manual/mod/mod_md.xml
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_md.xml?rev=1903677=1903676=1903677=diff
==
--- httpd/httpd/trunk/docs/manual/mod/mod_md.xml (original)
+++ httpd/httpd/trunk/docs/manual/mod/mod_md.xml Thu Aug 25 14:00:13 2022
@@ -1405,7 +1405,7 @@ MDMessageCmd /etc/apache/md-message
  
  
  
-

+
  MDRetryFailover
  
  MDRetryFailover number
@@ -1423,5 +1423,39 @@ MDMessageCmd /etc/apache/md-message
  
  
  
+
+
+MDStoreLocks
+


Hi,

a description is missing.
Not sure how to write it myself.

CJ


+MDStoreLocks on|off|duration
+MDStoreLocks off
+
+server config
+
+Available in version 2.4.55 and later
+
+
+Enable this to use a lock file on server startup when
+MDStoreDir is synchronized with the 
server
+configuration and renewed certificates are activated.
+
+Locking is intended for setups in a cluster that have a shared
+file system for MDStoreDir. It will protect the activation of
+renewed certificates when cluster nodes are restarted/reloaded
+at the same time. Under the condition that the shared file
+ system does support file locking.
+
+The default duration to obtain the lock is 5 seconds. If the 
log
+cannot be obtained, an error is logged and the server startup 
will
+continue. This may result in a cluster node to still use the
+previous certificate afterwards.
+
+A higher timeout will reduce that likelihood, but may delay 
server
+startups/reloads in case the locks are not properly handled in
+the underlying file system. A lock should only be held by a
+httpd instance for a short duration.
+
+
+

Re: mod_wasm: Contributing Upstream to Apache

[Christophe JAILLET]

Le 28/11/2022 à 19:17, Jesús González a écrit :

Hi everyone,

Following up on our email about contributing mod_wasm, we have continued 
to make progress on our side and just released mod_wasm v0.10.0.




Hi,

just a few nits to clean code and help reviews:

   - No need to send html files, it will be generated by the framework
   - I don't see the need for trace_nocontext(). Also have a look at 
APLOG_MARK and its usages.

   - APLOG_NOTICE looks too high for trace logging. APLOG_DEBUG?
   - At the end of create_dir_config(), 'note' and the corresponding 
apr_psprintf() are useless or a debugging logging call is missing
   - Please use only C89 comments (/* */) - try to configure with 
--enable-maintainer-mode

   - some double new lines could be saved

CJ


In this version, among other improvements, we introduce two major features:

  * #1: Wasm multi-module support
  * #2: Shared Wasm modules

In #1, you can now specify different Wasm modules to be used in 
different routes. For instance, now it’s possible with one-single Apache 
instance to load simultaneously the Wasm builds for the PHP 
and Python interpreters (and any other languages that compile to Wasm now or in the future).


And in #2, you can now specify different per-route configurations to the 
same Wasm module. The Wasm binary is loaded in memory only once, and the 
different configurations are applied to the Wasm module per-HTTP request.


Combining all together, you can have a more flexible configuration such as:



     SetHandler wasm-handler

     WasmModule /var/www/modules/php7.4.32.wasm

     WasmDir    /tmp

     …





     SetHandler wasm-handler

     WasmModule /var/www/modules/python3.11.wasm

     WasmArg    /var/www/python-app/app.py

     …





     SetHandler wasm-handler

     WasmModule /var/www/modules/python3.11.wasm

     WasmArg    /var/www/python-app2/app2.py

     …



We have run some simple, preliminary stress tests using ApacheBench and 
mod_wasm performs great in both MPM event and MPM worker modes.


Hope you can find some time to try mod_wasm and provide feedback. Let us 
know if you have questions or suggestions.


Jesús

PS: Updated patch attached.

*De: *Jesús González 
*Responder a: *"dev@httpd.apache.org" 
*Fecha: *lunes, 14 de noviembre de 2022, 7:38
*Para: *"dev@httpd.apache.org" 
*CC: *Daniel Lopez Ridruejo 
*Asunto: *mod_wasm: Contributing Upstream to Apache

Hi everyone,

I’m Jesús González, and I am part of VMware’s Wasm Labs: wasmlabs.dev 
, a group focused on creating open source tools for WebAssembly.


We have created mod_wasm, an Apachemodule for running WebAssembly 
binaries inside httpd, and we would like to contribute it upstream. 
Please see below for more details. We would love to get your feedback 
and understand what improvements would be needed (if any) before it 
could be considered for contribution to the project.


The details:

WebAssembly 
(Wasm) is a new binary instruction format that is open, portable, efficient, secure, and polyglot. It originated in the browser but is increasingly used in server applications, in particular NGINX, Apache APISIX, Istio provide Wasm-based plugin support (i.e.: https://apisix.apache.org/docs/apisix/wasm/ ).


mod_wasm is a way to run WebAssembly modules inside Apache Server. This 
is similar to how mod_php embeds a PHP runtime to run PHP code. This 
enables any language that supports WebAssembly (including C++, Rust, Go 
but also Python, PHP, Ruby) to run with mod_wasm and take advantage of 
the extra level of security and sandboxing. To learn more about mod_wasm 
you can check out the following resources:


  * An overviewarticle

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

[Marion & Christophe JAILLET]

Hi Emmanuel,

just a nit: every commit triggers our CI (see [1]). This helps to spot 
new build issues and regression.


When a commit does not change the code itself, triggering the CI is not 
really useful and will likely only waste some CPU and bandwidth.
So when only STATUS, CHANGES or documentation are changed, you can add 
in the commit text the string "[skip ci]".


On the contrary, if for some reason a regression or build issue has been 
introduced, you can also touch these files (removing a trailing space, 
fixing a typo, ...) to force the CI to run.


If of interest to you, where to find CI reports is also explained in [1].


Happy hacking :)

CJ

[1]: https://httpd.apache.org/dev/devnotes.html#continuous-integration-ci



Le 19/11/2022 à 02:45, m...@apache.org a écrit :

Author: manu
Date: Sat Nov 19 01:45:24 2022
New Revision: 1905387

URL: http://svn.apache.org/viewvc?rev=1905387=rev
Log:
Backport ptoposal for DAVlockDiscovery option, and attempt to open DAVLockDB
read-only when possible.

Modified:
 httpd/httpd/branches/2.4.x/STATUS

Modified: httpd/httpd/branches/2.4.x/STATUS
URL: 
http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?rev=1905387=1905386=1905387=diff
==
--- httpd/httpd/branches/2.4.x/STATUS (original)
+++ httpd/httpd/branches/2.4.x/STATUS Sat Nov 19 01:45:24 2022
@@ -282,6 +282,20 @@ PATCHES/ISSUES THAT ARE BEING WORKED
   make it nonblocking (by default)?
  jim: Non-blocking seems the best way to handle...
  
+  *) mod_dav: Open the lock database read-only when possible

+ trunk patch: http://svn.apache.org/r1905229
+ 2.4.x patch: trunk works
+ +1: manu
+
+  *) mod_dav: DAVlockDiscovery option to disable WebDAV lock discovery
+ This is a game changer for performances if client use PROPFIND a lot,
+ trunk patch: http://svn.apache.org/r1904638
+  http://svn.apache.org/r1904662
+  http://svn.apache.org/r1905170
+  http://svn.apache.org/r1905206
+  http://svn.apache.org/r1905230
+ 2.4.x patch: trunk works
+ +1: manu
  
  PATCHES/ISSUES THAT ARE STALLED
  

Re: New committer: Emmanuel Dreyfus

[Christophe JAILLET]

Le 08/11/2022 à 11:14, Joe Orton a écrit :

The Project Management Committee (PMC) for the Apache HTTP Server has
invited Emmanuel Dreyfus to become a committer and we are pleased to
announce that they have accepted.

Welcome, Emmanuel!

Regards, Joe




Welcome on board Emmanuel :).

CJ

Re: Define variable in modules

[Christophe JAILLET]

Le 20/10/2022 à 15:55, Nick Gearls a écrit :

Hello,

It would sometimes be very handy to be able to define a variable (like 
-D on command-line or "Define xxx" in the config) inside a module.
This would, for instance, allow to have a config file based on a 
define from the module, knowing if the new syntax is known or not, etc.


Concrete example: in mod_security2, they introduced a new "collection".
If you use this collection in an old version, it's a syntax error.
If mod_security2 defines the variable "support_new_collection" (OK, 
very bad name obviously), then we can enclose the rule using a 
".


Would it be possible to export a function to define such a variable?

Thanks


Hi,

Maybe this would not be super-clean, but the module could define some 
(useless) directives (i.e. MOD_SEC2_HAS_NEW_COLLECTION_SUPPORT) and 
config files could be tweaked with .


This should work as-is without any new code.
Does it match your use-case?

CJ

Re: svn commit: r1903744 - in /httpd/httpd/trunk: docs/manual/mod/mod_proxy_hcheck.xml modules/proxy/mod_proxy.c modules/proxy/mod_proxy.h modules/proxy/mod_proxy_hcheck.c

[Christophe JAILLET]

Le 28/08/2022 à 20:46, j...@apache.org a écrit :

Author: jim
Date: Sun Aug 28 18:46:21 2022
New Revision: 1903744

URL: http://svn.apache.org/viewvc?rev=1903744=rev
Log:
Allow for HTTP/1.1 or HTTP/1.0 protocol health checks

Modified:
 httpd/httpd/trunk/docs/manual/mod/mod_proxy_hcheck.xml
 httpd/httpd/trunk/modules/proxy/mod_proxy.c
 httpd/httpd/trunk/modules/proxy/mod_proxy.h
 httpd/httpd/trunk/modules/proxy/mod_proxy_hcheck.c

Modified: httpd/httpd/trunk/docs/manual/mod/mod_proxy_hcheck.xml
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_proxy_hcheck.xml?rev=1903744=1903743=1903744=diff
==
--- httpd/httpd/trunk/docs/manual/mod/mod_proxy_hcheck.xml (original)
+++ httpd/httpd/trunk/docs/manual/mod/mod_proxy_hcheck.xml Sun Aug 28 18:46:21 
2022
@@ -60,9 +60,12 @@

MethodDescriptionNote
NoneNo dynamic health checking 
done
TCPCheck that a socket to the backend can be created: e.g. "are you 
up"
-   OPTIONSSend an HTTP OPTIONS request to the 
backend*
-   HEADSend an HTTP HEAD request to the 
backend*
-   GETSend an HTTP GET request to the 
backend*
+   OPTIONSSend a HTTP OPTIONS request to the backend via 
HTTP/1.0*
+   HEADSend a HTTP HEAD request to the backend via 
HTTP/1.0*
+   GETSend a HTTP GET request to the backend via 
HTTP/1.0*
+   OPTIONS11Send a HTTP OPTIONS request to the backend via 
HTTP/1.1*
+   HEAD11Send a HTTP HEAD request to the backend via 
HTTP/1.1*
+   GET11Send a HTTP GET request to the backend via 
HTTP/1.1*
  

Re: Escaping double quotation marks in the error log

[Christophe JAILLET]

Le 05/10/2022 à 12:26, Rainer Jung a écrit :

Hi there,

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


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


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


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


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


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

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


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

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


Best regards,

Rainer



Hi,

not sure it answers your questions but r1829898 is already about JSON 
logging.



Also, jkaluza's ap_errorlog_provider proposal (see ISSUES THAT ARE 
STALLED in 2.4.x/STATUS) should be able to provide flexibility about how 
and what is logged.


I've never looked at the proposed API, but I *would* expect that "raw" 
strings are passed to the logger. If so, it should be able to escape or 
not whatever it wants, the way it wants.


CJ

Re: svn commit: r1904299 - /httpd/httpd/trunk/modules/http2/h2_workers.c

[Christophe JAILLET]

Le 27/09/2022 à 13:00, ic...@apache.org a écrit :

Author: icing
Date: Tue Sep 27 11:00:10 2022
New Revision: 1904299

URL: http://svn.apache.org/viewvc?rev=1904299=rev
Log:
   *) mod_http2: use proper apr_time_t where it is due, no (int) casting.


Modified:
 httpd/httpd/trunk/modules/http2/h2_workers.c

Modified: httpd/httpd/trunk/modules/http2/h2_workers.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/http2/h2_workers.c?rev=1904299=1904298=1904299=diff
==
--- httpd/httpd/trunk/modules/http2/h2_workers.c (original)
+++ httpd/httpd/trunk/modules/http2/h2_workers.c Tue Sep 27 11:00:10 2022
@@ -78,7 +78,7 @@ struct h2_workers {
  
  apr_uint32_t max_slots;

  apr_uint32_t min_active;
-volatile int idle_limit;
+volatile apr_time_t idle_limit;
  volatile int aborted;
  volatile int shutdown;
  int dynamic;
@@ -315,7 +315,7 @@ static void* APR_THREAD_FUNC slot_run(ap
  APR_RING_INSERT_TAIL(>idle, slot, h2_slot, link);
  ++workers->idle_slots;
  slot->is_idle = 1;
-if (slot->id >= workers->min_active && workers->idle_limit) {
+if (slot->id >= workers->min_active && workers->idle_limit > 0) {
  rv = apr_thread_cond_timedwait(slot->more_work, workers->lock,
 workers->idle_limit);
  if (APR_TIMEUP == rv) {
@@ -416,7 +416,8 @@ static apr_status_t workers_pool_cleanup
  }
  
  h2_workers *h2_workers_create(server_rec *s, apr_pool_t *pchild,

-  int max_slots, int min_active, apr_time_t 
idle_limit)
+  int max_slots, int min_active,
+  apr_time_t idle_limit)
  {
  apr_status_t rv;
  h2_workers *workers;
@@ -453,7 +454,7 @@ h2_workers *h2_workers_create(server_rec
  workers->pool = pool;
  workers->min_active = min_active;
  workers->max_slots = max_slots;
-workers->idle_limit = (int)((idle_limit > 0)? idle_limit : 
apr_time_from_sec(10));
+workers->idle_limit = (idle_limit > 0)? idle_limit : apr_time_from_sec(10);


Hi,

just wondering if this 10s is related to the default value of 
H2MaxWorkerIdleSeconds?


If yes, the doc says 600 (unless I missed something obvious).

CJ



  workers->dynamic = (workers->min_active < workers->max_slots);
  
  ap_log_error(APLOG_MARK, APLOG_INFO, 0, s,

Re: apreq documentation

[Christophe JAILLET]

Le 04/09/2022 à 08:18, Christophe JAILLET a écrit :

I've commited the change yesterday on 
https://github.com/apache/httpd-site, but the site has not been updated 
(mail to the csv mailing list about the commit neither)


I've contacted infra this morning about it.

If s.o. has an idea of what I did wrong or if something is broken 
somewhere, it is welcomed.


CJ



I saw that yesterday there has been some issues with a GitBox. This is 
maybe related to my problem.


I made a dummy change this morning on github and all changes have been 
applied.


CJ

Re: apreq documentation

[Christophe JAILLET]

Le 28/08/2022 à 15:48, Christophe JAILLET a écrit :

Hi,

with the recent release of apreq 2.17, the documentation ([1]) looked a 
bit out dated.

The main page speaks about 2.13!


It was last generated with Doxygen 1.5.6 nearly 12 years ago.
The link to the documentation can be found at ([2]).


Tweaking things a bit (see my recent commits), and using Doxygen 1.9.1, 
it now looks much better.
I've tried to re-implement the same layout as before, so the standard 
1.9.1 Doxygen layout has been slightly customized.


You can give it a try at:
http://home.apache.org/~jailletc36/apreq_doc_2.17/docs/html/index.html

If we reach an agreement on the new look, it can be uploaded on a.o.org 
to refresh the look and be more consistent with the rest of the website.



I'm not sure that the 2.17 Changelog is complete.
If I'm right, this release is mainly about a CVE, but it is not listed 
and [3] gives hints about other changes in the past months/years.



Comments and bug hunting welcome :)

CJ


[1]: https://httpd.apache.org/apreq/docs/libapreq2/index.html
|2]: https://httpd.apache.org/apreq/
[3]: https://svn.apache.org/viewvc/httpd/apreq/trunk/library/?sortby=date




I've commited the change yesterday on 
https://github.com/apache/httpd-site, but the site has not been updated 
(mail to the csv mailing list about the commit neither)


I've contacted infra this morning about it.

If s.o. has an idea of what I did wrong or if something is broken 
somewhere, it is welcomed.


CJ

apreq documentation

[Christophe JAILLET]

Hi,

with the recent release of apreq 2.17, the documentation ([1]) looked a 
bit out dated.

The main page speaks about 2.13!


It was last generated with Doxygen 1.5.6 nearly 12 years ago.
The link to the documentation can be found at ([2]).


Tweaking things a bit (see my recent commits), and using Doxygen 1.9.1, 
it now looks much better.
I've tried to re-implement the same layout as before, so the standard 
1.9.1 Doxygen layout has been slightly customized.


You can give it a try at:
http://home.apache.org/~jailletc36/apreq_doc_2.17/docs/html/index.html

If we reach an agreement on the new look, it can be uploaded on a.o.org 
to refresh the look and be more consistent with the rest of the website.



I'm not sure that the 2.17 Changelog is complete.
If I'm right, this release is mainly about a CVE, but it is not listed 
and [3] gives hints about other changes in the past months/years.



Comments and bug hunting welcome :)

CJ


[1]: https://httpd.apache.org/apreq/docs/libapreq2/index.html
|2]: https://httpd.apache.org/apreq/
[3]: https://svn.apache.org/viewvc/httpd/apreq/trunk/library/?sortby=date

Re: svn commit: r1898962 - /httpd/httpd/trunk/modules/md/md_store_fs.c

[Christophe JAILLET]

Le 16/03/2022 à 09:28, ic...@apache.org a écrit :

Author: icing
Date: Wed Mar 16 08:28:27 2022
New Revision: 1898962

URL: http://svn.apache.org/viewvc?rev=1898962=rev
Log:
   *) mod_md: fix compiler warning about NULL arg to a %s log. Fixes PR 65955.


Modified:
 httpd/httpd/trunk/modules/md/md_store_fs.c

Modified: httpd/httpd/trunk/modules/md/md_store_fs.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/md/md_store_fs.c?rev=1898962=1898961=1898962=diff
==
--- httpd/httpd/trunk/modules/md/md_store_fs.c (original)
+++ httpd/httpd/trunk/modules/md/md_store_fs.c Wed Mar 16 08:28:27 2022
@@ -503,6 +503,7 @@ static apr_status_t mk_group_dir(const c
  
  perms = gperms(s_fs, group);
  
+*pdir = NULL;

  rv = fs_get_dname(pdir, _fs->s, group, name, p);
  if ((APR_SUCCESS != rv) || (MD_SG_NONE == group)) goto cleanup;
  
@@ -521,7 +522,8 @@ static apr_status_t mk_group_dir(const c

  }
  cleanup:
  if (APR_SUCCESS != rv) {
-md_log_perror(MD_LOG_MARK, MD_LOG_ERR, rv, p, "mk_group_dir %d %s", 
group, name);
+md_log_perror(MD_LOG_MARK, MD_LOG_ERR, rv, p, "mk_group_dir %d %s",
+group, (*pdir? *pdir : (name? name : "(null)")));
  }
  return rv;
  }



Hi,

looks that this has been reverted in r1900313.

Is it intentional?

CJ

Re: svn commit: r1900356 - in /httpd/httpd/trunk: changes-entries/pr66037.txt modules/http2/h2_util.c modules/http2/h2_util.h

[Christophe JAILLET]

Le 28/04/2022 à 12:41, ic...@apache.org a écrit :

Author: icing
Date: Thu Apr 28 10:41:48 2022
New Revision: 1900356

URL: http://svn.apache.org/viewvc?rev=1900356=rev
Log:
   *) mod_http2: remove unused and insecure code. Fixes PR66037.
  Thanks to Ronald Crane (Zippenhop LLC) for reporting this.


Added:
 httpd/httpd/trunk/changes-entries/pr66037.txt
Modified:
 httpd/httpd/trunk/modules/http2/h2_util.c
 httpd/httpd/trunk/modules/http2/h2_util.h

Added: httpd/httpd/trunk/changes-entries/pr66037.txt
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/changes-entries/pr66037.txt?rev=1900356=auto
==
--- httpd/httpd/trunk/changes-entries/pr66037.txt (added)
+++ httpd/httpd/trunk/changes-entries/pr66037.txt Thu Apr 28 10:41:48 2022
@@ -0,0 +1,3 @@
+  *) mod_http2: remove unused and insecure code. Fixes PR66037.
+ Thanks to Ronald Crane (Zippenhop LLC) for reporting this.
+ [Stefan Eissing]


Hi Stefan,

Missing vote for this trivial clean-up?

CJ


\ No newline at end of file

Modified: httpd/httpd/trunk/modules/http2/h2_util.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/http2/h2_util.c?rev=1900356=1900355=1900356=diff
==
--- httpd/httpd/trunk/modules/http2/h2_util.c (original)
+++ httpd/httpd/trunk/modules/http2/h2_util.c Thu Apr 28 10:41:48 2022
@@ -76,26 +76,6 @@ size_t h2_util_hex_dump(char *buffer, si
  return strlen(buffer);
  }
  
-size_t h2_util_header_print(char *buffer, size_t maxlen,

-const char *name, size_t namelen,
-const char *value, size_t valuelen)
-{
-size_t offset = 0;
-size_t i;
-for (i = 0; i < namelen && offset < maxlen; ++i, ++offset) {
-buffer[offset] = name[i];
-}
-for (i = 0; i < 2 && offset < maxlen; ++i, ++offset) {
-buffer[offset] = ": "[i];
-}
-for (i = 0; i < valuelen && offset < maxlen; ++i, ++offset) {
-buffer[offset] = value[i];
-}
-buffer[offset] = '\0';
-return offset;
-}
-
-
  void h2_util_camel_case_header(char *s, size_t len)
  {
  size_t start = 1;

Modified: httpd/httpd/trunk/modules/http2/h2_util.h
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/http2/h2_util.h?rev=1900356=1900355=1900356=diff
==
--- httpd/httpd/trunk/modules/http2/h2_util.h (original)
+++ httpd/httpd/trunk/modules/http2/h2_util.h Thu Apr 28 10:41:48 2022
@@ -28,10 +28,6 @@ struct nghttp2_frame;
  size_t h2_util_hex_dump(char *buffer, size_t maxlen,
  const char *data, size_t datalen);
  
-size_t h2_util_header_print(char *buffer, size_t maxlen,

-const char *name, size_t namelen,
-const char *value, size_t valuelen);
-
  void h2_util_camel_case_header(char *s, size_t len);
  
  int h2_util_frame_print(const nghttp2_frame *frame, char *buffer, size_t maxlen);

Re: svn commit: r1898227 [1/3] - in /httpd/httpd/branches/2.4.x/docs/manual: expr.html.fr.utf8 mod/directives.html.fr.utf8 mod/mod_authnz_ldap.html.fr.utf8 mod/quickreference.html.fr.utf8

[Christophe JAILLET]

Le 20/02/2022 à 15:23, Lucien Gentis a écrit :

Hello,

Sorry, it is my fault !


Hmmm, reading below, I would say that it is mine :(
You are not the one who has back-ported the broken xml file without 
testing and generating the doc.


So, apologies!



I updated and committed mod_authnz_ldap.xml.fr while mod_authnz_ldap.xml 
was not a valid document.


It was fixed on trunk a long time ago in r1591113.



Effectively, 
httpd/httpd/branches/2.4.x/docs/manual/mod/directives.html.fr.utf8 had 
lost 560 of his 800 lines !


So I corrected mod_authnz_ldap.xml in order to make it valid, committed 
it, rebuilt the doc, and all seems OK again (deleted directives appear 
again in directives.html.fr.utf8).


All is OK yet ?



At least, it looks in a much better shape ;-)

I wouldn't have expected a broken xml file to be the root cause of a 
partly updated directives.html file!


Thanks for investigating and fixing.

CJ

Re: svn commit: r1898227 [1/3] - in /httpd/httpd/branches/2.4.x/docs/manual: expr.html.fr.utf8 mod/directives.html.fr.utf8 mod/mod_authnz_ldap.html.fr.utf8 mod/quickreference.html.fr.utf8

[Christophe JAILLET]

Le 19/02/2022 à 17:12, lgen...@apache.org a écrit :

Author: lgentis
Date: Sat Feb 19 16:12:53 2022
New Revision: 1898227

URL: http://svn.apache.org/viewvc?rev=1898227=rev
Log:
fr doc rebuild.

Modified:
 httpd/httpd/branches/2.4.x/docs/manual/expr.html.fr.utf8
 httpd/httpd/branches/2.4.x/docs/manual/mod/directives.html.fr.utf8
 httpd/httpd/branches/2.4.x/docs/manual/mod/mod_authnz_ldap.html.fr.utf8
 httpd/httpd/branches/2.4.x/docs/manual/mod/quickreference.html.fr.utf8

Modified: httpd/httpd/branches/2.4.x/docs/manual/expr.html.fr.utf8
URL: 
http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/docs/manual/expr.html.fr.utf8?rev=1898227=1898226=1898227=diff
==
--- httpd/httpd/branches/2.4.x/docs/manual/expr.html.fr.utf8 [utf-8] (original)
+++ httpd/httpd/branches/2.4.x/docs/manual/expr.html.fr.utf8 [utf-8] Sat Feb 19 
16:12:53 2022
@@ -497,6 +497,12 @@ listfunction ::= listfuncname "(
  filesize
  Renvoie la taille d'un fichier (ou 0 si le fichier n'existe
pas ou ne correspond pas à un fichier régulier)limité
+ldap
+Echappe les caractères selon la RFC4514 (Echappement des
+   noms distinctifs LDAP - DN) et la RFC4515 (Echappement des
+   filtres LDAP).
+   Disponible à partir de la version 2.4.53 du serveur HTTP
+   Apache.
  
  
  Les fonctions marquées comme "limité" dans la dernière colonne ne sont


Modified: httpd/httpd/branches/2.4.x/docs/manual/mod/directives.html.fr.utf8
URL: 
http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/docs/manual/mod/directives.html.fr.utf8?rev=1898227=1898226=1898227=diff
==
--- httpd/httpd/branches/2.4.x/docs/manual/mod/directives.html.fr.utf8 [utf-8] 
(original)
+++ httpd/httpd/branches/2.4.x/docs/manual/mod/directives.html.fr.utf8 [utf-8] 
Sat Feb 19 16:12:53 2022
@@ -46,34 +46,17 @@
sous une forme abrégée.
  

-A | B | C | D | E | F | G | H | I | K | L | M | N | O | P | Q | R | S | T | U | V | W | X

+A | C | D | E | F | G | H | I | K | L | M | N | O | P | Q | R | S | T | U | V
  
  
  AcceptFilter
  AcceptPathInfo
  AccessFileName
  Action
-AddAlt
-AddAltByEncoding
-AddAltByType
-AddCharset
  AddDefaultCharset
-AddDescription
-AddEncoding
-AddHandler
-AddIcon
-AddIconByEncoding
-AddIconByType
-AddInputFilter
-AddLanguage

[...]

All these removals look really really odd.

Any idea on what happened?

CJ

Re: opinion poll, stale issues

[Christophe JAILLET]

Le 16/02/2022 à 10:32, Stefan Eissing a écrit :

How about we close stale issues on our bugzilla after a year without changes 
with

WONTFIX
We are sorry, but no one found the interest/time to work on this.

ideally as an automated job somewhere?

Kind Regards,
Stefan


Hi,

I share Rüdiger point of view.

However, in the past, there has already been some mass updates (random 
example BZ 55039)
It has been done more than 1 year after the official EOL of the 2.2.x 
branch and only targeted 2.0.x and 2.2.x bugs.


I'm fine with the extensive explanation added and with the timing, long 
enough after EOL.


This approach could be refined with mass closing old entries tagged 
against HEAD.
For example in BZ 41088, 2.5-HEAD was certainly not against the actual 
2.5 when opened in 2006.


Such mass-updates can be done directly within the bugzilla HMI. Not sure 
if it requires some special rights, but should it need some special 
karma, some of us already have it.


CJ

Re: PCRE2 compatibility

[Christophe JAILLET]

Le 14/02/2022 à 21:10, Jeff McKenna a écrit :

Hi Doug,

If by "incompatible" you mean to ask if one can point to PCRE2 with 
CMake with Apache 2.4.51 & build successfully, I can tell you that yes 
it is incompatible, I was not able to build 2.4.51 with PCRE2 through 
CMake, with Visual Studio 2019.


(at the time I found many reporting this online, and a long list of 
"workarounds", not easy to implement, so for my distribution I chose to 
remain at PCRE 8.45, for now, unfortunately)


Thanks,

-jeff



Hi jeff,

if you can build and test on Windows, it would be great if you can try 
to apply patches listed in [1], build and test :).


In this link, you'll see another patch ([2]) to fix the performance issue.

So building and testing with [2] as well would be much appreciated :).


CJ

[1]: 
https://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?revision=1897901=markup#l147


[2]: https://github.com/apache/httpd/pull/289   or

https://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?revision=1897901=markup#l228

Re: PCRE2 compatibility

[Christophe JAILLET]

Le 14/02/2022 à 21:14, Doug Whitfield a écrit :

Thanks Jeff, this is exactly what I am talking about!

I see that there are some patches out that purport to fix this. Does 
anybody know if those work and if they are ever going to get merged 
since pcre is defunct?


I saw references to some pcre backports on a httpd mailing list last 
week (I think dev, but I wouldn’t swear to it). I’m not sure if those 
were related or not.





Hi,

PCRE2 has been added in trunk some time ago.
It has never reached the 2.4.x branch so far because of a performance 
issue related to memory allocation.


The backport to 2.4.x has re-surfaced a few weeks or months ago and some 
proposals to workaround the performance issue have also been proposed.


A backport for 2.4.x has been voted, but not merged yet.
A set of patches have been merged in trunk for the performance issue. 
AFAIK some testing on Windows would be welcomed.


So, yes, PCRE2 *should* be usable with the next version oh httpd, even 
if some performance tuning are merged later on.


CJ

Re: Fwd: FYI: change to travis-ci emailer could cause moderation headaches

[Christophe JAILLET]

Le 26/01/2022 à 14:58, Eric Covener a écrit :

I noticed I stopped getting "Travis CI" emails for httpd around 10/21.
But I see people still discussing CI failures, so I am a little
confused. Maybe they are only seeing it in the context of PRs.


For me, manual check of 
https://app.travis-ci.com/github/apache/httpd/builds as well.


CJ




Did we lose notifications to dev@ as a result of the below? Or something else?

-- Forwarded message -
From: sebb 
Date: Thu, Oct 28, 2021 at 11:08 AM
Subject: FYI: change to travis-ci emailer could cause moderation headaches
To: Users 


It looks like mails from bui...@travis-ci.com are now using a
different email provider.

This means that the envelope sender has changed.

They used to use mandrillapp.com, but now seem to use amazonses.com

mandrillapp.com used a dynamic envelope sender, but there was a
pattern to it which meant that the underlying sender could be detected
(see INFRA-18843)

It's not clear if the amazonses.com envelopes have a common pattern
that could be leveraged in the same way.

If not, I suspect every email from travis.com will need to be moderated.

Unless someone has a better idea of how to allow such emails without
opening the floodgates.

Sebb

Re: svn commit: r1897281 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h include/scoreboard.h modules/generators/mod_status.c modules/ssl/mod_ssl.c modules/ssl/ssl_engine_io.c server/mpm/event/event

[Christophe JAILLET]

Le 22/01/2022 à 14:01, Yann Ylavic a écrit :


+}
+else if (rv == APR_EAGAIN) {


APR_STATUS_IS_EAGAIN(rv)?



If it is likely the way to do, according to a quick grep "== 
APR_EAGAIN", their are a few places in event and http2 to check.


CJ

Re: svn commit: r1897281 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h include/scoreboard.h modules/generators/mod_status.c modules/ssl/mod_ssl.c modules/ssl/ssl_engine_io.c server/mpm/event/event

[Christophe JAILLET]

Le 21/01/2022 à 01:09, minf...@apache.org a écrit :

Author: minfrin
Date: Fri Jan 21 00:09:24 2022
New Revision: 1897281

URL: http://svn.apache.org/viewvc?rev=1897281=rev
Log:
event: Add support for non blocking behaviour in the
CONN_STATE_READ_REQUEST_LINE phase, in addition to the existing
CONN_STATE_WRITE_COMPLETION phase. Update mod_ssl to perform non blocking
TLS handshakes.

Modified:
 httpd/httpd/trunk/CHANGES
 httpd/httpd/trunk/include/ap_mmn.h
 httpd/httpd/trunk/include/scoreboard.h
 httpd/httpd/trunk/modules/generators/mod_status.c
 httpd/httpd/trunk/modules/ssl/mod_ssl.c
 httpd/httpd/trunk/modules/ssl/ssl_engine_io.c
 httpd/httpd/trunk/server/mpm/event/event.c



Apparently, this breaks several tests.

See https://app.travis-ci.com/github/apache/httpd/builds/245157318

CJ

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

[Christophe JAILLET]

Le 17/01/2022 à 13:27, Ruediger Pluem a écrit :



On 1/16/22 10:35 PM, William A Rowe Jr wrote:

4 day ago, you all saw this. 6 years ago, you all started using this on trunk.

Don't know what I can to do help this along and honor the library
author's wishes for
all of us to walk away from the dead fork, and use the maintained
fork. It's whatever
it is, I'm out of here and removing the backport application branch,
whoever 3rd upvotes
this be prepared to apply this for us all, thanks.


With regards to the de-optimization / stack usage probably stupid question:
Can't we use the TLS features that several compilers offer?
e.g. see at the end of the page at 
https://stackoverflow.com/questions/18298280/how-to-declare-a-variable-as-thread-local-portably

If we have no thread_local we could fall back to the current unoptimized 
implementation?

Regards

Rüdiger




What about something as stupid as the attached patch?
(just a POC to give the general idea)

Reserve some space on stack (in the spirit of the optimization for 
PCRE1) and implement a malloc/free that is clever enough to use this 
space instead a real malloc if pcre2 does not ask for too much space.


The only difference with what is done with PCRE1 is that in this case we 
use on the stack the exact space needed for for POSIX_MALLOC_THRESHOLD 
(10) matches. In the attach patch, we reserve "some space" on the stack 
and we expect that it is large enough to avoid a malloc.



The space required by pcre2 is:
offsetof(pcre2_match_data, ovector) + 2*oveccount*sizeof(PCRE2_SIZE)

With:
typedef struct pcre2_real_match_data {
  pcre2_memctl memctl;
  const pcre2_real_code *code;/* The pattern used for the match */
  PCRE2_SPTR   subject;   /* The subject that was matched */
  PCRE2_SPTR   mark;  /* Pointer to last mark */
  PCRE2_SIZE   leftchar;  /* Offset to leftmost code unit */
  PCRE2_SIZE   rightchar; /* Offset to rightmost code unit */
  PCRE2_SIZE   startchar; /* Offset to starting code unit */
  uint8_t  matchedby; /* Type of match (normal, JIT, DFA) */
  uint8_t  flags; /* Various flags */
  uint16_t oveccount; /* Number of pairs */
  int  rc;/* The return code from the match */
  PCRE2_SIZE   ovector[131072]; /* Must be last in the structure */
} pcre2_real_match_data;

(my understanding is that pcre2_real_match_data and pcre2_match_data are 
the same)




So we should be able to compute a MAX_PCRE2_STACK_DATA (see patch) that 
is both large enough to store 10 or so matches, and not too big.


Not sure it is a clean solution, but I guess that it could work.


BTW, does someone have some numbers for the cost of the malloc we try to 
avoid? (read: are we over engineering the solution?)


CJIndex: util_pcre.c
===
--- util_pcre.c	(révision 1896817)
+++ util_pcre.c	(copie de travail)
@@ -272,6 +272,31 @@
   eflags);
 }
 
+//
+// Code called somewhere at server start to "register" our malloc/free functions
+// For PCRE2 memory allocation optimization
+//
+pcre2_general_context *global_pcre2_context =
+pcre2_general_context_create(_malloc, _free, NULL)
+//
+//
+
+#define MAX_PCRE2_STACK_DATA1024
+#define PCRE2_ON_STACK  ((void *)(-1))
+
+void *pcre2_malloc(size_t size, void *data)
+{
+if (size <= MAX_PCRE2_STACK_DATA)
+return PCRE2_ON_STACK;
+
+return malloc(size);
+}
+
+void pcre2_free(void *mem, void *data)
+{
+return free(mem);
+}
+
 AP_DECLARE(int) ap_regexec_len(const ap_regex_t *preg, const char *buff,
apr_size_t len, apr_size_t nmatch,
ap_regmatch_t *pmatch, int eflags)
@@ -282,11 +307,12 @@
 #ifdef HAVE_PCRE2
 pcre2_match_data *matchdata;
 size_t *ovector;
+char small_ovector[MAX_PCRE2_STACK_DATA];
 #else
 int small_ovector[POSIX_MALLOC_THRESHOLD * 3];
-int allocated_ovector = 0;
 int *ovector = NULL;
 #endif
+int allocated_ovector = 0;
 
 if ((eflags & AP_REG_NOTBOL) != 0)
 options |= PCREn(NOTBOL);
@@ -304,9 +330,17 @@
  */
 nlim = ((apr_size_t)preg->re_nsub + 1) > nmatch
  ? ((apr_size_t)preg->re_nsub + 1) : nmatch;
-matchdata = pcre2_match_data_create(nlim, NULL);
+
+allocated_ovector = 1;
+matchdata = pcre2_match_data_create(nlim, global_pcre2_context);
 if (matchdata == NULL)
 return AP_REG_ESPACE;
+if (matchdata == PCRE2_ON_STACK)
+{
+allocated_ovector = 0;
+matchdata = small_ovector;
+}
+
 ovector = pcre2_get_ovector_pointer(matchdata);
 rc = pcre2_match((const pcre2_code *)preg->re_pcre,
  (const unsigned char *)buff, len,
@@ -343,7 +377,8 @@
 }
 
 #ifdef HAVE_PCRE2
-pcre2_match_data_free(matchdata);
+if (allocated_ovector)
+pcre2_match_data_free(matchdata);
 

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

[Christophe JAILLET]

Le 17/01/2022 à 14:16, Ruediger Pluem a écrit :


On 1/17/22 1:38 PM, Eric Covener wrote:

On Mon, Jan 17, 2022 at 7:28 AM Ruediger Pluem  wrote:



On 1/16/22 10:35 PM, William A Rowe Jr wrote:

4 day ago, you all saw this. 6 years ago, you all started using this on trunk.

Don't know what I can to do help this along and honor the library
author's wishes for
all of us to walk away from the dead fork, and use the maintained
fork. It's whatever
it is, I'm out of here and removing the backport application branch,
whoever 3rd upvotes
this be prepared to apply this for us all, thanks.

With regards to the de-optimization / stack usage probably stupid question:
Can't we use the TLS features that several compilers offer?
e.g. see at the end of the page at 
https://stackoverflow.com/questions/18298280/how-to-declare-a-variable-as-thread-local-portably

If we have no thread_local we could fall back to the current unoptimized 
implementation?

I more identified with Joe's comment, if we had an _ex version we
could pass pools for our own usage.
If some other heavy regex hitter third-party module finds an issue
(like mod_security) it might degrade a little bit but they can always
take advantage of it too.

Also, what about alloca()?

Trivia but I should add that in an integration between two third-party
mods I recently ripped out apr_threadkey stuff due to a crash after
some OS updates that nobody can explain. Fortunately the problematic
API had been extended with userdata and it was no longer absolutely
necessary. It was our only use of these API's so I was glad to
simplify and just remove them and move on.
Net, I would be hesitant to introduce something too new.

>From a quick glance apr_threadkey seems to use pthread_*specific for which I 
found postings that state that it is slow compared to
the compiler implemented thread locals. OTOH __thread alike stuff does not seem 
to offer any cleanup at thread exit which would
not allow us to free any resource that was created for that thread :-(. Hence I 
guess providing a pool to the call remains the
only solution here.


Some time ago, I played with apr_threadkey for another use case related 
to mod_unique_id (see r1887244+r1887245)
It has been reverted later because getting the thread ID was not 
reliable on Windows.


Discussion in BZ 65159.

I thought it could be a solution for PREC10 (see r1889287) but it wasn't.


I also looked at thread locals but AFAIK, it is not used in APR and it 
was raising a potential compatibility issue with build chain.



Just my 2c.

CJ



Regards

Rüdiger

Re: svn commit: r1896361 - /httpd/httpd/trunk/modules/ssl/mod_ssl_ct.c

[Marion & Christophe JAILLET]

Le 07/01/2022 à 14:13, Ruediger Pluem a écrit :


On 12/24/21 2:49 PM, jaillet...@apache.org wrote:

Author: jailletc36
Date: Fri Dec 24 13:49:35 2021
New Revision: 1896361

URL: http://svn.apache.org/viewvc?rev=1896361=rev
Log:
Close a file handle in case of error in ct_static_scts()

PR 65760 

Modified:
 httpd/httpd/trunk/modules/ssl/mod_ssl_ct.c

Modified: httpd/httpd/trunk/modules/ssl/mod_ssl_ct.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/mod_ssl_ct.c?rev=1896361=1896360=1896361=diff
==
--- httpd/httpd/trunk/modules/ssl/mod_ssl_ct.c (original)
+++ httpd/httpd/trunk/modules/ssl/mod_ssl_ct.c Fri Dec 24 13:49:35 2021
@@ -2967,6 +2967,7 @@ static const char *ct_static_scts(cmd_pa
  
  cert = PEM_read_X509(pemfile, NULL, NULL, NULL);

  if (!cert) {
+fclose(pemfile);

Couldn't we just move that before the if and remove the previously existing 
call?

Regards

Rüdiger


Hi,


if you mean something like:

https://github.com/tititiou36/httpd/commit/1348607c00ba58ce371f2f8ecb08abf610227043

Yes, this is just fine for me.


CJ

ocsp.t failing

[Christophe JAILLET]

Hi,

the last travis jobs have failed on trunk because of ocsp.t.

Unless I missed something, the only change with previous successful 
build is r1896361:


https://github.com/apache/httpd/commit/442b4b167f19e13df918402a7af28fe4a50c2730

I can't see any potential link.

Any idea?


BTW, ML don't receive anymore travis failures?

CJ

Re: Testing mod_tls

[Christophe JAILLET]

Le 20/12/2021 à 09:58, Stefan Eissing a écrit :




Am 19.12.2021 um 10:36 schrieb Christophe JAILLET 
:

Hi,

I've been able to build mod_tls

Basically, I've done:

sudo apt install cargo
sudo apt install cbindgen

git clone https://github.com/rustls/rustls-ffi.git git_rustls-ffi
sudo make install

I have:
/usr/local/lib/libcrustls.a
/usr/local/lib/librustls.a
/usr/local/include/crustls.h
/usr/local/include/rustls.h


pytest is also (apparently correctly) installed.
pytest test/modules/http2 works fine.


However, when I 'pytest test/modules/tls', I get:

Syntax error on line 31 of 
XXX/svn_httpd_2.4.x/test/gen/apache/conf/modules.conf: Cannot load 
XXX/httpd-2.4/modules/mod_tls.so into server: XXX/httpd-2.4/modules/mod_tls.so: 
undefined symbol: fmaf


My understanding is that mod_tls is correctly compiled, but that there is a 
missing library somewhere.

Does it ring some bell to s.o.?


The issue came up here: https://github.com/rustls/rustls-ffi/issues/133




Hi,

Rebuilding with the following patch made the trick for me.

You know all that much better than me, so I let you see if it should be 
applied on trunk/2.4.x.


CJ


Index: modules/tls/config2.m4
===
--- modules/tls/config2.m4  (révision 1896121)
+++ modules/tls/config2.m4  (copie de travail)
@@ -141,7 +141,7 @@
 MOD_TLS_LINK_LIBS="-lrustls -framework Security 
-framework Foundation"

 ;;
  *)
-MOD_TLS_LINK_LIBS="-lrustls"
+MOD_TLS_LINK_LIBS="-lrustls -lm"
 ;;
esac
# The only symbol which needs to be exported is the module

Re: Testing mod_tls

[Christophe JAILLET]

Le 20/12/2021 à 09:58, Stefan Eissing a écrit :




Am 19.12.2021 um 10:36 schrieb Christophe JAILLET 
:

Hi,

I've been able to build mod_tls

Basically, I've done:

sudo apt install cargo
sudo apt install cbindgen

git clone https://github.com/rustls/rustls-ffi.git git_rustls-ffi
sudo make install

I have:
/usr/local/lib/libcrustls.a
/usr/local/lib/librustls.a
/usr/local/include/crustls.h
/usr/local/include/rustls.h


pytest is also (apparently correctly) installed.
pytest test/modules/http2 works fine.


However, when I 'pytest test/modules/tls', I get:

Syntax error on line 31 of 
XXX/svn_httpd_2.4.x/test/gen/apache/conf/modules.conf: Cannot load 
XXX/httpd-2.4/modules/mod_tls.so into server: XXX/httpd-2.4/modules/mod_tls.so: 
undefined symbol: fmaf


My understanding is that mod_tls is correctly compiled, but that there is a 
missing library somewhere.

Does it ring some bell to s.o.?


The issue came up here: https://github.com/rustls/rustls-ffi/issues/133


Hi Stefan,

Thx for the pointer.

CJ





CJ

Testing mod_tls

[Christophe JAILLET]

Hi,

I've been able to build mod_tls

Basically, I've done:

sudo apt install cargo
sudo apt install cbindgen

git clone https://github.com/rustls/rustls-ffi.git git_rustls-ffi
sudo make install

I have:
/usr/local/lib/libcrustls.a
/usr/local/lib/librustls.a
/usr/local/include/crustls.h
/usr/local/include/rustls.h


pytest is also (apparently correctly) installed.
pytest test/modules/http2 works fine.


However, when I 'pytest test/modules/tls', I get:

Syntax error on line 31 of 
XXX/svn_httpd_2.4.x/test/gen/apache/conf/modules.conf: Cannot load 
XXX/httpd-2.4/modules/mod_tls.so into server: 
XXX/httpd-2.4/modules/mod_tls.so: undefined symbol: fmaf



My understanding is that mod_tls is correctly compiled, but that there 
is a missing library somewhere.


Does it ring some bell to s.o.?

CJ

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

[Christophe JAILLET]

Le 16/12/2021 à 15:03, Stefan Eissing a écrit :


Hi all,

Please find below the proposed release tarball and signatures:

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

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

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

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

Kind Regards,
Stefan



+1 ; Tested only with event.

Tested with:
Linux pop-os 5.15.5
gcc (Ubuntu 10.3.0-1ubuntu1) 10.3.0
OpenSSL 1.1.1j  16 Feb 2021
  libssl-dev 1.1.1j
  libbrotli-dev 1.0.9
  libjansson-dev 2.13.1
  libnghttp2-dev 1.43.0
  libpcre2-dev 10.36
  liblua5.3-dev 5.3.3
  libsystemd-dev 247.3
  libldap2-dev 2.4.57+dfsg
  libxml2-dev 2.9.10+dfsg
  libcurl4-openssl-dev 7.74.0

Thx a lot Stefan for RM.

CJ

Re: svn commit: r1895774 - /httpd/httpd/trunk/modules/ssl/ssl_engine_io.c

[Christophe JAILLET]

Le 10/12/2021 à 15:50, jor...@apache.org a écrit :

Author: jorton
Date: Fri Dec 10 14:50:19 2021
New Revision: 1895774

URL: http://svn.apache.org/viewvc?rev=1895774=rev
Log:
* modules/ssl/ssl_engine_io.c (bio_filter_in_ctrl): Remove debugging
   assert for unexpected control commands, matching bio_filter_out_ctrl
   which also ignores such invocations.  Fixes core dumps in debug
   builds with OpenSSL 3.0.0 which triggers this via the
   BIO_get_ktls_recv() call on the SSL bio, aka
 BIO_ctrl(b, BIO_CTRL_GET_KTLS_RECV, ...);

See: 
https://github.com/openssl/openssl/blob/105af0ad923a665ca5fee296b52dbf34b524a2aa/ssl/record/rec_layer_s3.c#L274

Modified:
 httpd/httpd/trunk/modules/ssl/ssl_engine_io.c

Modified: httpd/httpd/trunk/modules/ssl/ssl_engine_io.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_engine_io.c?rev=1895774=1895773=1895774=diff
==
--- httpd/httpd/trunk/modules/ssl/ssl_engine_io.c (original)
+++ httpd/httpd/trunk/modules/ssl/ssl_engine_io.c Fri Dec 10 14:50:19 2021
@@ -627,7 +627,6 @@ static long bio_filter_in_ctrl(BIO *bio,
  ap_log_cerror(APLOG_MARK, APLOG_TRACE1, 0, inctx->f->c,
"BUG: bio_filter_in_ctrl() should not be called with 
cmd=%i",
cmd);
-AP_DEBUG_ASSERT(0);


Does the "BUG" message still makes sense, then?

CJ


  return 0;
  }
  

Re: svn commit: r1893438 - in /httpd/test/framework/trunk/t/htdocs/modules/actions: action/dummy.txt script/dummy.txt

[Christophe JAILLET]

Le 19/09/2021 à 14:17, Eric Covener a écrit :

On Sun, Sep 19, 2021 at 8:09 AM Christophe JAILLET
 wrote:


Le 19/09/2021 à 13:49, cove...@apache.org a écrit :

Author: covener
Date: Sun Sep 19 11:49:34 2021
New Revision: 1893438

URL: http://svn.apache.org/viewvc?rev=1893438=rev
Log:
followup to r1893389: avoid empty dirs


Added:
  httpd/test/framework/trunk/t/htdocs/modules/actions/action/dummy.txt
  httpd/test/framework/trunk/t/htdocs/modules/actions/script/dummy.txt

Added: httpd/test/framework/trunk/t/htdocs/modules/actions/action/dummy.txt
URL: 
http://svn.apache.org/viewvc/httpd/test/framework/trunk/t/htdocs/modules/actions/action/dummy.txt?rev=1893438=auto
==
  (empty)

Added: httpd/test/framework/trunk/t/htdocs/modules/actions/script/dummy.txt
URL: 
http://svn.apache.org/viewvc/httpd/test/framework/trunk/t/htdocs/modules/actions/script/dummy.txt?rev=1893438=auto
==
  (empty)





Thx Eric.

Any idea why it fails on travis and works in some other configuration?


I am not sure if/why it is inconsistent within travis, but the reason
it fails is because git does not store empty directories and travis
currently pulls from the r/o github mirror due to a reliability
problem pulling from SVN



Got it. Thx.

Re: svn commit: r1893438 - in /httpd/test/framework/trunk/t/htdocs/modules/actions: action/dummy.txt script/dummy.txt

[Christophe JAILLET]

Le 19/09/2021 à 13:49, cove...@apache.org a écrit :

Author: covener
Date: Sun Sep 19 11:49:34 2021
New Revision: 1893438

URL: http://svn.apache.org/viewvc?rev=1893438=rev
Log:
followup to r1893389: avoid empty dirs


Added:
 httpd/test/framework/trunk/t/htdocs/modules/actions/action/dummy.txt
 httpd/test/framework/trunk/t/htdocs/modules/actions/script/dummy.txt

Added: httpd/test/framework/trunk/t/htdocs/modules/actions/action/dummy.txt
URL: 
http://svn.apache.org/viewvc/httpd/test/framework/trunk/t/htdocs/modules/actions/action/dummy.txt?rev=1893438=auto
==
 (empty)

Added: httpd/test/framework/trunk/t/htdocs/modules/actions/script/dummy.txt
URL: 
http://svn.apache.org/viewvc/httpd/test/framework/trunk/t/htdocs/modules/actions/script/dummy.txt?rev=1893438=auto
==
 (empty)





Thx Eric.

Any idea why it fails on travis and works in some other configuration?

CJ

Re: Broken: apache/httpd#1937 (trunk - 00e2ca5)

[Christophe JAILLET]

Le 17/09/2021 à 16:38, Travis CI a écrit :

apache

/

httpd

 



branch icontrunk 

build has failed
Build #1937 was broken 


arrow to build time
clock icon11 mins and 56 secs



Hi,

The error is related to some new tests I've added (r1893389) to improve 
our test-coverage.


The easiest would be to remove these (bogus ?) new tests.
They are likely due to my misunderstanding of how these directives work.

However, the tests work just fine on my config, so I don't really see 
why it fails on travis.


Some AH00128 are logged, so the 'default_handler' from core.c is called.
I don't see such errors in my logs. I've got only 3, which are expected. 
Two because .xyz and .xyz22 files have no handler, one because of a GET 
without any query arguments (e.g., foo.html?hi).


The failing tests are:
  t/modules/actions.t . 1/20
  # Failed test 9 in t/modules/actions.t at line 32 fail #5
  # Failed test 10 in t/modules/actions.t at line 33 fail #2
  # Failed test 13 in t/modules/actions.t at line 52
  # Failed test 14 in t/modules/actions.t at line 53
  # Failed test 16 in t/modules/actions.t at line 43 fail #2
  # Failed test 17 in t/modules/actions.t at line 44
  # Failed test 18 in t/modules/actions.t at line 52 fail #2
  # Failed test 19 in t/modules/actions.t at line 53 fail #2
  t/modules/actions.t . Failed 8/20 subtests

Test 9 and 10 try to access a non-existent file on purpose. In this 
case, the 'action' is configured as 'virtual' and the non-existence of 
the file should not be a problem.


The other tests are related to 'Script'. In this case, my understanding 
is that we could only end to the 'default_handler' if we are looping.
In such a case, I don't see why it would behave differently on my config 
and on travis.


:\

CJ

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

[Christophe JAILLET]

Le 10/09/2021 à 17:23, ste...@eissing.org a écrit :

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

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

The computed digests of the tarball up for vote are:
sha1: 525378680b3474ff319b83af76565891f8b98331 *httpd-2.4.49-rc1.tar.gz
sha256: 345d3b9b218b1974d1cebd5ae72f6a661d83b52d839310222ff9ec94abb62205 
*httpd-2.4.49-rc1.tar.gz
sha512: 
8efa12f239e1075c0eb8634dde5fa12e73b766a6a8f17882d6bedab8be3e02a1a15be8288413bb6da5be34e58a6e239342cdcb59ebe2d8d88ea4712028b03e5f
 *httpd-2.4.49-rc1.tar.gz

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

PS. Some slight change to previous releases:
The tarballs carry a prefix '-rc1' but the directory it unpacks
to is 'httpd-2.4.49'. This is to make sure that, when you vote
on a tarball and it is accepted, that we can release this very
thing you voted on.
All other things should be the same as in previous releases.



+1 ; Tested only with event.

Tested with:
Linux pop-os 5.11.0
gcc (Ubuntu 10.3.0-1ubuntu1) 10.3.0
OpenSSL 1.1.1j  16 Feb 2021
  libssl-dev 1.1.1j
  libbrotli-dev 1.0.9
  libjansson-dev 2.13.1
  libnghttp2-dev 1.43.0
  libpcre2-dev 10.36
  liblua5.3-dev 5.3.3
  libsystemd-dev 247.3
  libldap2-dev 2.4.57+dfsg
  libxml2-dev 2.9.10+dfsg
  libcurl4-openssl-dev 7.74.0


Also, a few things should be fixed, but can be done later:
LuaHookPreTranslateName  is not documented (neither in trunk nor in 
2.4.x)
 is not documented (neither in trunk nor in 
2.4.x)



Thx a lot Stefan for RM and tools.

CJ

Re: svn commit: r1893284 - /httpd/test/framework/trunk/README

[Christophe JAILLET]

Hi,

I've also been looking at this README file today and I have a few questions:
  - some of the explicitly named modules looks redundant with what is 
already in Bundle::ApacheTest
  - Crypt::SSLeay looks spurious. It doesn't compile on my machine 
because of function name conflicts with my openssl
    there is also a big warning that says that (recent) 
LWP::Protocol::https should be enough

  - this list is not in line with what is configured in .travis.yml

What puzzles me the most is the 3rd point.

CJ


Le 12/09/2021 à 19:12, cove...@apache.org a écrit :

Author: covener
Date: Sun Sep 12 17:12:55 2021
New Revision: 1893284

URL: http://svn.apache.org/viewvc?rev=1893284=rev
Log:
add FCGI and show cpanminus syntax for installation of all at onace


Modified:
 httpd/test/framework/trunk/README

Modified: httpd/test/framework/trunk/README
URL: 
http://svn.apache.org/viewvc/httpd/test/framework/trunk/README?rev=1893284=1893283=1893284=diff
==
--- httpd/test/framework/trunk/README (original)
+++ httpd/test/framework/trunk/README Sun Sep 12 17:12:55 2021
@@ -29,19 +29,15 @@ http://svn.apache.org/viewvc/perl/modper
  To run the tests for all Apache web server modules, some additional
  CPAN modules will be required. If the tests don't work, make sure
  that you have up to date versions of each of these perl modules:
-- HTTP::DAV (DAV tests)
-- DateTime (mod_include tests)
-- Time::HiRes
-- Protocol::HTTP2::Client and AnyEvent (mod_http2 tests)
-- Test
-- Test::Harness
-- Crypt::SSLeay
-- Net::SSLeay
-- IO::Socket::SSL
-- IO::Socket::IP
-- IO::Select
-- LWP::Protocol::https
-- AnyEvent::WebSocket::Client;
+
+```
+cpan App::cpanminus
+cpanm Bundle::ApacheTest \
+  HTTP::DAV DateTime Time::HiRes Protocol::HTTP2::Client Test  \
+  Test::Harness Crypt::SSLeay Net::SSLeay IO::Socket::SSL  \
+  IO::Socket::IP IO::Select LWP::Protocol::https AnyEvent  \
+  AnyEvent::WebSocket::Client FCGI
+```
  
  
  Quick Start

Re: project website update

[Christophe JAILLET]

Le 08/09/2021 à 12:13, ste...@eissing.org a écrit :

Need help to figure out how out website updates now after the "move" (whatever 
that means).

Formerly:

- changes committed into 
https://svn.apache.org/repos/asf/httpd/site/trunk/content

Changes committed in https://github.com/apache/httpd-site
(so needs to be listed as a contributor, I guess)


- TMP_KEY for from https://cms.apache.org/httpd/publish
- POST with same form fields done to trigger the update (I assume)
Nothing to do, it is now done automatically by some magic put in place 
by infra.

When pushed on github, it lands on h.a.o.

CJ



So, what is now the way?

- Stefan

Re: svn commit: r1892842 [9/24] - in /httpd/httpd/branches/2.4.x/docs/manual: ./ developer/ faq/ howto/ misc/ mod/ programs/ vhosts/

[Christophe JAILLET]

Le 03/09/2021 à 10:14, nil...@apache.org a écrit :

Modified: httpd/httpd/branches/2.4.x/docs/manual/install.html.de
URL: 
http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/docs/manual/install.html.de?rev=1892842=1892841=1892842=diff
==
--- httpd/httpd/branches/2.4.x/docs/manual/install.html.de (original)
+++ httpd/httpd/branches/2.4.x/docs/manual/install.html.de Fri Sep  3 08:14:02 
2021
[...]
-es |
-fr |
+es |
+fr |


Looks like we still have some UTF8 vs entities ping-pong issues related, 
I guess, to different versions of java.


I guess that UTF8 everywhere should be better to avoid it.
Apparently only es (2.4.x only), da, de and pt-br are concerned.

I'll try to remind the howto to convert them to UTF8.

CJ

Re: svn commit: r1893011 - /httpd/httpd/trunk/test/time-sem.c

[Christophe JAILLET]

Le 07/09/2021 à 10:52, yla...@apache.org a écrit :

Author: ylavic
Date: Tue Sep  7 08:52:23 2021
New Revision: 1893011

URL: http://svn.apache.org/viewvc?rev=1893011=rev
Log:
test/time-sem.c: unlock the accept mutex before exiting (error conditions).

Modified:
 httpd/httpd/trunk/test/time-sem.c


Hi,

just for my understanding, does anyone use these tests?
Are they run on travis? If no, should they be?

Same question, concerning the unitest framework (httpdunit)?
This is a great idea, but it looks mostly unused.

It tried to play with it a few years ago and found it quite hard to use, 
because most of our functions need some "context" (i.e. a request, a 
pool, a config, ...)

I was wondering if implementing such unittest as a module would make sense?
We could plug nearly anywhere with some hooks to have a meaningful 
context. We could also implement a new hook to let modules implement 
tests for functions that are not exported.
All this done, it could be run from our perl test framework as any other 
module.


CJ

Re: svn commit: r1893014 - in /httpd/httpd/trunk: changes-entries/event_maintenance_spawn_limit.txt server/mpm/event/event.c

[Christophe JAILLET]

Hi,

maybe completely off-topic, but we have the same kind of code in worker.c.

Just my 2c,

CJ

Le 07/09/2021 à 11:34, yla...@apache.org a écrit :

Author: ylavic
Date: Tue Sep  7 09:34:09 2021
New Revision: 1893014

URL: http://svn.apache.org/viewvc?rev=1893014=rev
Log:
mpm_event: Fix children processes possibly not stopped on graceful restart.

The number of children spawned can go above active_daemons_limit due to
exponential idle_spawn_rate growth (x 2), enforce the upper limit in
perform_idle_server_maintenance().  PR 63169.

Proposed by: Joel Self 

Added:
 httpd/httpd/trunk/changes-entries/event_maintenance_spawn_limit.txt
Modified:
 httpd/httpd/trunk/server/mpm/event/event.c

Added: httpd/httpd/trunk/changes-entries/event_maintenance_spawn_limit.txt
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/changes-entries/event_maintenance_spawn_limit.txt?rev=1893014=auto
==
--- httpd/httpd/trunk/changes-entries/event_maintenance_spawn_limit.txt (added)
+++ httpd/httpd/trunk/changes-entries/event_maintenance_spawn_limit.txt Tue Sep 
 7 09:34:09 2021
@@ -0,0 +1,2 @@
+  *) mpm_event: Fix children processes possibly not stopped on graceful
+ restart.  PR 63169.  [Joel Self ]
\ No newline at end of file

Modified: httpd/httpd/trunk/server/mpm/event/event.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/server/mpm/event/event.c?rev=1893014=1893013=1893014=diff
==
--- httpd/httpd/trunk/server/mpm/event/event.c (original)
+++ httpd/httpd/trunk/server/mpm/event/event.c Tue Sep  7 09:34:09 2021
@@ -3237,6 +3237,9 @@ static void perform_idle_server_maintena
  if (free_length > retained->idle_spawn_rate[child_bucket]) {
  free_length = retained->idle_spawn_rate[child_bucket];
  }
+if (free_length + active_daemons > active_daemons_limit) {
+free_length = active_daemons_limit - active_daemons;
+}
  if (retained->idle_spawn_rate[child_bucket] >= 8) {
  ap_log_error(APLOG_MARK, APLOG_INFO, 0, ap_server_conf, 
APLOGNO(00486)
   "server seems busy, (you may need "

re: *** SPAM *** svn commit: r1892963 - /httpd/httpd/branches/2.4.x/STATUS

[Marion et Christophe JAILLET]

 

 

 

 

 

> Message du 06/09/21 09:42
> De : ic...@apache.org
> A : c...@httpd.apache.org
> Copie à : 
> Objet : *** SPAM *** svn commit: r1892963 - /httpd/httpd/branches/2.4.x/STATUS
> 
> Author: icing
> Date: Mon Sep 6 07:42:34 2021
> New Revision: 1892963
> 
> URL: http://svn.apache.org/viewvc?rev=1892963=rev
> Log:
> assuming Christophe is for the backport he proposed. [skip ci]

Wrong assumption. :)

I sometimes propose for backport things that I don't vote for.
This happens when it really looks like a good candidate, but I don't have the 
knowledge to have my own opinion on it.
All I could do is to run the test framework, but travis already does it for us.

So, you don't have my +1 for this one :(
(but I'm sure Yann or anyone else will add his +1)

CJ

> 
> Modified:
> httpd/httpd/branches/2.4.x/STATUS
> 
> Modified: httpd/httpd/branches/2.4.x/STATUS
> URL: 
> http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?rev=1892963=1892962=1892963=diff
> ==
> --- httpd/httpd/branches/2.4.x/STATUS (original)
> +++ httpd/httpd/branches/2.4.x/STATUS Mon Sep 6 07:42:34 2021
> @@ -201,7 +201,7 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK:
> *) mpm_prefork: mask signals during ap_run_child_init()
> trunk patch: http://svn.apache.org/r1890465
> 2.4.x patch: svn merge -c 1890465 ^/httpd/httpd/trunk .
> - +1: 
> + +1: jailletc36, 
> 
> PATCHES/ISSUES THAT ARE BEING WORKED
> [ New entries should be added at the START of the list ]
> 
> 
>

Re: release?

[Christophe JAILLET]

Le 31/08/2021 à 20:25, Eric Covener a écrit :


Should we think about reverting the recent mod_unique_id changes?  It
seems like that was noticed pretty quickly but I think the current
problem is still not well understood. Meanwhile the original problem
on the old codebase wasn't widely reported.


+1

We can also easily narrow the time window where duplicate can be 
generated by just reordering the previous code.


CJ

Re: release?

[Christophe JAILLET]

Le 30/08/2021 à 13:53, Eric Covener a écrit :

On Mon, Aug 30, 2021 at 7:36 AM ste...@eissing.org  wrote:

In what state is our release handling? Given someone holding my hand, could I 
do it? Or is it better to look someone over the shoulder while he does it?

If there is an over-the-shoulder session I would like to tag along.  I
am flexible on time of day but I am GMT+4 (EDT).  I can host on webex.
Otherwise if you just want to struggle through it I can tag along but
I have no experience.


I can give another try with my limited experience.

I definitively would like to add a --dry-run option for all scripts so 
that they can be run for learning purpose without the fear of 
un-expected impact on svn.


Existing scripts are not that easy to read at first, but are 
understanbdable and following 
http://httpd.apache.org/dev/release.html#how-to-do-a-release helps a 
lot. The scripts should also be tweaked because of the latest changes in 
several places (at least web site update (now on github) and CVE 
announcement (if any) now that part of the process is handled elsewhere).


The CVE announcement should be much easier, now that we have a "Send 
these Emails" on cveprocess.a.o. This should simplify part of the 
process where we were preparing some scripts to send the announcement 
emails.


I've been lacking time for httpd since many weeks, but I should be able 
to RM next week if needed.


CJ


Also: Anyone who has a showstopper to delay a release (even if not yet
proposed) please add it to 2.4.x STATUS so we can get things in order.

Re: svn commit: r1892038 - /httpd/httpd/trunk/server/util.c

[Christophe JAILLET]

Le 08/08/2021 à 23:28, Eric Covener a écrit :

I finally got unlazy and got a local build w/ the UBISAN checking and
your patch works!

env CC=clang LD=clang CFLAGS=-fsanitize=undefined ./config.nice

Can you commit to trunk?


Now tested on my side as well and pushed as r1892185.

CJ





On Sun, Aug 8, 2021 at 5:03 PM Christophe JAILLET
 wrote:


Hi,

attached, my proposal. (compile tested only, but you'll get the idea)
It applies on top of current trunk (so after 1892038,1892063).

I'm not sure that the "(check > APR_INT64_MAX || check < tout)" check in
your patches is enough to catch overflows.

CJ

Re: svn commit: r1892038 - /httpd/httpd/trunk/server/util.c

[Christophe JAILLET]

Hi,

attached, my proposal. (compile tested only, but you'll get the idea)
It applies on top of current trunk (so after 1892038,1892063).

I'm not sure that the "(check > APR_INT64_MAX || check < tout)" check in 
your patches is enough to catch overflows.


CJ

Le 07/08/2021 à 20:33, Eric Covener a écrit :

Maybe making the constants unsigned?

On Sat, Aug 7, 2021 at 2:14 PM Eric Covener  wrote:


Seems like the fuzzer got farther but is still failing


util.c:2713:26: runtime error: signed integer overflow:
 * 1000 cannot be represented in type 'long'
#0 0x4be247 in ap_timeout_parameter_parse /src/httpd/server/util.c:2713:26

 case 'M':
 switch (*(++time_str)) {
 /* Time is in milliseconds */
 case 's':
 case 'S':
 check = tout * 1000;
 break;



Does this require a cast?

On Sat, Aug 7, 2021 at 6:45 AM Eric Covener  wrote:


On Sat, Aug 7, 2021 at 3:00 AM Christophe JAILLET
 wrote:


Hi,

Le 06/08/2021 à 15:10, cove...@apache.org a écrit :

Author: covener
Date: Fri Aug  6 13:10:45 2021
New Revision: 1892038

URL: http://svn.apache.org/viewvc?rev=1892038=rev
Log:
fix int overflow in ap_timeout_parameter_parse

signed integer overflow in ap_timeout_parameter_parse under fuzzing

Modified:
  httpd/httpd/trunk/server/util.c

Modified: httpd/httpd/trunk/server/util.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/server/util.c?rev=1892038=1892037=1892038=diff
==
--- httpd/httpd/trunk/server/util.c (original)
+++ httpd/httpd/trunk/server/util.c Fri Aug  6 13:10:45 2021
@@ -2676,6 +2676,7 @@ AP_DECLARE(apr_status_t) ap_timeout_para
   char *endp;
   const char *time_str;
   apr_int64_t tout;
+apr_uint64_t check;

   tout = apr_strtoi64(timeout_parameter, , 10);
   if (errno) {
@@ -2688,16 +2689,20 @@ AP_DECLARE(apr_status_t) ap_timeout_para
   time_str = endp;
   }

+if (tout < 0) {
+return APR_ERANGE;
+}
+
   switch (*time_str) {
   /* Time is in seconds */
   case 's':
   case 'S':
-*timeout = (apr_interval_time_t) apr_time_from_sec(tout);
+check = apr_time_from_sec(tout);
   break;
   case 'h':
   case 'H':
   /* Time is in hours */
-*timeout = (apr_interval_time_t) apr_time_from_sec(tout * 3600);
+check = apr_time_from_sec(tout * 3600);
   break;
   case 'm':
   case 'M':
@@ -2705,12 +2710,12 @@ AP_DECLARE(apr_status_t) ap_timeout_para
   /* Time is in milliseconds */
   case 's':
   case 'S':
-*timeout = (apr_interval_time_t) tout * 1000;
+check = tout * 1000;
   break;
   /* Time is in minutes */
   case 'i':
   case 'I':
-*timeout = (apr_interval_time_t) apr_time_from_sec(tout * 60);
+check = apr_time_from_sec(tout * 60);
   break;
   default:
   return APR_EGENERAL;
@@ -2719,6 +2724,10 @@ AP_DECLARE(apr_status_t) ap_timeout_para
   default:
   return APR_EGENERAL;
   }
+if (check > APR_INT64_MAX || check < 0) {


why "|| check < 0"?
'check' is unsigned (i.e. apr_uint64_t).



ty, changed in 1892063.




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






Index: server/util.c
===
--- server/util.c	(révision 1892087)
+++ server/util.c	(copie de travail)
@@ -2668,6 +2669,7 @@ AP_DECLARE(char *) ap_append_pid(apr_pool_t *p, co
  * in timeout_parameter.
  * @return Status value indicating whether the parsing was successful or not.
  */
+#define CHECK_OVERFLOW(a, b) if (a > b) return APR_ERANGE
 AP_DECLARE(apr_status_t) ap_timeout_parameter_parse(
const char *timeout_parameter,
apr_interval_time_t *timeout,
@@ -2697,11 +2699,13 @@ AP_DECLARE(apr_status_t) ap_timeout_parameter_pars
 /* Time is in seconds */
 case 's':
 case 'S':
+CHECK_OVERFLOW(tout, apr_time_sec(APR_INT64_MAX));
 check = apr_time_from_sec(tout);
 break;
+/* Time is in hours */
 case 'h':
 case 'H':
-/* Time is in hours */
+CHECK_OVERFLOW(tout, apr_time_sec(APR_INT64_MAX / 3600));
 check = apr_time_from_sec(tout * 3600);
 break;
 case 'm':
@@ -2710,11 +2714,13 @@ AP_DECLARE(apr_status_t) ap_timeout_parameter_pars
 /* Time is in milliseconds */
 case 's':
 case 'S':
-check = tout * 1000;
+CHECK_OVERFLOW(tout, apr_time_as_msec(APR_INT64_MAX));
+check = apr_time_from_msec(tout);
 break;
 /* Time is in minutes */
 case 'i':
 case 'I':
+CHECK_OVERFLOW(tout, apr_time_sec(APR_INT64_MAX / 60));
   

Re: svn commit: r1892038 - /httpd/httpd/trunk/server/util.c

[Christophe JAILLET]

Hi,

Le 06/08/2021 à 15:10, cove...@apache.org a écrit :

Author: covener
Date: Fri Aug  6 13:10:45 2021
New Revision: 1892038

URL: http://svn.apache.org/viewvc?rev=1892038=rev
Log:
fix int overflow in ap_timeout_parameter_parse

signed integer overflow in ap_timeout_parameter_parse under fuzzing

Modified:
 httpd/httpd/trunk/server/util.c

Modified: httpd/httpd/trunk/server/util.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/server/util.c?rev=1892038=1892037=1892038=diff
==
--- httpd/httpd/trunk/server/util.c (original)
+++ httpd/httpd/trunk/server/util.c Fri Aug  6 13:10:45 2021
@@ -2676,6 +2676,7 @@ AP_DECLARE(apr_status_t) ap_timeout_para
  char *endp;
  const char *time_str;
  apr_int64_t tout;
+apr_uint64_t check;
  
  tout = apr_strtoi64(timeout_parameter, , 10);

  if (errno) {
@@ -2688,16 +2689,20 @@ AP_DECLARE(apr_status_t) ap_timeout_para
  time_str = endp;
  }
  
+if (tout < 0) {

+return APR_ERANGE;
+}
+
  switch (*time_str) {
  /* Time is in seconds */
  case 's':
  case 'S':
-*timeout = (apr_interval_time_t) apr_time_from_sec(tout);
+check = apr_time_from_sec(tout);
  break;
  case 'h':
  case 'H':
  /* Time is in hours */
-*timeout = (apr_interval_time_t) apr_time_from_sec(tout * 3600);
+check = apr_time_from_sec(tout * 3600);
  break;
  case 'm':
  case 'M':
@@ -2705,12 +2710,12 @@ AP_DECLARE(apr_status_t) ap_timeout_para
  /* Time is in milliseconds */
  case 's':
  case 'S':
-*timeout = (apr_interval_time_t) tout * 1000;
+check = tout * 1000;
  break;
  /* Time is in minutes */
  case 'i':
  case 'I':
-*timeout = (apr_interval_time_t) apr_time_from_sec(tout * 60);
+check = apr_time_from_sec(tout * 60);
  break;
  default:
  return APR_EGENERAL;
@@ -2719,6 +2724,10 @@ AP_DECLARE(apr_status_t) ap_timeout_para
  default:
  return APR_EGENERAL;
  }
+if (check > APR_INT64_MAX || check < 0) {


why "|| check < 0"?
'check' is unsigned (i.e. apr_uint64_t).

If paranoiac, and want to prevent overflow or wrap around after the 
multiplication, I think that we should compute the maximum acceptable 
value pour each case ('s', 'h', ...) and test against it.


CJ

+return APR_ERANGE;
+}
+*timeout = (apr_interval_time_t) check;
  return APR_SUCCESS;
  }
  

Re: migration of the HTTPD project website

[Christophe JAILLET]

Le 02/07/2021 à 18:57, Dave Fisher a écrit :




On Jul 1, 2021, at 11:40 PM, Ruediger Pluem  wrote:



On 7/1/21 10:49 PM, Christophe JAILLET wrote:

Le 01/07/2021 à 18:37, Dave Fisher a écrit :

I see that there is already a PR to fix the modules hyperlink. Should this be 
applied


 From my point of view, no.
But /modules/ needs some clean-up.


and the ASF Pelican version of httpd.apache.org be put into production in 24 
hours?


Still, from my point of view, +1.


+1


The migrated httpd-site is now in production. Enjoy!



Hi,
when a PULL request is generated, it is forwarded to @dev. Same when it 
is accepted.

This is just fine for me.

However, when one directly modify within apache/httpd-site on GitHub, 
apparently, no notification is sent.


I think that is would be useful to also have these changes sent 
somewhere so that others know that there is some activity (and 
potentially fix/improve things, should it be only typo)


Is it possible?
Do you share this point of view?

CJ


Regards,
Dave



Regards

Rüdiger

Re: svn commit: r1891477 - in /httpd/httpd/trunk: changes-entries/ap_proxy_sync_balancer.txt modules/proxy/proxy_util.c

[Christophe JAILLET]

Le 12/07/2021 à 12:32, yla...@apache.org a écrit :

Author: ylavic
Date: Mon Jul 12 10:32:21 2021
New Revision: 1891477

URL: http://svn.apache.org/viewvc?rev=1891477=rev
Log:
mod_proxy: Fix icomplete initialization of BalancerMember(s) from the manager.

Clear the workers created in ap_proxy_sync_balancer(), notably ->local_status
for below ap_proxy_initialize_worker() to initialize all the child structures
like ->cp and ->cp->reslist, avoiding a possible crash when the workers are
used at runtime.

Added:
 httpd/httpd/trunk/changes-entries/ap_proxy_sync_balancer.txt
Modified:
 httpd/httpd/trunk/modules/proxy/proxy_util.c

Added: httpd/httpd/trunk/changes-entries/ap_proxy_sync_balancer.txt
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/changes-entries/ap_proxy_sync_balancer.txt?rev=1891477=auto
==
--- httpd/httpd/trunk/changes-entries/ap_proxy_sync_balancer.txt (added)
+++ httpd/httpd/trunk/changes-entries/ap_proxy_sync_balancer.txt Mon Jul 12 
10:32:21 2021
@@ -0,0 +1,2 @@
+  *) mod_proxy: Fix icomplete initialization of BalancerMember(s) from the
+ balancer-manager, which can lead to a crash.  [Yann Ylavic]

Modified: httpd/httpd/trunk/modules/proxy/proxy_util.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/proxy/proxy_util.c?rev=1891477=1891476=1891477=diff
==
--- httpd/httpd/trunk/modules/proxy/proxy_util.c (original)
+++ httpd/httpd/trunk/modules/proxy/proxy_util.c Mon Jul 12 10:32:21 2021
@@ -3681,9 +3681,8 @@ PROXY_DECLARE(apr_status_t) ap_proxy_syn
  runtime = apr_array_push(b->workers);
  *runtime = apr_palloc(conf->pool, sizeof(proxy_worker));
  apr_global_mutex_unlock(proxy_mutex);
+memset(*runtime, 0, sizeof(proxy_worker));
  (*runtime)->hash = shm->hash;
-(*runtime)->context = NULL;
-(*runtime)->cp = NULL;
  (*runtime)->balancer = b;
  (*runtime)->s = shm;
  #if APR_HAS_THREADS



Hi,
just wondering if it is safe to array_push+palloc within a mutex and 
finalize the initialization of this memory outside the mutex?


If this is fine, maybe the palloc could be done outside the mutex too?
If not, maybe pcalloc instead of an explicit memset?


Also, the #if APR_HAS_THREADS block could be removed, tmutex will be 
NULL'ed by the memset.


just my 2c.

CJ

Re: migration of the HTTPD project website

[Christophe JAILLET]

Le 01/07/2021 à 18:37, Dave Fisher a écrit :
I see that there is already a PR to fix the modules hyperlink. Should this be applied 


From my point of view, no.
But /modules/ needs some clean-up.


and the ASF Pelican version of httpd.apache.org be put into production in 24 
hours?


Still, from my point of view, +1.

CJ



HTH,
Dave


On Jun 29, 2021, at 2:23 PM, Dave Fisher  wrote:

Hi -


On Jun 29, 2021, at 1:17 PM, Marion & Christophe JAILLET 
 wrote:

Hi Dave,

Thanks for having done it.

You did faster and better than what I had started.


Here are a few details spotted here and there:
   - The download page looks broken
 (https://httpd.staged.apache.org/download.cgi)


This is due to the staging environment not picking up the production pickup of 
cgi to mirror mapping into the download.html template.



   - some '&' have been turned into 
 (https://httpd.staged.apache.org/dev/debugging.htmll#gcore)


Fixed by switching from ``` fenced code to 



   - some extra spaces in a command (around the use of awk)
(https://httpd.staged.apache.org/dev/release.html#how-to-do-a-release)


Removed. BTW - this page and associated scripts need to be edited to reflect 
the website being git based.



   - a bold string left with **
 (https://httpd.staged.apache.org/dev/styleguide.html)


Good catch Github Flavored Markdown (GFM) does not like spaces for emphasis. If 
you want to do bold italic: it’s ‘**_word_**'



   - a link that is left as [foo](bar) instead of an hypertext link
 (at the very bottom of https://httpd.staged.apache.org/contributors/)


Also GFM does not do any markdown within HTML blocks. I switched from  to 
### heading.



Only the first point is an issue. It is maybe linked to the fact that it is in 
staging?


Yes.



I guess that all the other tiny things could be fixed easily but don't have 
time to look at it by myself in the coming days/weeks.


I don't know if you hand modified a few things, but several places looks better 
now (some spacing between paragraphs which are smaller now, some alignment, 
some missing spaces between words that have been fixed, some numbering that 
were broken and fixed now, some links that have been added for URL or mails). 
So, great work!


There were a few tweaks to obviously broken content. URLs and emails are 
automatically turned to hyperlinks by GFM.


Thanks a lot.


You’re welcome.

Dave



CJ



Le 25/06/2021 à 19:12, Dave Fisher a écrit :

The Migration from CMS to ASF-Pelican is staged!

https://httpd.staged.apache.org/ is ready.

https://github.com/apache/httpd-site/

See the README on GitHub for details.

All The Best,
Dave


On Jun 22, 2021, at 11:00 AM, Dave Fisher  wrote:




On Jun 21, 2021, at 6:26 AM, Eric Covener  wrote:

On Sun, Jun 20, 2021 at 3:25 PM Andrew Wetmore  wrote:

Hi, Eric:

Yes, committers can use either GitHub or Gitbox.

I am not sure what the "can you give a hint about the migration aspect" means. 
Maybe I was not clear. We have to move all projects off the Apache CMS and to some other 
technology, such as Pelican. Infra can help with that move to a Git repository. Sometime 
this summer the Apache CMS will stop functioning, which would mean you would have a hard 
time updating your website.

I was referring to  "...migration process available that could speed
things along." not the overall migration off the CMS.
Daniel referred to
https://cwiki.apache.org/confluence/display/INFRA/Git+-+.asf.yaml+features
but I didn't find any reference to "migration".

https://github.com/apache/httpd-site was created but it's empty.  I
was assuming we'd have some starting point based on the CMS-based site
content and whatever additional template/scaffolding is needed that
we'd be able to see w/o replacing our currently published site.
I don't want anyone to start from scratch if there's a better way to
get started.

I have the go ahead to do the migration for you. The goal is to create a staged 
site that will be nearly identical to your current site.

Expect more information this week.

All The Best,
Dave

Re: migration of the HTTPD project website

[Marion & Christophe JAILLET]

Hi Dave,

Thanks for having done it.

You did faster and better than what I had started.


Here are a few details spotted here and there:
   - The download page looks broken
 (https://httpd.staged.apache.org/download.cgi)

   - some '&' have been turned into 
 (https://httpd.staged.apache.org/dev/debugging.htmll#gcore)

   - some extra spaces in a command (around the use of awk)
(https://httpd.staged.apache.org/dev/release.html#how-to-do-a-release)

   - a bold string left with **
 (https://httpd.staged.apache.org/dev/styleguide.html)

   - a link that is left as [foo](bar) instead of an hypertext link
 (at the very bottom of https://httpd.staged.apache.org/contributors/)

Only the first point is an issue. It is maybe linked to the fact that it 
is in staging?


I guess that all the other tiny things could be fixed easily but don't 
have time to look at it by myself in the coming days/weeks.



I don't know if you hand modified a few things, but several places looks 
better now (some spacing between paragraphs which are smaller now, some 
alignment, some missing spaces between words that have been fixed, some 
numbering that were broken and fixed now, some links that have been 
added for URL or mails). So, great work!


Thanks a lot.

CJ



Le 25/06/2021 à 19:12, Dave Fisher a écrit :

The Migration from CMS to ASF-Pelican is staged!

https://httpd.staged.apache.org/ is ready.

https://github.com/apache/httpd-site/

See the README on GitHub for details.

All The Best,
Dave


On Jun 22, 2021, at 11:00 AM, Dave Fisher  wrote:




On Jun 21, 2021, at 6:26 AM, Eric Covener  wrote:

On Sun, Jun 20, 2021 at 3:25 PM Andrew Wetmore  wrote:

Hi, Eric:

Yes, committers can use either GitHub or Gitbox.

I am not sure what the "can you give a hint about the migration aspect" means. 
Maybe I was not clear. We have to move all projects off the Apache CMS and to some other 
technology, such as Pelican. Infra can help with that move to a Git repository. Sometime 
this summer the Apache CMS will stop functioning, which would mean you would have a hard 
time updating your website.

I was referring to  "...migration process available that could speed
things along." not the overall migration off the CMS.
Daniel referred to
https://cwiki.apache.org/confluence/display/INFRA/Git+-+.asf.yaml+features
but I didn't find any reference to "migration".

https://github.com/apache/httpd-site was created but it's empty.  I
was assuming we'd have some starting point based on the CMS-based site
content and whatever additional template/scaffolding is needed that
we'd be able to see w/o replacing our currently published site.
I don't want anyone to start from scratch if there's a better way to
get started.

I have the go ahead to do the migration for you. The goal is to create a staged 
site that will be nearly identical to your current site.

Expect more information this week.

All The Best,
Dave

Re: svn commit: r1890598 - in /httpd/site/trunk/content/security/json: CVE-2019-17567.json CVE-2020-13938.json CVE-2020-13950.json CVE-2020-35452.json CVE-2021-26690.json CVE-2021-26691.json CVE-2021-

[Christophe JAILLET]

Le 08/06/2021 à 13:42, m...@apache.org a écrit :

Author: mjc
Date: Tue Jun  8 11:42:36 2021
New Revision: 1890598

URL: http://svn.apache.org/viewvc?rev=1890598=rev
Log:
Fix the release date and version

Modified:
 httpd/site/trunk/content/security/json/CVE-2019-17567.json
 httpd/site/trunk/content/security/json/CVE-2020-13938.json
 httpd/site/trunk/content/security/json/CVE-2020-13950.json
 httpd/site/trunk/content/security/json/CVE-2020-35452.json
 httpd/site/trunk/content/security/json/CVE-2021-26690.json
 httpd/site/trunk/content/security/json/CVE-2021-26691.json
 httpd/site/trunk/content/security/json/CVE-2021-30641.json
 httpd/site/trunk/content/security/json/CVE-2021-31618.json

Modified: httpd/site/trunk/content/security/json/CVE-2019-17567.json
URL: 
http://svn.apache.org/viewvc/httpd/site/trunk/content/security/json/CVE-2019-17567.json?rev=1890598=1890597=1890598=diff
==
--- httpd/site/trunk/content/security/json/CVE-2019-17567.json (original)
+++ httpd/site/trunk/content/security/json/CVE-2019-17567.json Tue Jun  8 
11:42:36 2021
@@ -13,14 +13,14 @@
"value": "reported"
  },
  {
-  "time": "--",
+  "time": "2021-06-01",
"lang": "eng",
"value": "public"
  },
  {
-  "time": "--",
+  "time": "2021-06-01",
"lang": "eng",
-  "value": "2.4.47 released"
+  "value": "2.4.48 released"
  }
],
"CNA_private": {
@@ -30,7 +30,7 @@
  "ASSIGNER": "secur...@apache.org",
  "AKA": "",
  "STATE": "PUBLIC",
-"DATE_PUBLIC": "--",
+"DATE_PUBLIC": "2021-06-01",
  "ID": "CVE-2019-17567",
  "TITLE": "mod_proxy_wstunnel tunneling of non Upgraded connections"
},
@@ -210,4 +210,4 @@
]
  }
}
-}
\ No newline at end of file
+}




Not a big issue from my point of view, but now cvetool, CHANGES and 
CHANGES_2.48 are not in line anymore with vulnerabilities_xx.html


My own preference is for keeping 2.4.47 because it was really fixed in 
this version, even if not announced.


I guess that it is mostly a matter of taste and that both point of view 
are acceptable.


CJ

Re: vulnerabilities page vs change log

[Christophe JAILLET]

Le 04/06/2021 à 20:01, Christophe JAILLET a écrit :

Le 04/06/2021 à 09:45, Steffen Land a écrit :



Thanks Christophe for all the work,  nice process changes !

See a little one:

- at https://httpd.apache.org/security/vulnerabilities_24.html I see 
under 2.4.48 the CVE 13938 and in the change log  under 2.4.47


- in changelog I see under 2.4.48 the CVE 31618 and at the page under 
2.4.47


Steffen


Hi,

you are right Steffen.

Hopefully, the new tools dedicated to CVE management provided by 
apache.org will help us avoid these small copy/paste issues.


I also plan to add some checks in our internal tools to catch such cases.

In the above cases, CHANGES is right (vulnerabilities_24.html is wrong)
This will be fixed by tomorrow.

Thanks for reporting.

CJ



Hi,
This should be fixed now. If you spot anything else that looks spurious, 
do not hesitate to notify us.


CJ

Re: vulnerabilities page vs change log

[Christophe JAILLET]

Le 04/06/2021 à 09:45, Steffen Land a écrit :



Thanks Christophe for all the work,  nice process changes !

See a little one:

- at https://httpd.apache.org/security/vulnerabilities_24.html I see 
under 2.4.48 the CVE 13938 and in the change log  under 2.4.47


- in changelog I see under 2.4.48 the CVE 31618 and at the page under 
2.4.47


Steffen


Hi,

you are right Steffen.

Hopefully, the new tools dedicated to CVE management provided by 
apache.org will help us avoid these small copy/paste issues.


I also plan to add some checks in our internal tools to catch such cases.

In the above cases, CHANGES is right (vulnerabilities_24.html is wrong)
This will be fixed by tomorrow.

Thanks for reporting.

CJ

Re: svn commit: r1890412 - /httpd/site/trunk/content/security/cvejsontohtml.py

[Christophe JAILLET]

Le 03/06/2021 à 08:31, jaillet...@apache.org a écrit :

Author: jailletc36
Date: Thu Jun  3 06:31:44 2021
New Revision: 1890412

URL: http://svn.apache.org/viewvc?rev=1890412=rev
Log:
Use natural order sorting, so that 2.4.9 is after 2.4.10

(trick found on 
https://stackoverflow.com/questions/4836710/is-there-a-built-in-function-for-string-natural-sort)

Modified:
 httpd/site/trunk/content/security/cvejsontohtml.py

Modified: httpd/site/trunk/content/security/cvejsontohtml.py
URL: 
http://svn.apache.org/viewvc/httpd/site/trunk/content/security/cvejsontohtml.py?rev=1890412=1890411=1890412=diff
==
--- httpd/site/trunk/content/security/cvejsontohtml.py (original)
+++ httpd/site/trunk/content/security/cvejsontohtml.py Thu Jun  3 06:31:44 2021
@@ -66,7 +66,8 @@ for k,v in sorted(entries.items(), key=l
  else:
  # Otherwise maybe we started doing things like "<2.7.8"
  affects.append(ver["version_affected"]+ver["version_value"])
-affects.sort(reverse=True)
+# Make a natural order sort (i.e. revrite version like 0002.4.8 and 
002.4.38)
+affects.sort(reverse=True, key=lambda x: '{0:0>8}'.format(x).lower())
  e['affects'] = ", ".join(affects)
  e['timetable'] = [];
  for time in cve["timeline"]:


This works better, IMHO, but is still not perfect.

For example 2.0.30 is now before 2.2.0 (which was not the case previously)
Googling gives some other solution, either with 3rd party module or hand 
writing a natural sort.


I'll leave it to anyone else better than me in python :)

So feel free to revert or improve.

CJ

Re: [RESULT - PASS] Release httpd-2.4.48

[Christophe JAILLET]

Le 01/06/2021 à 03:07, William A Rowe Jr a écrit :

Christophe, thanks for your energetic efforts to kick off the next release!

I looked for the post but couldn't find it, the community is confused. 
Is this release pulled for regressions? It hasn't been communicated 
well, but the release is sitting on every mirror, since 6 to 24 hours 
after you placed it on dist.


Inquiring minds would like to know, you seem to confirm this release in 
this specific post, so it appears that it has happened, even if adopting 
it is unwise.




Hi,

2.4.48 is live now.

However, the mails sent on annouce@a.o and annouce@httpd.a.o seem to not 
have reached their destination yet.

Maybe a moderation issue on the lists.

As you can see, there is also some security related fixes. There are 
listed at [1].


I still need to figure out a few things with our new CVE management 
mechanism. So our vulnerability listing ([2]) with some more details is 
not updated yet. I hope to be able to update it in the coming days.


Most CVE fixed in this release are rated from moderate to low impact. 
Only one, CVE-2021-31618 is rated as important and could be exploited 
for some DoS.


Christophe JAILLET


[1]: https://downloads.apache.org/httpd/CHANGES_2.4.48
[2]: https://httpd.apache.org/security/vulnerabilities_24.html

Re: svn commit: r1890245 - in /httpd/httpd/branches/2.4.x: ./ docs/manual/mod/ include/ modules/http2/ server/

[Christophe JAILLET]

Hi,

Nitpicking

CJ

Le 27/05/2021 à 15:08, ic...@apache.org a écrit :

Author: icing
Date: Thu May 27 13:08:21 2021
New Revision: 1890245

URL: http://svn.apache.org/viewvc?rev=1890245=rev
Log:
Merged 
r1734009,r1734231,r1734281,r1838055,r1838079,r1840229,r1876664,r1876674,r1876784,r1879078,r1881620,r1887311,r171
 from trunk:

   *) core: Split ap_create_request() from ap_read_request(). [Graham Leggett]

   *) core, h2: common ap_parse_request_line() and ap_check_request_header()
  code. [Yann Ylavic]

   *) core: Add StrictHostCheck to allow unconfigured hostnames to be
  rejected. [Eric Covener]

[...]

Modified: httpd/httpd/branches/2.4.x/docs/manual/mod/core.xml
URL: 
http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/docs/manual/mod/core.xml?rev=1890245=1890244=1890245=diff
==
--- httpd/httpd/branches/2.4.x/docs/manual/mod/core.xml (original)
+++ httpd/httpd/branches/2.4.x/docs/manual/mod/core.xml Thu May 27 13:08:21 2021
@@ -5207,6 +5207,42 @@ recognized methods to modules.
  
  
  

+StrictHostCheck
+Controls whether the server requires the requested hostname be
+ listed enumerated in the virtual host handling the request
+ 
+StrictHostCheck ON|OFF
+StrictHostCheck OFF
+server configvirtual host
+
+Added in 2.5.1


2.4.49


[...]

Modified: httpd/httpd/branches/2.4.x/include/ap_mmn.h
URL: 
http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/include/ap_mmn.h?rev=1890245=1890244=1890245=diff
==
--- httpd/httpd/branches/2.4.x/include/ap_mmn.h (original)
+++ httpd/httpd/branches/2.4.x/include/ap_mmn.h Thu May 27 13:08:21 2021
@@ -559,6 +559,9 @@
   *   and ap_ssl_answer_challenge and hooks.
   * 20120211.104 (2.4.47-dev) Move ap_ssl_* into new http_ssl.h header file
   * 20120211.105 (2.4.47-dev) Add ap_ssl_ocsp* hooks and functions to 
http_ssl.h.
+ * 20120211.106 (2.4.47-dev) Add ap_create_request().
+ * 20120211.107 (2.4.47-dev) Add ap_parse_request_line() and
+ *   ap_check_request_header()
   */
  


2.4.49-dev

Re: page https://httpd.apache.org/download.cgi says Stable Release - Latest Version:,, 2.4.46 (released 2020-08-07)

[Christophe JAILLET]

Le 26/05/2021 à 16:41, Dennis Clarke a écrit :


Seen at https://httpd.apache.org/download.cgi

 Stable Release - Latest Version:

 2.4.46 (released 2020-08-07)


I just followed the url link at :

 https://dist.apache.org/repos/dist/dev/httpd/Announcement2.4.html


Hi,

Did you reach the URL from httpd.a.o?

If yes, can you tell from where because we shouldn't point to 'dev'. I 
guess that 'release' would be expected.
Anyway, see below, there is a known small time window where things can 
look odd.

Then this https://httpd.apache.org/ seems similar, yet slightly
different.

I am guessing that all of this is in flow and changing now.



Right.

The 2.4.48 has been put in the dist/release directory yesterday morning.
Our release/announcement process ask for a 1 or 2 days delay so that 
mirrors have time to replicate (see step 16 at [1]).


So, all this will be sorted out when the official announcement will be made.

Also, to answer another remark I got in private, the date at the top of 
Announcement2.4.html for 2.4.48 will be updated automatically by our 
announcement script. (see line 248 of [2])


So yes, there is a small time window where things may look strange and 
one could wonder what it really up to date. I'll have a look to see if 
we can easily avoid it.


CJ

[1]: https://httpd.apache.org/dev/release.html#how-to-do-a-release
[2]: http://svn.apache.org/repos/asf/httpd/site/trunk/tools/announce.sh

[RESULT - PASS] Release httpd-2.4.48

[Christophe JAILLET]

Hi all,

With 8 binding PMC +1 votes, 5 additional +1 votes from the community, 
and no -1 votes, I'm pleased to report that the vote has PASSED to 
release 2.4.48.


The process of pushing to the distribution mirrors is one the way. I 
should make the announcement in the coming days.




Here are the votes I have recorded during the thread:
(apologies if I missed someone)
PMC:
dferradal, jfclere, gbechis, jailletc36, jorton, rjung, steffenal,
ylavic

Community and committers:
Noel Butler, Jan Ehrhardt, Cory McIntire, William A Rowe Jr (wrowe),
Ivan Zhakov (ivan)


The systems that have been tested on include:
CentOS 6, 7, 8
Debian
Fedora 34
RHEL 6, 7, 8
Slackware 14.0, 14.2 and 15 beta
SLES 11, 12, 15
Solaris 10   (Sparc)
Ubuntu 21.04
Windows   (x86 and x64)


Thanks to all of you for your time and cycles for testing on all these 
different platforms and configurations.


Christophe JAILLET

Re: [VOTE] Release httpd-2.4.48

[Christophe JAILLET]

Le 17/05/2021 à 23:36, Christophe JAILLET a écrit :

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

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

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

The computed digests of the tarball up for vote are:
sha1: b581bcfdd939fe77c3821f7ad3863c7307374919 *httpd-2.4.48.tar.gz
sha256: 315c0bc50206b866fb17c2cdc28c1973765a8d59ca168b80286e8cb077d0510e 
*httpd-2.4.48.tar.gz
sha512: 
91980f757fc0dede8c6cbf54ed973f82a63098aa50d0fce15fe3537687b4ffbb48ed50cdb4ae14eb4a8703450f032daf73f4f3d5e2dd0f75721948e12a9c6dfb 
*httpd-2.4.48.tar.gz


The SVN tag is '2.4.48' at r1889975.



My +1 as well,

CJ

Re: [VOTE] Release httpd-2.4.48

[Christophe JAILLET]

Le 18/05/2021 à 14:57, Giovanni Bechis a écrit :

On 5/18/21 1:53 PM, Joe Orton wrote:

On Tue, May 18, 2021 at 01:30:25PM +0200, Ruediger Pluem wrote:



On 5/18/21 11:52 AM, Giovanni Bechis wrote:

On 5/17/21 11:36 PM, Christophe JAILLET wrote:

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

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

The computed digests of the tarball up for vote are:
sha1: b581bcfdd939fe77c3821f7ad3863c7307374919 *httpd-2.4.48.tar.gz
sha256: 315c0bc50206b866fb17c2cdc28c1973765a8d59ca168b80286e8cb077d0510e 
*httpd-2.4.48.tar.gz
sha512: 
91980f757fc0dede8c6cbf54ed973f82a63098aa50d0fce15fe3537687b4ffbb48ed50cdb4ae14eb4a8703450f032daf73f4f3d5e2dd0f75721948e12a9c6dfb
 *httpd-2.4.48.tar.gz

The SVN tag is '2.4.48' at r1889975.


-1 for me.
new mod_md doesn't build with LibreSSL because nor EVP_PKEY_X25519 nor 
EVP_PKEY_X448 are defined.
I have asked LibreSSL guys if they will add EVP_PKEY_* constants to evp.h.


Hi Giovanni,

From my point of view, we do not *officially* support LibreSSL. The 
mod_ssl doc is only about OpenSSL. I've found no reference to it, apart 
from the many LIBRESSL_VERSION_NUMBER in the code itself.
So, even if the LibreSSL built was completely broken, I wouldn't 
consider it as a showstoper.


If we consider that Linking against LibreSSL is a must have, then, at 
least we should update the doc.




Did 2.4.46 build with LibreSSL?



2.4.46 and 2.4.47 builds.
 >> Looks like this is new in 2.4.48 but both LibreSSL users can work around

this or not build mod_md, it doesn't seem like a showstopper.


no real showstopper for me, please remove my "-1" vote.



Let us know if you want to change your vote to something else (see [1]) 
or if you just don't vote for this release.


  

Giovanni, if you care about keeping Libre support alive can you work out
how to get it building in Travis?  It's daft if we are only hitting
these compat issues in post-roll testing.


I agree and I will take a look at it.


Just great :)
Thx.

And then, updating the doc would worth it ;-)

CJ

[1]: 
https://apache.org/foundation/voting.html#expressing-votes-1-0-1-and-fractions

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

[Christophe JAILLET]

Le 18/05/2021 à 09:59, Ruediger Pluem a écrit :



On 5/17/21 11:39 PM, jaillet...@apache.org wrote:

Author: jailletc36
Date: Mon May 17 21:39:50 2021
New Revision: 1889978

URL: http://svn.apache.org/viewvc?rev=1889978=rev
Log:
Fix French vs English date format.

Modified:
 httpd/httpd/branches/2.4.x/STATUS

Modified: httpd/httpd/branches/2.4.x/STATUS
URL: 
http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?rev=1889978=1889977=1889978=diff
==
--- httpd/httpd/branches/2.4.x/STATUS (original)
+++ httpd/httpd/branches/2.4.x/STATUS Mon May 17 21:39:50 2021
@@ -30,7 +30,7 @@ Release history:
while x.{even}.z versions are Stable/GA releases.]
  
  2.4.49  : In development

-2.4.48  : Tagged on mai 17, 2021
+2.4.48  : Tagged on May 17, 2021


Should we put an

export LANG=C
or
export LANG=en_US.UTF-8

at the beginning of announce.sh / tag.sh to avoid this?

Regards

Rüdiger




I'll give it a try, but it is likely the way to go.

There is also a similar issue about the revision given at the end of the 
[VOTE] mail. It parses the output of 'svn info' and doesn't work well 
when the output is in French.


CJ

[VOTE] Release httpd-2.4.48

[Christophe JAILLET]

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

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

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

The computed digests of the tarball up for vote are:
sha1: b581bcfdd939fe77c3821f7ad3863c7307374919 *httpd-2.4.48.tar.gz
sha256: 315c0bc50206b866fb17c2cdc28c1973765a8d59ca168b80286e8cb077d0510e 
*httpd-2.4.48.tar.gz
sha512: 
91980f757fc0dede8c6cbf54ed973f82a63098aa50d0fce15fe3537687b4ffbb48ed50cdb4ae14eb4a8703450f032daf73f4f3d5e2dd0f75721948e12a9c6dfb 
*httpd-2.4.48.tar.gz


The SVN tag is '2.4.48' at r1889975.

--
Christophe JAILLET

Re: NOTICE: Intent to T on Sunday May 16, 2021

[Marion & Christophe JAILLET]

Hi all,

the issues that have shown up just before the announcement of 2.4.48 
seem to be gone now.


So I'll T a new 2.4.48 for testing later today.

CJ

Le 03/05/2021 à 21:29, Christophe JAILLET a écrit :

Hi all,

as you probably have noticed, the 2.4.47 has been distributed on mirrors 
but not announced, neither on your favorite ML, nor on the official 
httpd.apache.org website.


The reason is a very last minute regression discovered a few hours 
before the announcement.


So, as the 2.4.32 release in March 2018, this 2.4.47 release will never 
be officially announced.



In the hope of this issue being solved in the meantime, I plan a new T 
on Sunday May 16, 2021, forecasting for a 2.4.48 release on Sunday May 
23 or Monday May 24.



Best regards,
Christophe JAILLET

Re: CHANGES and change entries

[Christophe JAILLET]

Le 10/05/2021 à 10:32, Ruediger Pluem a écrit :



On 5/10/21 10:06 AM, Stefan Eissing wrote:

Team, me is confused about the status of CHANGES and changes-entries. Could we 
clarify for everyone how things are supposed to work now?

There was some back and forth in the past, the README.CHANGES says both are 
valid and on backport proposals people seem to prefer the entries (which I 
agree with).

Just a clear "this is how we do this from now on" from our chair would be 
appreciated. Thanks!


I think we should find a consensus here as a group. I proposed the 
changes-entries setup and I think that it has benefits. But I
wanted to give people time to get used to it and wanted to be sure that the 
setup does not contain bugs I haven't caught or
thought of. In addition I as an individual of this group cannot tell people how 
they should do things. I can only propose
approaches and hopefully the majority finds them beneficial and we as a whole 
decide to use them.

My personal opinion is +1 to use the change-entries approach.



+1 as well for me.


Regards

Rüdiger

Re: htcacheclean.c error when compiling with apr-1.6.x and apr-1.7.x

[Christophe JAILLET]

Le 04/05/2021 à 08:59, jean-frederic clere a écrit :

Hi,

I have the following:
+++
/home/jfclere/APR-1.7.x/build-1/libtool --silent --mode=compile gcc  -g 
-O2 -pthread -std=c89 -Werror -Wall -Wstrict-prototypes 
-Wmissing-prototypes -Wmissing-declarations 
-Wdeclaration-after-statement -Wpointer-arith -Wformat -Wformat-security 
-Wunused -DLINUX -D_REENTRANT -D_GNU_SOURCE -DAP_DEBUG    -I. 
-I/home/jfclere/httpd-trunk/os/unix -I/home/jfclere/httpd-trunk/include 
-I/home/jfclere/APR-1.7.x/include/apr-1 
-I/home/jfclere/APU-1.6.x/include/apr-1 
-I/home/jfclere/httpd-trunk/modules/aaa 
-I/home/jfclere/httpd-trunk/modules/cache 
-I/home/jfclere/httpd-trunk/modules/core 
-I/home/jfclere/httpd-trunk/modules/database 
-I/home/jfclere/httpd-trunk/modules/filters 
-I/home/jfclere/httpd-trunk/modules/ldap 
-I/home/jfclere/httpd-trunk/modules/loggers 
-I/home/jfclere/httpd-trunk/modules/lua 
-I/home/jfclere/httpd-trunk/modules/proxy 
-I/home/jfclere/httpd-trunk/modules/http2 
-I/home/jfclere/httpd-trunk/modules/session 
-I/home/jfclere/httpd-trunk/modules/ssl 
-I/home/jfclere/httpd-trunk/modules/test 
-I/home/jfclere/httpd-trunk/server 
-I/home/jfclere/httpd-trunk/modules/md 
-I/home/jfclere/httpd-trunk/modules/arch/unix 
-I/home/jfclere/httpd-trunk/modules/dav/main 
-I/home/jfclere/httpd-trunk/modules/generators 
-I/home/jfclere/httpd-trunk/modules/mappers  -prefer-non-pic -static -c 
htcacheclean.c -o htcacheclean.lo

In file included from htcacheclean.c:36:
htcacheclean.c: In function ‘process_dir’:
/home/jfclere/APR-1.7.x/include/apr-1/apr_ring.h:183:37: error: array 
subscript ‘struct _direntry[0]’ is partly outside array bounds of 
‘struct [1]’ [-Werror=array-bounds]

  183 | #define APR_RING_PREV(ep, link) (ep)->link.prev
  | ^~
/home/jfclere/APR-1.7.x/include/apr-1/apr_ring.h:230:38: note: in 
expansion of macro ‘APR_RING_PREV’
  230 | APR_RING_PREV((ep1), link) = APR_RING_PREV((lep), 
link);    \

  |
+++

Before looking more closely to the problem I have a question, trunk 
should be building with apr 1.7.x and apr-util 1.6.x correct?




Yes and it is tested on travis:
Latest build: https://travis-ci.com/github/apache/httpd/builds/224657764

(search for 1.7.0 or 1.7.x)

CJ

I used to build with apr 1.6.x and apr-util 1.6.x but something looks 
broken now.

NOTICE: Intent to T on Sunday May 16, 2021

[Christophe JAILLET]

Hi all,

as you probably have noticed, the 2.4.47 has been distributed on mirrors 
but not announced, neither on your favorite ML, nor on the official 
httpd.apache.org website.


The reason is a very last minute regression discovered a few hours 
before the announcement.


So, as the 2.4.32 release in March 2018, this 2.4.47 release will never 
be officially announced.



In the hope of this issue being solved in the meantime, I plan a new T 
on Sunday May 16, 2021, forecasting for a 2.4.48 release on Sunday May 
23 or Monday May 24.



Best regards,
Christophe JAILLET

Re: [RESULT - PASS - aborted] Release httpd-2.4.47

[Christophe JAILLET]

Le 28/04/2021 à 15:22, Christophe JAILLET a écrit :

Hi all,

With 8 binding PMC +1 votes, 3 additional +1 votes from the community, 
and no -1 votes, I'm pleased to report that the vote has PASSED to 
release 2.4.47.


I will begin the process of pushing to the distribution mirrors which 
should enable us for an announcement in the coming days.




Here are the votes I have recorded during the thread:
(apologies if I missed someone)
PMC:
 covener, dferradal, jailletc36, jblond, jorton, rjung,
 steffenal, ylavic

Community an commiters:
 Giovanni Bechis, Noel Butler, Jan Ehrhardt

The systems that have been tested on include:
 AIX/xlc   (PPC64)
 CentOS 7.9
 Debian 9, 10, 11
 Fedora 33
 OpenBSD 6.9
 RHEL 6, 7, 8
 Slackware 14.0, 14.2 and 15 beta
 SLES 11, 12, 15
 Solaris 10   (Sparc)
 Ubuntu 21.04
 Windows   (x86 and x64)


Thanks to all of you for your time and cycles for testing on all these 
different platforms and configurations.


Christophe JAILLET



Hi all,

as you probably have noticed, the 2.4.47 has been distributed on mirrors 
but not announced, neither on your favorite ML, nor on the official 
httpd.apache.org website.


The reason is a very last minute regression discovered a few hours 
before the announcement.


So, as the 2.4.32 release in March 2018, this 2.4.47 release will never 
be officially announced.


A fix for the regression has already been proposed on trunk (r1889341). 
It should be reviewed and tested and, if agreed, backported to 2.4.x.


So, I propose to give a little time for all this to occur and I already 
plan a new T on Sunday May 16, 2021, hoping for a successful release 
on Sunday May 23 or Monday May 24.


Best regards,
Christophe JAILLET

[RESULT - PASS] Release httpd-2.4.47

[Christophe JAILLET]

Hi all,

With 8 binding PMC +1 votes, 3 additional +1 votes from the community, 
and no -1 votes, I'm pleased to report that the vote has PASSED to 
release 2.4.47.


I will begin the process of pushing to the distribution mirrors which 
should enable us for an announcement in the coming days.




Here are the votes I have recorded during the thread:
(apologies if I missed someone)
PMC:
covener, dferradal, jailletc36, jblond, jorton, rjung,
steffenal, ylavic

Community an commiters:
Giovanni Bechis, Noel Butler, Jan Ehrhardt

The systems that have been tested on include:
AIX/xlc   (PPC64)
CentOS 7.9
Debian 9, 10, 11
Fedora 33
OpenBSD 6.9
RHEL 6, 7, 8
Slackware 14.0, 14.2 and 15 beta
SLES 11, 12, 15
Solaris 10   (Sparc)
Ubuntu 21.04
Windows   (x86 and x64)


Thanks to all of you for your time and cycles for testing on all these 
different platforms and configurations.


Christophe JAILLET

Re: [VOTE] Release httpd-2.4.47

[Christophe JAILLET]

Le 22/04/2021 à 11:25, Christophe JAILLET a écrit :

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

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

[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 for me as well.

Tested on Ubuntu 21.04
gcc 11.0.1
maintainer-mode
APR latest 1.7.x branch (i.e 1.7.0+)
APR-UTIL latest 1.6.x branch (i.e 1.6.1+)
Tested with event, prefork, worker

Nothing special.

Test coverage data is more or less the same as for 2.4.44. A few modules 
have a slightly better coverage (mod_lua, mod_proxy_wstunnel) which 
looks logical according to change history in the test framework.


Detailed gcov data available on demand if anyone is interested.


CJ

[VOTE] Release httpd-2.4.47

[Christophe JAILLET]

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

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

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

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


The SVN tag is '2.4.47' at r1889091.

--
Christophe JAILLET

Re: svn commit: r1885605 - in /httpd/httpd/branches/2.4.x: ./ include/ modules/proxy/

[Christophe JAILLET]

Le 18/04/2021 à 19:45, Eric Covener a écrit :

The last hunk of r1877558 seems to be missing in this backport.

@@ -2180,6 +2165,9 @@ static int proxy_http_handler(request_re

   /* Step Five: Receive the Response... Fall thru to cleanup */
   status = ap_proxy_http_process_response(req);
+if (req->backend) {
+proxy_run_detach_backend(r, req->backend);
+}

   break;
   }

I guess that it is not intentional and should go to 2.4.x as well.
Anyone to confirm my supposition?


The hook does not exist in 2.4.x so I think it's OK.
The only reference to it is guarded with an MMN check to keep proxy_h2 common.



+1.
Thanks for the clarification. (and sorry for the noise)

CJ

Re: svn commit: r1885605 - in /httpd/httpd/branches/2.4.x: ./ include/ modules/proxy/

[Christophe JAILLET]

Le 03/02/2021 à 09:24, Ruediger Pluem a écrit :



On 2/2/21 4:18 PM, Yann Ylavic wrote:

On Tue, Feb 2, 2021 at 10:32 AM Ruediger Pluem  wrote:



New Revision: 1885605

URL: http://svn.apache.org/viewvc?rev=1885605=rev

[]

+/* Yield if the output filters stack is full? This is to avoid
+ * blocking and give the caller a chance to POLLOUT async.
+ */
+if (flags & AP_PROXY_TRANSFER_YIELD_PENDING) {
+int rc = OK;
+
+if (!ap_filter_should_yield(c_o->output_filters)) {
+rc = ap_filter_output_pending(c_o);


I am confused here: !ap_filter_should_yield(c_o->output_filters) means there is 
no pending output.
Why should we try to send it then? Shouldn't it be the other way round?


Yes, !ap_filter_should_yield() means that there is no pending output,
but only for filters that play the
ap_filter_{setaside,reinstate}_brigade() game.

The goal here is to try to flush pending data of filters that don't
ap_filter_setaside_brigade(), like e.g. ssl_io_filter_coalesce() which


But isn't ap_filter_output_pending a noop that always returns DECLINED in case
of !ap_filter_should_yield(c_o->output_filters)?

Regards

Rüdiger



Same backport for which a just sent a question about a potential missing 
part of r1877558.



Unrelated, but is there still something to discuss here.
The last comment from Rüdiger seems to have been left un-answered.

CJ

Re: svn commit: r1885605 - in /httpd/httpd/branches/2.4.x: ./ include/ modules/proxy/

[Christophe JAILLET]

Le 17/01/2021 à 17:21, minf...@apache.org a écrit :

Author: minfrin
Date: Sun Jan 17 16:21:35 2021
New Revision: 1885605

URL: http://svn.apache.org/viewvc?rev=1885605=rev
Log:
Backport to v2.4:

   *) mod_proxy_http: handle upgrade/tunneling protocols. BZ 61616 is about
  mod_proxy_connect but there has been wstunnel reports
  on dev@ about that too lately.
  trunk patch: https://svn.apache.org/r1678771
   https://svn.apache.org/r1832348
   https://svn.apache.org/r1869338
   https://svn.apache.org/r1869420
   https://svn.apache.org/r1878367
   https://svn.apache.org/r1877557
   https://svn.apache.org/r1877558


Here


   https://svn.apache.org/r1877646
   https://svn.apache.org/r1877695
   https://svn.apache.org/r1879401
   https://svn.apache.org/r1879402
   https://svn.apache.org/r1880200
   https://svn.apache.org/r1885239
   https://svn.apache.org/r1885240
   https://svn.apache.org/r1885244
  2.4.x patch: 
http://people.apache.org/~ylavic/patches/2.4.x-mod_proxy_http-upgrade-4on5-v2.patch
   https://github.com/apache/httpd/pull/158
  +1: ylavic, covener, minfrin
  ylavic: All the corresponding trunk changes to mod_proxy_wstunnel (but
  r1885239) have been dropped for this backport proposal, the goal
  being to handle upgrade in mod_proxy_http from now, while r1885239
  allows to benefit from the Upgrade improvements done in proxy_http
  with existing wstunnel configurations (provided mod_proxy_http
  module is loaded).


Modified:
 httpd/httpd/branches/2.4.x/CHANGES
 httpd/httpd/branches/2.4.x/STATUS
 httpd/httpd/branches/2.4.x/include/ap_mmn.h
 httpd/httpd/branches/2.4.x/modules/proxy/mod_proxy.c
 httpd/httpd/branches/2.4.x/modules/proxy/mod_proxy.h
 httpd/httpd/branches/2.4.x/modules/proxy/mod_proxy_connect.c
 httpd/httpd/branches/2.4.x/modules/proxy/mod_proxy_http.c
 httpd/httpd/branches/2.4.x/modules/proxy/mod_proxy_wstunnel.c
 httpd/httpd/branches/2.4.x/modules/proxy/proxy_util.c



[...]

The last hunk of r1877558 seems to be missing in this backport.

@@ -2180,6 +2165,9 @@ static int proxy_http_handler(request_re

 /* Step Five: Receive the Response... Fall thru to cleanup */
 status = ap_proxy_http_process_response(req);
+if (req->backend) {
+proxy_run_detach_backend(r, req->backend);
+}

 break;
 }

I guess that it is not intentional and should go to 2.4.x as well.
Anyone to confirm my supposition?

CJ

NOTICE: Intent to T on next Wednesday

[Christophe JAILLET]

Hi dear Apache contributors and casual readers.

The latest httpd release was done about 8 months ago.
I think it is time to roll-out an new update.

CHANGES for 2.4.47 includes some interesting stuff, including 
performance improvements, fixes for unusual edge cases and new 
directives to tweak even more your settings.


This will also fixes a dozen of PR from our bugzilla.

I plan to T on Wednesday and let vote run through the weekend.

So until Wednesday, feel free to add all your last minute backport 
proposals (if they are not to big and scary :)), to give them a chance 
to be widely spread in the coming days.
Please also test and votes for backports for the proposals already 
waiting in STATUS.



This will be my first release as a RM.
I hope that everything will run smoothly :)


--
Christophe Jaillet

Re: [RESULT: PASS] Re: [VOTE] Release libapreq2-2.15

[Christophe JAILLET]

Le 08/03/2021 à 18:00, Ruediger Pluem a écrit :



On 3/8/21 5:40 PM, Steve Hay wrote:

On Tue, 23 Feb 2021 at 10:20, Joe Orton  wrote:


On Mon, Feb 22, 2021 at 03:57:25PM +, Steve Hay wrote:

On Fri, 13 Nov 2020 at 16:43, Joe Orton  wrote:


Thanks all for testing, the vote has passed:

PMC votes +1: ylavic, rpluem, covener
Community +1: stevehay

(Steve, looks like we need to get you on the httpd PMC!)

and no -1 votes.

I'll promote the release & prep the announcement mail.



I think these releases normally go to Perl's CPAN as well (it is item
12 in build/RELEASE), but I don't see 2.15 here:
https://metacpan.org/release/libapreq2

Do you have perms to upload there? If not then I don't mind trying to
see if I can do it. (I've done mod_perl releases before, so it might
work ;-))





The simplest way for us to fix this is to release a 2.16 with a
corrected META.yml. I've just committed rev. 1887336 to fix the
generation of the META.yml file for our next release.




I would be willing to vote again with a +1 if Joe is willing to roll 2.16 with 
just that change over 2.15.

Regards

Rüdiger




Hi,

should a new release be done quickly, BZ 56598 and maybe BZ 52370 should 
be looked at.


It looks like easy to check and test patches.
I've not svn'ed this repo so far, I won't be able to do so in the near 
future.



Just my 2c
CJ

Re: svn commit: r1885610 - in /httpd/httpd/branches/2.4.x: ./ modules/dav/main/ modules/md/ modules/proxy/ modules/session/ modules/ssl/ server/

[Marion & Christophe JAILLET]

Le 17/01/2021 à 18:07, minf...@apache.org a écrit :

Modified: httpd/httpd/branches/2.4.x/CHANGES
URL: 
http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/CHANGES?rev=1885610=1885609=1885610=diff
==
--- httpd/httpd/branches/2.4.x/CHANGES [utf-8] (original)
+++ httpd/httpd/branches/2.4.x/CHANGES [utf-8] Sun Jan 17 17:07:42 2021
@@ -1,6 +1,15 @@
   -*- coding: utf-8 -*-
  Changes with Apache 2.4.47
  
+  *) Synch 2.4.x and trunk

+   - mod_dav: save a few cycles
+   - mod_{ssl,md}: init_stapling_status hooks should return an int
+   - util_md5: avoid temporary stack result in ap_md5_binary()
+   - mod_proxy_balancer: Add a missing 
+   - mod_md: get_stapling_status hooks should return an int
+   - mod_session: Improve a message about SessionExpiryUpdateInterval 
values
+ [Christophe Jaillet]
+
   


Entry not needed, IMOH.

Their are no user visible changes.

CJ

Re: Broken: apache/httpd#1394 (2.4.x - fa22b50)

[Marion & Christophe JAILLET]

Le 17/01/2021 à 18:02, Graham Leggett a écrit :

Hi all,

https://travis-ci.com/github/apache/httpd/builds/213431494?utm_medium=notification_source=email 
 
failed for what looks like missing perl libraries:


t/modules/proxy_websockets.t  Can't locate 
AnyEvent/WebSocket/Client.pm in @INC (you may need to install the 
AnyEvent::WebSocket::Client module) (@INC contains: 
/home/travis/build/apache/httpd/test/perl-framework/blib/lib 
/home/travis/build/apache/httpd/test/perl-framework/blib/arch 
/home/travis/build/apache/httpd/test/perl-framework 
/home/travis/perl5/lib/perl5/5.26.1/x86_64-linux-gnu-thread-multi 
/home/travis/perl5/lib/perl5/5.26.1/x86_64-linux-gnu-thread-multi 
/home/travis/perl5/lib/perl5/5.26.1 
/home/travis/perl5/lib/perl5/x86_64-linux-gnu-thread-multi 
/home/travis/perl5/lib/perl5/5.26.1/x86_64-linux-gnu-thread-multi 
/home/travis/perl5/lib/perl5/5.26.1 
/home/travis/perl5/lib/perl5/x86_64-linux-gnu-thread-multi 
/home/travis/perl5/lib/perl5 
/home/travis/perl5/lib/perl5/5.26.0/x86_64-linux-gnu-thread-multi 
/home/travis/perl5/lib/perl5/5.26.0 
/home/travis/perl5/lib/perl5/5.26.0/x86_64-linux-gnu-thread-multi 
/home/travis/perl5/lib/perl5/5.26.1/x86_64-linux-gnu-thread-multi 
/home/travis/perl5/lib/perl5/5.26.1 
/home/travis/perl5/lib/perl5/x86_64-linux-gnu-thread-multi 
/home/travis/perl5/lib/perl5 /etc/perl 
/usr/local/lib/x86_64-linux-gnu/perl/5.26.1 
/usr/local/share/perl/5.26.1 /usr/lib/x86_64-linux-gnu/perl5/5.26 
/usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.26 
/usr/share/perl/5.26 /home/travis/perl5/lib/perl5/5.26.0 
/home/travis/perl5/lib/perl5/5.26.0/x86_64-linux-gnu-thread-multi 
/home/travis/perl5/lib/perl5/5.26.0 
/home/travis/perl5/lib/perl5/5.26.0/x86_64-linux-gnu-thread-multi 
/usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base .) at 
t/modules/proxy_websockets.t line 10.
2718BEGIN failed--compilation aborted at t/modules/proxy_websockets.t 
line 10.
2719t/modules/proxy_websockets.t  Dubious, test returned 2 
(wstat 512, 0x200)

2720No subtests run




Regards,
Graham
—



Should be fixed by r1885608

CJ

Re: Your project's website

[Marion & Christophe JAILLET]

Hi,

I have something that seems to work pretty well on my machine.

The main steps done so far are:

   - install pelican

   - move, as-is, the content of the old CMS into the content/pages/ 
directory of pelican


   - rename .mdtext files into .md files
 find . -name '*.mdtext' -exec sh -c 'mv "$0" "${0%.mdtext}.md"' {} \;

   - copy the 'simple' template from pelican

   - tweak the base.html and page.html from this template

   - move some css and images in the static/css and static/images 
directories of the theme template


   - move the the 'navigation.mdtext' from the template directory of 
the old CMS to the content/pages/ directory in order to keep its 
markdown syntax
    (I've not been able to use Markdown within the template, and I've 
adapted the solution proposed in 
https://stackoverflow.com/questions/60759348/how-to-include-a-markdown-file-in-index-html)


   - make some tweak here and there (the {.centered} in the main 
index.md file doesn't work the same for exemple)


Still need some testing but the result is visually the same for what 
have looked at.


To be continued.

CJ


Le 10/11/2020 à 21:21, Marion & Christophe JAILLET a écrit :


Hi,

I'll try to give a look at Pelican to see what I can get out of it.
I agree with Daniel that it shouldn't be to difficult. But it may take 
some time to install/test/tweak the site as I've never used Pelican 
before.


Moreover, we have some scripts that update the CMS when we make a 
release that will need some attention too.


CJ

Le 10/11/2020 à 15:22, Andrew Wetmore a écrit :

Hi, all:

Any progress on the site migration? Is there a Jira ticket for 
tracking this work?


Thanks in advance.

Andrew

On Tue, Aug 18, 2020 at 10:59 AM Andrew Wetmore <mailto:andr...@apache.org>> wrote:


Hi:

Any progress finding someone to handle the site migration?
Initial steps include:

- deciding what technology to move to, either Pelican, Hugo,
GitHub Pages or some other static site generator
- recording a formal PMC decision to make the move
- opening a Jira ticket for INFRA to help us track what we need
to do to facilitate the move.

Thanks!

Andrew

On Wed, Aug 5, 2020 at 9:17 AM Andrew Wetmore mailto:andr...@apache.org>> wrote:

Hi:

I am part of the Infrastructure team, and am writing to ask
whether your project is still using the Apache CMS for your
project website. As you know, the CMS is reaching
end-of-life, and we need projects to move their websites onto
a different option within the next few weeks.

There are several alternatives available, including those
listed on this page [1] on managing project websites. Infra
is assembling a Wiki page [2] on migrating a website from the
CMS, and is looking forward to helping projects with this
transition.

Please let me know whether your site is still on the Apache
CMS and, if so, who will be the project point-of-contact with
Infra for the migration.

Thank you!




[1] https://infra.apache.org/project-site.html
<https://infra.apache.org/project-site.html>

[2]

https://cwiki.apache.org/confluence/display/INFRA/Migrate+your+project+website+from+the+Apache+CMS

<https://cwiki.apache.org/confluence/display/INFRA/Migrate+your+project+website+from+the+Apache+CMS>



-- 
Andrew Wetmore

Technical Writer-Editor
Infra
*Apache Software Foundation*
andr...@apache.org <mailto:andr...@apache.org>


<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
Virus-free. www.avast.com

<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>




-- 
Andrew Wetmore

Technical Writer-Editor
Infra
*Apache Software Foundation*
andr...@apache.org <mailto:andr...@apache.org>



--
Andrew Wetmore
Technical Writer-Editor
Infra
*Apache Software Foundation*
andr...@apache.org <mailto:andr...@apache.org>

Re: Your project's website

[Marion & Christophe JAILLET]

Hi,

I'll try to give a look at Pelican to see what I can get out of it.
I agree with Daniel that it shouldn't be to difficult. But it may take 
some time to install/test/tweak the site as I've never used Pelican before.


Moreover, we have some scripts that update the CMS when we make a 
release that will need some attention too.


CJ

Le 10/11/2020 à 15:22, Andrew Wetmore a écrit :

Hi, all:

Any progress on the site migration? Is there a Jira ticket for 
tracking this work?


Thanks in advance.

Andrew

On Tue, Aug 18, 2020 at 10:59 AM Andrew Wetmore > wrote:


Hi:

Any progress finding someone to handle the site migration? Initial
steps include:

- deciding what technology to move to, either Pelican, Hugo,
GitHub Pages or some other static site generator
- recording a formal PMC decision to make the move
- opening a Jira ticket for INFRA to help us track what we need to
do to facilitate the move.

Thanks!

Andrew

On Wed, Aug 5, 2020 at 9:17 AM Andrew Wetmore mailto:andr...@apache.org>> wrote:

Hi:

I am part of the Infrastructure team, and am writing to ask
whether your project is still using the Apache CMS for your
project website. As you know, the CMS is reaching end-of-life,
and we need projects to move their websites onto a different
option within the next few weeks.

There are several alternatives available, including those
listed on this page [1] on managing project websites. Infra is
assembling a Wiki page [2] on migrating a website from the
CMS, and is looking forward to helping projects with this
transition.

Please let me know whether your site is still on the Apache
CMS and, if so, who will be the project point-of-contact with
Infra for the migration.

Thank you!




[1] https://infra.apache.org/project-site.html


[2]

https://cwiki.apache.org/confluence/display/INFRA/Migrate+your+project+website+from+the+Apache+CMS





-- 
Andrew Wetmore

Technical Writer-Editor
Infra
*Apache Software Foundation*
andr...@apache.org 



Virus-free. www.avast.com






-- 
Andrew Wetmore

Technical Writer-Editor
Infra
*Apache Software Foundation*
andr...@apache.org 



--
Andrew Wetmore
Technical Writer-Editor
Infra
*Apache Software Foundation*
andr...@apache.org 

Re: Changing the httpd security process

[Christophe JAILLET]

Le 20/08/2020 à 18:24, Joe Orton a écrit :

On Mon, Aug 17, 2020 at 12:08:35PM +0100, Joe Orton wrote:

This roughly reverts the httpd process to what we used prior to adopting
the Tomcat-esque policy for the whole ASF.  We would have to document
this and possibly need it approved by the ASF security team.

Thanks to those who have given feedback.

I won't rush this since it's Summer and people may be on holiday, if by
the start of September there is no dissent I will assume PMC consensus
for making this change and work out how to document & notify security@.

Regards, Joe

+1

CJ

Re: Trunk warnings win64 1-sept-2020

[Christophe JAILLET]

Le 01/09/2020 à 16:30, Steffen Land a écrit :




Trunk  revision 1881351 date 1 sept 2020


New layout list, more readable now.

01 sept 2020  405 some solved already by jailletc36
14 May 2020  416

Steffen



Hi Steffen,

I've looked more closely at the generated warnings.
Most of them are just noise. Some are false positive.

I've not spotted any real issue up to now.
The most interesting one so far has been fixed in r1881311.

I'll try to fix some of them but it is unlikely that I can fix all of 
them. Fixing them would require is many cases to add some casting. I'm 
not a big fan of having casting everywhere only to please a given 
compiler, when there is no real issue.


As I don't compile on Windows, I "blindly" fix things. Then I test with 
gcc. So, should we try to fix many things, I would need someone to 
refresh the list from time to time and check if a "fix" dos not 
introduce a new warning.



Finally, any patch to help in the task is appreciated ;-)

CJ

Re: Broken: apache/httpd#1091 (trunk - 74d32d7)

[Christophe JAILLET]

Le 29/08/2020 à 22:43, Travis CI a écrit :

apache

/

httpd

<https://travis-ci.org/github/apache/httpd?utm_medium=notification_source=email> 



branch icontrunk <https://github.com/apache/httpd/tree/trunk>

build has failed
Build #1091 was broken 
<https://travis-ci.org/github/apache/httpd/builds/722360185?utm_medium=notification_source=email>

arrow to build time
clock icon12 mins and 2 secs

Christophe Jaillet avatarChristophe Jaillet

74d32d7 CHANGESET → 
<https://github.com/apache/httpd/compare/e602f55d734a...74d32d7bafd3>


Fix a few warnings on 64 bits windows compilation

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1881303 
13f79535-47bb-0310-9956-ffa450edef68


Want to know about upcoming build environment updates?

Would you like to stay up-to-date with the upcoming Travis CI build 
environment updates? We set up a mailing list for you!


SIGN UP HERE <http://eepurl.com/9OCsP>

book icon

Documentation <https://docs.travis-ci.com/> about Travis CI

Have any questions? We're here to help. <mailto:supp...@travis-ci.com>
Unsubscribe 
<https://travis-ci.org/account/preferences/unsubscribe?repository=69847_medium=notification_source=email> 
from build emails from the apache/httpd repository.
To unsubscribe from *all* build emails, please update your settings 
<https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notification_source=email>. 


black and white travis ci logo <https://travis-ci.com>

Travis CI GmbH, Rigaer Str. 8, 10427 Berlin, Germany | GF/CEO: Randy 
Jacops | Contact: cont...@travis-ci.com <mailto:cont...@travis-ci.com> | 
Amtsgericht Charlottenburg, Berlin, HRB 140133 B | Umsatzsteuer-ID gemäß 
§27 a Umsatzsteuergesetz: DE282002648




Hi,

spurious failure, unlikely related to the corresponding commit.
Never seen that before.

Any idea?

CJ


Thread 66 (Thread 0x7f13a6525700 (LWP 7436)):

#0  0x7f13dd61a187 in kill () from /lib/x86_64-linux-gnu/libc.so.6
#1  
#2  0x7f13dd619e97 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#3  0x7f13dd61b801 in abort () from /lib/x86_64-linux-gnu/libc.so.6
#4  0x7f13ddc05f62 in apr_table_mergen (t=0x560cba82d790, 
key=key@entry=0x560cb949006a "Connection", val=val@entry=0x560cb9488f86 
"close") at tables/apr_tables.c:750
#5  0x560cb9434fcf in ap_set_keepalive (r=r@entry=0x560cba7c9c60) at 
http_protocol.c:309
#6  0x560cb943a475 in ap_http_header_filter (f=0x560cba74f8e0, 
b=0x560cba65db80) at http_filters.c:1369
#7  0x560cb9458091 in ap_content_length_filter (f=0x560cba1d95c0, 
b=0x560cba65db80) at protocol.c:2040

Re: svn commit: r1880368 - /httpd/httpd/trunk/docs/manual/style/lang-targets.xml

[Christophe JAILLET]

Le 19/08/2020 à 09:47, Joe Orton a écrit :

On Wed, Aug 19, 2020 at 08:36:02AM +0100, Joe Orton wrote:

On Tue, Aug 18, 2020 at 07:08:21AM -0400, Eric Covener wrote:

On Tue, Aug 18, 2020 at 6:34 AM Joe Orton  wrote:


On Tue, Jul 28, 2020 at 07:32:01AM -0400, Eric Covener wrote:

FYI I am seeing if I can coordinate with Humbedooh to change all the
generated files without one of those 17-part commit threads.
But I will probably just commit in the next few hours either way.


Does this still need to be done for trunk?  I'm kind of lost here (as
usual with the docs), but running "./build.sh all" in trunk gives me a
tonne of *.html.en.utf8 files.

I have docs/manual/build at r1880369

Should we do a mass "svn mv" for .html.en to .html.en.utf8?


yes sorry. It looks nearly as noisy in the commit when I tested it but
I did chat with Daniel and he said just bite the bullet and don't
fiddle around with the mailing list.


Thanks & no worries.  The public /docs/trunk/ content still seems to be
working so I'm hoping I haven't completely broken everything:

r1880980 - magic bootstrap step needed to regenerate the typemaps correctly
r1880982 - surely the longest I have ever seen svn commit run for


... in fact in r1880982 I only ran "./build.sh en" I think.

And I am still seeing a big diff changing ISO-8859-1 characters into
HTML entities for other languages when re-running "build.sh all":

$ svn diff vhosts/index.html.de  | head
Index: vhosts/index.html.de
===
--- vhosts/index.html.de(revision 1880979)
+++ vhosts/index.html.de(working copy)
@@ -23,59 +23,59 @@
  
  http://www.apache.org/;>Apache  http://httpd.apache.org/;>HTTP-Server  http://httpd.apache.org/docs/;>Dokumentation  Version 2.5Apache-Dokumentation zu virtuellen Hosts
  
-Verf�gbare Sprachen: de |
+Verfgbare Sprachen: de |

FWIW, using:

$ $JAVA_HOME/bin/java -version
openjdk version "11.0.8" 2020-07-14
OpenJDK Runtime Environment 18.9 (build 11.0.8+10)
OpenJDK 64-Bit Server VM 18.9 (build 11.0.8+10, mixed mode, sharing)

Stupid question, why do we need to change the suffix to .utf8 to convert
these files into UTF-8?


I don't think it is needed, just a matter of consistancy in naming.
See r1878788 to see the magic needed to concert to UTF-8 (without 
renaming files)


CJ




M   man/htdbm.1
M   manual/bind.html.de
M   manual/configuring.html.de
M   manual/glossary.html.de
M   manual/howto/htaccess.html.pt-br
M   manual/index.html.da
M   manual/index.html.de
M   manual/index.html.pt-br
M   manual/install.html.de
M   manual/invoking.html.de
M   manual/mod/core.html.de
M   manual/mod/core.html.es.utf8
M   manual/mod/core.html.ja.utf8
M   manual/mod/core.html.tr.utf8
M   manual/mod/directives.html.de
M   manual/mod/directives.html.ja.utf8
M   manual/mod/directives.html.ko.euc-kr
M   manual/mod/directives.html.tr.utf8
M   manual/mod/directives.html.zh-cn.utf8
M   manual/mod/index.html.de
M   manual/mod/mod_actions.html.de
M   manual/mod/mpm_common.html.de
M   manual/mod/mpm_winnt.html.de
M   manual/mod/prefork.html.de
M   manual/mod/quickreference.html.de
M   manual/mod/quickreference.html.ja.utf8
M   manual/mod/quickreference.html.ko.euc-kr
M   manual/mod/quickreference.html.tr.utf8
M   manual/mod/quickreference.html.zh-cn.utf8
M   manual/mod/worker.html.de
M   manual/mpm.html.de
M   manual/new_features_2_0.html.de
M   manual/new_features_2_0.html.pt-br
M   manual/new_features_2_2.html.pt-br
M   manual/sitemap.html.de
M   manual/stopping.html.de
M   manual/vhosts/index.html.de
M   manual/vhosts/name-based.html.de

Re: svn commit: r1880368 - /httpd/httpd/trunk/docs/manual/style/lang-targets.xml

[Christophe JAILLET]

Le 19/08/2020 à 09:57, Ruediger Pluem a écrit :



On 8/19/20 9:47 AM, Joe Orton wrote:

On Wed, Aug 19, 2020 at 08:36:02AM +0100, Joe Orton wrote:

On Tue, Aug 18, 2020 at 07:08:21AM -0400, Eric Covener wrote:

On Tue, Aug 18, 2020 at 6:34 AM Joe Orton  wrote:


On Tue, Jul 28, 2020 at 07:32:01AM -0400, Eric Covener wrote:

FYI I am seeing if I can coordinate with Humbedooh to change all the
generated files without one of those 17-part commit threads.
But I will probably just commit in the next few hours either way.


Does this still need to be done for trunk?  I'm kind of lost here (as
usual with the docs), but running "./build.sh all" in trunk gives me a
tonne of *.html.en.utf8 files.

I have docs/manual/build at r1880369

Should we do a mass "svn mv" for .html.en to .html.en.utf8?


yes sorry. It looks nearly as noisy in the commit when I tested it but
I did chat with Daniel and he said just bite the bullet and don't
fiddle around with the mailing list.


Thanks & no worries.  The public /docs/trunk/ content still seems to be
working so I'm hoping I haven't completely broken everything:

r1880980 - magic bootstrap step needed to regenerate the typemaps correctly
r1880982 - surely the longest I have ever seen svn commit run for


... in fact in r1880982 I only ran "./build.sh en" I think.

And I am still seeing a big diff changing ISO-8859-1 characters into
HTML entities for other languages when re-running "build.sh all":


Should we move these languages to utf8 as well like we did for en?

Regards

Rüdiger



+1

Re: svn commit: r1880368 - /httpd/httpd/trunk/docs/manual/style/lang-targets.xml

[Christophe JAILLET]

Le 18/08/2020 à 12:33, Joe Orton a écrit :

On Tue, Jul 28, 2020 at 07:32:01AM -0400, Eric Covener wrote:

FYI I am seeing if I can coordinate with Humbedooh to change all the
generated files without one of those 17-part commit threads.
But I will probably just commit in the next few hours either way.

Does this still need to be done for trunk?


Yes, I think that it has been done just half-way on trunk. See below



   I'm kind of lost here (as
usual with the docs), but running "./build.sh all" in trunk gives me a
tonne of *.html.en.utf8 files.


My first thought was that it shouldn't, unless you modified:
   /home/tititou36/svn_httpd_trunk/docs/manual/style/lang/en.xml

Mine has:
    .html.en

If you look at fr.xml, for example, it has:
    .html.fr.utf8

So, unless, I missed something, only html.en should be generated.


My 2nd thought, is that in fact, I've missed something. See r1880368.
And running build.sh also generates *.html.en.utf8 for me.


So, now it is me who is lost.
What is the relation between what is in .xml and lang-targets.xml 
?


.xml controls what is written in .html and lang-targets.xml 
how files are named?
If so, it is wired and, if feasible, it would be great to have it 
defined at only one place.



So I think, that en doc is actually broken on trunk, because the html 
files point to non-existing files for en version.


:(

CJ



I have docs/manual/build at r1880369

Should we do a mass "svn mv" for .html.en to .html.en.utf8?

Regards, Joe



On Tue, Jul 28, 2020 at 7:21 AM  wrote:

Author: covener
Date: Tue Jul 28 11:21:32 2020
New Revision: 1880368

URL: http://svn.apache.org/viewvc?rev=1880368=rev
Log:
use .utf8 output


Modified:
 httpd/httpd/trunk/docs/manual/style/lang-targets.xml

Modified: httpd/httpd/trunk/docs/manual/style/lang-targets.xml
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/style/lang-targets.xml?rev=1880368=1880367=1880368=diff
==
--- httpd/httpd/trunk/docs/manual/style/lang-targets.xml (original)
+++ httpd/httpd/trunk/docs/manual/style/lang-targets.xml Tue Jul 28 11:21:32 
2020
@@ -75,7 +75,7 @@
  
  
  
-
+

  
  
@@ -312,4 +312,4 @@
  
  

-
\ No newline at end of file
+




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