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: svn commit: r33393 - /release/httpd/CHANGES_2.4

[Marion et Christophe JAILLET]

Hi,

 

CHANGES_2.4 has been updated with the SECURITY tags and is available from 
httpd.a.o.

However, http://www.apache.org/dist/httpd/CHANGES_2.4.39 still reflects the 
file without these SECURITY items.

 

I won't be able to update it before Friday, so feel free to fix it in the 
meantime.

 

CJ

 

 

 

> Message du 02/04/19 03:04
> De : drugg...@apache.org
> A : c...@httpd.apache.org
> Copie à : 
> Objet : svn commit: r33393 - /release/httpd/CHANGES_2.4
> 
> Author: druggeri
> Date: Tue Apr 2 01:04:50 2019
> New Revision: 33393
> 
> Log:
> Correct changelog for vulnerabilities
> 
> Modified:
> release/httpd/CHANGES_2.4
> 
> Modified: release/httpd/CHANGES_2.4
> ==
> --- release/httpd/CHANGES_2.4 (original)
> +++ release/httpd/CHANGES_2.4 Tue Apr 2 01:04:50 2019
> @@ -1,13 +1,50 @@
> -*- coding: utf-8 -*-
> Changes with Apache 2.4.39
> + *) SECURITY: CVE-2019-0197 (cve.mitre.org)
> + mod_http2: fixes a possible crash when HTTP/2 was enabled for a http:
> + host or H2Upgrade was enabled for h2 on a https: host. An Upgrade
> + request from http/1.1 to http/2 that was not the first request on a
> + connection could lead to a misconfiguration and crash. Servers that
> + never enabled the h2 protocol or only enabled it for https: and
> + did not set "H2Upgrade on" are unaffected by this issue.
> + [Stefan Eissing]
> +
> + *) SECURITY: CVE-2019-0196 (cve.mitre.org)
> + mod_http2: using fuzzed network input, the http/2 request
> + handling could be made to access freed memory in string
> + comparision when determining the method of a request and
> + thus process the request incorrectly. [Stefan Eissing]
> +
> + *) SECURITY: CVE-2019-0211 (cve.mitre.org)
> + MPMs unix: Fix a local priviledge escalation vulnerability by not
> + maintaining each child's listener bucket number in the scoreboard,
> + preventing unprivileged code like scripts run by/on the server (e.g. via
> + mod_php) from modifying it persistently to abuse the priviledged main
> + process. [Charles Fol , Yann Ylavic]
> +
> + *) SECURITY: CVE-2019-0196 (cve.mitre.org)
> + mod_http2: using fuzzed network input, the http/2 request
> + handling could be made to access freed memory in string
> + comparision when determining the method of a request and
> + thus process the request incorrectly. [Stefan Eissing]
> +
> + *) SECURITY: CVE-2019-0217 (cve.mitre.org)
> + mod_auth_digest: Fix a race condition checking user credentials which
> + could allow a user with valid credentials to impersonate another,
> + under a threaded MPM. PR 63124. [Simon Kappel ]
> +
> + *) SECURITY: CVE-2019-0215 (cve.mitre.org)
> + mod_ssl: Fix access control bypass for per-location/per-dir client
> + certificate verification in TLSv1.3.
> +
> + *) SECURITY: CVE-2019-0220 (cve.mitre.org)
> + Merge consecutive slashes in URL's. Opt-out with
> + `MergeSlashes OFF`. [Eric Covener]
> 
> *) mod_proxy/ssl: Cleanup per-request SSL configuration anytime a backend
> connection is recycled/reused to avoid a possible crash with some SSLProxy
> configurations in or context. PR 63256. [Yann Ylavic]
> 
> - *) mod_ssl: Correctly restore SSL verify state after TLSv1.3 PHA failure.
> - [Michael Kaufmann ]
> -
> *) mod_log_config: Support %{c}h for conn-hostname, %h for useragent_host
> PR 55348
> 
> @@ -59,13 +96,6 @@ Changes with Apache 2.4.39
> *) mod_cache_socache: Avoid reallocations and be safe with outgoing data
> lifetime. [Yann Ylavic]
> 
> - *) MPMs unix: bind the bucket number of each child to its slot number, for a
> - more efficient per bucket maintenance. [Yann Ylavic]
> -
> - *) mod_auth_digest: Fix a race condition. Authentication with valid
> - credentials could be refused in case of concurrent accesses from
> - different users. PR 63124. [Simon Kappel ]
> -
> *) mod_http2: enable re-use of slave connections again. Fixed slave connection
> keepalives counter. [Stefan Eissing]
> 
> 
> 
>

Re: svn commit: r1851794 [1/37] - in /httpd/httpd/trunk/docs/manual: ./ developer/ howto/ misc/ mod/ platform/ programs/ rewrite/ ssl/ vhosts/

[Marion et Christophe JAILLET]

My fault (if this is a fault :) ).

 

It is part of r1851168 ("Give a little breath before the permalink") in order 
to tweak the permalink I've added (on trunk only for now).
I've added a space because it looked nicer (IMHO)

 

Another less intrusive change was done on css in r1851167.

 

So, this is normal and not related to a java x issue.

The JDK version issue was (partly IMHO) fixed with FR and US changed to use 
UTF-8.

I still have some issues with generated man files and with entities in 
"Available Languages:  en  |  fr  |  ja  | blahblah", at least in my built 
environment.

 

CJ

 

 

 

> Message du 22/01/19 15:27
> De : "Eric Covener" 
> A : "Apache HTTP Server Development List" 
> Copie à : c...@httpd.apache.org
> Objet : Re: svn commit: r1851794 [1/37] - in /httpd/httpd/trunk/docs/manual: 
> ./ developer/ howto/ misc/ mod/ platform/ programs/ rewrite/ ssl/ vhosts/
> 
> > Modified: httpd/httpd/trunk/docs/manual/bind.html.de
> > URL: 
> > http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/bind.html.de?rev=1851794=1851793=1851794=diff
> > ==
> > --- httpd/httpd/trunk/docs/manual/bind.html.de (original)
> > +++ httpd/httpd/trunk/docs/manual/bind.html.de Tue Jan 22 09:53:04 2019
> > @@ -46,7 +46,7 @@
> > Apache

Kommentare


> >


> >

> > -
Überblick¶

> > +
Überblick ¶

> 
> I noticed my recent xform tried to do something like this too.
> 

re: svn commit: r32075 - /dev/httpd/ /release/httpd/

[Marion et Christophe JAILLET]

 

s/September/January/

in the announcement (html and txt)

 

CJ

 

 

> Message du 21/01/19 16:03
> De : drugg...@apache.org
> A : c...@httpd.apache.org
> Copie à : 
> Objet : svn commit: r32075 - /dev/httpd/ /release/httpd/
> 
> Author: druggeri
> Date: Mon Jan 21 15:03:33 2019
> New Revision: 32075
> 
> Log:
> Push 2.4.38 up to the release directory
> 
> Added:
> release/httpd/CHANGES_2.4.38
> - copied unchanged from r32074, dev/httpd/CHANGES_2.4.38
> release/httpd/httpd-2.4.38.tar.bz2
> - copied unchanged from r32074, dev/httpd/httpd-2.4.38.tar.bz2
> release/httpd/httpd-2.4.38.tar.bz2.asc
> - copied unchanged from r32074, dev/httpd/httpd-2.4.38.tar.bz2.asc
> release/httpd/httpd-2.4.38.tar.bz2.md5
> - copied unchanged from r32074, dev/httpd/httpd-2.4.38.tar.bz2.md5
> release/httpd/httpd-2.4.38.tar.bz2.sha1
> - copied unchanged from r32074, dev/httpd/httpd-2.4.38.tar.bz2.sha1
> release/httpd/httpd-2.4.38.tar.bz2.sha256
> - copied unchanged from r32074, dev/httpd/httpd-2.4.38.tar.bz2.sha256
> release/httpd/httpd-2.4.38.tar.gz
> - copied unchanged from r32074, dev/httpd/httpd-2.4.38.tar.gz
> release/httpd/httpd-2.4.38.tar.gz.asc
> - copied unchanged from r32074, dev/httpd/httpd-2.4.38.tar.gz.asc
> release/httpd/httpd-2.4.38.tar.gz.md5
> - copied unchanged from r32074, dev/httpd/httpd-2.4.38.tar.gz.md5
> release/httpd/httpd-2.4.38.tar.gz.sha1
> - copied unchanged from r32074, dev/httpd/httpd-2.4.38.tar.gz.sha1
> release/httpd/httpd-2.4.38.tar.gz.sha256
> - copied unchanged from r32074, dev/httpd/httpd-2.4.38.tar.gz.sha256
> Removed:
> dev/httpd/CHANGES_2.4
> dev/httpd/CHANGES_2.4.38
> dev/httpd/httpd-2.4.38-deps.tar.bz2
> dev/httpd/httpd-2.4.38-deps.tar.bz2.asc
> dev/httpd/httpd-2.4.38-deps.tar.bz2.md5
> dev/httpd/httpd-2.4.38-deps.tar.bz2.sha1
> dev/httpd/httpd-2.4.38-deps.tar.bz2.sha256
> dev/httpd/httpd-2.4.38-deps.tar.gz
> dev/httpd/httpd-2.4.38-deps.tar.gz.asc
> dev/httpd/httpd-2.4.38-deps.tar.gz.md5
> dev/httpd/httpd-2.4.38-deps.tar.gz.sha1
> dev/httpd/httpd-2.4.38-deps.tar.gz.sha256
> dev/httpd/httpd-2.4.38.tar.bz2
> dev/httpd/httpd-2.4.38.tar.bz2.asc
> dev/httpd/httpd-2.4.38.tar.bz2.md5
> dev/httpd/httpd-2.4.38.tar.bz2.sha1
> dev/httpd/httpd-2.4.38.tar.bz2.sha256
> dev/httpd/httpd-2.4.38.tar.gz
> dev/httpd/httpd-2.4.38.tar.gz.asc
> dev/httpd/httpd-2.4.38.tar.gz.md5
> dev/httpd/httpd-2.4.38.tar.gz.sha1
> dev/httpd/httpd-2.4.38.tar.gz.sha256
> Modified:
> release/httpd/Announcement2.4.html
> release/httpd/Announcement2.4.txt
> release/httpd/CHANGES_2.4
> 
> Modified: release/httpd/Announcement2.4.html
> ==
> --- release/httpd/Announcement2.4.html (original)
> +++ release/httpd/Announcement2.4.html Mon Jan 21 15:03:33 2019
> @@ -49,15 +49,15 @@
>
 

> 
>

> - Apache HTTP Server 2.4.37 Released
> + Apache HTTP Server 2.4.38 Released
>

>
> 
> - October 23, 2018
> + September 21, 2018
>


>
> 
> The Apache Software Foundation and the Apache HTTP Server Project are
> pleased to announce
> - the release of version 2.4.37 of the Apache
> + the release of version 2.4.38 of the Apache
> HTTP Server ("Apache"). This version of Apache is our latest GA
> release of the new generation 2.4.x branch of Apache HTTPD and
> represents fifteen years of innovation by the project, and is
> @@ -69,7 +69,7 @@
> encourage users of all prior versions to upgrade.
>


>
> 
> - Apache HTTP Server 2.4.37 is available for download from:
> + Apache HTTP Server 2.4.38 is available for download from:
>


>
>> @@ -77,7 +77,7 @@
> 
>
> 
> Please see the CHANGES_2.4 file, linked from the download page, for a
> - full list of changes. A condensed list, CHANGES_2.4.37 includes only
> + full list of changes. A condensed list, CHANGES_2.4.38 includes only
> those changes introduced since the prior 2.4 release. A summary of all 
> of the security vulnerabilities addressed in this and earlier releases 
> is available:
> 
> Modified: release/httpd/Announcement2.4.txt
> ==
> --- release/httpd/Announcement2.4.txt (original)
> +++ release/httpd/Announcement2.4.txt Mon Jan 21 15:03:33 2019
> @@ -1,9 +1,9 @@
> - Apache HTTP Server 2.4.37 Released
> + Apache HTTP Server 2.4.38 Released
> 
> - October 23, 2018
> + September 21, 2018
> 
> The Apache Software Foundation and the Apache HTTP Server Project
> - are pleased to announce the release of version 2.4.37 of the Apache
> + are pleased to announce the release of version 2.4.38 of the Apache
> HTTP Server ("Apache"). This version of Apache is our latest GA
> release of the new generation 2.4.x branch of Apache HTTPD and
> represents fifteen years of innovation by the project, and is
> @@ -13,7 +13,7 @@
> We consider this release to be the best version of Apache available, and
> encourage users of all prior versions to upgrade.
> 
> - Apache HTTP Server 2.4.37 is available for download from:
> + Apache HTTP Server 2.4.38 is available for 

re: AW: AW: [VOTE] Release httpd-2.4.36

[Marion et Christophe JAILLET]

No, I don't know and won't be able to check before tomorrow evening.

 

I would say that these tests were passing with 2.4.x when it was added (~3 
weeks ago), so it could be a regression.

But it needs to be checked to be sure about it.

 

Nothing obvious in the recent commits look related to a change of behavior in 
this area.

 

CJ

 

> Message du 11/10/18 13:15
> De : "Plüm, Rüdiger, Vodafone Group" 
> A : "dev@httpd.apache.org" 
> Copie à : 
> Objet : AW: AW: [VOTE] Release httpd-2.4.36
> 
>

Do you know if the failure is a regression over 2.4.35?

 

Regards

 

Rüdiger

 




Von: Marion et Christophe JAILLET  
> Gesendet: Donnerstag, 11. Oktober 2018 13:13
> An: dev@httpd.apache.org
> Betreff: re: AW: [VOTE] Release httpd-2.4.36



 

> Waouh!

>  

> This would mean I've provided a new useful test!

> (it has been added recently in r1841508)

>  

> :)

>  

> I definitely need to document how to generate and use test-coverage data when 
> running the test framework.

> This helps to spot where new tests are needed.

>  

> CJ

>  

>  

>  


> Message du 11/10/18 10:08
> > De : "Plüm, Rüdiger, Vodafone Group" 
> > A : "dev@httpd.apache.org" 
> > Copie à : 
> > Objet : AW: [VOTE] Release httpd-2.4.36
> > 
> > Anyone else seeing
> > 
> > t/modules/buffer.t (Wstat: 0 Tests: 12 Failed: 2)
> > Failed tests: 8, 12
> > 
> > ?
> > 
> > I don't see this with trunk on the same machine. Issue seems to be if input 
> > filtering is on on large POSTs.
> > 
> > Regards
> > 
> > Rüdiger
> > 
> > > -Ursprüngliche Nachricht-
> > > Von: Daniel Ruggeri 
> > > Gesendet: Donnerstag, 11. Oktober 2018 02:27
> > > An: dev@httpd.apache.org
> > > Betreff: Re: [VOTE] Release httpd-2.4.36
> > > 
> > > +1 from me (talking to myself).
> > > 
> > > Test environment follows. I observe only one failure of the test suite
> > > (mentioned elsewhere) - it seems only to apply w/ OpenSSL 1.1.1 and H2.
> > > 
> > > system:
> > >   kernel:
> > >     name: Linux
> > >     release: 3.16.0-4-amd64
> > >     version: #1 SMP Debian 3.16.51-3 (2017-12-13)
> > >     machine: x86_64
> > > 
> > >   libraries:
> > >     openssl: "1.1.1"
> > >     openldap: "2.4.46"
> > >     apr: "1.6.5"
> > >     apr-util: "1.6.1"
> > >     iconv: "1.2.2"
> > >     brotli: "1.0.6"
> > >     nghttp2: "1.34.0"
> > >     zlib: "1.2.11"
> > >     pcre: "8.42"
> > >     libxml2: "2.9.8"
> > >     php: "5.6.38"
> > >     lua: "5.3.5"
> > >     curl: "7.61.1"
> > > 
> > > --
> > > Daniel Ruggeri
> > > 
> > > On 10/10/2018 2:18 PM, Daniel Ruggeri 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.36:
> > > > [ ] +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: e40e7a879b84df860215b8a80f2a535534a1c4b4 *httpd-2.4.36.tar.gz
> > > > sha256:
> > > > ef788fb7c814acb2506a8b758a1a3f91f368f97bd4e6db16e98001f468e8e288
> > > > *httpd-2.4.36.tar.gz
> > > >
> > 
> >

re: AW: [VOTE] Release httpd-2.4.36

[Marion et Christophe JAILLET]

Waouh!

 

This would mean I've provided a new useful test!

(it has been added recently in r1841508)

 

:)

 

I definitely need to document how to generate and use test-coverage data when 
running the test framework.

This helps to spot where new tests are needed.

 

CJ

 

 

 

> Message du 11/10/18 10:08
> De : "Plüm, Rüdiger, Vodafone Group" 
> A : "dev@httpd.apache.org" 
> Copie à : 
> Objet : AW: [VOTE] Release httpd-2.4.36
> 
> Anyone else seeing
> 
> t/modules/buffer.t (Wstat: 0 Tests: 12 Failed: 2)
> Failed tests: 8, 12
> 
> ?
> 
> I don't see this with trunk on the same machine. Issue seems to be if input 
> filtering is on on large POSTs.
> 
> Regards
> 
> Rüdiger
> 
> > -Ursprüngliche Nachricht-
> > Von: Daniel Ruggeri 
> > Gesendet: Donnerstag, 11. Oktober 2018 02:27
> > An: dev@httpd.apache.org
> > Betreff: Re: [VOTE] Release httpd-2.4.36
> > 
> > +1 from me (talking to myself).
> > 
> > Test environment follows. I observe only one failure of the test suite
> > (mentioned elsewhere) - it seems only to apply w/ OpenSSL 1.1.1 and H2.
> > 
> > system:
> >   kernel:
> >     name: Linux
> >     release: 3.16.0-4-amd64
> >     version: #1 SMP Debian 3.16.51-3 (2017-12-13)
> >     machine: x86_64
> > 
> >   libraries:
> >     openssl: "1.1.1"
> >     openldap: "2.4.46"
> >     apr: "1.6.5"
> >     apr-util: "1.6.1"
> >     iconv: "1.2.2"
> >     brotli: "1.0.6"
> >     nghttp2: "1.34.0"
> >     zlib: "1.2.11"
> >     pcre: "8.42"
> >     libxml2: "2.9.8"
> >     php: "5.6.38"
> >     lua: "5.3.5"
> >     curl: "7.61.1"
> > 
> > --
> > Daniel Ruggeri
> > 
> > On 10/10/2018 2:18 PM, Daniel Ruggeri 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.36:
> > > [ ] +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: e40e7a879b84df860215b8a80f2a535534a1c4b4 *httpd-2.4.36.tar.gz
> > > sha256:
> > > ef788fb7c814acb2506a8b758a1a3f91f368f97bd4e6db16e98001f468e8e288
> > > *httpd-2.4.36.tar.gz
> > >
> 
>

Re: Time for 2.4.34?

[Marion et Christophe JAILLET]

+1, but latest zh-cn and zh-tw translation of error pages should be 
included IMHO.


I've pushed for including what was already in trunk, but Codeingboy and 
popcorner have made improvements since the backport. (see docs@ ML)


Not sure to have time tonight to push it on trunk and propose for backport.
And, after tonight, I won't be able before monday evening.

CJ


Le 05/07/2018 à 17:43, Jim Jagielski a écrit :

Seems to me that we are just about due for a 2.4.34 release...
Anyone opposed? I volunteer to RM.

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

[Marion et Christophe JAILLET]

Le 02/07/2018 à 22:51, drugg...@apache.org a écrit :

+ druggeri: Why no +1, jallietc36?
+


I vote when I can test or when trivial enough.
But it does not prevent me from proposing what looks interesting, so 
that the other ones, with more technical background or experience than 
me, have a change to vote and backport it, if my intuition (or in this 
particular case, the log message) is correct.


In such a case, just running the test framework is not enough, IMHO. One 
need a deeper understanding of what is changed (what can be the 
consequences of inserting an error bucket? Should be none, but...). It 
also looks not that easy to test and trigger the issue (" When a 
post-handshake check fails"...).
This could look trivial, but the devil is in the detail (and mod_ssl is 
a to big beast for me, with too many differences between 2.4.x and trunk 
(but easy backport proposal are on the way :))


So, just proposing, is my only contribution in such a case.
Hoping it helps.

CJ

Re: svn commit: r1834017 - in /httpd/httpd/trunk/docs/manual/mod: mod_proxy_uwsgi.html mod_proxy_uwsgi.html.en

[Marion et Christophe JAILLET]

Hi,

not directly related, but when diff 2.4.x and trunk, Apache-apr2.dsw 
2.4.x has the following lines which are missing in trunk:


-   Project_Dep_Name mod_proxy_uwsgi
-   End Project Dependency
-   Begin Project Dependency

I'm not a win32 man (anymore) and I've never tried to compile httpd with 
Visual Studio, so I don't really know the impact of these missing lines.


Anyone?

CJ

Le 21/06/2018 à 15:40, j...@apache.org a écrit :

Author: jim
Date: Thu Jun 21 13:40:02 2018
New Revision: 1834017

URL: http://svn.apache.org/viewvc?rev=1834017=rev
Log:
re-add uwsgi

Added:
 httpd/httpd/trunk/docs/manual/mod/mod_proxy_uwsgi.html
 httpd/httpd/trunk/docs/manual/mod/mod_proxy_uwsgi.html.en

Bug 62220

[Marion et Christophe JAILLET]

Hi,

should PR 62220 be considered as a showstopper?
It is the 3rd time is is reported.

I tried to debug it but ended nowhere.
Removing "| EXEC_ON_READ" around line 1248 where 
RemoteIPTrustedProxyList and RemoteIPInternalProxyListdirectives 
directives are defined, in mod_remoteip.c fixes the issue, according to 
Martynas Bendorius (smtalk in the bug report)


But, if this is the correct fix, I can't explain why it worked before 
and why there is a regression!


Some discussion can be found in thread 
http://mail-archives.apache.org/mod_mbox/httpd-dev/201804.mbox/%3cpa8d38$81i$1...@blaine.gmane.org%3e.


CJ

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

[Marion et Christophe JAILLET]

Le 30/05/2018 à 00:40, Yann Ylavic a écrit :

Hi Christophe,

On Fri, May 25, 2018 at 10:00 PM,   wrote:

Author: jailletc36
Date: Fri May 25 20:00:04 2018
New Revision: 1832275

URL: http://svn.apache.org/viewvc?rev=1832275=rev
Log:
Add test for ProxyPassReverseCookieDomain and ProxyPassReverseCookiePath.

See PR 61560.
Corrently broken, but working on a fix :)

Even after r1832283, t/modules/proxy.t fails in 2.4.x:
Yes. I was not clear enough about what I was about to fix. Not the test 
itself (r1832283 only adds some other cases), but the code in trunk (in 
r1832280), which will be proposed for backport soon.
I still waiting, because I want to double check something.I think that 
the 'apr_pstrdup' added before the main 'while' loop I've added can be 
avoided. I was thinking that 'apr_strtok' would modify the source (i.e. 
add a \0 where needed to split the string), but in fact, it duplicates 
each token and only keep track of the current position in the, 
un-modified, input.

So, a follow-up should arrive tonight or tomorrow's evening.


Do these depend on r1832280 (not in 2.4.x yet)?

Thanks,
Yann.


Yes, that's it.

CJ

Re: Experimental C unit test suite available for hacking

[Marion et Christophe JAILLET]

Le 23/05/2018 à 14:48, Micha Lenk a écrit :

On 05/25/2017 11:44 PM, Jacob Champion wrote (almost a year ago):
Last week I had a personal hackathon since I couldn't make it out to 
ApacheCon. As a result there is now a C-language unit test suite 
available in branches/httpdunit (based on trunk). I've tested it with 
a Windows+CMake toolchain as well as an Ubuntu+autoconf toolchain.


The suite itself is based on Check, which is a testing library I've 
had some success with in the past. It's supported on a wide variety 
of platforms and has a nice feature of running each test in a 
separate process space, so a crash doesn't derail the entire suite. 
(Note: Check is LGPL.) The build system has been augmented slightly 
to generate some of the more tedious boilerplate code.


If you want to give it a try, just install Check (and, if using the 
configure scripts, make sure Check is visible via pkg-config). The 
test suite will then automatically be added to the default targets. 
Once everything builds you just run the suite directly with


 $ ./test/httpdunit

As a Check binary, it has multiple knobs to control which tests run 
and how the reporting is done, but by default it just runs all the 
tests and prints TAP to stdout.


The example tests that are currently running are testing a new API 
for strict Base64 decoding. Right now it's a feature without a 
client; I included it here because it was a good showcase of the test 
suite (see test/unit/base64.c for the test case code).


Let me know what you think!


I totally like the idea of having unit tests for httpd, so thanks a 
lot for adding them!


I recently struggled compiling trunk locally on Debian 9.4 because of 
these unit tests. Apparently it fails to link test/httpdunit because 
of undefined references to ap_queue_info_push_pool and other symbols. 
See the attached build log for more details.


Does anybody have an idea what went wrong? Am I missing something?
How does buildbot build?

Best regards,
Micha

Hi,
did you try to make a 'make clean'?
As explained in another message, 'test/httpdunit' is built if the 
'check' library is found on the system. However, the .o files don't seem 
to be updated when the code of httpd is updated. So the (previous) .o 
files could have references to some functions that do not exists any more.


Could you please try to 'make clean' and 'make' to see if you still have 
the build issue?


CJ

Re: Experimental C unit test suite available for hacking

[Marion et Christophe JAILLET]

Le 23/05/2018 à 16:14, Micha Lenk a écrit :

Hi Eric,

On 05/23/2018 02:59 PM, Eric Covener wrote:
I guess the CI setup needs to be updated to at least build the unit 
tests?


I did not configure the build explicitly to run the unit tests, so it 
is just the plain "make" that causes this target to get build. I would 
expect the CI setup to implicitly build it as well. Yes, no?!


Does the target 'test/httpdunit' not get build in your local builds?

Cheers,
Micha Lenk


'test/httpdunit' is always built in my dev machine.

This is added automatically to the 'other_target' if the 'check' library 
(>= version 0.9.12) is found on the system at configuration time.

CJ

Re: Experimental C unit test suite available for hacking

[Marion et Christophe JAILLET]

Le 23/05/2018 à 16:21, Joe Orton a écrit :

On Wed, May 23, 2018 at 04:14:39PM +0200, Micha Lenk wrote:

Hi Eric,

On 05/23/2018 02:59 PM, Eric Covener wrote:

I guess the CI setup needs to be updated to at least build the unit tests?

I did not configure the build explicitly to run the unit tests, so it is
just the plain "make" that causes this target to get build. I would expect
the CI setup to implicitly build it as well. Yes, no?!

Does the target 'test/httpdunit' not get build in your local builds?

It should only get built if you configure --with-test-suite=... and
specify the path to a perl-framework wc.  It builds for me in trunk.

Regards, Joe


Hi,

'--with-test-suite=...' is for the Perl test framework, not for the 
'test/httpdunit'.
'test/httpdunit' is designed for unit tests, written in C, and is included in 
trunk.

Up to now, there is not that much in it, but at least a framework is available.

CJ

Re: A proposal...

[Marion et Christophe JAILLET]

Le 24/04/2018 à 19:58, Daniel Ruggeri a écrit :
One thing you mention above is "wait for a new minor release". I can 
definitely see that being an issue for our current maj.minor layout 
given that minor bumps are measured in years. In this proposal, unless 
there's a pressing need to send out a patch release right now, the 
next version WOULD be that minor bump. Put into practice, I would see 
major bumps being measured in years, minor bumps in quarters and patch 
bumps in weeks/months.

I think the same.
But we should be clear on how long we maintain each version and the 
effort needed for that.


How long does we backport bug fixes?
How long does we fix security issues?
Should we also need some kind of LTS version? If yes, how to choose 
them? M.0.0 version? In an unpredictable way as Linux does, "when it's 
time for it"? On a timely basis as Ubuntu does?


2.2 vs 2.4 was already not that active in the last months/years of 2.2, 
as already discussed in the list.
I'm a bit reluctant to backport things in, let say, 4 minors branches 
because we maintain them for 1 year (4 quarters) + 1 or maybe even 2 LTS 
branches!
To dare to go this way, either me need much more man power (and I'm 
please to see many names active on the list these days), or we should 
avoid writing bugs, so we don't have to maintain fix for them :)


CJ

Re: A proposal...

[Marion et Christophe JAILLET]

As express by others, please don't !

IMHO, ONE language/framework is all what we need. Having a set of 
unrelated materials will bring nightmares and something hard, not to say 
impossible, to maintain/understand.


So we should keep it as-is, or switch to something new. But trying to 
please every-one is not the right way to go.
Even if the existing framework looks hard to me, I still think that it 
is a good option. Others have been able to extend the base, so it is 
possible :)


CJ

Le 24/04/2018 à 14:50, Jim Jagielski a écrit :

One idea is that we setup, using the existing perl test framework, a sort of "catch 
all" test, where the framework simply runs all scripts from a subdir via system() 
(or whatever), and the reports success or failure. Those scripts could be written in 
anything. This would mean that people could add tests w/o knowing any Perl at all. It 
would require, however, some sort of process since those scripts themselves would need to 
be universal enough that all testers can run them.

I may give that a whirl... I have some nodejs scripts that test websockets and I may see 
how/if I can "wrap" them within the test framework.

Re: A proposal...

[Marion et Christophe JAILLET]

Le 23/04/2018 à 23:09, Mark Blackman a écrit :




On 23 Apr 2018, at 19:17, Christophe Jaillet  
wrote:

Le 23/04/2018 à 16:00, Jim Jagielski a écrit :

It seems that, IMO, if there was not so much concern about "regressions" in 
releases, this whole revisit-versioning debate would not have come up. This implies, to 
me at least, that the root cause (as I've said before) appears to be one related to QA 
and testing more than anything. Unless we address this, then nothing else really matters.
We have a test framework. The questions are:
  1. Are we using it?
  2. Are we using it sufficiently well?
  3. If not, what can we do to improve that?
  4. Can we supplement/replace it w/ other frameworks?
It does seem to me that each time we patch something, there should be a test 
added or extended which covers that bug. We have gotten lax in that. Same for 
features. And the more substantial the change (ie, the more core code it 
touches, or the more it refactors something), the more we should envision what 
tests can be in place which ensure nothing breaks.
In other words: nothing backported unless it also involves some changes to the 
Perl test framework or some pretty convincing reasons why it's not required.


Hi,
+1000 on my side for more tests.

But, IMHO, the perl framework is complex to understand for most of us.


Do you believe the Perl element is contributing to the complexity? I’d say Perl 
is perfect for this case in general, although I would have to look at it first 
to confirm.


For my personal case, Yes, I consider that the Perl syntax itself is 
complex and/or tricky. That is certainly because I've never worked that 
much with it.
I think that this can limit the number of people who can increase our 
test coverage.




I certainly believe adequate testing is a bigger and more important problem to 
solve than versioning policies, although some versioning policies might make it 
simpler to allow enough time for decent testing to happen. I personally have a 
stronger incentive to help with testing, than I do with versioning policies.

- Mark

Re: Expanding httpd adoption internationally - POC

[Marion et Christophe JAILLET]

Le 24/04/2018 à 02:58, William A Rowe Jr a écrit :

On Thu, Apr 19, 2018 at 12:20 AM, Marion et Christophe JAILLET
<christophe.jail...@wanadoo.fr> wrote:

Le 18/04/2018 à 22:12, William A Rowe Jr a écrit :

On Wed, Apr 18, 2018 at 2:31 PM, Nick Kew <n...@apache.org> wrote:

I suspect the straightforward way to do this, in 2.6/3.0, will be to add
an
i18n table of the error log strings extracted from and indexed by those
APLOGNO() entries. No match? Default English message.

Please, not without an overhaul of APLOGNO to automate it a lot better!
The time to devise your error message is when coding an original
ap_log_*error, not retrospectively once a number has been generated!

++1

This could be achieved easily by just adding in 'log_error_core()':
(+ a few lines to initialize gettext in main() + a few lines to get a pool
in 'log_error_core()' (i.e. p below))

 /* Check if we have a leading AHn: header */
 if (p &&
 fmt[0] == 'A' &&
 fmt[1] == 'H' &&
 apr_isdigit(fmt[2]) &&
 apr_isdigit(fmt[3]) &&
 apr_isdigit(fmt[4]) &&
 apr_isdigit(fmt[5]) &&
 apr_isdigit(fmt[6]) &&
 fmt[7] == ':' &&
 fmt[8] == ' ') {
 const char *tmp;

 /* Get the translation of the message itself */
 tmp = gettext([9]);

 /* Rewrite the format string with the translated message */
 fmt = apr_pstrcat(p, apr_pstrmemdup(p, fmt, 9), tmp, NULL);
 printf("tmp: %s\n", fmt);
 }

That's all.
If interested by this approach, I can give a full working patch.

While we are unconcerned whether build tooling is GPL, we are very concerned
that we retain license and copyright of that output, and that linking system GPL
code does not alter our license.

As a GPL toolchain and call, this seems to require additional research.

If the tooling is clean and the gettext() call is not, then I could
fully support
following GPL gettext conversion file conventions in any custom code we create.

I'm not really a license man, but as far as I understand, the gettext 
library itself is LGPL, not GPL 
(https://www.gnu.org/software/gettext/manual/html_node/Licenses.html). I 
suppose that this is fine with the Apache license (but once again, I'm 
not a license man...)


CJ

Re: Expanding httpd adoption internationally - POC

[Marion et Christophe JAILLET]

Le 18/04/2018 à 22:12, William A Rowe Jr a écrit :

On Wed, Apr 18, 2018 at 2:31 PM, Nick Kew  wrote:

I suspect the straightforward way to do this, in 2.6/3.0, will be to add an
i18n table of the error log strings extracted from and indexed by those
APLOGNO() entries. No match? Default English message.

Please, not without an overhaul of APLOGNO to automate it a lot better!
The time to devise your error message is when coding an original
ap_log_*error, not retrospectively once a number has been generated!

++1

This could be achieved easily by just adding in 'log_error_core()':
(+ a few lines to initialize gettext in main() + a few lines to get a 
pool in 'log_error_core()' (i.e. p below))


    /* Check if we have a leading AHn: header */
    if (p &&
    fmt[0] == 'A' &&
    fmt[1] == 'H' &&
    apr_isdigit(fmt[2]) &&
    apr_isdigit(fmt[3]) &&
    apr_isdigit(fmt[4]) &&
    apr_isdigit(fmt[5]) &&
    apr_isdigit(fmt[6]) &&
    fmt[7] == ':' &&
    fmt[8] == ' ') {
    const char *tmp;

    /* Get the translation of the message itself */
    tmp = gettext([9]);

    /* Rewrite the format string with the translated message */
    fmt = apr_pstrcat(p, apr_pstrmemdup(p, fmt, 9), tmp, NULL);
    printf("tmp: %s\n", fmt);
    }

That's all.
If interested by this approach, I can give a full working patch.

the po file can then be generated with things like:
   xgettext server/core.c -kap_log_error:5

This could be a good starting point which does not need to refactor 
everything, at the cost of some cycles and some additional memory.



In fact, it would call for a refactoring of the entire ap_log framework
away from printf-style format strings and vars, that’ll inevitably give rise
to a whole new level of awkwardness.  Which seems like a very bad
effort-to-gain ratio.  -1 to embarking on this, unless you want to
create a new experimental branch to play in.

I agree this is not a trivial change. There are specific risks of corrupting
one language's %tokens in a way that segfaults the runtime (switch any
%d for a %s and boom.) The resulting table is absolutely a root admin's
directive, must not be manipulated by any other than root.


If using gettext, there are some tools to check for that.

CJ

Re: "Most Popular Web Server?"

[Marion et Christophe JAILLET]

Le 18/04/2018 à 21:00, Luca Toscano a écrit :


Before joining the httpd project as contributor I struggled to find 
good technical sources about how the httpd internals work, especially 
when it comes to important bits like mpm-event and how its 
architecture can be compared with other products. One of my first 
tasks was to improve the mpm-event's documentation page, and it took 
me a ton of time to understand a very high level overview of it (plus 
a lot of people patiently tried to explain to me how things were 
working). Without good "authoritative" references a lot of people can 
write whatever they want on httpd, because there are too few people 
that can scan the web and discuss inaccuracies (https://xkcd.com/386).


I keep struggling with internals in these days, even if I check 
httpd's code daily, so I can't imagine somebody not involved in the 
project that tries to make a comparison between httpd and product X, 
when the latter has a ton of good explanation about how it works in 
detail (most of the times with a lot of really explicative graphics 
attached).


My point is: blogging is fine, but before even starting that I'd focus 
on dumping everybody's knowledge in sections of the docs like 
http://httpd.apache.org/docs/trunk/developer 
. It is boring and less 
fun than writing C code for sure, but I bet that a ton of people would 
enjoy details about how things work. It will be easier for people to 
spot "liars" in the web that focus their marketing strategy only on 
how httpd is "old" and not performant too..



+1

There are some books around about these internals. Some can be 
downloaded in pdf.
I also from time to time give a look at 
http://www.fmc-modeling.org/category/projects/apache/amp/Apache_Modeling_Project.html 
which gives a nice overview, which I hope, is still correct.


CJ

Re: Expanding httpd adoption internationally

[Marion et Christophe JAILLET]

Le 18/04/2018 à 20:00, William A Rowe Jr a écrit :

I'm speaking of personal i18n experience as a Windows developer, and
assigning support for Cyrillic-based languages in nginx that I've presumed
exist (I've never researched the software but am familiar with the origins.)

[...]

In short, we demand admins read their httpd error log in English, even
where the underlying cause has been rendered in their local language
by the underlying operating system. (OS error messaging falls apart in
mass hosting where readers of different languages are hosted on the
same box, but that's an unusual situation, based on mass-vhoster
marketing alone.)

Localizing our error messages alone would go a long ways to being
friendly to non-english speaking administrators. If we don't want to
bother, we can expect for our software to be further marginalized.
you mean something like instrumenting our logging functions and use, for 
example, gettext as a translation mechanism?


As an example on 1 file, with one logging function, something like:
   xgettext server/core.c -kap_log_error:5 -o -
With this example, APLOGNO() are swallowed, because xgettext is not 
aware of the stringizing done in APLOGNO(), but we could try to find a 
way to deal with it.


CJ

Re: svn commit: r1828883 - /httpd/httpd/branches/2.4.x/

[Marion et Christophe JAILLET]

Trying before proposing is always a good practice.

   svn merge --dry-run 

can help in this situation.

 

CJ

 

> Message du 11/04/18 11:25
> De : "Yann Ylavic" 
> A : "httpd-dev" 
> Copie à : 
> Objet : Re: svn commit: r1828883 - /httpd/httpd/branches/2.4.x/
> 
> It happens when trying to do the real merge before proposing ;)
> 
> On Wed, Apr 11, 2018 at 11:18 AM, ste...@eissing.org  wrote:
> > urgs, sorry.
> >
> >> Am 11.04.2018 um 11:16 schrieb yla...@apache.org:
> >>
> >> Author: ylavic
> >> Date: Wed Apr 11 09:16:56 2018
> >> New Revision: 1828883
> >>
> >> URL: http://svn.apache.org/viewvc?rev=1828883=rev
> >> Log:
> >> Revert r1828882's mergeinfo.
> >>
> >> Modified:
> >> httpd/httpd/branches/2.4.x/ (props changed)
> >>
> >> Propchange: httpd/httpd/branches/2.4.x/
> >> --
> >> --- svn:mergeinfo (original)
> >> +++ svn:mergeinfo Wed Apr 11 09:16:56 2018
> >> @@ -8,4 +8,4 @@
> >> /httpd/httpd/branches/trunk-md:1804087-1804529
> >> /httpd/httpd/branches/trunk-override-index:1793921-1793931
> >> /httpd/httpd/branches/wombat-integration:723609-723841
> >> -/httpd/httpd/trunk:1200475,1200478,1200482,1200491,1200496,1200513,1200550,1200556,1200580,1200605,1200612,1200614,1200639,1200646,1200656,1200667,1200679,1200699,1200702,1200955,1200957,1200961,1200963,1200968,1200975,1200977,1201032,1201042,120,1201194,1201198,1201202,1201443,1201450,1201460,1201956,1202236,1202453,1202456,1202886,1203400,1203491,1203632,1203714,1203859,1203980,1204630,1204968,1204990,1205061,1205075,1205379,1205885,1206291,1206472,1206587,1206850,1206940,1206978,1207719,1208753,1208835,1209053,1209085,1209417,1209432,1209461,1209601,1209603,1209618,1209623,1209741,1209754,1209766,1209776,1209797-1209798,1209811-1209812,1209814,1209908,1209910,1209913,1209916-1209917,1209947,1209952,1210067,1210080,1210120,1210124,1210130,1210148,1210219,1210221,1210252,1210284,1210336,1210378,1210725,1210892,1210951,1210954,1211351-1211352,1211364,1211490,1211495,1211528,1211663,1211680,1212872,1212883,1213338,1213380-1213381,1213391,1213399,1213567,1214003,1214005,1214015,12
> >> 15514,1220462,1220467,1220493,1220524,1220570,1220768,1220794,1220826,1220846,1221205,1221292,1222335,1222370,1222473,1222915,1222917,1222921,1222930,1223048,1225060,1225197-1225199,1225223,1225380,1225476,1225478,1225791,1225795-1225796,1226339,1226375,1227910,1228700,1228816,1229024,1229059,1229099,1229116,1229134,1229136,1229930,1230286,1231255,1231257,1231442,1231446,1231508,1231510,1231518,1232575,1232594,1232630,1232838,1234180,1234297,1234479,1234511,1234565,1234574,1234642-1234643,1234876,1234899,1235019,1236122,1236701,1237407,1238545,1238768,1239029-1239030,1239071,1239565,1240315,1240470,1240778,1241069,1241071,1242089,1242798,1242967,1243176,1243246,1243797,1243799,1244211,1245717,1290823,1290835,1291819-1291820,1291834,1291840,1292043,1293405,1293534-1293535,1293658,1293678,1293708,1294306,1294349,1294356,1294358,1294372,1294471,1297560,1299718,1299786,1300766,130,1301725,1302444,1302483,1302653,1302665,1302674,1303201,1303435,1303827,1304087,1304874-1304875,1305167
> >> ,1305586,1306350,1306409,1306426,1306841,1307790,1308327,1308459,1309536,1309567,1311468,1324760,1325218,1325227,1325250,1325265,1325275,1325632,1325724,1326980,1326984,1326991,1327689,1328325-1328326,1328339,1328345,1328950,1330189,1330964,1331110,1331115,1331942,1331977,1332378,1333969,1334343,1335882,1337344,1341906,1341913,1343085,1343087,1343094,1343099,1343109,1343935,1345319,1345329,1346905,1347980,1348036,1348653,1348656,1348660,1349905,1351012-1351020,1351071-1351072,1351074,1351737,1352047,1352534,1352909-1352912,1357685,1358061,1359057,1359881,1359884,1361153,1361298,1361766,1361773,1361778,1361784,1361791-1361792,1361801,1361803,1362020,1362538,1362707,1363035,1363183,1363186,1363312,1363440,1363557,1363589,1363829,1363832,1363836-1363837,1363853,1364133,1364138,1364229,1364601,1364695,1365001,1365020,1365029,1365479,1366319,1366344,1366621,1367778,1367819,1368053,1368058,1368094,1368121,1368131,1368393,1368396,1369419,1369568,1369604,1369618,1369904,1369995,136,1370
> >> 

Re: Question about RemoteIPInternalProxyList (PR 62220)

[Marion et Christophe JAILLET]

Le 06/04/2018 à 20:23, Eric Covener a écrit :

On Fri, Apr 6, 2018 at 2:10 PM, Christophe Jaillet
 wrote:

Hi list,

I'm working on PR 62220 and I don't understand what could cause the reported
regression.

Apparently the behavior of RemoteIPInternalProxyList has changed in 2.4.33.
But RemoteIPInternalProxy (without List) still works as expected.

Looking at the implementation of the 2 directives, RemoteIPInternalProxyList
is equivalent to several RemoteIPInternalProxy directives. So why one should
stop working and not the other?

After some debugging, it appeared that removing the EXEC_ON_READ from
RemoteIPInternalProxyList makes it work as expected again.

My question are:
   - why is RemoteIPInternalProxyList defined with EXEC_ON_READ? This makes
nearly no cense so me.

I guess it makes some sense in that it is acting almost like an
"Include", so I don't think it's a copy/paste kind of thing.


   - BUT if removing it is the solution, why was it working before???

is it broken w/o vhosts? I am not sure cmd->server is right for
EXEC_ON_READ?  Maybe something in this neighborhood?


Hi,
at least the 'config' used in 'proxies_set()' is not the same when 
parsing RemoteIPInternalProxyList  and RemoteIPInternalProxy directives.

And yes, according to my test, it seems to work without vhosts.

CJ

Re: svn commit: r1827719 - /httpd/site/trunk/content/download.mdtext

[Marion et Christophe JAILLET]

Le 25/03/2018 à 16:37, jaillet...@apache.org a écrit :

Author: jailletc36
Date: Sun Mar 25 14:37:13 2018
New Revision: 1827719

URL: http://svn.apache.org/viewvc?rev=1827719=rev
Log:
Update download page to 2.4.33

Modified:
 httpd/site/trunk/content/download.mdtext

Modified: httpd/site/trunk/content/download.mdtext
URL: 
http://svn.apache.org/viewvc/httpd/site/trunk/content/download.mdtext?rev=1827719=1827718=1827719=diff
[...]
  
-- httpd-2.4.29.tar.* are signed by Jim Jagielski `791485A8`

+- httpd-2.4.33.tar.* are signed by Daniel Ruggeri `?`
  
[...]

I've not been able to sort out what was needed here.
I've not found Daniel in the KEYS file.

CJ

Re: Question about 'RegexDefaultOptions'

[Marion et Christophe JAILLET]

Le 23/03/2018 à 22:14, Yann Ylavic a écrit :

So I propose that we don't document EXTENDED for RegexDefaultOptions
for now (and definitely never in 2.4.x), AP_REG_EXTENDED needs more
work in trunk before it becomes meaningful.

+1

Thanks Christophe for noticing and trying to take care of this mess (mine).
Improvement of my first documentation update for RegexDefaultOptions is 
welcome :)


CJ

re: svn commit: r1774014 - /httpd/httpd/branches/2.4.x/STATUS

[Marion et Christophe JAILLET]

Hi,

 

I can't send a patch because I'm on travel, but there is a minor issue with 
r1768245.

I think that  should be 
or 
.

 

I thought I had sent a patch for it, but can find it in SVN history.

Maybe, I forgot to commit, or it was for another similar issue in another file.

 

CJ

 

 

> 
> > -
> + *) mod_socache_memcache: Provide memcache STATs to mod_status
> + trunk patch: http://svn.apache.org/r1768245
> + trunk patch: http://svn.apache.org/r1770828
> + 2.4.x patch: trunk works
> + +1: jim, icing, covener
> >

Re: Question about mod_sed

[Marion et Christophe JAILLET]

Hi,

 

The code in trunk and 2.4 don't have the 3 last lines:

   memcpy(eval->gspend, sz, len + 1);
   /* hspend will now point to NULL character */
   eval->gspend += len;

 

See:

   
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/filters/sed1.c?revision=1326984=markup#l231

 

 

The code in my first post is what I think is correct. 

Sorry for not being clear.

 

CJ

> Message du 17/06/16 12:00
> De : "Ruediger Pluem" 
> A : dev@httpd.apache.org
> Copie à : 
> Objet : Re: Question about mod_sed
> 
> 
> 
> On 06/16/2016 10:33 PM, Christophe JAILLET wrote:
> > Hi,
> > 
> > 
> > I'm not familiar with sed implementation, but 'copy_to_genbuf' looks 
> > spurious.
> > 
> > Actually it only expands a buffer if some space is needed, but nothing is 
> > copied.
> > 
> > 
> > Should it look like:
> > 
> > static void copy_to_genbuf(sed_eval_t *eval, const char* sz)
> > {
> > int len = strlen(sz);
> > unsigned int reqsize = len + 1;
> > if (eval->gsize < reqsize) {
> > grow_gen_buffer(eval, reqsize, NULL);
> > }
> > memcpy(eval->gspend, sz, len + 1);
> 
> The above does a copy, or do I miss your point?
> 
> > /* hspend will now point to NULL character */
> > eval->gspend += len;
> > }
> 
> Regards
> 
> Rüdiger
>

re: svn commit: r1712294 - in /httpd/httpd/branches/2.4.x: ./ CHANGES STATUS server/scoreboard.c

[Marion et Christophe JAILLET]

 

 

 

 

 

> Message du 03/11/15 14:31
> De : minf...@apache.org
> A : c...@httpd.apache.org
> Copie à : 
> Objet : svn commit: r1712294 - in /httpd/httpd/branches/2.4.x: ./ CHANGES 
> STATUS server/scoreboard.c
> 
> Author: minfrin
> Date: Tue Nov 3 13:31:28 2015
> New Revision: 1712294
> 
> URL: http://svn.apache.org/viewvc?rev=1712294=rev
> Log:
> core: Fix scoreboard crash (SIGBUS) on hardware requiring strict 64bit
> alignment (SPARC64, PPC64).
> Submitted by: ylavic
> Reviewed by: jim, minfrin
> 
[...]
> Modified: httpd/httpd/branches/2.4.x/server/scoreboard.c
> URL: 
> http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/server/scoreboard.c?rev=1712294=1712293=1712294=diff
> ==
> --- httpd/httpd/branches/2.4.x/server/scoreboard.c (original)
> +++ httpd/httpd/branches/2.4.x/server/scoreboard.c Tue Nov 3 13:31:28 2015
> @@ -129,14 +129,19 @@ static apr_status_t ap_cleanup_shared_me
> return APR_SUCCESS;
> }
> 
> +#define SIZE_OF_scoreboard APR_ALIGN_DEFAULT(sizeof(scoreboard))
> +#define SIZE_OF_global_score APR_ALIGN_DEFAULT(sizeof(global_score))
> +#define SIZE_OF_process_score APR_ALIGN_DEFAULT(sizeof(process_score))
> +#define SIZE_OF_worker_score APR_ALIGN_DEFAULT(sizeof(worker_score))
> +
> AP_DECLARE(int) ap_calc_scoreboard_size(void)
> {
> ap_mpm_query(AP_MPMQ_HARD_LIMIT_THREADS, _limit);
> ap_mpm_query(AP_MPMQ_HARD_LIMIT_DAEMONS, _limit);
> 
> - scoreboard_size = sizeof(global_score);
> - scoreboard_size += sizeof(process_score) * server_limit;
> - scoreboard_size += sizeof(worker_score) * server_limit * thread_limit;
> + scoreboard_size = SIZE_OF_global_score;
> + scoreboard_size += SIZE_OF_process_score * server_limit;
> + scoreboard_size += SIZE_OF_worker_score * server_limit * thread_limit;
> 
> return scoreboard_size;
> }
> @@ -153,17 +158,17 @@ AP_DECLARE(void) ap_init_scoreboard(void
> 
> ap_calc_scoreboard_size();
> ap_scoreboard_image =
> - ap_calloc(1, sizeof(scoreboard) + server_limit * sizeof(worker_score *));
> + ap_calloc(1, SIZE_OF_scoreboard + server_limit * sizeof(worker_score *));
Should this also be SIZE_OF_worker_score also here ?

 

Best regards,

CJ

re: svn commit: r1712294 - in /httpd/httpd/branches/2.4.x: ./ CHANGES STATUS server/scoreboard.c

[Marion et Christophe JAILLET]

> Message du 03/11/15 15:38
> De : "Marion et Christophe JAILLET" 
> A : dev@httpd.apache.org
> Copie à : 
> Objet : re: svn commit: r1712294 - in /httpd/httpd/branches/2.4.x: ./ CHANGES 
> STATUS server/scoreboard.c
> 
>
>  

>  

>  

>  

>  

> Message du 03/11/15 14:31
> De : minf...@apache.org
> A : c...@httpd.apache.org
> Copie à : 
> Objet : svn commit: r1712294 - in /httpd/httpd/branches/2.4.x: ./ CHANGES 
> STATUS server/scoreboard.c
> 
> Author: minfrin
> Date: Tue Nov 3 13:31:28 2015
> New Revision: 1712294
> 
> URL: http://svn.apache.org/viewvc?rev=1712294=rev
> Log:
> core: Fix scoreboard crash (SIGBUS) on hardware requiring strict 64bit
> alignment (SPARC64, PPC64).
> Submitted by: ylavic
> Reviewed by: jim, minfrin
> 
[...]
> Modified: httpd/httpd/branches/2.4.x/server/scoreboard.c
> URL: 
> http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/server/scoreboard.c?rev=1712294=1712293=1712294=diff
> ==
> --- httpd/httpd/branches/2.4.x/server/scoreboard.c (original)
> +++ httpd/httpd/branches/2.4.x/server/scoreboard.c Tue Nov 3 13:31:28 2015
> @@ -129,14 +129,19 @@ static apr_status_t ap_cleanup_shared_me
> return APR_SUCCESS;
> }
> 
> +#define SIZE_OF_scoreboard APR_ALIGN_DEFAULT(sizeof(scoreboard))
> +#define SIZE_OF_global_score APR_ALIGN_DEFAULT(sizeof(global_score))
> +#define SIZE_OF_process_score APR_ALIGN_DEFAULT(sizeof(process_score))
> +#define SIZE_OF_worker_score APR_ALIGN_DEFAULT(sizeof(worker_score))
> +
> AP_DECLARE(int) ap_calc_scoreboard_size(void)
> {
> ap_mpm_query(AP_MPMQ_HARD_LIMIT_THREADS, _limit);
> ap_mpm_query(AP_MPMQ_HARD_LIMIT_DAEMONS, _limit);
> 
> - scoreboard_size = sizeof(global_score);
> - scoreboard_size += sizeof(process_score) * server_limit;
> - scoreboard_size += sizeof(worker_score) * server_limit * thread_limit;
> + scoreboard_size = SIZE_OF_global_score;
> + scoreboard_size += SIZE_OF_process_score * server_limit;
> + scoreboard_size += SIZE_OF_worker_score * server_limit * thread_limit;
> 
> return scoreboard_size;
> }
> @@ -153,17 +158,17 @@ AP_DECLARE(void) ap_init_scoreboard(void
> 
> ap_calc_scoreboard_size();
> ap_scoreboard_image =
> - ap_calloc(1, sizeof(scoreboard) + server_limit * sizeof(worker_score *));
> + ap_calloc(1, SIZE_OF_scoreboard + server_limit * sizeof(worker_score *));
> Should this also be SIZE_OF_worker_score also here ?

>  

> Best regards,

> CJ


 

Forget it, "sizeof(worker_score *)" is not "sizeof(worker_score)"

Sorry for the noise.

 

CJ

Re: svn commit: r1598946 - in /httpd/httpd/trunk: CHANGES modules/proxy/mod_proxy_fdpass.c

[Marion et Christophe JAILLET]

Hi,

 

obviously, no problem for me for merging the 2 in the same proposal.

I'll have a look at it tonight.


CJ



 Message du 17/06/14 10:02
 De : Yann Ylavic 
 A : jaillet...@apache.org, httpd 
 Copie à : 
 Objet : Re: svn commit: r1598946 - in /httpd/httpd/trunk: CHANGES 
 modules/proxy/mod_proxy_fdpass.c
 
 Christophe,
 
 do you agree if I modify the 2.4.x proposal with :
 
 Index: STATUS
 ===
 --- STATUS (revision 1603074)
 +++ STATUS (working copy)
 @@ -224,12 +224,14 @@
 2.4.x patch: trunk works (modulo CHANGES)
 +1: ylavic
 
 - * mod_proxy_fdpass: Fix computation of the size of 'struct sockaddr_un'
 - when passed to 'connec()'.
 - [Graham Dumpleton ]
 + * mod_proxy: Don't limit the size of the connectable Unix Domain
 Socket paths.
 + [Graham Dumpleton , Christophe Jaillet,
 + Yann Ylavic]
 trunk patch: http://svn.apache.org/r1598946
 - 2.4.x patch: trunk works (modulo CHANGES)
 - +1: jailletc36
 + http://svn.apache.org/r1602989
 + 2.4.x patch:
 http://people.apache.org/~ylavic/httpd-2.4.x-ap_proxy_connect_uds.patch
 + (modulo CHANGES/MMN)
 + +1: ylavic
 
 since both commits seem to address the same concern?
 Or should I add a new one?
 
 Please note you would have to re-vote.
 
 Regards,
 Yann.

Re: [PATCH ASF bugzilla# 55897]prefork_mpm patch with SO_REUSEPORT support

[Marion et Christophe JAILLET]

Hi,

 

see http://httpd.apache.org/lists.html#http-dev

You should just send a mail to  dev-unsubscr...@httpd.apache.org.

 

best regards,

 

CJ





 Message du 02/06/14 16:16
 De : Mihai Iacob 
 A : dev@httpd.apache.org
 Copie à : 
 Objet : Re: [PATCH ASF bugzilla# 55897]prefork_mpm patch with SO_REUSEPORT 
 support
 

 How do I unsubscribe from this list ?
 
 Regards,
 Mihai Iacob
 DB2 Security Development
 DB2 pureScale Development
 Phone: (905) 413-5378
 Email: mia...@ca.ibm.com

Re: UDS Patch

[Marion et Christophe JAILLET]

Hi,

 

one of my thought was the change from

   worker-s-name

to

   ap_proxy_worker_name(r-pool, worker)

in logging function.

ap_proxy_worker_name allocates memory in the pool and performs some operations 
on strings (apr_pstrcat).

 

These operations are performed in all cases, even if DEBUG messages are not 
logged.

 

I don't think this should have a real effect on performance. (If I remember 
well when I looked at it, there is no ap_log_error calls in sensitive code)

Just to be sure, you could try to simplify ap_proxy_worker_name in Daniel's 
build to remove the apr_pstrcat and check performance with his build.

 

Should you and Daniel have different logging levels, it could explain why you 
don't measure the same discrepancy.

 

 

Just my 2 cents.

If I have time, I'll give another look tonight.

 

CJ





 Message du 02/12/13 13:46
 De : Jim Jagielski 
 A : dev@httpd.apache.org
 Copie à : 
 Objet : Re: UDS Patch
 
 OK, I can't by inspection or by test see any performance
 differences between the 2 implementations (in fact,
 the older one, in some benchmarks, was slower due to
 the string operations in the critical path)...
 
 Any ideas?
 
 On Nov 26, 2013, at 4:23 PM, Jim Jagielski wrote:
 
  Thx... the key is httpd-2.4.6-uds-delta.patch and
  that shows nothing, that I can see, which would
  result in the old being faster than the new...
  especially in the critical section where we do
  the apr_sockaddr_info_get() stuff...
  
  On Nov 26, 2013, at 3:07 PM, Daniel Ruggeri wrote:
  
  I reapplied the patches in order to 2.4.6 before r1531340 was added to
  the proposal. Attached are the three diff's of use:
  httpd-2.4.6-uds-original.patch - Everything in the backport proposal up
  to (but not including) r1531340 sans the stuff that doesn't fit
  httpd-2.4.6-uds-new.patch - The 2.4 patch proposed with r1511313 applied
  first. Note that this doesn't include r1543174
  httpd-2.4.6-uds-delta.patch - The delta between the two modified trees
  
  --
  Daniel Ruggeri
  
  On 11/22/2013 5:27 PM, Daniel Ruggeri wrote:
  Sorry, I thought the diffs I sent off list were good enough. I'll have
  to see if I even still have the original build lying around.
  Effectively, I just took the list of patches in the backport proposal
  and applied them one at a time to the 2.4.6 sources. If I can't find the
  build, I'll do the same over and send that instead.
  
  --
  Daniel Ruggeri
  
  
  
 

re: ap_rgetline_core in protocol.c

[Marion et Christophe JAILLET]

Hi,

 

I wanted to have a look at 
http://prefetch.net/blog/index.php/2005/12/12/profiling-apache-modules-with-dtrace/

but had no time to look at it for now.

 

May it help you ?

 

 

Personnaly, I have activated the pool profiling functions in APR which give me 
information of what and from where is allocated memory using the pool mechanism.

After that, I had some printf debugging code to check more in detail what I 
want to see. (the sample i posted on the dev mailing list was created this way)

 

 

I was also planning to use the profiling functionality of gcc (-pg option) but 
didn't manage to have it work yet.

If someone has already used it, I'm really interesting.

Could also be interesting to have a configure option to control that.

 

 

 

Best regards.

CJ




 Message du 14/05/13 13:25
 De : kalyan sita 
 A : dev@httpd.apache.org
 Copie à : 
 Objet : ap_rgetline_core in protocol.c
 




Hi Chris,

 Can you please tell me in what way we can debug the ap_rgetline_core in 
protocol.c.

I would like to know how you are calling ap_rgetline_core in protocol.c.
 
 

Thanks in advance,

Kalyan