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

[Jim Jagielski]

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

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

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

[Jim Jagielski]

+1

> On Apr 4, 2024, at 5:43 AM, Ruediger Pluem  wrote:
> 
> 
> 
> On 4/3/24 4:32 PM, Joe Orton wrote:
>> On Tue, Apr 02, 2024 at 12:25:40PM +0200, Rainer Jung wrote:
>>> Hi there,
>>> 
>>> in the light of the recent xz attack I was wondering, whether we should also
>>> reduce our library dependencies by no longer using sd_notify() in
>>> mod_systemd (thus loading libsystemd and all of its dependencies), but
>>> instead taking the approach to hard code sd_notify functionality.
>>> 
>>> I guess the Linux distributors who patched sshd to use libsystemd for
>>> notification are on their way to do the same for their sshd patches, so we
>>> might soon get an idea how to do that properly.
>>> 
>>> This is not meant to become part of out next release (this week), but
>>> hopefully we can manage to code it for the next one.
>>> 
>>> WDYT: does this make sense?
>> 
>> The trunk mod_systemd has got slightly wider library use than just 
>> sd_notify - so it is not quite that simple. If there was an alternative 
>> minimal library implementing the sd_* API parts required, that would 
>> definitely make sense. I'm not sure that reimplementing them all from 
>> scratch makes sense (especially multiplied by N projects doing this).
>> 
> 
> +1
> 
>> It looks like systemd folks have also changed the library implementation 
>> to dlopen() the various dependant libraries on demand now rather than 
>> directly linking to them, which removes the specific attack vector used 
>> here IIUC.
> +1. Unless the systemd folks show that they are unwilling to address issues
> I would stay with libsystemd.
> 
> Regards
> 
> Rüdiger

Re: age in proxy_balancer_method

[Jim Jagielski]

Yeah, that sounds about right. I'd say that whatever changes need (or should 
be) made are fine

> On Dec 21, 2023, at 1:32 PM, Rainer Jung  wrote:
> 
> I guess it could be like this: when Mladen originally implemented the by 
> requests load balancing method in mod_jk he used the count and subtract 
> method for the counters. He then ported this to mod_proxy_balancer and I 
> think it is still, how by requests counting woorks there.
> 
> There are pros and cons, e.g. in case a worker goes down for some time. A bit 
> later we switched in mod_jk to a count and divide, where division by 2 was 
> done roughly every 60 seconds (configurable).
> 
> I think the idea of the age method was roughly, that you could implement a 
> balanvcer method, that registers a mod_watchdog task, that regularly ages the 
> balancing counters. Aging because you want to give the past a smaller 
> influence on the balancing decision than the more recent activity.
> 
> I hope that's understandable and maybe Jim remembers something similar to 
> that.
> 
> Best regards,
> 
> Rainer
> 
> Am 21.12.23 um 08:23 schrieb jean-frederic clere:
>> On 12/20/23 21:22, Jim Jagielski wrote:
>>> I'll have to go back through my notes... I do recall adding fields that 
>>> although
>>> were not being used at the time, were _going to be used_ as some point, and
>>> I didn't want to have to worry about ABI compatibility.
>> Cool I will wait before implementing something that breaks your design ;-)
>>> 
>>>> On Dec 14, 2023, at 8:27 AM, jean-frederic clere  wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> Any examples or docs about:
>>>> apr_status_t (*age)(proxy_balancer *balancer, server_rec *s);
>>>> 
>>>> In struct proxy_balancer_method?
>>>> 
>>>> -- 
>>>> Cheers
>>>> 
>>>> Jean-Frederic

Re: age in proxy_balancer_method

[Jim Jagielski]

I'll have to go back through my notes... I do recall adding fields that although
were not being used at the time, were _going to be used_ as some point, and
I didn't want to have to worry about ABI compatibility.

> On Dec 14, 2023, at 8:27 AM, jean-frederic clere  wrote:
> 
> Hi,
> 
> Any examples or docs about:
> apr_status_t (*age)(proxy_balancer *balancer, server_rec *s);
> 
> In struct proxy_balancer_method?
> 
> -- 
> Cheers
> 
> Jean-Frederic

Re: svn commit: r1912245 - in /httpd/httpd/trunk/modules/proxy: balancers/mod_lbmethod_bybusyness.c mod_proxy_balancer.c proxy_util.c proxy_util.h

[Jim Jagielski]

> On Nov 28, 2023, at 4:29 PM, Yann Ylavic  wrote:
> 
> On Fri, Nov 24, 2023 at 3:28 PM Ruediger Pluem  > wrote:
>> 
>> On 11/24/23 10:59 AM, Yann Ylavic wrote:
>>> On Thu, Nov 23, 2023 at 5:47 PM Ruediger Pluem  wrote:
 
 On 11/23/23 5:05 PM, Yann Ylavic wrote:
> On Thu, Nov 23, 2023 at 4:46 PM Yann Ylavic  wrote:
>> 
>> On Thu, Nov 23, 2023 at 4:17 PM Ruediger Pluem  wrote:
>>> 
>>> On 11/23/23 3:53 PM, Yann Ylavic wrote:
 
>>> I am asking because I guess I am hit now by races in the byrequests LB
>>> with the worker->s->lbstatus.
>>> I probably want to look for a way to solve this in a more generic way
>>> for various shared worker fields.
>> 
>> lbstatus is an int so the 32bit apr_atomic API could do I think.
> 
> I mean, if lbstatus becomes inconsistent because of the race then we
 
 My current theory is that this is the case.
 
> can do something, but if it is e.g. that a worker switches from error
> state to non-error become some threads can connect while some others
> can't this is something we should address elsewhere (like a failure
> threshold).
> 
>> Maybe we need some ap_atomic_{int,long,size_t,..}_*() helpers for
>> system dependent widths. It preferably would be implemented in APR but
>> in the meantime we could have something in httpd already.
>> What we should avoid IMO is needing 64bit atomics on 32bit systems
>> (because we'd have to reimplement the mutexes etc), but apart from
>> that I think we can wrap anything using the existing apr atomics.
> 
> What we need for lbstatus is ap_atomic_int_or() and
> ap_atomic_int_and_not() it seems, both could be implemented with a
> cas32 loop.
 
 What functionality are ap_atomic_int_or() / ap_atomic_int_and_not() are 
 supposed to deliver?
 I am having a hard time guessing it from the name :-).
>>> 
>>> Actually I mixed ->lbstatus and ->status, so I thought we needed an
>>> atomic "or" and an atomic "and not" to handle the ->status mask..
>>> 
>>> But ->lbstatus is much like the ->busy count and updated almost at the
>>> same place, though it's an "int" and we can't reuse the same functions
>>> for both :/
>>> It seems that we need to make sure that 0 <= lbstatus <= INT_MAX too,
>> 
>> I think lbstatus is allowed to become negative.
> 
> Tried something in https://github.com/apache/httpd/pull/396
> WDYT?

+1 for concept

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

[Jim Jagielski]

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

> On Aug 30, 2023, at 11:19 AM, jean-frederic clere  wrote:
> 
> Hi,
> 
> All the balancers have thread/process safe issues, but with bybusyness the 
> effect is worse, basically a worker may stay with a busy count greater than 
> zero even no request is being processed.
> 
> busy is displayed in the balancer_handler() so users/customers will notice 
> the value doesn't return to zero...
> 
> If you run a load test the value of busy will increase by time and in all the 
> workers
> 
> When using bybusyness, having pics in the load and later no much load makes 
> the lowest busy workers used and the ones with a wrong higher value not being 
> used.
> 
> In a test with 3 workers, I end with busy:
> worker1: 3
> worker2: 0
> worker3: 2
> Doing the load test several time the buys values are increasing in all 
> workers.
> 
> I am wondering is we could end with something like:
> worker1: 1000
> worker2: 0
> worker3: 1000
> 
> in this case bybusyness will send all the load to worker2 until we reach 1000 
> simultaneous request on worker2... Obvious that looks bad.
> 
> How to fix that?
> 1 - reset the busy using a watchdog and elected (or transferred+read) 
> unchanged for some time (using one of timeout we have on workers).
> 2 - warn in the docs that bybusyness is not the best choice for loadbalancing.
> 3 - create another balancer that just choose random a worker.
> 
> -- 
> Cheers
> 
> Jean-Frederic

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

[Jim Jagielski]

Isn't the call to find the best balancer mutex protected?

> On Aug 31, 2023, at 7:44 AM, jean-frederic clere  wrote:
> 
> On 8/30/23 17:33, Rainer Jung wrote:
>> Hi JFC,
>> I have not checked ur current code, but the topic reminds me of our history 
>> in mod_jk land. There we switched the counters to atomics were available. 
>> The other problematic part could be how to handle process local counters 
>> versus global counters.
> 
> Using apr_atomic_inc32()/apr_atomic_dec32 on apr_size_t busy won't work?
> Actual apr_size_t for busy is probably overkill does using apr_atomic_add64() 
> and apr_atomic_dec64() makes sense here?
> 
> Anyway I will give it a try.
> 
>> Busyness was especially problematic for mod_jk as well, because we never 
>> deremented below zero if we lost increments, but if we lost decrements the 
>> counters stayed elevated. I think there we now have no longer such problems.
>> Best regards,
>> Rainer
>> Am 30.08.23 um 17:19 schrieb jean-frederic clere:
>>> Hi,
>>> 
>>> All the balancers have thread/process safe issues, but with bybusyness the 
>>> effect is worse, basically a worker may stay with a busy count greater than 
>>> zero even no request is being processed.
>>> 
>>> busy is displayed in the balancer_handler() so users/customers will notice 
>>> the value doesn't return to zero...
>>> 
>>> If you run a load test the value of busy will increase by time and in all 
>>> the workers
>>> 
>>> When using bybusyness, having pics in the load and later no much load makes 
>>> the lowest busy workers used and the ones with a wrong higher value not 
>>> being used.
>>> 
>>> In a test with 3 workers, I end with busy:
>>> worker1: 3
>>> worker2: 0
>>> worker3: 2
>>> Doing the load test several time the buys values are increasing in all 
>>> workers.
>>> 
>>> I am wondering is we could end with something like:
>>> worker1: 1000
>>> worker2: 0
>>> worker3: 1000
>>> 
>>> in this case bybusyness will send all the load to worker2 until we reach 
>>> 1000 simultaneous request on worker2... Obvious that looks bad.
>>> 
>>> How to fix that?
>>> 1 - reset the busy using a watchdog and elected (or transferred+read) 
>>> unchanged for some time (using one of timeout we have on workers).
>>> 2 - warn in the docs that bybusyness is not the best choice for 
>>> loadbalancing.
>>> 3 - create another balancer that just choose random a worker.
> 
> -- 
> Cheers
> 
> Jean-Frederic

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

[Jim Jagielski]

> On May 4, 2023, at 4:34 AM, Ruediger Pluem  wrote:
> 
> This is a formal vote on whether we should move our read/write repository 
> from Subversion to Git.
> This means that our latest read/write repository will be no longer available 
> via svn.apache.org. It
> will be available via Git at 
> https://gitbox.apache.org/repos/asf/httpd-site.git and 
> https://github.com/apache/httpd.git.
> Github also offers the possibility to use a Subversion client:
> https://docs.github.com/en/get-started/working-with-subversion-on-github/support-for-subversion-clients
> 
> 
> [X]: Move the read/write repository from Subversion to Git and leverage the 
> features of Github (for now Actions and PR).
> [ ]: Move the read/write repository from Subversion to Git, but I don't want 
> to work with Github and I will only work with
> what gitbox.apache.org offers.
> [ ]: Leave everything as is.
> 

+1 for the move. "binding" if we are specifically noting votes from PMC members.

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

[Jim Jagielski]

> On Jan 10, 2023, at 8:40 AM, Eric Covener  wrote:
> 
> Hi all,
> 
> Please find below the proposed release tarball and signatures:
> 
> https://dist.apache.org/repos/dist/dev/httpd/
> 
> I would like to call a VOTE over the next few days to release
> this candidate tarball httpd-2.4.55-rc1 as 2.4.55:
> [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!

Tested:

  macOS 12.6.2 / Xcode 14.2
  Ubuntu 20.04LTS
  CentOS 7

Thanks for RMing.

Cheers!

Re: friends of mod_proxy

[Jim Jagielski]

+1

> On Oct 11, 2022, at 3:47 AM, Stefan Eissing via dev  
> wrote:
> 
> 
> 
>> Am 10.10.2022 um 20:39 schrieb Ruediger Pluem :
>> 
>> 
>> 
>> On 10/10/22 6:35 PM, Eric Covener wrote:
>>> On Mon, Oct 10, 2022 at 11:55 AM Yann Ylavic  wrote:
 
 On Fri, Oct 7, 2022 at 9:14 PM Ruediger Pluem  wrote:
> 
> On 10/7/22 7:11 PM, Stefan Eissing via dev wrote:
>> 
>> 
>>> Am 07.10.2022 um 18:45 schrieb Yann Ylavic :
>>> 
>> 
>> Thanks, Yann, for the detailed explanation on how this works and that 
>> the default does the right thing.
> 
> +1. I missed the default of not reusing the connection in these cases but 
> having the possibility to override it like the user did.
> But shouldn't we default to not reusing the connection in case of a $ 
> inside the port as well?
 
 We default to disabling connection reuse for any $ substitution
 already, the compat issue is for an explicit enablereuse=on which used
 to "work" because it was ignored..
 
 How about a patch like the attached one now, which disables connection
 reuse definitively (regardless of enablereuse) if there is a $
 substitution in the hostname or port part of the URL?
 The patch uses the existing "is_address_reusable" flag (set to false
 initially in this case), and since it's not configurable by the user
 we are safe from a connection reuse point of vue in any case.
>>> 
>>> +1 in concept
>>> 
>> 
>> Looks sensible. +1.
> 
> I like the patch. +1
> 
> Cheers,
> Stefan

Re: friends of mod_proxy

[Jim Jagielski]

Yeah... The logic in not re-using a worker is that the pattern matching aspect 
made it both difficult and somewhat inconsistent due to the dynamic nature of 
the situation, hence the use of the "default" worker for these.

We now have the functionality to handle this, but it is still a performance hit 
and in most cases enablereuse should be disabled. But we still make that an 
admin decision, and I think that's still the right move.

Cheers!

> On Oct 6, 2022, at 11:32 AM, Eric Covener  wrote:
> 
> On Thu, Oct 6, 2022 at 10:21 AM Stefan Eissing via dev
> mailto:dev@httpd.apache.org>> wrote:
>> 
>> Friends of mod_proxy, I have a question:
>> 
>> In  someone reported wrong 
>> connection reuse for a config like:
>> 
>> ProxyPassMatch ^/(prod|dev)/([-a-z0-9]+)/(.*)$ h2://$2.internal/$1/$2/$3 
>> enablereuse=on keepalive=on
>> 
>> Leaving aside the issue that such a pattern is insecure due to the client 
>> influencing the hostname, the fact remains that mod_proxy_http2 will use a 
>> previous connection, even if the matched hostname is different. I replicated 
>> that, using "just" ports in a test case:
>> 
>> ProxyPassMatch ^/h2proxy/([0-9]+)/(.*)$ h2c://127.0.0.1:$1/$2 enablereuse=on 
>> keepalive=on
>> 
>> Then
>> 1. /h2proxy/5002/hello.py
>> 2. /h2proxy/5004/hello.py
>> 
>> results in 2) re-using the connection of 1). The log file says for 2):
>> 
>> [proxy:debug] proxy_util.c(2538): AH00942: H2C: has acquired connection for 
>> (127.0.0.1:80)
>> [proxy:debug] proxy_util.c(2596): [remote 127.0.0.1:60121] AH00944: 
>> connecting h2c://127.0.0.1:5004/hello.py to 127.0.0.1:5004
>> [proxy:debug] proxy_util.c(2819): [remote 127.0.0.1:60121] AH00947: 
>> connected /hello.py to 127.0.0.1:5002
>> [proxy_http2:trace1] mod_proxy_http2.c(374): [remote 127.0.0.1:60121] H2: 
>> determined connect to 127.0.0.1:5002
>> [proxy:trace2] proxy_util.c(3101): H2C: reusing backend connection 
>> 127.0.0.1:60120<>127.0.0.1:5002
>> 
>> and that looks wrong.
>> 
>> Question: do we have a bug or do we consider such ProxyPassMatch as broken 
>> and require at least enablereuse=off?
> 
> I can't find all the history, but some time ago proxypassmatch never
> tried to find a matching worker
> https://bz.apache.org/bugzilla/show_bug.cgi?id=62167 
> 
> 
> Later, we must have gotten some logic added but you still have to
> opt-in, I think it is likely
> http://home.apache.org/~ylavic/patches/httpd-2.4.x-ap_proxy_define_match_worker.patch
>  
> 
> or adjacent
> 
> Not sure if it helps

Git(Hub) workflow

[Jim Jagielski]

Do we have an approved and official Git(Hub) based workflow defined?

Re: Named shared memory on macOS Monterey

[Jim Jagielski]

Yep. If I build APR w/ --enable-posix-shm all tests pass just fine. Otherwise I 
run into errors
where, when creating the shared memory segments, we run out (NOSPC)

> On May 18, 2022, at 8:15 AM, Eric Covener  wrote:
> 
> Is this what breaks the test framework with heartmonitor loaded? I've
> lost the errors, ended up commenting out the mod and re-running
> Makefiles.PL to get unblocked.
> 
> On Tue, May 17, 2022 at 3:26 PM Jim Jagielski  wrote:
>> 
>> Anyone else notice that the later version of macOS really prefer
>> that APR use posix for shared memory for both anon and name-based,
>> instead of posix for anon and sysv/ipc for name?
>> 
>> The issue seems to be that the kernel params are much lower than
>> previous versions as well as it being nigh-impossible to reset
>> those sysctl params on each boot, due to SIP.
>> 
>> Shouldn't we prefer posix over sysv in any case?
> 
> 
> 
> -- 
> Eric Covener
> cove...@gmail.com

Named shared memory on macOS Monterey

[Jim Jagielski]

Anyone else notice that the later version of macOS really prefer
that APR use posix for shared memory for both anon and name-based,
instead of posix for anon and sysv/ipc for name?

The issue seems to be that the kernel params are much lower than
previous versions as well as it being nigh-impossible to reset
those sysctl params on each boot, due to SIP.

Shouldn't we prefer posix over sysv in any case?

Re: svn commit: r1899390 - in /httpd/httpd/trunk: CHANGES modules/proxy/mod_proxy.c modules/proxy/mod_proxy.h

[Jim Jagielski]

It was added in anticipation of the capability to be folded in, and done so 
"now" so that it would;t require any API changes.

Unless it's actually breaking something, I'd vote to simply keep it

> On Apr 1, 2022, at 3:42 AM, jean-frederic clere  wrote:
> 
> On 01/04/2022 08:47, jean-frederic clere wrote:
>> On 31/03/2022 12:59, Ruediger Pluem wrote:
>>> 
>>> 
>>> On 3/31/22 12:34 PM, Stefan Eissing wrote:
 
 
> Am 31.03.2022 um 11:55 schrieb Ruediger Pluem :
> 
> 
> 
> On 3/31/22 11:11 AM, Ruediger Pluem wrote:
>> 
>> 
>> On 3/30/22 4:42 PM, jfcl...@apache.org wrote:
>>> Author: jfclere
>>> Date: Wed Mar 30 14:42:14 2022
>>> New Revision: 1899390
>>> 
>>> URL: http://svn.apache.org/viewvc?rev=1899390=rev
>>> Log:
>>> Add WorkerBalancerGrowth. To allow creation of workers
>>> to dynamically added balancers.
>>> 
>>> Modified:
>>> httpd/httpd/trunk/CHANGES
>>> httpd/httpd/trunk/modules/proxy/mod_proxy.c
>>> httpd/httpd/trunk/modules/proxy/mod_proxy.h
>>> 
>>> Modified: httpd/httpd/trunk/CHANGES
>>> URL: 
>>> http://svn.apache.org/viewvc/httpd/httpd/trunk/CHANGES?rev=1899390=1899389=1899390=diff
>>>  
>>> ==
>>>  
>>> --- httpd/httpd/trunk/CHANGES [utf-8] (original)
>>> +++ httpd/httpd/trunk/CHANGES [utf-8] Wed Mar 30 14:42:14 2022
>>> @@ -1,6 +1,10 @@
>>> -*- coding: utf-8 -*-
>>> Changes with Apache 2.5.1
>>> 
>>> + *) mod_proxy: Add WorkerBalancerGrowth to allow adding workers to
>>> + balancer created dynamically or via "empty" 
>>> + [Jean-Frederic Clere]
>> 
>> I am not sure why this is needed. You can already do this via
>> 
>> 
>> 
> 
> Or
> 
> 
> ProxySet growth=10
> 
 
 FYI: Travis trunk also fails almost completely. Does not seem to accept a 
 proxy configuration.
>>> 
>>> This is because the if
>>> 
>>> +  if (!ap_strchr_c(conf->p, ':'))
>>> +  return apr_pstrcat(cmd->pool, thiscmd->name,
>>> +  "> arguments are not supported for non url.",
>>> +  NULL);
>>> 
>>> should not return with an error, but just encapsulate the remainder of the 
>>> block. And I think the further
>>> return apr_pstrcat are also wrong.
>>> 
>>> But as said I am not sure about the purpose at all as you can already do, 
>>> what the patch should provide if I understand the patch
>>> correctly.
>> The purpose was to be able to add a balancer in the balancer-manager handle 
>> but that needs to pre-create the mutex and the slots for the workers.
>> While looking to that I noted that:
>> 
>> 
>> was doing nothing, the balancer is ignored, I should I revert the patch and 
>> add an error message if there is an empty entry like this one?
> 
> There is also the BalancerGrowth directive that does nothing else than 
> creating a memory slot for balancers we never add/create in the 
> balancer-manager, I am tempted to remove it...
> 
> Would it be better to add the missing logic? I have some pieces in 
> mod_proxy_cluster (https://github.com/modcluster/mod_proxy_cluster 
>  that could use the logic.
>>> 
>>> Regards
>>> 
>>> Rüdiger
> 
> 
> -- 
> Cheers
> 
> Jean-Frederic

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

[Jim Jagielski]

> On Mar 9, 2022, at 11:19 AM, Stefan Eissing  wrote:
> 
> Hi all,
> 
> Please find below the proposed release tarball and signatures:
> 
> https://dist.apache.org/repos/dist/dev/httpd/
> 
> I would like to call a VOTE over the next few days to release
> this candidate tarball httpd-2.4.53-rc2 as 2.4.53:
> [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.
> 

macOS 12.2.1 / Xcode 13.2.1
Ubuntu 20.04LTS

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

[Jim Jagielski]

> On Mar 9, 2022, at 8:58 AM, Yann Ylavic  wrote:
> 
> On Wed, Mar 9, 2022 at 2:45 PM Stefan Eissing  > wrote:
>> 
>>> Am 09.03.2022 um 14:25 schrieb Yann Ylavic :
>>> 
>>> On Tue, Mar 8, 2022 at 6:22 PM Rainer Jung  wrote:
 
 - configure for APR in the dependency tarball still fails for me due to
 a bug in autoconf 2.71 used to create the configure script. That problem
 was already reported by me during another release vote. I replaced the
 changed three files in the bundled apr and apr-util with the earlier ones.
>>> 
>>> Does this depend on the RM's autoconf version?
>>> If so, Stefan could you downgrade to autoconf 2.69 on your system? I
>>> just did that on mine with:
>>> $ apt install autoconf=2.69-1
>>> 
>>> Sorry, I don't have a better idea..
>> 
>> I downgraded my autoconf from 2.71 to 2.69. Can I make some check before
>> or will we just see the outcome of the rc2? (which is easy to make)
> 
> Thanks, I think a clean build on your local 2.4.x should do it:
> $ cd 2.4.x
> $ make distclean
> $ rm `find . -name configure`
> $ ./builconf
> $ ./config.nice
> $ make depend && make
> 

I've found make extraclean works a bit better

Re: backports

[Jim Jagielski]

> On Mar 8, 2022, at 7:58 AM, Graham Leggett  wrote:
> 
> 
> I would far rather the empty APLOGNO check was part of the build.
> 
> Vastly simpler.
> 

I agree w/ that...

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

[Jim Jagielski]

> On Mar 7, 2022, at 10:55 AM, Stefan Eissing  wrote:
> 
> Hi all,
> 
> Please find below the proposed release tarball and signatures:
> 
> https://dist.apache.org/repos/dist/dev/httpd/
> 
> I would like to call a VOTE over the next few days to release
> this candidate tarball httpd-2.4.53-rc1 as 2.4.53:
> [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.
> 

Tested:
  o macOS 12.2.1 w/ Xcode 13.2.1 / OpenSSL 1.1.1m
  o Ubuntu 20.04LTS / OpenSSL 1.1.1m

Re: backports

[Jim Jagielski]

> On Mar 7, 2022, at 6:28 AM, Graham Leggett  wrote:
> 
> On 07 Mar 2022, at 11:21, Stefan Eissing  > wrote:
> 
>> I'd really like, as a reviewer of backports, you can:
>> - see that it passes all our tests. No need to patch/compile/test locally.
> 
> “No need to patch/compile locally" is not a good idea - currently the travis 
> tests target Ubuntu only, and this is a practical limitation forced upon us 
> by the nature of the Travis service. I want to see reviewers try out the 
> patch on different architectures. I for example work on MacOS, but deploy to 
> Redhat, so those are my two environments. Others will have different 
> environments.
> 
> Our testing needs to be wide and diverse.

++1

Re: backports

[Jim Jagielski]

> On Mar 4, 2022, at 12:40 PM, Roy T. Fielding  wrote:
> 
>> On Mar 4, 2022, at 6:17 AM, Eric Covener  wrote:
>> 
>> On Fri, Mar 4, 2022 at 9:05 AM Jim Jagielski  wrote:
>>> 
>>> A question: Would it be easier for all this if we moved to being Github 
>>> canon?
>> 
>> I think it is much more straightforward.  The original work, reviews
>> and travis results are all in the same place and nothing is copied
>> around.
>> I have had the same thought a few times this week. But I was hesitant
>> to reopen that thread/discussion because I'm pessimistic we can get
>> anywhere on it.
> 
> I think we are far beyond that point where staying with svn/bugzilla is 
> actively
> hurting the project for little or no benefit.
> 
> I'd +1 a switch just to get real issue management and PRs.
> 

That's where I was heading with this, so I'm an obvious +1 to switching to 
making
a Github-based workflow "official" for the PMC.

Re: backports

[Jim Jagielski]

A question: Would it be easier for all this if we moved to being Github canon?

> On Mar 4, 2022, at 5:08 AM, Stefan Eissing  wrote:
> 
> We should improve our backport procedure and provide guidance on how to use 
> it after the next release.
> 
> Post-mortem dbm backport:
> - the patch pointed to the in 2.4.x/STATUS was incomplete, lacking APLOGNO()
> - the incomplete patch was voted on and accepted, as local tests do not have 
> the full CI checks
> - Jim applied the voted on backport patch
> - CI failed
> No one did anything really wrong. We did just not apply the CI tools 
> available until the damage was done.
> 
> As noted in the related thread, backport proposal should really be PRs on 
> github. Those are checked by
> our CI and a PR can easily be improved by adding submits to the branch it is 
> based on. In addition, we
> get the github UI for review and comments. Should be a win for all.
> 
> Kind Regards,
> Stefan
> 
> 

Re: svn commit: r1898566 - in /httpd/httpd/branches/2.4.x: ./ modules/aaa/ modules/cache/ modules/dav/fs/ modules/dav/lock/ modules/mappers/ modules/proxy/

[Jim Jagielski]

Do we have a users guide for this specific implementation and setup? TIA!

Cheers

c99

[Jim Jagielski]

I'm guessing we all heard the news that Linux is switching
to c99 from c89.

Time for us to consider it as well?

Re: intent to make a release candidate on Monday

[Jim Jagielski]

All three promoted. I went ahead and merged the 'dbm' patch

> On Mar 3, 2022, at 4:37 AM, Stefan Eissing  wrote:
> 
> There are some important fixes pending release. Work does not appear to
> slow down in the foreseeable future, so I'd like us to make them available.
> 
> Looking at 2.4.x STATUS, there are 3 backport proposals lacking 1 vote:
> - dbm: Split the loading of a dbm driver
> - mod_proxy: Bump shared worker name to 384 chars. PR 53218
> - mod_http2: preserve the port number given in a HTTP/1.1
> 
> Maybe someone finds the time to look at those.
> 
> If you see something that definitely should be in the next
> release, but lack the time to make it ready for Monday, please
> let us know and we can discuss how we can help or adjust the
> schedule.
> 
> Kind Regards,
> 
> Stefan
> 
> 

Re: mod_tls as experimental module?

[Jim Jagielski]

Add it in :-)

> On Nov 24, 2021, at 4:46 AM, ste...@eissing.org wrote:
> 
> Coming back to this. Since there was no feedback on my post: are people
> just too occupied/opposed/not interested?
> 
> Curious,
> Stefan
> 
>> Am 18.11.2021 um 18:48 schrieb ste...@eissing.org:
>> 
>> How would you feel about adding mod_tls 
>> (https://github.com/abetterinternet/mod_tls) as an experimental module to 
>> Apache httpd?
>> 
>> For people who have not followed that development:
>> - it is a TLS 1.2/1.3 implementation based on rustls, 
>> https://github.com/rustls/rustls
>> - the C API is rustls-ffi, found at https://github.com/rustls/rustls-ffi
>> - it is itself written in C, linking all the Rust things from the rustls-ffi 
>> library
>> - it does not bring any Rust into our code base
>> - functionality wise, it is a clear subset of what mod_ssl offers via openssl
>> (e.g. no client certificates now and not as tweakable - at least for now)
>> - it can be co-loaded and co-used with mod_ssl on different ports or 
>> front-/backend roles
>> - performance-wise, according to my plain vanilla tests, it is on par with 
>> mod_ssl
>> 
>> The decision to offer it downstream is of course then made by the distros, 
>> as usual with experimental modules. And if and how it is then used rests 
>> with the users. It is an offered alternative for people.
>> 
>> What would be the benefit to the project?
>> - we offer people an alternative. If they feel the memory safety that Rust 
>> offers is important to them, they can do it with Apache httpd for the TLS 
>> stack.
>> - we could see how people react to this and adapt our TLS offering 
>> accordingly. It being experimental, we remain free to change it. Or remove 
>> it again.
>> 
>> Organizational Things:
>> - the development was done by myself
>> - the work was sponsored by the ISRG (https://www.abetterinternet.org), the 
>> org behind Let's Encrypt, as part of they "memory safety" initiative 
>> (https://www.memorysafety.org)
>> 
>> 
>> Feedback appreciated,
>> 
>> Stefan
>> 
>> PS. On a more personal note:
>> The way this project turned out was a clean separation between C and Rust. 
>> The API offered by rustls-ffi is colored by Rust's immutability/borrowed 
>> memory concepts, but there is nothing Rust special the C code needs to do. 
>> It remains C code. It remains in our core competence.
>> 
>> Working with the rustls people has been nice and productive. The only thing 
>> I can report is that they come from the client TLS side and specific server 
>> needs require some explaining. There are things we can offer to them here.
>> 
>> There are a lot of political things going on right now around OpenSSL and I 
>> definitely want to stay out of that. Again, we can offer this without having 
>> to switch ourself. Even better, customers can use this without needing to 
>> switch completely, as it co-exists. I think that fits into the concepts our 
>> server is designed with.
>> 
>> Thanks for your time.
>> 
> 

Re: reporting the bytes read and transferred to the worker from the tunnel

[Jim Jagielski]

LGTM

> On May 5, 2021, at 5:59 AM, jean-frederic clere  wrote:
> 
> Hi,
> 
> I have noted that when using websocket the bytes read and transfered by the 
> worker when using the tunnel are not taken in account.
> 
> I have a patch attached, for comments ;-)
> 
> Any better ideas how to fix that?
> 
> -- 
> Cheers
> 
> Jean-Frederic
> 

Apachecon

[Jim Jagielski]

Anyone submitting any httpd related proposals for AC2021?

Xcode 12

[Jim Jagielski]

Anyone hacking away on httpd and/or APR w/ Xcode 12? On my system at least it 
is throwing errors about -Werror,-Wimplicit-function-declaration, and not 
enabling IPv6:

checking if APR supports IPv6... no -- no working getaddrinfo

also likely due to an error when compiling because of stdlib.h not being 
included...

Warning: Xcode12 breaks apr* and httpd

[Jim Jagielski]

The upgrade from Xcode11 -> Xcode12 has been reported to break builds for APR 
and httpd... Issues seem to be some sort of forced C99 compliance and not 
discovering IPv6 capability.

I'm not upgrading anytime soon so no idea how bad it is.

Re: Changing the httpd security process

[Jim Jagielski]

++1. I was never quite happy with this process, but it seemed like there was a 
lot of support for this kind of treatment. 

> On Aug 17, 2020, at 7:08 AM, 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.
> 

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

[Jim Jagielski]

+1

> On Jul 31, 2020, at 9:41 AM, Eric Covener  wrote:
> 
> On Fri, Jul 31, 2020 at 9:37 AM Rainer Jung  wrote:
>> 
>> Since there wasn't yet any reaction to Daniel's question: Is anybody
>> right now working on more warnings fixes for Windows?
>> 
> 
> Not me. I don't think we should wait on them.
> 
>> The most prominent one (missing APLOGNo number = missing macro argument)
>> IMHO was already fixed by Christophe in r1880438. Anything else worth
>> waiting for or are we (is Daniel) good to go for 2.4.46?
> 
> Good to go from my POV.
> 
>> Concerning lua I'd say the fix(es) for 5.4.0 need a bit more testing.
> 
> +1

Re: [VOTE] Release httpd-2.4.45

[Jim Jagielski]

> On Jul 30, 2020, at 5:55 AM, Christophe JAILLET 
>  wrote:
> 
> I wouldn't say it is a show stopper, but I thought that we had a travis job 
> for that.
> Apparently, it is on trunk only (see r1879370 which is not backported, maybe 
> on purpose)
> 

I agree that it's not a show-stopper but it is something that seems easy to fix 
and, considering that (1) we want to release the best possible version as we 
can and (2) there is quite a bit of time between releases, I wouldn't be 
opposed if the RM decided to skip 2.4.45 and go w/ 2.4.46.

Re: [VOTE] Release httpd-2.4.44

[Jim Jagielski]

I'll hold off testing and voting until we hear from the RM on whether this 
release is DOA or not...

> On Jul 29, 2020, at 8:02 AM, Stefan Eissing  
> wrote:
> 
> -1.
> 
> I have to apologise. I missed an important change in HTTP/2 that I like to 
> get in the release. This is about removing support for an abandoned http-wg 
> draft that we do not want any longer in our server.
> 
> Will do the changes right away and let you know when I am done.
> 
> Again, sorry to everyone for the wasted cycles. :(
> 
> - Stefan
> 
>> Am 28.07.2020 um 19:51 schrieb Daniel Ruggeri :
>> 
>> 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.44:
>> [ ] +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: 5a9eac997db0e466103b09b80ccc0fccc7e46fa3 *httpd-2.4.44.tar.gz
>> sha256: a422d30fe9ad9f0c2efcbbb7b56c820d4891cd74d7d55d3853f372193fbf059e
>> *httpd-2.4.44.tar.gz
>> sha512:
>> f9065b30df4d91b70739631e19e65c5a68d4f4ed9071c2b040176b5ee839a86078f178cadd8430f325edda8dddf1ff95c7924e62d73f8f3b6e9b7f48f0b3b257
>> *httpd-2.4.44.tar.gz
>> 
>> The SVN tag is '2.4.44' at r1880378.
>> 
>> -- 
>> Daniel Ruggeri
>> 
>> 
> 

Re: NOTICE: Intent to T late this week

[Jim Jagielski]

Sure. Go ahead. +1

> On Jul 22, 2020, at 7:32 PM, Daniel Ruggeri  wrote:
> 
> Hi, all;
> It's been a while since we've rolled a release and gotten fixes/etc in our 
> community's hands. Apologies for not suggesting this sooner. How about a T 
> Friday? That will let vote run through the weekend.
> -- 
> Daniel Ruggeri

Re: svn commit: r1879285 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/core.xml include/ap_mmn.h include/http_core.h include/http_protocol.h include/httpd.h modules/dav/fs/repos.c modules/test/mod_

[Jim Jagielski]

> On Jun 29, 2020, at 10:27 AM, Graham Leggett  wrote:
> 
> On 29 Jun 2020, at 14:49, Yann Ylavic  > wrote:
> 
>>> Yes we can and should (but in separate commits).
>>> 
>>> I have my eye on the r->proxyreq flag, we can pack this into the binary 
>>> notes too, values don’t need to be one bit wide.
>> 
>> Actually I was thinking the other way around, have the new "unsigned
>> int strong_etag:1" bitfield rather than changing the existing ones...
>> Why adding complexity with bit(s) macros while bitfields exist?
> 
> The problem with bitfields in the public APIs is that they’re not binary 
> compatible across compilers. While it is very rare that a module will be 
> built with a different compiler than httpd was, it’s still theoretically 
> possible, and we should probably avoid it. Bitfields aren’t a problem for 
> in-module or in-core code.

++1

Re: RFC: Documenting changes in the CHANGES file

[Jim Jagielski]

Works for me.

> On May 29, 2020, at 3:30 PM, Ruediger Pluem  wrote:
> 
> Reviewing our backport process I noticed that in many cases a clean merge via 
> svn merge fails due to conflicts in CHANGES. While
> these are easy to solve it puts IMHO unnecessary extra work on the backport 
> process, both for reviewing and for actually doing the
> backport. How about if we change the way we document changes the following 
> way:
> 
> 1. We create a changes-fragments directory (name to be determined) at the top 
> level.
> 2. For each release we create a subdirectory such that we end up with the 
> following structure:
> 
>   changes-fragments/
> 2.4.41/
> 2.4.42/
> 2.4.43/
> 2.4.44/
> 
> 3. Each directory contains the changes for each release and each change entry 
> is a single file.
> 4. We have a script that builds our current CHANGES file from the content in 
> changes-fragments directories with the help of
>   a template or at least some sort of header / footer that is static.
> 5. This script can be called either manually and we commit the resulting 
> CHANGES file as we like just like the x-forms commits
>   for documentation plus this script is called by the release scripts from 
> Daniel as part of the preparation of rolling a
>   release.
> 
> 
> Regards
> 
> Rüdiger

Re: Building from svn on MacOS

[Jim Jagielski]

I always have svn co of apr and apr-util in srclib when I build from SVN

Re: svn commit: r1876511 - /httpd/httpd/trunk/modules/core/mod_watchdog.c

[Jim Jagielski]

very, very elegant.

> On Apr 14, 2020, at 8:37 AM, jor...@apache.org wrote:
> 
> Author: jorton
> Date: Tue Apr 14 12:37:17 2020
> New Revision: 1876511
> 
> URL: http://svn.apache.org/viewvc?rev=1876511=rev
> Log:
> * modules/core/mod_watchdog.c: Switch to simpler logic to avoid the
>  thread cleanup running before the thread has started, avoiding
>  mutex operations which both have undefined behaviour:
> 
>  a) double-locking an UNNESTED (non-recursive) mutex twice in the parent
>  b) unlocking a mutex in the spawned thread which was locked by the parent
> 
>  (wd_startup, wd_worker_cleanup, wd_worker): Use a boolean to ensure
>  the cleanup does nothing if the thread wasn't started, drop the mutex.
> 
> Modified:
>httpd/httpd/trunk/modules/core/mod_watchdog.c
> 
> Modified: httpd/httpd/trunk/modules/core/mod_watchdog.c
> URL: 
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/core/mod_watchdog.c?rev=1876511=1876510=1876511=diff
> ==
> --- httpd/httpd/trunk/modules/core/mod_watchdog.c (original)
> +++ httpd/httpd/trunk/modules/core/mod_watchdog.c Tue Apr 14 12:37:17 2020
> @@ -24,6 +24,8 @@
> #include "http_core.h"
> #include "util_mutex.h"
> 
> +#include "apr_atomic.h"
> +
> #define AP_WATCHDOG_PGROUP"watchdog"
> #define AP_WATCHDOG_PVERSION  "parent"
> #define AP_WATCHDOG_CVERSION  "child"
> @@ -43,7 +45,7 @@ struct watchdog_list_t
> 
> struct ap_watchdog_t
> {
> -apr_thread_mutex_t   *startup;
> +apr_uint32_t  thread_started; /* set to 1 once thread running */
> apr_proc_mutex_t *mutex;
> const char   *name;
> watchdog_list_t  *callbacks;
> @@ -74,6 +76,10 @@ static apr_status_t wd_worker_cleanup(vo
> apr_status_t rv;
> ap_watchdog_t *w = (ap_watchdog_t *)data;
> 
> +/* Do nothing if the thread wasn't started. */
> +if (apr_atomic_read32(>thread_started) != 1)
> +return APR_SUCCESS;
> +
> if (w->is_running) {
> watchdog_list_t *wl = w->callbacks;
> while (wl) {
> @@ -110,7 +116,8 @@ static void* APR_THREAD_FUNC wd_worker(a
> w->pool = apr_thread_pool_get(thread);
> w->is_running = 1;
> 
> -apr_thread_mutex_unlock(w->startup);
> +apr_atomic_set32(>thread_started, 1); /* thread started */
> +
> if (w->mutex) {
> while (w->is_running) {
> if (ap_mpm_query(AP_MPMQ_MPM_STATE, _s) != APR_SUCCESS) {
> @@ -264,10 +271,7 @@ static apr_status_t wd_startup(ap_watchd
> {
> apr_status_t rc;
> 
> -/* Create thread startup mutex */
> -rc = apr_thread_mutex_create(>startup, APR_THREAD_MUTEX_UNNESTED, p);
> -if (rc != APR_SUCCESS)
> -return rc;
> +apr_atomic_set32(>thread_started, 0);
> 
> if (w->singleton) {
> /* Initialize singleton mutex in child */
> @@ -277,22 +281,12 @@ static apr_status_t wd_startup(ap_watchd
> return rc;
> }
> 
> -/* This mutex fixes problems with a fast start/fast end, where the pool
> - * cleanup was being invoked before the thread completely spawned.
> - */
> -apr_thread_mutex_lock(w->startup);
> -apr_pool_pre_cleanup_register(p, w, wd_worker_cleanup);
> -
> /* Start the newly created watchdog */
> rc = apr_thread_create(>thread, NULL, wd_worker, w, p);
> -if (rc) {
> -apr_pool_cleanup_kill(p, w, wd_worker_cleanup);
> +if (rc == APR_SUCCESS) {
> +apr_pool_pre_cleanup_register(p, w, wd_worker_cleanup);
> }
> 
> -apr_thread_mutex_lock(w->startup);
> -apr_thread_mutex_unlock(w->startup);
> -apr_thread_mutex_destroy(w->startup);
> -
> return rc;
> }
> 
> 
> 

Re: [VOTE] Release httpd-2.4.43

[Jim Jagielski]

+1:
   o macOS 10.14.6, Xcode 11.3.1 (Event MPM): No regressions - Perl test 
framework
   o CentOS 6.10, 64bit (Event and Worker MPM): No regressions - Perl test 
framework
   o CentOS 7.7, 64bit (Event and Worker MPM): No regressions - Perl test 
framework

> On Mar 26, 2020, at 10:50 AM, 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.43:
> [ ] +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: 15d8605b094dfe5e283cd9e90770368dd14e26f2 *httpd-2.4.43.tar.gz
> sha256: 2624e92d89b20483caeffe514a7c7ba93ab13b650295ae330f01c35d5b50d87f
> *httpd-2.4.43.tar.gz
> sha512:
> d9879b8f8ef7d94dee1024e9c25b56d963a3b072520878a88a044629ad577c109a5456791b39016bf4f6672c04bf4a0e5cfd32381211e9acdc81d4a50b359e5e
> *httpd-2.4.43.tar.gz
> 
> The SVN tag is '2.4.43' at r1875715.
> 
> -- 
> Daniel Ruggeri
> 

Re: [VOTE] Release httpd-2.4.42

[Jim Jagielski]

Based on this, I change my vote to -1

> On Mar 19, 2020, at 11:19 AM, Eric Covener  wrote:
> 
> On Thu, Mar 19, 2020 at 10:45 AM 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.42:
>> [ ] +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: 2e4505796dfaebcceab6ba22e5fa221e07ad488e *httpd-2.4.42.tar.gz
>> sha256: cbac6f8211744a74f798db792b74da9f6fb5a4fbee94234cf2b01aeb9ffe57ed
>> *httpd-2.4.42.tar.gz
>> sha512:
>> 09d0f3bd9266907eea91ac9129a3c41658929b9fd88d627c1fccceaf952548d2c3ad62099b9bcd1ae4822402c1dbda90b8bfb9f64cd5eac9f84ed249faffb837
>>  *httpd-2.4.42.tar.gz
>> 
>> The SVN tag is '2.4.42' at r1875427.
>> 
> 
> Looks like r1874288 broke my basic apxs usage w/o DESTDIR in use.
> Seems broken in my trunk sandbox too.

Re: async filters still borked (was Re: svn commit: r1874775 - /httpd/httpd/trunk/test/README.travis)

[Jim Jagielski]

+1 from me.

> On Mar 20, 2020, at 9:46 AM, Joe Orton  wrote:
> 
> On Fri, Mar 06, 2020 at 09:30:41AM +0100, Ruediger Pluem wrote:
>> On 3/4/20 9:23 AM, jor...@apache.org wrote:
>>> Author: jorton
>>> Date: Wed Mar  4 08:23:55 2020
>>> New Revision: 1874775
>>> 
>>> URL: http://svn.apache.org/viewvc?rev=1874775=rev
>>> Log:
>>> Update docs. The expr_string.t failure has not been seen since 
>>> the workaround was added AFAICT.  The async filter bug
>>> is still breaking the tests regularly. [skip ci].
>> 
>> Anyone found time to check
>> 
>> https://github.com/apache/httpd/pull/88
>> 
>> regarding the async filter bug?
> 
> [crickets]
> 
> We are two months on since discussing this first.  It seems quite 
> worrying that the async filters stuff was introduced with apparently 
> nasty bugs and yet is already bitrotting on trunk with not enough people 
> to review and fix it.  Can we move the code to a branch until it is 
> ready?
> 
> Regards, Joe
> 

Re: [VOTE] Release httpd-2.4.42

[Jim Jagielski]

+1: macOS 10.14.6, Xcode 11.3.1: No regressions - Perl test framework

Will try to test on CentOS 6-8 today

> On Mar 19, 2020, at 10:45 AM, 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.42:
> [ ] +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: 2e4505796dfaebcceab6ba22e5fa221e07ad488e *httpd-2.4.42.tar.gz
> sha256: cbac6f8211744a74f798db792b74da9f6fb5a4fbee94234cf2b01aeb9ffe57ed 
> *httpd-2.4.42.tar.gz
> sha512: 
> 09d0f3bd9266907eea91ac9129a3c41658929b9fd88d627c1fccceaf952548d2c3ad62099b9bcd1ae4822402c1dbda90b8bfb9f64cd5eac9f84ed249faffb837
>  *httpd-2.4.42.tar.gz
> 
> The SVN tag is '2.4.42' at r1875427.
> 
> -- 
> Daniel Ruggeri

Netcraft

[Jim Jagielski]

Wow. Was Netcraft actually somewhat kind to Apache httpd? They actually 
admitted some areas where httpd is doing better, and still does better, 
market-share wise, than nginx.

Re: Add an entry in CHANGES file for Travis CI testing

[Jim Jagielski]

++1

> On Feb 11, 2020, at 12:43 PM, Mike Rumph  wrote:
> 
> With the talk of releasing 2.4.42, I was thinking that it might be a good 
> idea to add some mention of the Travis CI testing that was added in this 
> release.
> Perhaps something in the CHANGES file that gives a summary of the results 
> achieved by this.
> This could include a list of the various platforms and architectures that 
> were tested.
> 
> Mike

Time for 2.4.42?

[Jim Jagielski]

Seems like a good time to propose a release... I can RM if desired.

Your Apache HTTPD story

[Jim Jagielski]

The CFP (Call For Papers) for ApacheCon NA 2020 is now open, and one major 
topic will be regarding the one project that started it all: Apache httpd.

I am coordinating the Apache httpd track, and I am encouraging not only 
developers but more importantly USERS of the Apache web server to submit a talk 
or talks about how YOU use Apache; share your knowledge, share your experience!

Check out the following link and, if you feel so inclined, Email me a copy of 
your proposal:

https://apachecon.com/acna2020/cfp.html

Cheers!

Re: Time for httpd 2.6.x?

[Jim Jagielski]

> On Nov 1, 2019, at 11:59 AM, Luca Toscano  wrote:
> 
> Il giorno mar 29 ott 2019 alle ore 18:31 Graham Leggett
> mailto:minf...@sharp.fm>> ha scritto:
>> 
>> On 29 Oct 2019, at 15:51, Jim Jagielski  wrote:
>> 
>>> My only question regards workflow w/ trunk. Right now, I think we all agree 
>>> that there are codepaths and features in trunk that are not as stable as we 
>>> would like. Which is fine... trunk is CTR. But we do need some way to vet 
>>> those changes (ie, we need to "R" all those "C"s). Some will be accepted, 
>>> others not. Into what branch do those accepted go? And for the things not 
>>> accepted for eventually inclusion in 2.5/2.6, do they get removed from 
>>> trunk? Do they stay in trunk?
>> 
>> As I recall from v2.4, we branched from trunk, and then we removed anything 
>> we deemed “not ready” from the branch. “not ready” had reasonably simple 
>> criteria, like “not documented yet”.
>> 
>>> So it seems to me that we need to branch trunk into 2.5.x and "clean up" 
>>> that branch (items 1-5) and leave trunk alone.
>> 
>> +1.
>> 
>> Let’s get a 2.5 out there, and let people bash on it.
> 
> If this was the previous way of doing things and it worked, +1 as
> well. Is there anybody willing to start this process?

I don't want to start any process w/o more consensus about going forward... In 
particular, branching 2.5.x from trunk...

Re: Time for httpd 2.6.x?

[Jim Jagielski]

> On Oct 29, 2019, at 9:36 AM, Eric Covener  wrote:
> 
> On Tue, Oct 29, 2019 at 9:18 AM Luca Toscano  > wrote:
>> 
>> Hi everybody,
>> 
>> Il giorno ven 25 ott 2019 alle ore 12:52 Yann Ylavic
>>  ha scritto:
>>> 
>>> So how about:
>>> 0. github workflow? meanwhile...
>>> 1. compare trunk/2.4.x (inventory)
>>> 2. discuss unused/deprecated in trunk to cleanup
>>> 3. address STALLED entries in trunk if it's not for compatibily reasons
>>> 4. do API/ABI breaking changes in trunk
>>> 5. improve trunk w/ things we want in 2.6.x (the real part!)
>>> 6. trunk => 2.6.x
>>> 7. remove from 2.6.x things not deprecated in 2. but w/ no champion either
>>> 8. 2.6.alpha/beta/gamma/rc/whatever
>>> 9. fix in trunk and backport to 2.6.x
>>> 10. if not good enough goto 8.
>>> 11. 2.6.0
>>> 12+ usual release cycle
>> 
>> The above proposal from Yann seems to be something that could work for
>> everybody as far as I can tell, what do you think? Do we need an
>> explicit vote thread?
> 
> Nit: Not using 2.5.x is a departure from convention.
> 
> I don't think a wholesale vote is needed for #1-5. I am skeptical
> there is interest/velocity in getting past #2.
> By the time we're at #8, I would say a vote is warranted as an
> additional branch has a cost.

My only question regards workflow w/ trunk. Right now, I think we all agree 
that there are codepaths and features in trunk that are not as stable as we 
would like. Which is fine... trunk is CTR. But we do need some way to vet those 
changes (ie, we need to "R" all those "C"s). Some will be accepted, others not. 
Into what branch do those accepted go? And for the things not accepted for 
eventually inclusion in 2.5/2.6, do they get removed from trunk? Do they stay 
in trunk?

So it seems to me that we need to branch trunk into 2.5.x and "clean up" that 
branch (items 1-5) and leave trunk alone.

Just my 2c

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

[Jim Jagielski]

Yikes! How can we test for that via the Perl test framework?

> On Oct 29, 2019, at 9:45 AM, Rainer Jung  wrote:
> 
> Aha, and this is due to the fact, that r1656259 "mod_proxy_http: don't 
> connect or reuse backend before prefetching request body." or parts of it was 
> backported from trunk to 2.4 as part of r1860166.
> 
> So I think (not yet verified), that the same problems applies to trunk since 
> r1656259 in February 2015 :(
> 
> Regards,
> 
> Rainer
> 
> Am 29.10.2019 um 14:21 schrieb Rainer Jung:
>> The reason why this fails now is that we prefetch in 2.4.41 the request body 
>> before doing the connection check to the backend. In 2.4.39 we did that 
>> after doing the check, so the body was still there when doing the final 
>> request sending.
>> 2.4.39:
>> In proxy_http_handler():
>> - ap_proxy_determine_connection()
>> - ap_proxy_check_connection()
>> - optionally ap_proxy_connect_backend() which might fail.
>> - ap_proxy_connection_create_ex()
>> - ap_proxy_http_request() which does prefetch late!
>> 2.4.41:
>> In proxy_http_handler():
>> - ap_proxy_determine_connection()
>> - early ap_proxy_http_prefetch() which does the prefetch!
>> - optionally again ap_proxy_determine_connection()
>> - ap_proxy_check_connection()
>> - optionally ap_proxy_connect_backend() which might fail.
>> - ap_proxy_connection_create_ex()
>> - ap_proxy_http_request()
>> So we either need to remember the prefetch result for later retries or 
>> switch back to the old order.
>> Regards,
>> Rainer
>> Am 29.10.2019 um 12:46 schrieb Rainer Jung:
>>> This happens in the case of a small body. We read the body into 
>>> req->input_brigade in ap_proxy_http_prefetch() before trying the first 
>>> node, but then loose it on the second node, because we use another req and 
>>> thus also another req->input_brigade then.
>>> 
>>> Not sure, how we could best save the read input_brigade for the second 
>>> attempt after failover. Will try some experiments.
>>> 
>>> If you try to reproduce yourself, make sure you use a small POST (here: 30 
>>> bytes) and also exclude /favicon.ico from forwarding when using a browser. 
>>> Otherwise some of the failovers will be triggered by favicon.ico and you'll 
>>> not notice the problem in the POST request:
>>> 
>>> ProxyPass /favicon.ico !
>>> 
>>> Regards,
>>> 
>>> Rainer
>>> 
>>> Am 29.10.2019 um 11:15 schrieb Rainer Jung:
 A first heads-up: it seems this commit broke failover for POST requests. 
 Most (or all?) of the times a balancer failover happens for a POST 
 request, the request send to the failover node has a Content-Length of "0" 
 instead of the real content length.
 
 I use a trivial setup like this:
 
 
ProxySet lbmethod=byrequests
BalancerMember http://localhost:5680
BalancerMember http://localhost:5681
 
 
 ProxyPass / balancer://backends/
 
 where one backend node is up and the second node is down.
 
 I will investigate further.
 
 Regards,
 
 Rainer
> 
> -- 
> kippdata
> informationstechnologie GmbH   Tel: 0228 98549 -0
> Bornheimer Str. 33aFax: 0228 98549 -50
> 53111 Bonn www.kippdata.de
> 
> HRB 8018 Amtsgericht Bonn / USt.-IdNr. DE 196 457 417
> Geschäftsführer: Dr. Thomas Höfer, Rainer Jung, Sven Maurmann

Re: Time for httpd 2.6.x?

[Jim Jagielski]

> On Oct 25, 2019, at 6:59 AM, Graham Leggett  wrote:
> 
> On 24 Oct 2019, at 14:14, Jim Jagielski  wrote:
> 
>> Going from 2.4.x to 2.6.x implies an ABI break... Up to now, all backports 
>> from trunk have maintained the 2.4.x ABI backwards compatibility.
>> 
>> So I would propose that if we do the below, which I am fine w/ BTW, that the 
>> 1st issues we tackle after branching 2.6.x from httpd-24 are all the ABI 
>> changes.
>> 
>> Yes, there is a lot of cool stuff in trunk. There is also a lot of, IMO, 
>> untested and wonky stuff that I would be somewhat worried about releasing... 
>> So that's why I like basing 2.6.x off of 2.4.x rather than trunk.
> 
> I would rather we stick to our existing practise of branching off trunk, then 
> evaluating what we want in 2.6 and explicitly removing what we don't want.
> 
> This is what we did when 2.4 came out, and it worked well.
> 

I'm fine w/ whatever we all decide.

Re: Time for httpd 2.6.x?

[Jim Jagielski]

Going from 2.4.x to 2.6.x implies an ABI break... Up to now, all backports from 
trunk have maintained the 2.4.x ABI backwards compatibility.

So I would propose that if we do the below, which I am fine w/ BTW, that the 
1st issues we tackle after branching 2.6.x from httpd-24 are all the ABI 
changes.

Yes, there is a lot of cool stuff in trunk. There is also a lot of, IMO, 
untested and wonky stuff that I would be somewhat worried about releasing... So 
that's why I like basing 2.6.x off of 2.4.x rather than trunk.

FTR: Both APR and httpd have similar versioning guidelines (semver)... I don't 
see the attraction or need to revisit it.

> On Oct 23, 2019, at 9:02 AM, Luca Toscano  wrote:
> 
> Thanks a lot for all the answers, waiting for more people to chime in!
> What I personally like (at a very high level):
> 
> 1) create a 2.6.x branch from 2.4.x and start backporting commits from
> trunk (with votes etc..), up to the point that we feel 2.6.0 GA is
> ready, then follow the regular release process. Christophe's tool for
> visualizing diffs between trunk and 2.4.x could be really handy and
> helpful.
> 2) Leave trunk as it is, and consider fixing the issues currently outstanding.
> 3) Use STATUS to decide what modules/code is to be deprecated.
> 4) Decide when 2.4.x should be considered EOLed in the future.
> 5) Decide how/when to bump minor versions in the future, so anybody
> adding/contributing code to httpd will have a very high level
> expectation of when some code can be released. IIRC during the past
> threads it was mentioned that a lot of people contributed with good
> code still sitting in trunk due to backporting issues to 2.4.x
> (breaking ABI etc..). It is not really fair and it surely drives away
> contributors that aim to work on major changes to httpd.
> 
> Luca
> 
> 
> Il giorno mer 23 ott 2019 alle ore 10:40 Stefan Eissing
>  ha scritto:
>> 
>> Hi All,
>> 
>> I agree with CJ here.
>> 
>> As I said in the past, my idea would be to:
>> - trunk -> trunk-old,
>> - copy 2.4.x -> trunk
>> - any feature to bring from trunk-old to the new trunk needs a champion, 
>> e.g. someone who does the work (porting and test cases)
>> 
>> To some, that looks like we do not honour past work from people (that was 
>> one of the arguments brought forward last time). But it is not only about 
>> honour of devs, but also about the sweat and tears of the maintainers during 
>> 2.6.x releases. If a feature does not find someone to merge from one branch 
>> to another, how could we support this feature in a release? What do the 5-6 
>> people who handle 99% of all PRs think about this?
>> 
>> As to the list of things to abandon from 2.4.x, we could handle those like 
>> the backport voting in STATUS.
>> 
>> Cheers, Stefan
>> 
>>> Am 23.10.2019 um 10:18 schrieb Christophe JAILLET 
>>> :
>>> 
>>> Hi Luco,
>>> 
>>> I've nothing against a 2.6.x branch.
>>> My only fear is things in trunk that is incomplete and or not enough 
>>> reviewed.
>>> In other words, our backport mechanism with at least 3 votes is safeguard 
>>> for me.
>>> 
>>> My personal point of view is that 2.6.x should be built with backports from 
>>> trunk, just as done actually for 2.4.x.
>>> But I know it is not the point of view of many others that consider that 
>>> what is in trunk is (or should be) functional, reviewed and tested.
>>> Anyway, even if some things are less reviewed, alpha, beta and GA are there 
>>> to give others the opportunity to test and report issues, so I is maybe not 
>>> that bad to go this way, after all.
>>> 
>>> 
>>> If we want to go on the 2.6 way, maybe we could open some discussion:
>>> 
>>>  - should we deprecate or remove some 2.4.x functionalities or modules? 
>>> (mod_imagemap, mod_cern_meta, maybe NetWare support which has really low 
>>> activity, ...)
>>> 
>>>  - should we remove things in trunk that are incomplete or lack consensus: 
>>> (this illustrate my fears above)
>>>- mod_serf and libserf support? : serf project looks mostly inactive 
>>> nowadays, mod_sef have no documentation
>>>- pcre2 support? (comments in commits or code say that it is 
>>> incomplete and that there is performance or memory management issues)
>>>- things listed in 2.4/STATUS: PATCHES/ISSUES THAT ARE STALLED
>>> 
>>>  - should we increase the APR minimum version and cleanup existing code 
>>> accordingly? (i.e. switch from some ap_ to apr_ functions)
>>> 
>>>  - we could start to write a "new_features_2_6.html" in order to list new 
>>> goodies and incompatibilities and changed behavior
>>> 
>>> 
>>> just my 2c.
>>> 
>>> CJ
>>> 
>>> Le 23/10/2019 à 08:28, Luca Toscano a écrit :
 Not even a comment? :)
 
 Luca
 
 Il giorno dom 13 ott 2019 alle ore 20:58 Luca Toscano
  ha scritto:
> Hi everybody,
> 
> in trunk's STATUS there are a lot of suggestions about things to
> improve/change for 2.6.x. There have been discussions during the past
> couple of years about 

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

[Jim Jagielski]

> On Oct 14, 2019, at 3:14 PM, jaillet...@apache.org wrote:
> 
> Author: jailletc36
> Date: Mon Oct 14 19:14:04 2019
> New Revision: 1868456
> 
> URL: http://svn.apache.org/viewvc?rev=1868456=rev
> Log:
> Add a note
> 
> 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=1868456=1868455=1868456=diff
> ==
> --- httpd/httpd/branches/2.4.x/STATUS (original)
> +++ httpd/httpd/branches/2.4.x/STATUS Mon Oct 14 19:14:04 2019
> @@ -178,6 +178,11 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK:
>   trunk patch: http://svn.apache.org/r1867183
>   2.4.x patch: svn merge -c 1867183 ^/httpd/httpd/trunk .
>   +1: jim
> +  jailletc36: -0
> +  I don't think that the #pragma black magic is of any help 
> with GCC 
> +  and jim seems to still have problem with clang and 
> comments with //.
> +  See discussion at:
> +  
> https://lists.apache.org/thread.html/628cc54a1a345cb773d8e1be0639f8e75d2b481cf89232051c83b787@%3Cdev.httpd.apache.org%3E


The problem still exists because this is NOT back ported yet. With this back 
port, the problem goes away.

Re: httpd 2.4 and maintainer-mode

[Jim Jagielski]

Yeah, this seems clang specific...

> On Oct 14, 2019, at 2:48 PM, Marion & Christophe JAILLET 
>  wrote:
> 
> 
> Le 14/10/2019 à 17:15, Jim Jagielski a écrit :
>> 
>>> On Oct 10, 2019, at 2:49 PM, Marion & Christophe JAILLET 
>>>  wrote:
>>> 
>>> I guess that my version of GCC (i.e. 8.3.0) tolerates some c89 deviation in 
>>> .h files included from "outside".
>> So you aren't using Xcode and clang?
> 
> 
> No, just some comand line tools, some scripts, gcc and Geany as an IDE.
> 
> CJ
> 

Re: httpd 2.4 and maintainer-mode

[Jim Jagielski]

> On Oct 10, 2019, at 2:49 PM, Marion & Christophe JAILLET 
>  wrote:
> 
> I guess that my version of GCC (i.e. 8.3.0) tolerates some c89 deviation in 
> .h files included from "outside".
> 

So you aren't using Xcode and clang?

Re: httpd 2.4 and maintainer-mode

[Jim Jagielski]

And this is with maintainer-mode? I'm wondering why your setup is either OK w/ 
the C++ style comments or maybe Homebrew changes the comment style??

> On Oct 10, 2019, at 8:33 AM, Stefan Eissing  
> wrote:
> 
> When will I learn to read mails completely?
> 
> - Ok, proxy-html is not build by default, which explains the happiness due to 
> ignorance. 
> - Once enabled, it does not find libxml2 (I think MacOS Vista removed it)
> - brew reinstall libxml2
> - configure   --with-libxml2=/usr/local/opt/libxml2
> 
> and it builds on my machine.
> 
> - Stefan
> 
>> Am 10.10.2019 um 14:10 schrieb Jim Jagielski :
>> 
>> I am using MacPorts libxml2. But the issue seems to be w/ libxml2 itself; it 
>> is the package that uses the '//' comment style. Where does your build grab 
>> its xml2 stuff from?
>> 
>>> On Oct 10, 2019, at 3:58 AM, Stefan Eissing  
>>> wrote:
>>> 
>>> Compiling trunk and 2.4.x under MacOS Vista, no issues. Some homebrew 
>>> install?
>>> 
>>>> Am 09.10.2019 um 19:04 schrieb Marion & Christophe JAILLET 
>>>> :
>>>> 
>>>> Hi Jim,
>>>> 
>>>> I always compile (and test) with --enable-maintainer-mode.
>>>> 
>>>> I've just updated my 2.4 branch / make clean / make, and there is nothing 
>>>> special.
>>>> 
>>>> Any specific issue?
>>>> 
>>>> CJ
>>>> 
>>>> 
>>>> Le 09/10/2019 à 15:33, Jim Jagielski a écrit :
>>>>> Anyone else trying to build HEAD of httpd-2.4 with 
>>>>> --enable-maintainer-mode?
>>>>> 
>>> 
>> 
> 

Re: httpd 2.4 and maintainer-mode

[Jim Jagielski]

as mentioned, this is httpd-2.4... I was curious why I seem to be the only one 
whom this hits.

> On Oct 10, 2019, at 9:43 AM, William A Rowe Jr  wrote:
> 
> On Wed, Oct 9, 2019 at 3:42 PM Jim Jagielski  <mailto:j...@jagunet.com>> wrote:
> Just the issues w/ libxml comments:
> 
> In file included from mod_xml2enc.c:38:
> In file included from /usr/local/include/libxml2/libxml/encoding.h:31:
> /usr/local/include/unicode/ucnv.h:1:1: error: // comments are not allowed in 
> this language [-Werror,-Wcomment]
> // Copyright (C) 2016 and later: Unicode, Inc. and others.
> 
> Jim, are you missing 
> http://svn.apache.org/viewvc?view=revision=1867183 
> <http://svn.apache.org/viewvc?view=revision=1867183>
> which you had already fixed the quirk on trunk/?  Seems that clang is being a 
> bit opaque
> about it's identity and confounding the pragmas wrapping our libxml2.h 
> includes.
> 

Re: httpd 2.4 and maintainer-mode

[Jim Jagielski]

I am using MacPorts libxml2. But the issue seems to be w/ libxml2 itself; it is 
the package that uses the '//' comment style. Where does your build grab its 
xml2 stuff from?

> On Oct 10, 2019, at 3:58 AM, Stefan Eissing  
> wrote:
> 
> Compiling trunk and 2.4.x under MacOS Vista, no issues. Some homebrew install?
> 
>> Am 09.10.2019 um 19:04 schrieb Marion & Christophe JAILLET 
>> :
>> 
>> Hi Jim,
>> 
>> I always compile (and test) with --enable-maintainer-mode.
>> 
>> I've just updated my 2.4 branch / make clean / make, and there is nothing 
>> special.
>> 
>> Any specific issue?
>> 
>> CJ
>> 
>> 
>> Le 09/10/2019 à 15:33, Jim Jagielski a écrit :
>>> Anyone else trying to build HEAD of httpd-2.4 with --enable-maintainer-mode?
>>> 
> 

Re: httpd 2.4 and maintainer-mode

[Jim Jagielski]

 included from /usr/local/include/libxml2/libxml/encoding.h:31:
/usr/local/include/unicode/ucnv.h:1:1: error: // comments are not allowed in 
this language [-Werror,-Wcomment]
// Copyright (C) 2016 and later: Unicode, Inc. and others.
^
In file included from mod_proxy_html.c:44:
In file included from /usr/local/include/libxml2/libxml/HTMLparser.h:16:
In file included from /usr/local/include/libxml2/libxml/parser.h:810:
In file included from /usr/local/include/libxml2/libxml/encoding.h:31:
In file included from /usr/local/include/unicode/ucnv.h:52:
/usr/local/include/libxml2/unicode/ucnv_err.h:1:1: error: // comments are not 
allowed in this language [-Werror,-Wcomment]
// Copyright (C) 2016 and later: Unicode, Inc. and others.
^
In file included from mod_proxy_html.c:44:
In file included from /usr/local/include/libxml2/libxml/HTMLparser.h:16:
In file included from /usr/local/include/libxml2/libxml/parser.h:810:
In file included from /usr/local/include/libxml2/libxml/encoding.h:31:
In file included from /usr/local/include/unicode/ucnv.h:52:
In file included from /usr/local/include/libxml2/unicode/ucnv_err.h:88:
/usr/local/include/libxml2/unicode/utypes.h:1:1: error: // comments are not 
allowed in this language [-Werror,-Wcomment]
// Copyright (C) 2016 and later: Unicode, Inc. and others.
^
In file included from mod_proxy_html.c:44:
In file included from /usr/local/include/libxml2/libxml/HTMLparser.h:16:
In file included from /usr/local/include/libxml2/libxml/parser.h:810:
In file included from /usr/local/include/libxml2/libxml/encoding.h:31:
In file included from /usr/local/include/unicode/ucnv.h:52:
In file included from /usr/local/include/libxml2/unicode/ucnv_err.h:88:
In file included from /usr/local/include/libxml2/unicode/utypes.h:38:
/usr/local/include/libxml2/unicode/umachine.h:1:1: error: // comments are not 
allowed in this language [-Werror,-Wcomment]
// Copyright (C) 2016 and later: Unicode, Inc. and others.
^
In file included from mod_proxy_html.c:44:
In file included from /usr/local/include/libxml2/libxml/HTMLparser.h:16:
In file included from /usr/local/include/libxml2/libxml/parser.h:810:
In file included from /usr/local/include/libxml2/libxml/encoding.h:31:
In file included from /usr/local/include/unicode/ucnv.h:52:
In file included from /usr/local/include/libxml2/unicode/ucnv_err.h:88:
In file included from /usr/local/include/libxml2/unicode/utypes.h:38:
In file included from /usr/local/include/libxml2/unicode/umachine.h:46:
/usr/local/include/libxml2/unicode/ptypes.h:1:1: error: // comments are not 
allowed in this language [-Werror,-Wcomment]
// Copyright (C) 2016 and later: Unicode, Inc. and others.
^
In file included from mod_proxy_html.c:44:
In file included from /usr/local/include/libxml2/libxml/HTMLparser.h:16:
In file included from /usr/local/include/libxml2/libxml/parser.h:810:
In file included from /usr/local/include/libxml2/libxml/encoding.h:31:
In file included from /usr/local/include/unicode/ucnv.h:52:
In file included from /usr/local/include/libxml2/unicode/ucnv_err.h:88:
In file included from /usr/local/include/libxml2/unicode/utypes.h:38:
In file included from /usr/local/include/libxml2/unicode/umachine.h:46:
In file included from /usr/local/include/libxml2/unicode/ptypes.h:52:
/usr/local/include/libxml2/unicode/platform.h:1:1: error: // comments are not 
allowed in this language [-Werror,-Wcomment]
// Copyright (C) 2016 and later: Unicode, Inc. and others.
^
In file included from mod_proxy_html.c:44:
In file included from /usr/local/include/libxml2/libxml/HTMLparser.h:16:
In file included from /usr/local/include/libxml2/libxml/parser.h:810:
In file included from /usr/local/include/libxml2/libxml/encoding.h:31:
In file included from /usr/local/include/unicode/ucnv.h:52:
In file included from /usr/local/include/libxml2/unicode/ucnv_err.h:88:
In file included from /usr/local/include/libxml2/unicode/utypes.h:38:
In file included from /usr/local/include/libxml2/unicode/umachine.h:46:
In file included from /usr/local/include/libxml2/unicode/ptypes.h:52:
In file included from /usr/local/include/libxml2/unicode/platform.h:24:
/usr/local/include/libxml2/unicode/uconfig.h:1:1: error: // comments are not 
allowed in this language [-Werror,-Wcomment]
// Copyright (C) 2016 and later: Unicode, Inc. and others.
^


> On Oct 9, 2019, at 1:04 PM, Marion & Christophe JAILLET 
>  wrote:
> 
> Hi Jim,
> 
> I always compile (and test) with --enable-maintainer-mode.
> 
> I've just updated my 2.4 branch / make clean / make, and there is nothing 
> special.
> 
> Any specific issue?
> 
> CJ
> 
> 
> Le 09/10/2019 à 15:33, Jim Jagielski a écrit :
>> Anyone else trying to build HEAD of httpd-2.4 with --enable-maintainer-mode?
>> 

httpd 2.4 and maintainer-mode

[Jim Jagielski]

Anyone else trying to build HEAD of httpd-2.4 with --enable-maintainer-mode?

ACNA20 and Apache https's 25th anniversary

[Jim Jagielski]

Next year will be httpd's 25th anniversary. I think it would be great if the 
web server PMC would commit to having a httpd track at ACNA20...

Anyone else interested? We'd need about 6-7 talks to fill the track.

Migrate to git?

[Jim Jagielski]

Various PMCs have made their default/de-facto SCM git and have seen an increase 
in contributions and contributors...

Is this something the httpd project should consider? Especially w/ the 
foundation officially supporting Github, it seems like time to have a 
discussion about it, especially as we start thinking about the next 25 years of 
this project :)

Cheers!

Problem w/ Revision 1864435

[Jim Jagielski]

This breaks building on macOS:

Making all in filters
/Users/jim/src/asf/code/dev/httpd-trunk/srclib/apr/libtool --silent --mode=link 
gcc -I/usr/local/include/libxml2 -I/usr/local/include -Wall 
-Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -std=c89 
-Werror -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations 
-Wdeclaration-after-statement -Wpointer-arith -Wformat -Wformat-security 
-Wunused -g -O0 -static  -o libmod_data.la mod_data.lo
/Users/jim/src/asf/code/dev/httpd-trunk/srclib/apr/libtool --silent --mode=link 
gcc -I/usr/local/include/libxml2 -I/usr/local/include -Wall 
-Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -std=c89 
-Werror -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations 
-Wdeclaration-after-statement -Wpointer-arith -Wformat -Wformat-security 
-Wunused -g -O0 -static  -o libmod_ratelimit.la mod_ratelimit.lo
/Users/jim/src/asf/code/dev/httpd-trunk/srclib/apr/libtool --silent --mode=link 
gcc -I/usr/local/include/libxml2 -I/usr/local/include -Wall 
-Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -std=c89 
-Werror -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations 
-Wdeclaration-after-statement -Wpointer-arith -Wformat -Wformat-security 
-Wunused -g -O0 -static  -o libmod_reqtimeout.la mod_reqtimeout.lo
/Users/jim/src/asf/code/dev/httpd-trunk/srclib/apr/libtool --silent --mode=link 
gcc -I/usr/local/include/libxml2 -I/usr/local/include -Wall 
-Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -std=c89 
-Werror -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations 
-Wdeclaration-after-statement -Wpointer-arith -Wformat -Wformat-security 
-Wunused -g -O0 -static  -o libmod_ext_filter.la mod_ext_filter.lo
/Users/jim/src/asf/code/dev/httpd-trunk/srclib/apr/libtool --silent --mode=link 
gcc -I/usr/local/include/libxml2 -I/usr/local/include -Wall 
-Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -std=c89 
-Werror -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations 
-Wdeclaration-after-statement -Wpointer-arith -Wformat -Wformat-security 
-Wunused -g -O0 -static  -o libmod_request.la mod_request.lo
/Users/jim/src/asf/code/dev/httpd-trunk/srclib/apr/libtool --silent --mode=link 
gcc -I/usr/local/include/libxml2 -I/usr/local/include -Wall 
-Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -std=c89 
-Werror -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations 
-Wdeclaration-after-statement -Wpointer-arith -Wformat -Wformat-security 
-Wunused -g -O0 -static  -o libmod_include.la mod_include.lo
/Users/jim/src/asf/code/dev/httpd-trunk/srclib/apr/libtool --silent --mode=link 
gcc -I/usr/local/include/libxml2 -I/usr/local/include -Wall 
-Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -std=c89 
-Werror -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations 
-Wdeclaration-after-statement -Wpointer-arith -Wformat -Wformat-security 
-Wunused -g -O0 -static  -o libmod_filter.la mod_filter.lo
/Users/jim/src/asf/code/dev/httpd-trunk/srclib/apr/libtool --silent --mode=link 
gcc -I/usr/local/include/libxml2 -I/usr/local/include -Wall 
-Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -std=c89 
-Werror -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations 
-Wdeclaration-after-statement -Wpointer-arith -Wformat -Wformat-security 
-Wunused -g -O0 -static  -o libmod_reflector.la mod_reflector.lo
/Users/jim/src/asf/code/dev/httpd-trunk/srclib/apr/libtool --silent --mode=link 
gcc -I/usr/local/include/libxml2 -I/usr/local/include -Wall 
-Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -std=c89 
-Werror -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations 
-Wdeclaration-after-statement -Wpointer-arith -Wformat -Wformat-security 
-Wunused -g -O0 -static  -o libmod_substitute.la mod_substitute.lo
/Users/jim/src/asf/code/dev/httpd-trunk/srclib/apr/libtool --silent --mode=link 
gcc -I/usr/local/include/libxml2 -I/usr/local/include -Wall 
-Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -std=c89 
-Werror -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations 
-Wdeclaration-after-statement -Wpointer-arith -Wformat -Wformat-security 
-Wunused -g -O0 -static  -o libmod_sed.la mod_sed.lo sed0.lo sed1.lo 
regexp.lo
/Users/jim/src/asf/code/dev/httpd-trunk/srclib/apr/libtool --silent --mode=link 
gcc -I/usr/local/include/libxml2 -I/usr/local/include -Wall 
-Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -std=c89 
-Werror -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations 
-Wdeclaration-after-statement -Wpointer-arith -Wformat -Wformat-security 
-Wunused -g -O0 -static  -o libmod_charset_lite.la mod_charset_lite.lo
/Users/jim/src/asf/code/dev/httpd-trunk/srclib/apr/libtool --silent --mode=link 
gcc -I/usr/local/include/libxml2 

Suggestions

[Jim Jagielski]

Any suggestions or recommendation for features, capabilities, etc that I should 
make sure to include in my Apache httpd 2.4 overview preso at ACNA19 next week 
(or my reverse proxy one)??

Cheers!

Re: [PATCH 63503] - Reverse proxy server - SIGSEGV

[Jim Jagielski]

Via inspection this looks quite sane.

> On Aug 12, 2019, at 3:24 PM, Eric Covener  wrote:
> 
> Hi Don, can you try this very similar patch? I applied yours to my
> sandbox to get more context and made a few minor changes (including
> pre-existing stuff that looked misleading)
> 
> http://people.apache.org/~covener/trunk-proxy-segv.diff
> 
> 

Re: [VOTE] Release httpd-2.4.41

[Jim Jagielski]

Tested:

  o macOS 10.14.6, Xcode 10.3 (64bit)
  o CentOS 5, 6 (64bit)
  o Ubuntu 14.04 LTS (64bit)

All +1: no regressions.

Thanks for RMing!

> On Aug 9, 2019, at 9:40 AM, 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.41:
> [ ] +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: b713e835aa7cde823a4b7f8e3463164f3d9fe63e *httpd-2.4.41.tar.gz
> sha256: 3c0f9663240beb0f008acf3b4501c4f339d7467ee345a36c86c46b4d6f3a5461 
> *httpd-2.4.41.tar.gz
> -- 
> Daniel Ruggeri

Re: [VOTE] Release httpd-2.4.40

[Jim Jagielski]

I vote -1 due to the known issue w/ building and running mod_md.

Yes, it's not a regression, but the fix is easy and version numbers are cheap. 
We should release the best possible version each time.

Let's mark 2.4.40 DOA and release 2.4.41 w/ the patch.

> On Aug 3, 2019, at 9:51 AM, 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.40:
> [ ] +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: 31bc6f87ac209010b8b364abc1c80dfaee53cc64 *httpd-2.4.40.tar.gz
> sha256: 451e6cf6caa09119900b74652266427f70050de5c51948acd4aaaf60d0d3cad0
> *httpd-2.4.40.tar.gz
> 
> -- 
> Daniel Ruggeri
> 

Re: release?

[Jim Jagielski]

> On Jul 19, 2019, at 7:41 AM, Daniel Ruggeri  wrote:
> 
> Argh. I guess my mail client ate my response.
> 
> I replied yesterday with a +1 and offered to begin the process Friday (a week 
> from today).
> 
> I am available for being RM since the heavy lifting is scripted, but if you 
> would prefer to, it's all yours, Jim :-)
> 

I wouldn't mind giving it a spin... might be a good way to get a wider UX on 
the scripting.

> Happy weekend!
> -- 
> Daniel Ruggeri
> 
> On July 19, 2019 6:34:10 AM CDT, Jim Jagielski  wrote:
> +1. If Daniel doesn't have the time, I can.
> 
> On Jul 18, 2019, at 10:06 AM, Stefan Eissing  
> wrote:
> 
> It would be great if we could make a release this month. There are several 
> fixes and improvements already backported and a few outstanding issues that 
> need a vote or two. 
> 
> Please have a look if you find the time. I think Daniel expressed willingness 
> to RM this? That'd be great!
> 
> Cheers, Stefan
> 

Re: release?

[Jim Jagielski]

+1. If Daniel doesn't have the time, I can.

> On Jul 18, 2019, at 10:06 AM, Stefan Eissing  
> wrote:
> 
> It would be great if we could make a release this month. There are several 
> fixes and improvements already backported and a few outstanding issues that 
> need a vote or two. 
> 
> Please have a look if you find the time. I think Daniel expressed willingness 
> to RM this? That'd be great!
> 
> Cheers, Stefan

Re: Arranging mod_proxy_balancer to make it provider of balancer/worker.

[Jim Jagielski]

Go for it!

> On May 14, 2019, at 3:40 AM, jean-frederic clere  wrote:
> 
> Hi,
> 
> I would like to be able to add worker/balancer from another module
> (mod_proxy_cluster) basically using a part of balancer_handler() to make
> a provider (like insert_update_worker(params)), any objections or
> suggestions?
> 
> -- 
> Cheers
> 
> Jean-Frederic

Re: ApacheCon call for presentations, httpd content

[Jim Jagielski]

I can always do my "httpd 2.4 overview" as well as my "httpd 2.4 reverse proxy" 
talk.

> On May 2, 2019, at 10:39 AM, Daniel Ruggeri  wrote:
> 
> Hi, Rich;
>   I was looking at the CFP and didn't quite see something that aligns with 
> httpd. These are the categories allowed:
> General
> Community
> Tomcat
> Big Data
> Machine Learning
> IoT
> Geospatial
> Cassandra
> Traffic Control Summit
> Cloudstack Collaboration Conference
> Integration
> Graph Processing
> Karaf
> Drill
> Observability
> Beam
> 
> *maybe* that has has an effect on folks' submissions? Dunno... I just 
> submitted in "general"
> -- 
> Daniel Ruggeri
> 
> On 2019/05/01 20:35:49, Rich Bowen  wrote: 
>> Hi, folks.
>> 
>> The call for presentations for ApacheCon North America closes in a
>> little less than two weeks. As of right now, as far as I can tell, there
>> is exactly zero httpd content.
>> 
>> If we want to have our project represented at ApacheCon this year, what
>> would you want to see? Is there any chance we can fill a half-day of
>> content (ie, 3-4 talks) with what new things have happened in the past
>> year, and what's important now?
>> 
>> Personally, I'd like to see a presentation on using mod_md, and perhaps
>> something on the benefits of, and use of, http2 in httpd?
>> 
>> The CFP is here - https://www.apachecon.com/acna19/cfp.html - and closes
>> May 13th.
>> 
>> Thanks!
>> 
>> --Rich
>> 

Re: [VOTE] Release httpd-2.4.39

[Jim Jagielski]

My own..

Cheers!

> On Mar 28, 2019, at 10:00 AM, Plüm, Rüdiger, Vodafone Group 
>  wrote:
> 
> What pcre lib did you use on CentOS5? The one provided by CentOS or your own?
>  
> Regards
>  
> Rüdiger
>  
>  
> C2 General
> Von: Jim Jagielski  
> Gesendet: Donnerstag, 28. März 2019 14:52
> An: httpd 
> Betreff: Re: [VOTE] Release httpd-2.4.39
>  
> Yep, CentOS5. Mostly due to the fact that regressions would likely show up 
> more readily on older OSs rather than newer ones.
>  
> Plus, there's still a crap-ton of systems using CentOS5/RHEL5
>  
> 
> On Mar 28, 2019, at 8:51 AM, Plüm, Rüdiger, Vodafone Group 
> mailto:ruediger.pl...@vodafone.com>> wrote:
>  
> 
> 
> 
> C2 General
> 
> 
> -Ursprüngliche Nachricht-
> Von: Jim Jagielski mailto:j...@jagunet.com>>
> Gesendet: Donnerstag, 28. März 2019 13:39
> An: httpd mailto:dev@httpd.apache.org>>
> Betreff: Re: [VOTE] Release httpd-2.4.39
> 
> 
> 
> On Mar 27, 2019, at 11:09 AM, Daniel Ruggeri  <mailto:drugg...@primary.net>>
> wrote:
> 
> 
> Hi, all;
>  Please find below the proposed release tarball and signatures:
> https://dist.apache.org/repos/dist/dev/httpd/ 
> <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.39:
> 
> [ ] +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: e66d6bfea42254e64d3b5009f49ecc486ac46de2 *httpd-2.4.39.tar.gz
> sha256:
> 8b95fe249f3a6c50aad3ca125eef3e02d619116cde242e1bc3c266b7b5c37c30 *httpd-
> 2.4.39.tar.gz
> 
> 
> --
> Daniel Ruggeri
> 
> Tested and passed on the following systems (no regressions):
> 
>  o macOS 10.14.4, Xcode 10.2
>  o CentOS 5, 64bit
> 
> Really CentOS 5? Just asking because it does not receive further OS updates 
> and I wouldn't recommend to use it any longer.
> 
> Regards
> 
> Rüdiger

Re: [VOTE] Release httpd-2.4.39

[Jim Jagielski]

Yep, CentOS5. Mostly due to the fact that regressions would likely show up more 
readily on older OSs rather than newer ones.

Plus, there's still a crap-ton of systems using CentOS5/RHEL5

> On Mar 28, 2019, at 8:51 AM, Plüm, Rüdiger, Vodafone Group 
>  wrote:
> 
> 
> 
> 
> C2 General
> 
>> -Ursprüngliche Nachricht-
>> Von: Jim Jagielski 
>> Gesendet: Donnerstag, 28. März 2019 13:39
>> An: httpd 
>> Betreff: Re: [VOTE] Release httpd-2.4.39
>> 
>> 
>>> On Mar 27, 2019, at 11:09 AM, 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.39:
>>> [ ] +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: e66d6bfea42254e64d3b5009f49ecc486ac46de2 *httpd-2.4.39.tar.gz
>>> sha256:
>> 8b95fe249f3a6c50aad3ca125eef3e02d619116cde242e1bc3c266b7b5c37c30 *httpd-
>> 2.4.39.tar.gz
>>> 
>>> --
>>> Daniel Ruggeri
>> 
>> Tested and passed on the following systems (no regressions):
>> 
>>  o macOS 10.14.4, Xcode 10.2
>>  o CentOS 5, 64bit
> 
> Really CentOS 5? Just asking because it does not receive further OS updates 
> and I wouldn't recommend to use it any longer.
> 
> Regards
> 
> Rüdiger

Re: [VOTE] Release httpd-2.4.39

[Jim Jagielski]

> On Mar 27, 2019, at 11:09 AM, 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.39:
> [ ] +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: e66d6bfea42254e64d3b5009f49ecc486ac46de2 *httpd-2.4.39.tar.gz
> sha256: 8b95fe249f3a6c50aad3ca125eef3e02d619116cde242e1bc3c266b7b5c37c30 
> *httpd-2.4.39.tar.gz
> 
> -- 
> Daniel Ruggeri

Tested and passed on the following systems (no regressions):

  o macOS 10.14.4, Xcode 10.2
  o CentOS 5, 64bit
  o CentOS 6, 64bit
  o Fedora 23, 64bit

+1 for release! Thx for RMing.

Re: http://svn.apache.org/r1850745

[Jim Jagielski]

> On Mar 13, 2019, at 11:04 AM, William A Rowe Jr  wrote:
> 
> 
> As you can see, you didn't modify only modules/filters/ ... Maybe you 
> meant to modify MOD_CPPFLAGS, as modules/http2/modules.mak does?
>  

If that will solve the issue I'm all for it!

Thx.

Re: http://svn.apache.org/r1850745

[Jim Jagielski]

> On Mar 13, 2019, at 8:51 AM, Yann Ylavic  wrote:
> 
> On Wed, Mar 13, 2019 at 1:45 PM Eric Covener  wrote:
>> 
>> On Wed, Mar 13, 2019 at 8:43 AM Jim Jagielski  wrote:
>>> 
>>> Is there anyone else building 2.4 on macOS under maintainer-mode
>>> who is also being affected by the above? The fact that I seem to
>>> be the anyone "complaining" :) seems weird...
>> 
>> FWIW Looks like I have maintainer mode but not libxml2
> 
> Maintainer mode and libxml2 here, but not macOS :)

Yeah, I also think it depends on the version of clang... previous versions did 
not flag

/usr/local/include/unicode/uenum.h:1:1: error: // comments are not allowed 
in this language [-Werror,-Wcomment]

as fatal errors.

Re: http://svn.apache.org/r1850745

[Jim Jagielski]

It's libxml2 from MacPorts... which is basically vanilla libxml2.

APR is 1.6.x

> On Mar 13, 2019, at 8:56 AM, Nick Kew  wrote:
> 
> 
> 
>> On 13 Mar 2019, at 12:43, Jim Jagielski  wrote:
>> 
>> Is there anyone else building 2.4 on macOS under maintainer-mode
>> who is also being affected by the above? The fact that I seem to
>> be the anyone "complaining" :) seems weird...
>> 
>> Thx!
> 
> Just out of interest, is that with a libxml2-enabled APR version?
> Guess I need to test-drive that on Mac/latest, which has bitten me
> on similar platform issues before now!
> 
> -- 
> Nick Kew
> 

http://svn.apache.org/r1850745

[Jim Jagielski]

Is there anyone else building 2.4 on macOS under maintainer-mode
who is also being affected by the above? The fact that I seem to
be the anyone "complaining" :) seems weird...

Thx!

Re: lmdb, load-balancing, Sharing data about worker nodes among processes and threads in httpd

[Jim Jagielski]

One of the reasons we use mod_slotmem for load-balancing is that it
allows for other storage mechanisms to be used rather than shared memory...
mod_slotmem uses the httpd provider mechanism to extend the underlying
implementation. As such, we could use LMDB, Geode,  as our
shared storage.

> On Feb 18, 2019, at 4:56 AM, Michal Karm  wrote:
> 
> Hello,
> 
> Over the years spent on and off with mod_proxy_cluster [1]
> it has always been a problem and a bottleneck to maintain
> fresh shared information among httpd's processes and threads
> about joining _and leaving_ workers. Especially when the number
> of workers is in many hundreds and the joining/leaving fluctuation
> is a regular ongoing activity.
> 
> The implementation is basically shm/slotmem with all its
> boons and banes.
> 
> 
> QUESTIONS:
> 
> 1) Would it make sense to get rid of all shm and offload the information
> sharing for these highly dynamic load balancing scenarios to LMDB [2]?
> 
> I learned about LMDB while working with Knot Resolver [3]. Knot Resolver
> is a modern high-performance resolver (CZ-NIC uses it in our Czech TLD
> infrastructure).
> It scales with processes using event loop - and all its processes share a 
> cache of
> resolved domains [4]. Over the years LMDB emerged as the winning backend for
> that cache.
> 
> 
> 2) Given its license [5], would it ever be even possible for httpd trunk
> to depend on it?
> 
> 
> 3) Is there any similar ongoing effort? I remember Jim's notes on nng
> for messaging between workers and balancers. But I don't think he meant
> it to also serve for httpd processes to exchange information about workers...?
> Did you? :)
> 
> 
> 4) Does it even make sense to be spending any time with anything like this
> or is it a solved problem in some mod_proxy* library I am missing?
> 
> 
> Cheers
> K.
> 
> [1] http://modcluster.io/
> [2] https://en.wikipedia.org/wiki/Lightning_Memory-Mapped_Database
> [3] https://github.com/CZ-NIC/knot-resolver
> [4] https://knot-resolver.readthedocs.io/en/stable/daemon.html
> [5] http://www.openldap.org/software/release/license.html
> [6] https://github.com/nanomsg/nng
> 
> Michal Karm Babacek
> 
> -- 
> Sent from my Hosaka Ono-Sendai Cyberspace 7
> 
> 

Re: http workshop

[Jim Jagielski]

i could present

> On Jan 28, 2019, at 10:21 AM, Stefan Eissing  
> wrote:
> 
> The HTTP Workshop is returning 2019 on April 2-4 in Amsterdam 
> (https://github.com/httpworkshop/workshop2019). While I attended the last 
> three shops(?), I think it would be a good opportunity for someone else from 
> the team to go there and meet some smart and friendly people from the HTTP 
> world.
> 
> The HTTP WS organisers expressed the wish to have someone from "Apache" 
> present. Anyone interested? Could also be someone from another HTTP related 
> Apache project, of course.
> 
> Cheers,
> 
> Stefan

Re: Latest test builds

[Jim Jagielski]

sorry wrong list

> On Jan 19, 2019, at 8:16 PM, Jim Jagielski  wrote:
> 
> I've uploaded the latest test builds for macOS and Linux 64.
> These are based on ~r1851640 and include 2 main updates from
> the earlier one:
> 
>  o beanshell now included
>  o macOS path bug should now be squashed 
> (https://bz.apache.org/ooo/show_bug.cgi?id=127965)
> 
> Let me know if anyone wants me to kick off a Linux 32bit
> build.
> 
> Find them here:
> 
>  http://home.apache.org/~jim/AOO-builds/4.2.0-dev-r1851640/
> 
> Cheers!

Latest test builds

[Jim Jagielski]

I've uploaded the latest test builds for macOS and Linux 64.
These are based on ~r1851640 and include 2 main updates from
the earlier one:

  o beanshell now included
  o macOS path bug should now be squashed 
(https://bz.apache.org/ooo/show_bug.cgi?id=127965)

Let me know if anyone wants me to kick off a Linux 32bit
build.

Find them here:

  http://home.apache.org/~jim/AOO-builds/4.2.0-dev-r1851640/

Cheers!

Re: [VOTE] Release httpd-2.4.38

[Jim Jagielski]

+1: Tested on:

  o macOS 10.14.2, Xcode 10.1
  o CentOS7

Will do more testing today but so far, so good.

Thx for RMing!

> On Jan 17, 2019, at 1:49 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.38:
> [ ] +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: 6ee19a7b936a6ddbbf81b313c4a8b38bf232b40e *httpd-2.4.38.tar.gz
> sha256: 38d0b73aa313c28065bf58faf64cec12bf7c7d5196146107df2ad07541aa26a6 
> *httpd-2.4.38.tar.gz
> 
> -- 
> Daniel Ruggeri

Re: [VOTE] Release httpd-2.4.28

[Jim Jagielski]

Ahhh good.

> On Jan 17, 2019, at 12:46 PM, Yann Ylavic  wrote:
> 
> On Thu, Jan 17, 2019 at 6:44 PM Jim Jagielski  wrote:
>> 
>> Note that simply changing the commit msg logs does not solve the problem. 
>> There is,
>> in fact, no 2.4.38 tag at all. And I'm guessing we destroyed the "real" 
>> 2.4.28 tag... :(
> 
> Fortunately it just created tags/2.4.28/2.4.x since tags/2.4.28 existed 
> already.

Re: [VOTE] Release httpd-2.4.28

[Jim Jagielski]

Note that simply changing the commit msg logs does not solve the problem. There 
is,
in fact, no 2.4.38 tag at all. And I'm guessing we destroyed the "real" 2.4.28 
tag... :(

Re: [VOTE] Release httpd-2.4.28

[Jim Jagielski]

Shouldn't this be 2.4.38??

> On Jan 17, 2019, at 12:13 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.28:
> [ ] +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: 87d389fca46620ac165f8d659ba0bc8180532114 *httpd-2.4.28.tar.gz
> sha256: 216e3ee1dbd8d62f16155dff7a8aac7c6dbc6532954bec6cb8966a46f9819a23 
> *httpd-2.4.28.tar.gz
> 
> -- 
> Daniel Ruggeri

Re: svn commit: r1851549 - /httpd/httpd/tags/2.4.28/2.4.x/

[Jim Jagielski]

2.4.28?

> On Jan 17, 2019, at 12:08 PM, drugg...@apache.org wrote:
> 
> Author: druggeri
> Date: Thu Jan 17 17:08:22 2019
> New Revision: 1851549
> 
> URL: http://svn.apache.org/viewvc?rev=1851549=rev
> Log:
> Tag HEAD of 2.4.x as 2.4.28
> 
> Added:
>httpd/httpd/tags/2.4.28/2.4.x/   (props changed)
>  - copied from r1851548, httpd/httpd/branches/2.4.x/
> 
> Propchange: httpd/httpd/tags/2.4.28/2.4.x/
> --
> --- svn:ignore (added)
> +++ svn:ignore Thu Jan 17 17:08:22 2019
> @@ -0,0 +1,45 @@
> +config.nice
> +configure
> +missing
> +install-sh
> +mkinstalldirs
> +aclocal.m4
> +.deps
> +generated_lists
> +buildmk.stamp
> +config.log
> +Makefile
> +libtool
> +shlibtool
> +config.status
> +modules.c
> +config.cache
> +.libs
> +httpd
> +httpd.exe
> +modules.lo
> +Debug
> +Release
> +LibD
> +LibR
> +Apache.suo
> +Apache.ncb
> +Apache.opt
> +apachecore.dll
> +*.x
> +*.aps
> +*.plg
> +*.dep
> +*.mak
> +*.rc
> +Apache.sln
> +BuildLog.htm
> +*.stc
> +*.stt
> +*.sto
> +*.vcproj
> +*.vcproj.*
> +autom4te.cache
> +httpd.spec
> +tags
> +TAGS
> 
> Propchange: httpd/httpd/tags/2.4.28/2.4.x/
> --
> --- svn:mergeinfo (added)
> +++ svn:mergeinfo Thu Jan 17 17:08:22 2019
> @@ -0,0 +1,11 @@
> +/httpd/httpd/branches/2.4.17-protocols-changes:1712542-1715252
> +/httpd/httpd/branches/2.4.17-protocols-http2:1701609-1705681
> +/httpd/httpd/branches/2.4.x-mod_md:1816423-1821089
> +/httpd/httpd/branches/2.4.x-mpm_fdqueue:1824383-1824864
> +/httpd/httpd/branches/revert-ap-ldap:1150158-1150173
> +/httpd/httpd/branches/tlsv1.3-for-2.4.x:1840105-1841571
> +/httpd/httpd/branches/trunk-buildconf-noapr:1780253-1795930
> +/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,1341905-1341906,1341913,1341930,1342065,1343085,1343087,1343094,1343099,1343109,1343935,1344712,1345147,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,1369
> 

Re: svn commit: r1850745 - /httpd/httpd/trunk/modules/filters/config.m4

[Jim Jagielski]

I specifically didn't use  #pragma GCC diagnostic push
in order to avoid this exact kind of discussion...

> On Jan 16, 2019, at 4:46 PM, Jim Jagielski  wrote:
> 
> I'm sorry but I'm confused. The patch is as specific as you can get. It just 
> adds the minimal option and JUST for filters and JUST if libxml2 is part of 
> the build. Anything else seems more disruptive than that. So why are the more 
> disruptive changes preferred? I'm just trying to understand the logic there.
> 
>> On Jan 16, 2019, at 4:24 PM, William A Rowe Jr  wrote:
>> 
>> In case my opinion wasn't clear, I'm +1 to any of the proposed choices,
>> but I'm also partial to choice 2 or 1, at least add -Wno-error=comment
>> in maintainer mode, or simply switch to -std=c99 presuming that more 
>> and more of the system headers follow c99 syntax over time. 
>> And revert the tweak of modules/filters/config.m4.
>> 
>> On Wed, Jan 16, 2019 at 3:39 AM Plüm, Rüdiger, Vodafone Group 
>>  wrote:
>> 
>> C2 General
>> 
>> > -Ursprüngliche Nachricht-
>> > Von: Stefan Eissing 
>> > Gesendet: Mittwoch, 16. Januar 2019 10:00
>> > An: dev@httpd.apache.org
>> > Betreff: Re: svn commit: r1850745 -
>> > /httpd/httpd/trunk/modules/filters/config.m4
>> > 
>> > 
>> > 
>> > > Am 16.01.2019 um 03:33 schrieb William A Rowe Jr > > clan.net>:
>> > >
>> > > On Tue, Jan 15, 2019 at 8:37 AM Jim Jagielski  wrote:
>> > >
>> > > > On Jan 15, 2019, at 9:21 AM, Eric Covener  wrote:
>> > > >
>> > > > On Tue, Jan 15, 2019 at 9:14 AM Jim Jagielski 
>> > wrote:
>> > > >>
>> > > >> On Jan 9, 2019, at 7:41 PM, William A Rowe Jr 
>> > wrote:
>> > > >>
>> > > >> Hi Jim,
>> > > >>
>> > > >> Does CFLAGS -std=c99 solve your issue? It seems to work here. I'm
>> > building on the Fedora 29, largely frozen end-of-july. Reverting the
>> > patch below and toggling -std=c89 to -std=c99 in configure.in building
>> > all but two modules from trunk is building clean, and results in this
>> > command for error checking;
>> > > >> /usr/lib64/apr-1/build/libtool --silent --mode=compile gcc  -
>> > pthread -std=c99 -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
>> > > >>
>> > > >> Is it reasonable to enforce c99 limitations at this late date? I'm
>> > not suggesting we change the general builds from c89 in the 2.4 branch,
>> > but that is something we might want to consider for trunk, 20 years out.
>> > > >>
>> > > >>
>> > > >> Personally, I'd be fine allowing c99 in both 2.4 and trunk,
>> > considering that we are in 2019 already :)
>> > > >>
>> > > >> Any platform that lacks a c99 compatible CC likely doesn't build
>> > anyway.
>> > > >
>> > > > As a binary distributor, even though a C99 compiler may be available
>> > > > on platform X, it might not be in use.  Wouldn't love seeing it in
>> > > > 2.4.
>> > >
>> > > I'm not proposing a change for 2.4... but I wouldn't oppose it either
>> > :)
>> > >
>> > > Allowing c99 for trunk would make backporting to 2.4 (which would stay
>> > c89) possibly more difficult. This is either a good thing or a bad
>> > thing. So far, however, iirc we have not had any issues sticking with
>> > c89 and I don't think the above would warrant such a change. IMO of
>> > course.
>> > >
>> > > I might not have been clear, above. I'm not suggesting changing things
>> > for the
>> > > customary build, leave that (at least on httpd 2.4) as -std=c89. I
>> > think we should
>> > > have this discussion of when we will begin accepting c99 source
>> > patches, but
>> > > that isn't the immediate problem you've tripped over.
>> > >
>> > > I see several options;
>> > >
>> > >   Only for maintainer mode, where we are strictly handling all errors,
>> > always
>> > >   accept all -std=c99 behaviors (fix any legacy pre-c99 issues that
>> > may arise.)
>> > >   All the system headers using c99 (or earlier) semantics should
>>

Re: svn commit: r1850745 - /httpd/httpd/trunk/modules/filters/config.m4

[Jim Jagielski]

I'm sorry but I'm confused. The patch is as specific as you can get. It just 
adds the minimal option and JUST for filters and JUST if libxml2 is part of the 
build. Anything else seems more disruptive than that. So why are the more 
disruptive changes preferred? I'm just trying to understand the logic there.

> On Jan 16, 2019, at 4:24 PM, William A Rowe Jr  wrote:
> 
> In case my opinion wasn't clear, I'm +1 to any of the proposed choices,
> but I'm also partial to choice 2 or 1, at least add -Wno-error=comment
> in maintainer mode, or simply switch to -std=c99 presuming that more 
> and more of the system headers follow c99 syntax over time. 
> And revert the tweak of modules/filters/config.m4.
> 
> On Wed, Jan 16, 2019 at 3:39 AM Plüm, Rüdiger, Vodafone Group 
> mailto:ruediger.pl...@vodafone.com>> wrote:
> 
> C2 General
> 
> > -Ursprüngliche Nachricht-
> > Von: Stefan Eissing  > <mailto:stefan.eiss...@greenbytes.de>>
> > Gesendet: Mittwoch, 16. Januar 2019 10:00
> > An: dev@httpd.apache.org <mailto:dev@httpd.apache.org>
> > Betreff: Re: svn commit: r1850745 -
> > /httpd/httpd/trunk/modules/filters/config.m4
> > 
> > 
> > 
> > > Am 16.01.2019 um 03:33 schrieb William A Rowe Jr  > clan.net <http://clan.net/>>:
> > >
> > > On Tue, Jan 15, 2019 at 8:37 AM Jim Jagielski  > > <mailto:j...@jagunet.com>> wrote:
> > >
> > > > On Jan 15, 2019, at 9:21 AM, Eric Covener  > > > <mailto:cove...@gmail.com>> wrote:
> > > >
> > > > On Tue, Jan 15, 2019 at 9:14 AM Jim Jagielski  > > > <mailto:j...@jagunet.com>>
> > wrote:
> > > >>
> > > >> On Jan 9, 2019, at 7:41 PM, William A Rowe Jr  > > >> <mailto:wr...@rowe-clan.net>>
> > wrote:
> > > >>
> > > >> Hi Jim,
> > > >>
> > > >> Does CFLAGS -std=c99 solve your issue? It seems to work here. I'm
> > building on the Fedora 29, largely frozen end-of-july. Reverting the
> > patch below and toggling -std=c89 to -std=c99 in configure.in 
> > <http://configure.in/> building
> > all but two modules from trunk is building clean, and results in this
> > command for error checking;
> > > >> /usr/lib64/apr-1/build/libtool --silent --mode=compile gcc  -
> > pthread -std=c99 -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
> > > >>
> > > >> Is it reasonable to enforce c99 limitations at this late date? I'm
> > not suggesting we change the general builds from c89 in the 2.4 branch,
> > but that is something we might want to consider for trunk, 20 years out.
> > > >>
> > > >>
> > > >> Personally, I'd be fine allowing c99 in both 2.4 and trunk,
> > considering that we are in 2019 already :)
> > > >>
> > > >> Any platform that lacks a c99 compatible CC likely doesn't build
> > anyway.
> > > >
> > > > As a binary distributor, even though a C99 compiler may be available
> > > > on platform X, it might not be in use.  Wouldn't love seeing it in
> > > > 2.4.
> > >
> > > I'm not proposing a change for 2.4... but I wouldn't oppose it either
> > :)
> > >
> > > Allowing c99 for trunk would make backporting to 2.4 (which would stay
> > c89) possibly more difficult. This is either a good thing or a bad
> > thing. So far, however, iirc we have not had any issues sticking with
> > c89 and I don't think the above would warrant such a change. IMO of
> > course.
> > >
> > > I might not have been clear, above. I'm not suggesting changing things
> > for the
> > > customary build, leave that (at least on httpd 2.4) as -std=c89. I
> > think we should
> > > have this discussion of when we will begin accepting c99 source
> > patches, but
> > > that isn't the immediate problem you've tripped over.
> > >
> > > I see several options;
> > >
> > >   Only for maintainer mode, where we are strictly handling all errors,
> > always
> > >   accept all -std=c99 behaviors (fix any legacy pre-c99 issues that
> > may arise.)
> > >   All the system headers using c99 (or earlier) semantics should
> > behave well.
> > >
> > >   Or, for maintainer mode, always relax the comments restriction only
> > so we
>

Re: svn commit: r1850745 - /httpd/httpd/trunk/modules/filters/config.m4

[Jim Jagielski]

> On Jan 15, 2019, at 9:21 AM, Eric Covener  wrote:
> 
> On Tue, Jan 15, 2019 at 9:14 AM Jim Jagielski  wrote:
>> 
>> 
>> 
>> On Jan 9, 2019, at 7:41 PM, William A Rowe Jr  wrote:
>> 
>> Hi Jim,
>> 
>> Does CFLAGS -std=c99 solve your issue? It seems to work here. I'm building 
>> on the Fedora 29, largely frozen end-of-july. Reverting the patch below and 
>> toggling -std=c89 to -std=c99 in configure.in building all but two modules 
>> from trunk is building clean, and results in this command for error checking;
>> /usr/lib64/apr-1/build/libtool --silent --mode=compile gcc  -pthread 
>> -std=c99 -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
>> 
>> Is it reasonable to enforce c99 limitations at this late date? I'm not 
>> suggesting we change the general builds from c89 in the 2.4 branch, but that 
>> is something we might want to consider for trunk, 20 years out.
>> 
>> 
>> Personally, I'd be fine allowing c99 in both 2.4 and trunk, considering that 
>> we are in 2019 already :)
>> 
>> Any platform that lacks a c99 compatible CC likely doesn't build anyway.
> 
> As a binary distributor, even though a C99 compiler may be available
> on platform X, it might not be in use.  Wouldn't love seeing it in
> 2.4.

I'm not proposing a change for 2.4... but I wouldn't oppose it either :)

Allowing c99 for trunk would make backporting to 2.4 (which would stay c89) 
possibly more difficult. This is either a good thing or a bad thing. So far, 
however, iirc we have not had any issues sticking with c89 and I don't think 
the above would warrant such a change. IMO of course.

Re: [NOTICE] Intent to T 2.4.28

[Jim Jagielski]

Could I please get one more vote on adding in mod_socache_redis from trunk...

It's been waiting for several releases by now.

> On Jan 15, 2019, at 7:27 AM, Daniel Ruggeri  wrote:
> 
> Hi, all;
> It's been a while since we've rolled a release and we've had some recent 
> movement, so I'd like to propose T of 2.4.38 in the next day or two. I'll 
> plan to proceed Thursday morning (US Central).
> -- 
> Daniel Ruggeri

Re: svn commit: r1850745 - /httpd/httpd/trunk/modules/filters/config.m4

[Jim Jagielski]

> On Jan 9, 2019, at 7:41 PM, William A Rowe Jr  wrote:
> 
> Hi Jim,
> 
> Does CFLAGS -std=c99 solve your issue? It seems to work here. I'm building on 
> the Fedora 29, largely frozen end-of-july. Reverting the patch below and 
> toggling -std=c89 to -std=c99 in configure.in  building 
> all but two modules from trunk is building clean, and results in this command 
> for error checking;
> /usr/lib64/apr-1/build/libtool --silent --mode=compile gcc  -pthread -std=c99 
> -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
> 
> Is it reasonable to enforce c99 limitations at this late date? I'm not 
> suggesting we change the general builds from c89 in the 2.4 branch, but that 
> is something we might want to consider for trunk, 20 years out.

Personally, I'd be fine allowing c99 in both 2.4 and trunk, considering that we 
are in 2019 already :)

Any platform that lacks a c99 compatible CC likely doesn't build anyway.

Re: [PATCH] fix test/mod_dialup.c for non-threaded APR

[Jim Jagielski]

+1 by me.

> On Jan 8, 2019, at 7:09 AM, Stefan Sperling  wrote:
> 
> See https://svn.apache.org/r1663375 for a related fix by covener.
> Which, by the way, should probably be backported to 2.4; I see a failure
> on a buildbot which deliberately builds with non-threaded APR to ensure
> that this configuration remains in SVN's test matrix:
> https://ci.apache.org/builders/svn-bb-openbsd/builds/272/steps/Build/logs/stdio
> 
> This patch hasn't even been compile tested but looks obvious enough.
> Fine to commit?
> 
> Index: modules/test/mod_dialup.c
> ===
> --- modules/test/mod_dialup.c (revision 1850735)
> +++ modules/test/mod_dialup.c (working copy)
> @@ -107,7 +107,9 @@ dialup_callback(void *baton)
> dialup_baton_t *db = (dialup_baton_t *)baton;
> conn_rec *c = db->r->connection;
> 
> +#if APR_HAS_THREADS
> apr_thread_mutex_lock(db->r->invoke_mtx);
> +#endif
> 
> status = dialup_send_pulse(db);
> 
> @@ -115,7 +117,9 @@ dialup_callback(void *baton)
> ap_mpm_register_timed_callback(apr_time_from_sec(1), dialup_callback, 
> baton);
> }
> else if (status == DONE) {
> +#if APR_HAS_THREADS
> apr_thread_mutex_unlock(db->r->invoke_mtx);
> +#endif
> ap_finalize_request_protocol(db->r);
> ap_process_request_after_handler(db->r);
> return;
> @@ -127,7 +131,9 @@ dialup_callback(void *baton)
> ap_die(status, db->r);
> }
> 
> +#if APR_HAS_THREADS
> apr_thread_mutex_unlock(db->r->invoke_mtx);
> +#endif
> 
> ap_mpm_resume_suspended(c);
> }

Jim's been busy

[Jim Jagielski]

I've been slammed both at work and personal and haven't had
time to do much httpd stuff... just a FYI in case people were
curious. Should free up by the end of the month.

Re: Plan to add sandbox branch

[Jim Jagielski]

Hmmm... this has me thinking about maybe using the provider interface to 
implement the communication mechanism... let me mull this over.

> On Nov 30, 2018, at 8:27 AM, Jim Jagielski  wrote:
> 
> Yeah, I looked for something else, esp various pubsub implementations, but 
> they really didn't fit in with what was needed.
> 
> 
>> On Nov 29, 2018, at 3:02 AM, jean-frederic clere  wrote:
>> 
>> On 29/11/2018 07:02, Christophe JAILLET wrote:
>>> Le 28/11/2018 à 02:33, Daniel Ruggeri a écrit :
>>>> Hi, Jim;
>>>> I'm coming up empty on a search against the Google-machine for SURVEY
>>>> protocol. Any pointers you can share?
>>>> 
>>> Hi
>>> 
>>> Not sure if the answers already posted are what you are looking for.
>>> Here are some links:
>>>   https://nanomsg.org/gettingstarted/survey.html and other resources on
>>> https://nanomsg.org/
>>> 
>>> 
>>> CJ
>>> 
>> 
>> So as I am looking to proxy tomcat using httpd I need a 'pure" java
>> implementation for tomcat, it seems that it is missing for the moment,
>> correct?
>> 
>> -- 
>> Cheers
>> 
>> Jean-Frederic
> 

Re: Plan to add sandbox branch

[Jim Jagielski]

Yeah, I looked for something else, esp various pubsub implementations, but they 
really didn't fit in with what was needed.


> On Nov 29, 2018, at 3:02 AM, jean-frederic clere  wrote:
> 
> On 29/11/2018 07:02, Christophe JAILLET wrote:
>> Le 28/11/2018 à 02:33, Daniel Ruggeri a écrit :
>>> Hi, Jim;
>>> I'm coming up empty on a search against the Google-machine for SURVEY
>>> protocol. Any pointers you can share?
>>> 
>> Hi
>> 
>> Not sure if the answers already posted are what you are looking for.
>> Here are some links:
>>https://nanomsg.org/gettingstarted/survey.html and other resources on
>> https://nanomsg.org/
>> 
>> 
>> CJ
>> 
> 
> So as I am looking to proxy tomcat using httpd I need a 'pure" java
> implementation for tomcat, it seems that it is missing for the moment,
> correct?
> 
> -- 
> Cheers
> 
> Jean-Frederic

Re: Plan to add sandbox branch

[Jim Jagielski]

https://nanomsg.org

> On Nov 27, 2018, at 8:33 PM, Daniel Ruggeri  wrote:
> 
> Hi, Jim;
> I'm coming up empty on a search against the Google-machine for SURVEY 
> protocol. Any pointers you can share?
> 
> I'm also curious what your thoughts are about dealing with growth of the 
> worker pool beyond the control of the proxy admin. For example, if I 
> configure a balancer for 10 nodes, I have an idea of tuning parameters I 
> might set differently than if the number of backends is in the tens of 
> servers.

Since nanomsg/nng will provide the communication between httpd and the 
backends, we could add something like a CONFIG survey that allows for the 
backends to "suggest" params.

> -- 
> Daniel Ruggeri
> 
> On November 27, 2018 5:23:25 AM CST, Jim Jagielski  wrote:
> In the coming week or so, I will be committing my load balance,
> load determination and discovery work to a sandbox trunk. Many
> people have asked for more info, so here we go.
> 
> Basically, this new feature uses nanomsg (nng) to implement the
> SURVEY protocol between workers (nodes) and the front end server.
> The proxy server will send out MEMBERSHIP and STATUS surveys, that
> nodes can respond to; thus new nodes can automagically add themselves
> as they come up as well as remove themselves when they restart or
> shutdown via MEMBERSHIP. STATUS can be used to provide real-time
> load on each node, which will be sent via a __packed__ struct,
> ala NTP and other common usage patterns, in which 32bit fields are
> converted from endian-ness to network and back. That STATUS info can
> be used for "intelligent" load balancing and will provide some
> typical server metrics such as memory, # of cpus, etc...

Plan to add sandbox branch

[Jim Jagielski]

In the coming week or so, I will be committing my load balance,
load determination and discovery work to a sandbox trunk. Many
people have asked for more info, so here we go.

Basically, this new feature uses nanomsg (nng) to implement the
SURVEY protocol between workers (nodes) and the front end server.
The proxy server will send out MEMBERSHIP and STATUS surveys, that
nodes can respond to; thus new nodes can automagically add themselves
as they come up as well as remove themselves when they restart or
shutdown via MEMBERSHIP. STATUS can be used to provide real-time
load on each node, which will be sent via a __packed__ struct,
ala NTP and other common usage patterns, in which 32bit fields are
converted from endian-ness to network and back. That STATUS info can
be used for "intelligent" load balancing and will provide some
typical server metrics such as memory, # of cpus, etc...

Re: 2.4.38

[Jim Jagielski]

> On Nov 9, 2018, at 2:54 PM, Graham Leggett  wrote:
> 
> On 09 Nov 2018, at 17:51, Stefan Eissing  wrote:
> 
>> So, the chance is high that releases we do will work for most of you.
>> AND the chance is high that releases might break something for some of you 
>> (hopefully a few).
> 
> The chance is very low that releases might break something, and this is done 
> by design.
> 
> The place where we might break something is trunk. Before you get anywhere 
> near a release, you have to carve out your change, and propose it for 
> backport to a release branch. This is the first check. Two other people will 
> then check your backport, and if problems are found you’ll be asked to fix 
> it. That’s the second and third check. Then a release is proposed. A tarball 
> is cut, and a whole lot of new people do checks on the tarball. In the case 
> of 2.4.37, this was the fourth, fifth, sixth, seventh, eighth, ninth, tenth 
> and eleventh check for the 8 people who tested it.
> 
> This strategy has worked very well for us since the 1990s, and we must not 
> understate its importance.
> 

If it ain't broke. :)

Re: Load balancing and load determination

[Jim Jagielski]

I have a semi-working implementation that I'll be committing to trunk in a 
bit...

> On Nov 8, 2018, at 1:33 AM, Mladen Turk  wrote:
> 
> On 30.10.2018. 13:53, Jim Jagielski wrote:
>> As some of you know, one of my passions and area of focus is
>> on the use of Apache httpd as a reverse proxy and, as such, load
>> balancing, failover, etc are of vital interest to me.
> 
> Been a while, but seems I'm back :D
> Love the idea to have more intelligent then "lets guess"
> way of deducting the load balancer score.
> 
> What we did for heartbeat/heartmonitor/watchdog can be used
> for collecting backend data.
> 
> The thing I'm trying to do is the way that backend can
> register or remove itself as node inside load balancer.
> That would also require some sort of backend-server communication,
> shared memory management (mod_slotmem maybe), and a way to
> survive graceful restart.
> 
> Backend sending its load status at regular intervals would
> be addition to "I'm here, count me in" or
> "I'm out, bye, good luck with other nodes".
> 
> What do you think?
> 
> 
> 
> Regards
> -- 
> ^TM