Re: release?

2019-07-19 Thread 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?

2019-07-19 Thread 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.

2019-05-15 Thread 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

2019-05-09 Thread 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

2019-03-28 Thread 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

2019-03-28 Thread 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

2019-03-28 Thread 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

2019-03-13 Thread 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

2019-03-13 Thread 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

2019-03-13 Thread 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

2019-03-13 Thread 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

2019-02-19 Thread 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

2019-01-28 Thread 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

2019-01-20 Thread 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

2019-01-19 Thread 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

2019-01-18 Thread 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

2019-01-17 Thread 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

2019-01-17 Thread 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

2019-01-17 Thread 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/

2019-01-17 Thread 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

2019-01-16 Thread 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

2019-01-16 Thread 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

2019-01-15 Thread 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

2019-01-15 Thread 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

2019-01-15 Thread 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

2019-01-08 Thread 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

2018-12-11 Thread 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

2018-11-30 Thread 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

2018-11-30 Thread 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

2018-11-28 Thread 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

2018-11-27 Thread 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

2018-11-09 Thread 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

2018-11-08 Thread 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



2.4.38

2018-11-07 Thread Jim Jagielski
Now that we have a 2.4.37 out, one in which the number of enhancements and 
fixes and feature were limited, it makes sense to consider having a 2.4.38 
release somewhat "soonish", esp considering the number of backports that lack 
only a single vote.

Comments?

Re: Load balancing and load determination

2018-11-06 Thread Jim Jagielski
Which is why we allow for both pre-send checks and out-of-band health checks...

> On Nov 5, 2018, at 10:58 AM, William A Rowe Jr  wrote:
> 
> 
> The last thing we want are the routing headaches of contacting an
> ever-changing list one-or-many potential balancers. And we can't
> rely on a dying lbmember to "check in" that it isn't functional. Since
> the balancer must already start requests to the backend, having that
> backend supplement the responses with its health status is simple.



Re: Load balancing and load determination

2018-11-05 Thread Jim Jagielski
I was thinking about something more robust and usable than heartbeat (due to 
multicast) but similar in basic concept.

> On Nov 5, 2018, at 8:48 AM, jean-frederic clere  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.
>> 
>> One topic which I have mulling over, off and on, has been the
>> idea of some sort of universal load number, that could be used
>> and agreed upon by web servers. Right now, the reverse proxy
>> "guesses" the load on the backend servers which is OK, and
>> works well enough, but it would be great if it actually "knew"
>> the current loads on those servers. I already have code that
>> shares basic architectural info, such as number of CPUs, available
>> memory, loadavg, etc which can help, of course, but again, all
>> this info can be used to *infer* the current status of those backend
>> servers; it doesn't really provide what the current load actually
>> *is*.
>> 
>> So I was thinking maybe some sort of small, simple and "fast"
>> benchmark which could be run by the backends as part of their
>> "status" update to the front-end reverse proxy server... something
>> that shows general capability at that point in time, like Hanoi or
>> something similar. Or maybe some hash function. Some simple code
>> that could be used to create that "universal" load number.
>> 
>> Thoughts? Ideas? Comments? Suggestions? :)
> 
> having the back-ends to provide the load they are able to handle
> lbfactor (via w_lf or somethere similar. That requires the back-ends to
> be able to send request to httpd balancer-manager handler.
> 
>> 
> 
> 
> -- 
> Cheers
> 
> Jean-Frederic



Re: __attribute__

2018-11-02 Thread Jim Jagielski


> On Nov 1, 2018, at 5:53 PM, William A Rowe Jr  wrote:
> 
> On Thu, Nov 1, 2018 at 3:31 PM Jim Jagielski  <mailto:j...@jagunet.com>> wrote:
> Since __attribute__ is used in various places in trunk and 2.4, is it safe to 
> assume that I can write something that requires __attribute__(packed)?
> 
> No ... but surely you meant to write __attribute__((packed))

Why No? And don't call me Shirley.

> 
> The real question is... why?

Why does anyone use it because they need a packed struct.

> It is sorely suboptimal except on x86_64 where the cpu handles the heavy lift 
> ... the compiler must cope with it on MIPS/SPARC/POWER etc, may break atomic 
> updates (our atomics don't protect against this), and doesn't address 
> endianness. It all leads to lots of other questions...
> 
> https://stackoverflow.com/questions/45116212/are-packed-structs-portable 
> <https://stackoverflow.com/questions/45116212/are-packed-structs-portable> 
> https://stackoverflow.com/questions/8568432/is-gccs-attribute-packed-pragma-pack-unsafe
>  
> <https://stackoverflow.com/questions/8568432/is-gccs-attribute-packed-pragma-pack-unsafe>

All known and considered, but thanks for the intro to C lesson.

> 
> Adding this to any existing public struct definition is not backportable to 
> 2.4.x.

Of course. Who would propose such a thing??

> 
> A use case would be helpful provide a fair answer to your question.


I plan to use it in a very NTP-like way.

__attribute__

2018-11-01 Thread Jim Jagielski
Since __attribute__ is used in various places in trunk and 2.4, is it safe to 
assume that I can write something that requires __attribute__(packed)?

Re: Load balancing and load determination

2018-10-30 Thread Jim Jagielski



> On Oct 30, 2018, at 9:06 AM, Daniel Ruggeri  wrote:
> 
> Hi, Jim J;
> I recall a while back that Jim Riggs proposed a spec for exactly this a while 
> back... I think it was shared here on list and some light iteration was done. 
> IIUC, he was even planning to present it at ACNA until travel plans fell 
> through.
> 


https://lists.apache.org/thread.html/ca115bd3f21f7da91fa01a4d83af7d73987750e1e48bb2bf76236e52@1430369651@%3Cdev.httpd.apache.org%3E





Re: Load balancing and load determination

2018-10-30 Thread Jim Jagielski
The only reason why I brought up the concept of a benchmark is because it is 
dead easy to provide the source for said benchmark and have backend servers 
simply time how long it takes to run it each status update. Each backend would 
simply then send the "time taken" and that would provide some measure of how 
beefy and/or loaded said server was.

The main consideration is one of consistency... unless there is some agreed 
upon "standard" then comparisons are worthless and the resulting load balancing 
will be inaccurate. For example, say that Apache is front-ending 10 servers, 5 
are Apache and other 5 are Foo, but Foo consistently falsifies it's capability 
simply to ensure that it gets all the traffic. Sure, you can adjust settings on 
the front end to offset that, but that defeats the whole purpose of some 
*accurate*, objective measure of capability.

Yeah, I recall JR posting something after I brought up this topic at one of my 
ApacheCon sessions...

Maybe it's more of an "availability factor" than a load factor... with 0 being 
"send me nothing" and 1 being "I am completely unloaded" and decimal values 
between indicating their "availability" to handle traffic.

> On Oct 30, 2018, at 9:06 AM, Daniel Ruggeri  wrote:
> 
> Hi, Jim J;
> I recall a while back that Jim Riggs proposed a spec for exactly this a while 
> back... I think it was shared here on list and some light iteration was done. 
> IIUC, he was even planning to present it at ACNA until travel plans fell 
> through.
> 
> Hi, Jim R;
> Any chance you have the latest and greatest, or is the version from the list 
> archives current state?
> 
> 
> One of the things I recall *really liking* from the recommendation is letting 
> the backend decide its factor based on whatever it believes is most 
> important. In some servers, that may be available threads. In others it could 
> be percentage of memory used. Still yet, other servers may decide based on 
> number of idle GPUs on-system. I think this is roughly the same you are 
> suggesting, Jim J, but I struggle to think of a universal benchmark because 
> backends are so varied.
> -- 
> Daniel Ruggeri
> 
> On October 30, 2018 7:53:20 AM CDT, 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.
> 
> One topic which I have mulling over, off and on, has been the
> idea of some sort of universal load number, that could be used
> and agreed upon by web servers. Right now, the reverse proxy
> "guesses" the load on the backend servers which is OK, and
> works well enough, but it would be great if it actually "knew"
> the current loads on those servers. I already have code that
> shares basic architectural info, such as number of CPUs, available
> memory, loadavg, etc which can help, of course, but again, all
> this info can be used to *infer* the current status of those backend
> servers; it doesn't really provide what the current load actually
> *is*.
> 
> So I was thinking maybe some sort of small, simple and "fast"
> benchmark which could be run by the backends as part of their
> "status" update to the front-end reverse proxy server... something
> that shows general capability at that point in time, like Hanoi or
> something similar. Or maybe some hash function. Some simple code
> that could be used to create that "universal" load number.
> 
> Thoughts? Ideas? Comments? Suggestions? :)



Load balancing and load determination

2018-10-30 Thread Jim Jagielski
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.

One topic which I have mulling over, off and on, has been the
idea of some sort of universal load number, that could be used
and agreed upon by web servers. Right now, the reverse proxy
"guesses" the load on the backend servers which is OK, and
works well enough, but it would be great if it actually "knew"
the current loads on those servers. I already have code that
shares basic architectural info, such as number of CPUs, available
memory, loadavg, etc which can help, of course, but again, all
this info can be used to *infer* the current status of those backend
servers; it doesn't really provide what the current load actually
*is*.

So I was thinking maybe some sort of small, simple and "fast"
benchmark which could be run by the backends as part of their
"status" update to the front-end reverse proxy server... something
that shows general capability at that point in time, like Hanoi or
something similar. Or maybe some hash function. Some simple code
that could be used to create that "universal" load number.

Thoughts? Ideas? Comments? Suggestions? :)


Re: SetHandler balancer-manager question.

2018-10-23 Thread Jim Jagielski
Yes, it is normal and expected behavior, but one can say that such behavior 
isn't "correct" or "should be changed", esp now that we can add members 
dynamically. So I would be +1 on changing the code to show all balancers, 
regardless of whether they have workers/members or not.

> On Oct 23, 2018, at 5:25 AM, jean-frederic clere  wrote:
> 
> Hi,
> 
> I have started to look how to enhance mod_proxy_balancer to replace
> mod_cluster, the first question is it normal that a balancer without
> workers is NOT displayed by the handler?
> -- 
> Cheers
> 
> Jean-Frederic



Re: Test framework regressions - spelling and usertrack

2018-10-22 Thread Jim Jagielski
Well, we'll see if other macOS users also have the same failures... that will 
determine if my hypothesis is correct.

> On Oct 22, 2018, at 11:37 AM, Stefan Eissing  
> wrote:
> 
> dAMn! uSABilitY StRiks aGAIn!
> 
>> Am 22.10.2018 um 17:34 schrieb Jim Jagielski :
>> 
>> OK, I think I know what may be happening; I am guessing its due to the macOS 
>> file system being case insensitive but case preserving...
> 



Re: Test framework regressions - spelling and usertrack

2018-10-22 Thread Jim Jagielski
OK, I think I know what may be happening; I am guessing its due to the macOS 
file system being case insensitive but case preserving...

Re: Test framework regressions - spelling and usertrack

2018-10-22 Thread Jim Jagielski
The latest update to usertrack works. Thx! speling still bad:

On httpd-2.4 HEAD:

  t/modules/speling.t . 1/48 # Failed test 11 in 
t/modules/speling.t at line 46 fail #6
  # Failed test 12 in t/modules/speling.t at line 50 fail #5
  # Failed test 35 in t/modules/speling.t at line 46 fail #18
  # Failed test 36 in t/modules/speling.t at line 50 fail #9
  t/modules/speling.t . Failed 4/48 subtests
(less 13 skipped subtests: 31 okay)

On trunk:

  t/modules/speling.t . 1/48 # Failed test 11 in 
t/modules/speling.t at line 46 fail #6
  # Failed test 12 in t/modules/speling.t at line 50 fail #5
  # Failed test 13 in t/modules/speling.t at line 46 fail #7
  # Failed test 14 in t/modules/speling.t at line 50 fail #6
  # Failed test 15 in t/modules/speling.t at line 46 fail #8
  # Failed test 16 in t/modules/speling.t at line 50 fail #7
  # Failed test 35 in t/modules/speling.t at line 46 fail #18
  # Failed test 36 in t/modules/speling.t at line 50 fail #9
  # Failed test 37 in t/modules/speling.t at line 46 fail #19
  # Failed test 38 in t/modules/speling.t at line 50 fail #10
  # Failed test 39 in t/modules/speling.t at line 46 fail #20
  # Failed test 40 in t/modules/speling.t at line 50 fail #11
  t/modules/speling.t . Failed 12/48 subtests
  (less 13 skipped subtests: 23 okay)

This is on macOS. The speling tests show:

# testing : Checking case. Expecting: 301
# expected: 301
# received: '200'
not ok 11
# testing : Redirect ok
# expected: qr/good\.html|several1\.html/
# received: '
# 
# 404 Not Found
# 
# Not Found
# The requested URL /modules/speling/nocase/good.wrong_ext was not found on 
this server.
# 
# '
not ok 14
# Failed test 13 in t/modules/speling.t at line 46 fail #7
# Failed test 14 in t/modules/speling.t at line 50 fail #6
# testing : Checking NC wrong extension. Expecting: 300
# expected: 300
# received: '404'
not ok 15
# testing : Redirect ok
# expected: qr/good\.html|several1\.html/
# received: '
# 
# 404 Not Found
# 
# Not Found
# The requested URL /modules/speling/nocase/GOOD.wrong_ext was not found on 
this server.
# 
# '

Test framework regressions - spelling and usertrack

2018-10-22 Thread Jim Jagielski
These are new from a coupla day ago:

t/modules/speling.t . 1/48 # Failed test 11 in 
t/modules/speling.t at line 46 fail #6
# Failed test 12 in t/modules/speling.t at line 50 fail #5
# Failed test 35 in t/modules/speling.t at line 46 fail #18
# Failed test 36 in t/modules/speling.t at line 50 fail #9
t/modules/speling.t . Failed 4/48 subtests
(less 13 skipped subtests: 31 okay)

t/modules/usertrack.t ... 714/1001 Argument "135/256" isn't numeric 
in numeric eq (==) at t/modules/usertrack.t line 62.
t/modules/usertrack.t ... Dubious, test returned 255 (wstat 65280, 
0xff00)
Failed 1/1001 subtests

Re: [VOTE] Release httpd-2.4.37

2018-10-19 Thread Jim Jagielski
+1:

  o macOS 10.13.6, Xcode 10, OpenSSL 1.1.1 and 1.0.2p
  o CentOS 5&6, OpenSSL 1.0.2, 64bit

Thx for RMing!

> On Oct 18, 2018, at 10:36 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.37:
> [ ] +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: b0521606d1df54bb425adcdecf6348f126aa352c *httpd-2.4.37.tar.gz
> sha256: aa97a834a32d51974be8d8a013b561e28d327387cb1da2c3c2762acd0146aabd 
> *httpd-2.4.37.tar.gz
> 
> -- 
> Daniel Ruggeri



Re: svn commit: r1843478 - /httpd/test/framework/trunk/t/ssl/ocsp.t

2018-10-18 Thread Jim Jagielski



> On Oct 16, 2018, at 11:36 AM, William A Rowe Jr  wrote:
> 
> To button this issue up, it's clear to me that Jim had transposed the meaning 
> of result values from posix commands, and that was the origin of 
> irrationality in this discussion.
> 

Actually, I did not. But thanks for playing. I will ignore the implied insult.



Re: svn commit: r1843478 - /httpd/test/framework/trunk/t/ssl/ocsp.t

2018-10-15 Thread Jim Jagielski
Forget this. My patch works and is correct and handles the specific situation 
which is noted in the test case itself related to older versions. It is an 
IMPROVEMENT over what we currently have.

The sole reason why Bill doesn't like it is because *I* committed it.

Whatever. I have no desire or patience with him anymore. I could not care less 
what patch is included.

Re: svn commit: r1843478 - /httpd/test/framework/trunk/t/ssl/ocsp.t

2018-10-15 Thread Jim Jagielski
-1 (veto).

'list' is not a valid command.

> On Oct 15, 2018, at 11:04 AM, William A Rowe Jr  wrote:
> 
> On Mon, Oct 15, 2018 at 7:52 AM Jim Jagielski  <mailto:j...@jagunet.com>> wrote:
> 
> And lest we forget, the orig version used:
> 
> $openssl list -commands
> 
> I have no idea what version of openssl supports 'list'. The result
> of which was that the ocsp testing was ALWAYS SKIPPED.
> 
> No, it wasn't skipped. We weren't looking at the result code, but examining 
> stdout, and jorton's original test was correct for everyone testing with 
> OpenSSL 1.1.0 and later.

Show me.



Re: svn commit: r1843917 - /httpd/test/framework/trunk/t/ssl/ocsp.t

2018-10-15 Thread Jim Jagielski
-1 (veto)

Please revert. 'list' is NOT a command and this causes OCSP to be skipped.

% openssl version
OpenSSL 1.0.2p  14 Aug 2018
% openssl list -commands
openssl:Error: 'list' is an invalid command.

Standard commands
asn1parse caciphers   cms
crl   crl2pkcs7 dgst  dh
dhparam   dsa   dsaparam  ec
ecparam   enc   engineerrstr
gendh gendsagenpkey   genrsa
nseq  ocsp  passwdpkcs12
pkcs7 pkcs8 pkey  pkeyparam
pkeyutl   prime rand  req
rsa   rsautls_client  s_server
s_timesess_id   smime speed
spkac srp   tsverify
version   x509

Message Digest commands (see the `dgst' command for more details)
md4   md5   mdc2  rmd160
sha   sha1

Cipher commands (see the `enc' command for more details)
aes-128-cbc   aes-128-ecb   aes-192-cbc   aes-192-ecb
aes-256-cbc   aes-256-ecb   base64bf
bf-cbcbf-cfbbf-ecbbf-ofb
camellia-128-cbc  camellia-128-ecb  camellia-192-cbc  camellia-192-ecb
camellia-256-cbc  camellia-256-ecb  cast  cast-cbc
cast5-cbc cast5-cfb cast5-ecb cast5-ofb
des   des-cbc   des-cfb   des-ecb
des-ede   des-ede-cbc   des-ede-cfb   des-ede-ofb
des-ede3  des-ede3-cbc  des-ede3-cfb  des-ede3-ofb
des-ofb   des3  desx  idea
idea-cbc  idea-cfb  idea-ecb  idea-ofb
rc2   rc2-40-cbcrc2-64-cbcrc2-cbc
rc2-cfb   rc2-ecb   rc2-ofb   rc4
rc4-40seed  seed-cbc  seed-cfb
seed-ecb  seed-ofb  zlib


% openssl version
OpenSSL 1.0.1e-fips 11 Feb 2013
% openssl list -commands
openssl:Error: 'list' is an invalid command.

Standard commands
asn1parse caciphers   cms
crl   crl2pkcs7 dgst  dh
dhparam   dsa   dsaparam  ec
ecparam   enc   engineerrstr
gendh gendsagenpkey   genrsa
nseq  ocsp  passwdpkcs12
pkcs7 pkcs8 pkey  pkeyparam
pkeyutl   prime rand  req
rsa   rsautls_client  s_server
s_timesess_id   smime speed
spkac tsverifyversion
x509

Message Digest commands (see the `dgst' command for more details)
md2   md4   md5   rmd160
sha   sha1

Cipher commands (see the `enc' command for more details)
aes-128-cbc   aes-128-ecb   aes-192-cbc   aes-192-ecb
aes-256-cbc   aes-256-ecb   base64bf
bf-cbcbf-cfbbf-ecbbf-ofb
camellia-128-cbc  camellia-128-ecb  camellia-192-cbc  camellia-192-ecb
camellia-256-cbc  camellia-256-ecb  cast  cast-cbc
cast5-cbc cast5-cfb cast5-ecb cast5-ofb
des   des-cbc   des-cfb   des-ecb
des-ede   des-ede-cbc   des-ede-cfb   des-ede-ofb
des-ede3  des-ede3-cbc  des-ede3-cfb  des-ede3-ofb
des-ofb   des3  desx  idea
idea-cbc  idea-cfb  idea-ecb  idea-ofb
rc2   rc2-40-cbcrc2-64-cbcrc2-cbc
rc2-cfb   rc2-ecb   rc2-ofb   rc4
rc4-40seed  seed-cbc  seed-cfb
seed-ecb  seed-ofb  zlib

> On Oct 15, 2018, at 10:55 AM, wr...@apache.org wrote:
> 
> Author: wrowe
> Date: Mon Oct 15 14:55:27 2018
> New Revision: 1843917
> 
> URL: http://svn.apache.org/viewvc?rev=1843917=rev
> Log:
> Revert r1832567, r1843476, r1843478
> 
> Restore jorton's detection from r1831398, and portably redirect stderr
> to capture and evaluate the available command list,
> from either stdout (1.1.0 and later) or stderr (1.0.2 and prior).
> 
> 
> Modified:
>httpd/test/framework/trunk/t/ssl/ocsp.t
> 
> Modified: httpd/test/framework/trunk/t/ssl/ocsp.t
> URL: 
> http://svn.apache.org/viewvc/httpd/test/framework/trunk/t/ssl/ocsp.t?rev=1843917=1843916=1843917=diff
> ==
> --- httpd/test/framework/trunk/t/ssl/ocsp.t (original)
> +++ httpd/test/framework/trunk/t/ssl/ocsp.t Mon Oct 15 14:55:27 2018
> @@ -21,7 +21,7 @@ Apache::TestRequest::module('ssl_ocsp');
> # support in earlier versions without messing around with stderr
> my $openssl = 

Re: [VOTE] Release httpd-2.4.36

2018-10-15 Thread Jim Jagielski



> On Oct 15, 2018, at 10:20 AM, Stefan Eissing  
> wrote:
> 
> 
> 
>> Am 15.10.2018 um 16:11 schrieb Jim Jagielski :
>> 
>> It's up to the RM on whether or not to release... one can't veto a release 
>> and a -1 is not a veto.
> 
> Huh? I was referring to "TLS 1.3 support isn't quite yet tested enough to 
> warrant a public release". I wanted to point out that without attempting a 
> public release, we may not have found this bug for months

Agreed.

> . I am -1 on 2.4.36 as well, in case that was not clear. Don't know how this 
> "veto" came into this...

It wasn't directed at anyone, just a general statement... 

> 
> -Stefan
> 
>>> On Oct 15, 2018, at 10:07 AM, Stefan Eissing  
>>> wrote:
>>> 
>>> 
>>> 
>>>> Am 15.10.2018 um 15:58 schrieb Jim Jagielski :
>>>> 
>>>> Considering all this, I am changing my vote from a +1 to a -1. I was not 
>>>> able to trigger this error, but this shows, at least IMO, that TLS 1.3 
>>>> support isn't quite yet tested enough to warrant a public release, unless 
>>>> we are super clear that it is "experimental" or "early access"...
>>> 
>>> I do not see it this black/white way. 
>>> 
>>> We have found no regression with any SSL != OpenSSL 1.1.1. 
>>> We have not even found a bug with TLSv1.3 as such. What we have found is a 
>>> behaviour change in OpenSSL where our code relied on either changed or not 
>>> well documented behaviour. 
>>> 
>>> We do not want to ship a version of httpd which has severe interop problems 
>>> with the released openssl 1.1.1. 
>>> HOWEVER: it is unclear, if this will not also trigger in some scenario when 
>>> one links 2.4.35 with OpenSSL 1.1.1.
>>> 
>>> I am all in favor of pushing a 2.4.37 immediately after this bug is fixed. 
>>> We will not solve any remaining problems by letting it stew in the 
>>> repository. 
>>> 
>>> -Stefan
>>> 
>>>> 
>>>>> On Oct 15, 2018, at 4:06 AM, Stefan Eissing 
>>>>>  wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>>> Am 14.10.2018 um 23:46 schrieb Daniel Ruggeri :
>>>>>> 
>>>>>> Hi, Helmut;
>>>>>> Note that the vote may run longer than 72 hours as 72 is the minimum. As 
>>>>>> it stands now, we have more than 3 binding +1 votes, but I am waiting 
>>>>>> for closure on the conversation on-list about the tests with reported 
>>>>>> H2/TLS 1.3 failures. Since this is one of the primary features of this 
>>>>>> release, I want to be sure the topic gets due attention.
>>>>> 
>>>>> See my mail on the other thread. It seems that h2 traffic triggers a call 
>>>>> sequence that exposes a change in OpenSSL behaviour of SSL_read() between 
>>>>> 1.1.0 and 1.1.1. It looks as if mod_ssl interpreted the return codes of 
>>>>> SSL_read() in a way that no longer works and that we need to change 
>>>>> mod_ssl handling here.
>>>>> 
>>>>> Waiting on confirmation  or rebuttal of my analysis on the other thread.
>>>>> 
>>>>> Cheers,
>>>>> 
>>>>> Stefan
>>>>> 
>>>>>> -- 
>>>>>> Daniel Ruggeri
>>>>>> 
>>>>>> On October 14, 2018 4:44:04 PM CDT, "Helmut K. C. Tessarek" 
>>>>>>  wrote:
>>>>>> On 2018-10-10 15:18, Daniel Ruggeri wrote:
>>>>>> Hi, all;
>>>>>> Please find below the proposed release tarball and signatures:
>>>>>> https://dist.apache.org/repos/dist/dev/httpd/
>>>>>> 
>>>>>> I would like to call a VOTE over the next few days to release this
>>>>>> candidate tarball as 2.4.36:
>>>>>> [ ] +1: It's not just good, it's good enough!
>>>>>> [ ] +0: Let's have a talk.
>>>>>> [ ] -1: There's trouble in paradise. Here's what's wrong.
>>>>>> 
>>>>>> The computed digests of the tarball up for vote are:
>>>>>> sha1: e40e7a879b84df860215b8a80f2a535534a1c4b4 *httpd-2.4.36.tar.gz
>>>>>> sha256: ef788fb7c814acb2506a8b758a1a3f91f368f97bd4e6db16e98001f468e8e288
>>>>>> *httpd-2.4.36.tar.gz
>>>>>> 
>>>>>> 72h have passed, so what is the outcome of the vote?
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 



Re: [VOTE] Release httpd-2.4.36

2018-10-15 Thread Jim Jagielski
It's up to the RM on whether or not to release... one can't veto a release and 
a -1 is not a veto.

> On Oct 15, 2018, at 10:07 AM, Stefan Eissing  
> wrote:
> 
> 
> 
>> Am 15.10.2018 um 15:58 schrieb Jim Jagielski :
>> 
>> Considering all this, I am changing my vote from a +1 to a -1. I was not 
>> able to trigger this error, but this shows, at least IMO, that TLS 1.3 
>> support isn't quite yet tested enough to warrant a public release, unless we 
>> are super clear that it is "experimental" or "early access"...
> 
> I do not see it this black/white way. 
> 
> We have found no regression with any SSL != OpenSSL 1.1.1. 
> We have not even found a bug with TLSv1.3 as such. What we have found is a 
> behaviour change in OpenSSL where our code relied on either changed or not 
> well documented behaviour. 
> 
> We do not want to ship a version of httpd which has severe interop problems 
> with the released openssl 1.1.1. 
> HOWEVER: it is unclear, if this will not also trigger in some scenario when 
> one links 2.4.35 with OpenSSL 1.1.1.
> 
> I am all in favor of pushing a 2.4.37 immediately after this bug is fixed. We 
> will not solve any remaining problems by letting it stew in the repository. 
> 
> -Stefan
> 
>> 
>>> On Oct 15, 2018, at 4:06 AM, Stefan Eissing  
>>> wrote:
>>> 
>>> 
>>> 
>>>> Am 14.10.2018 um 23:46 schrieb Daniel Ruggeri :
>>>> 
>>>> Hi, Helmut;
>>>> Note that the vote may run longer than 72 hours as 72 is the minimum. As 
>>>> it stands now, we have more than 3 binding +1 votes, but I am waiting for 
>>>> closure on the conversation on-list about the tests with reported H2/TLS 
>>>> 1.3 failures. Since this is one of the primary features of this release, I 
>>>> want to be sure the topic gets due attention.
>>> 
>>> See my mail on the other thread. It seems that h2 traffic triggers a call 
>>> sequence that exposes a change in OpenSSL behaviour of SSL_read() between 
>>> 1.1.0 and 1.1.1. It looks as if mod_ssl interpreted the return codes of 
>>> SSL_read() in a way that no longer works and that we need to change mod_ssl 
>>> handling here.
>>> 
>>> Waiting on confirmation  or rebuttal of my analysis on the other thread.
>>> 
>>> Cheers,
>>> 
>>> Stefan
>>> 
>>>> -- 
>>>> Daniel Ruggeri
>>>> 
>>>> On October 14, 2018 4:44:04 PM CDT, "Helmut K. C. Tessarek" 
>>>>  wrote:
>>>> On 2018-10-10 15:18, Daniel Ruggeri wrote:
>>>> Hi, all;
>>>> Please find below the proposed release tarball and signatures:
>>>> https://dist.apache.org/repos/dist/dev/httpd/
>>>> 
>>>> I would like to call a VOTE over the next few days to release this
>>>> candidate tarball as 2.4.36:
>>>> [ ] +1: It's not just good, it's good enough!
>>>> [ ] +0: Let's have a talk.
>>>> [ ] -1: There's trouble in paradise. Here's what's wrong.
>>>> 
>>>> The computed digests of the tarball up for vote are:
>>>> sha1: e40e7a879b84df860215b8a80f2a535534a1c4b4 *httpd-2.4.36.tar.gz
>>>> sha256: ef788fb7c814acb2506a8b758a1a3f91f368f97bd4e6db16e98001f468e8e288
>>>> *httpd-2.4.36.tar.gz
>>>> 
>>>> 72h have passed, so what is the outcome of the vote?
>>>> 
>>> 
>> 
> 



Re: [VOTE] Release httpd-2.4.36

2018-10-15 Thread Jim Jagielski
Considering all this, I am changing my vote from a +1 to a -1. I was not able 
to trigger this error, but this shows, at least IMO, that TLS 1.3 support isn't 
quite yet tested enough to warrant a public release, unless we are super clear 
that it is "experimental" or "early access"...

> On Oct 15, 2018, at 4:06 AM, Stefan Eissing  
> wrote:
> 
> 
> 
>> Am 14.10.2018 um 23:46 schrieb Daniel Ruggeri :
>> 
>> Hi, Helmut;
>> Note that the vote may run longer than 72 hours as 72 is the minimum. As it 
>> stands now, we have more than 3 binding +1 votes, but I am waiting for 
>> closure on the conversation on-list about the tests with reported H2/TLS 1.3 
>> failures. Since this is one of the primary features of this release, I want 
>> to be sure the topic gets due attention.
> 
> See my mail on the other thread. It seems that h2 traffic triggers a call 
> sequence that exposes a change in OpenSSL behaviour of SSL_read() between 
> 1.1.0 and 1.1.1. It looks as if mod_ssl interpreted the return codes of 
> SSL_read() in a way that no longer works and that we need to change mod_ssl 
> handling here.
> 
> Waiting on confirmation  or rebuttal of my analysis on the other thread.
> 
> Cheers,
> 
> Stefan
> 
>> -- 
>> Daniel Ruggeri
>> 
>> On October 14, 2018 4:44:04 PM CDT, "Helmut K. C. Tessarek" 
>>  wrote:
>> On 2018-10-10 15:18, Daniel Ruggeri wrote:
>> Hi, all;
>>   Please find below the proposed release tarball and signatures:
>> https://dist.apache.org/repos/dist/dev/httpd/
>> 
>> I would like to call a VOTE over the next few days to release this
>> candidate tarball as 2.4.36:
>> [ ] +1: It's not just good, it's good enough!
>> [ ] +0: Let's have a talk.
>> [ ] -1: There's trouble in paradise. Here's what's wrong.
>> 
>> The computed digests of the tarball up for vote are:
>> sha1: e40e7a879b84df860215b8a80f2a535534a1c4b4 *httpd-2.4.36.tar.gz
>> sha256: ef788fb7c814acb2506a8b758a1a3f91f368f97bd4e6db16e98001f468e8e288
>> *httpd-2.4.36.tar.gz
>> 
>> 72h have passed, so what is the outcome of the vote?
>> 
> 



Re: svn commit: r1843478 - /httpd/test/framework/trunk/t/ssl/ocsp.t

2018-10-15 Thread Jim Jagielski



> On Oct 14, 2018, at 3:59 PM, William A Rowe Jr  wrote:
> 
> $ openssl xyz >/dev/null
> Invalid command 'xyz'; type "help" for a list.
> $ echo $?
> 1
> $ openssl version
> OpenSSL 1.1.0i-fips  14 Aug 2018
>  
> I have no idea which bastardization of the openssl command line tool you are 
> using which returns success for bad verbs.
> 

It looks like your version suffers from such "bastardization" as well

And lest we forget, the orig version used:

$openssl list -commands

I have no idea what version of openssl supports 'list'. The result
of which was that the ocsp testing was ALWAYS SKIPPED.



Re: svn commit: r1843478 - /httpd/test/framework/trunk/t/ssl/ocsp.t

2018-10-14 Thread Jim Jagielski
All we are checking is the error code. Nothing else.

   % openssl version
   OpenSSL 1.0.2p  14 Aug 2018
   % openssl ocsp 2>/dev/null
   % print $?
   1
   % openssl foo 2>/dev/null
   % print $?
   0

With 1.1.1, both return 1, but so what, we know that it has oscp.

Complaining about /dev/null : orig code had this. Why was that OK?


> On Oct 13, 2018, at 2:35 PM, William A Rowe Jr  wrote:
> 
> On Wed, Oct 10, 2018 at 12:27 PM mailto:j...@apache.org>> 
> wrote:
> Author: jim
> Date: Wed Oct 10 17:27:33 2018
> New Revision: 1843478
> 
> URL: http://svn.apache.org/viewvc?rev=1843478=rev 
> 
> Log:
> Better method... just check return status
> 
> Modified:
> httpd/test/framework/trunk/t/ssl/ocsp.t
> 
> Modified: httpd/test/framework/trunk/t/ssl/ocsp.t
> URL: 
> http://svn.apache.org/viewvc/httpd/test/framework/trunk/t/ssl/ocsp.t?rev=1843478=1843477=1843478=diff
>  
> 
> ==
> --- httpd/test/framework/trunk/t/ssl/ocsp.t (original)
> +++ httpd/test/framework/trunk/t/ssl/ocsp.t Wed Oct 10 17:27:33 2018
> @@ -21,7 +21,7 @@ Apache::TestRequest::module('ssl_ocsp');
>  # support in earlier versions without messing around with stderr
>  my $openssl = Apache::TestSSLCA::openssl();
>  if (!have_min_apache_version('2.4.26')
> -or `$openssl list-standard-commands 2>/dev/null` !~ /ocsp/) {
> +or system("$openssl ocsp 2>/dev/null") == 0) {
> 
> On Windows, /dev/null is invalid (output target nul, eg NUL). 
> 
> On every platform this is an always-fail noop, since `openssl ocsp` always 
> results in an error. Not enough arguments. You disabled this test on all 
> environments, please revert.
> 
> One test without extraneous stdout garbage might be to test ( `$openssl ocsp 
> -help` !~ /Usage:/ ) ... in theory this would both succeed (success 0), eat 
> stdout, and there should be no Usage: instructions if the ocsp verb doesn't 
> exist.
> 
> Thoughts?
> 
> 



Re: [VOTE] Release httpd-2.4.36

2018-10-11 Thread Jim Jagielski
Oh, and it's not a regression since, at least, 2.4.34 (at least for me)

> On Oct 11, 2018, at 7:35 AM, Jim Jagielski  wrote:
> 
> FWIW, on macOS, both trunk and httpd-2.4 fail on this test:
> 
>  t/modules/buffer.t .. 3/12 # Failed test 4 in 
> t/modules/buffer.t at line 32
>  t/modules/buffer.t .. 7/12 # Failed test 8 in 
> t/modules/buffer.t at line 32 fail #2
>  t/modules/buffer.t .. 11/12 # Failed test 12 in 
> t/modules/buffer.t at line 32 fail #3
>  t/modules/buffer.t .. Failed 3/12 subtests
> 
> 
>> On Oct 11, 2018, at 7:15 AM, Plüm, Rüdiger, Vodafone Group 
>>  wrote:
>> 
>> Do you know if the failure is a regression over 2.4.35?
>> 
>> Regards
>> 
>> Rüdiger
>> 
>> Von: Marion et Christophe JAILLET  
>> Gesendet: Donnerstag, 11. Oktober 2018 13:13
>> An: dev@httpd.apache.org
>> Betreff: re: AW: [VOTE] Release httpd-2.4.36
>> 
>> Waouh!
>> 
>> 
>> 
>> This would mean I've provided a new useful test!
>> 
>> (it has been added recently in r1841508)
>> 
>> 
>> 
>> :)
>> 
>> 
>> 
>> I definitely need to document how to generate and use test-coverage data 
>> when running the test framework.
>> 
>> This helps to spot where new tests are needed.
>> 
>> 
>> 
>> CJ
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>> Message du 11/10/18 10:08
>>> De : "Plüm, Rüdiger, Vodafone Group" 
>>> A : "dev@httpd.apache.org" 
>>> Copie à : 
>>> Objet : AW: [VOTE] Release httpd-2.4.36
>>> 
>>> Anyone else seeing
>>> 
>>> t/modules/buffer.t (Wstat: 0 Tests: 12 Failed: 2)
>>> Failed tests: 8, 12
>>> 
>>> ?
>>> 
>>> I don't see this with trunk on the same machine. Issue seems to be if input 
>>> filtering is on on large POSTs.
>>> 
>>> Regards
>>> 
>>> Rüdiger
>>> 
>>>> -Ursprüngliche Nachricht-
>>>> Von: Daniel Ruggeri 
>>>> Gesendet: Donnerstag, 11. Oktober 2018 02:27
>>>> An: dev@httpd.apache.org
>>>> Betreff: Re: [VOTE] Release httpd-2.4.36
>>>> 
>>>> +1 from me (talking to myself).
>>>> 
>>>> Test environment follows. I observe only one failure of the test suite
>>>> (mentioned elsewhere) - it seems only to apply w/ OpenSSL 1.1.1 and H2.
>>>> 
>>>> system:
>>>>  kernel:
>>>>name: Linux
>>>>release: 3.16.0-4-amd64
>>>>version: #1 SMP Debian 3.16.51-3 (2017-12-13)
>>>>machine: x86_64
>>>> 
>>>>  libraries:
>>>>openssl: "1.1.1"
>>>>openldap: "2.4.46"
>>>>apr: "1.6.5"
>>>>apr-util: "1.6.1"
>>>>iconv: "1.2.2"
>>>>brotli: "1.0.6"
>>>>nghttp2: "1.34.0"
>>>>zlib: "1.2.11"
>>>>pcre: "8.42"
>>>>libxml2: "2.9.8"
>>>>php: "5.6.38"
>>>>lua: "5.3.5"
>>>>curl: "7.61.1"
>>>> 
>>>> --
>>>> Daniel Ruggeri
>>>> 
>>>> On 10/10/2018 2:18 PM, Daniel Ruggeri wrote:
>>>>> Hi, all;
>>>>>   Please find below the proposed release tarball and signatures:
>>>>> https://dist.apache.org/repos/dist/dev/httpd/
>>>>> 
>>>>> I would like to call a VOTE over the next few days to release this
>>>>> candidate tarball as 2.4.36:
>>>>> [ ] +1: It's not just good, it's good enough!
>>>>> [ ] +0: Let's have a talk.
>>>>> [ ] -1: There's trouble in paradise. Here's what's wrong.
>>>>> 
>>>>> The computed digests of the tarball up for vote are:
>>>>> sha1: e40e7a879b84df860215b8a80f2a535534a1c4b4 *httpd-2.4.36.tar.gz
>>>>> sha256:
>>>>> ef788fb7c814acb2506a8b758a1a3f91f368f97bd4e6db16e98001f468e8e288
>>>>> *httpd-2.4.36.tar.gz
>>>>> 
>>> 
>>> 
> 



Re: [VOTE] Release httpd-2.4.36

2018-10-11 Thread Jim Jagielski
FWIW, on macOS, both trunk and httpd-2.4 fail on this test:

  t/modules/buffer.t .. 3/12 # Failed test 4 in 
t/modules/buffer.t at line 32
  t/modules/buffer.t .. 7/12 # Failed test 8 in 
t/modules/buffer.t at line 32 fail #2
  t/modules/buffer.t .. 11/12 # Failed test 12 in 
t/modules/buffer.t at line 32 fail #3
  t/modules/buffer.t .. Failed 3/12 subtests


> On Oct 11, 2018, at 7:15 AM, Plüm, Rüdiger, Vodafone Group 
>  wrote:
> 
> Do you know if the failure is a regression over 2.4.35?
>  
> Regards
>  
> Rüdiger
>  
> Von: Marion et Christophe JAILLET  
> Gesendet: Donnerstag, 11. Oktober 2018 13:13
> An: dev@httpd.apache.org
> Betreff: re: AW: [VOTE] Release httpd-2.4.36
>  
> Waouh!
> 
>  
> 
> This would mean I've provided a new useful test!
> 
> (it has been added recently in r1841508)
> 
>  
> 
> :)
> 
>  
> 
> I definitely need to document how to generate and use test-coverage data when 
> running the test framework.
> 
> This helps to spot where new tests are needed.
> 
>  
> 
> CJ
> 
>  
> 
>  
> 
>  
> 
> > Message du 11/10/18 10:08
> > De : "Plüm, Rüdiger, Vodafone Group" 
> > A : "dev@httpd.apache.org" 
> > Copie à : 
> > Objet : AW: [VOTE] Release httpd-2.4.36
> > 
> > Anyone else seeing
> > 
> > t/modules/buffer.t (Wstat: 0 Tests: 12 Failed: 2)
> > Failed tests: 8, 12
> > 
> > ?
> > 
> > I don't see this with trunk on the same machine. Issue seems to be if input 
> > filtering is on on large POSTs.
> > 
> > Regards
> > 
> > Rüdiger
> > 
> > > -Ursprüngliche Nachricht-
> > > Von: Daniel Ruggeri 
> > > Gesendet: Donnerstag, 11. Oktober 2018 02:27
> > > An: dev@httpd.apache.org
> > > Betreff: Re: [VOTE] Release httpd-2.4.36
> > > 
> > > +1 from me (talking to myself).
> > > 
> > > Test environment follows. I observe only one failure of the test suite
> > > (mentioned elsewhere) - it seems only to apply w/ OpenSSL 1.1.1 and H2.
> > > 
> > > system:
> > >   kernel:
> > > name: Linux
> > > release: 3.16.0-4-amd64
> > > version: #1 SMP Debian 3.16.51-3 (2017-12-13)
> > > machine: x86_64
> > > 
> > >   libraries:
> > > openssl: "1.1.1"
> > > openldap: "2.4.46"
> > > apr: "1.6.5"
> > > apr-util: "1.6.1"
> > > iconv: "1.2.2"
> > > brotli: "1.0.6"
> > > nghttp2: "1.34.0"
> > > zlib: "1.2.11"
> > > pcre: "8.42"
> > > libxml2: "2.9.8"
> > > php: "5.6.38"
> > > lua: "5.3.5"
> > > curl: "7.61.1"
> > > 
> > > --
> > > Daniel Ruggeri
> > > 
> > > On 10/10/2018 2:18 PM, Daniel Ruggeri wrote:
> > > > Hi, all;
> > > >Please find below the proposed release tarball and signatures:
> > > > https://dist.apache.org/repos/dist/dev/httpd/
> > > >
> > > > I would like to call a VOTE over the next few days to release this
> > > > candidate tarball as 2.4.36:
> > > > [ ] +1: It's not just good, it's good enough!
> > > > [ ] +0: Let's have a talk.
> > > > [ ] -1: There's trouble in paradise. Here's what's wrong.
> > > >
> > > > The computed digests of the tarball up for vote are:
> > > > sha1: e40e7a879b84df860215b8a80f2a535534a1c4b4 *httpd-2.4.36.tar.gz
> > > > sha256:
> > > > ef788fb7c814acb2506a8b758a1a3f91f368f97bd4e6db16e98001f468e8e288
> > > > *httpd-2.4.36.tar.gz
> > > >
> > 
> > 



Re: NOTICE: Intent to T 2.4.36

2018-10-11 Thread Jim Jagielski
BTW, and I'm sure you know this, that this fails w/ trunk:

% make
Making all in mod_http2
  CC   mod_http2_la-h2_alt_svc.lo
  CC   mod_http2_la-h2_bucket_beam.lo
  CC   mod_http2_la-h2_bucket_eos.lo
  CC   mod_http2_la-h2_config.lo
  CC   mod_http2_la-h2_conn.lo
h2_conn.c:311:8: error: no member named 'data_in_input_filters' in 'struct 
conn_rec'; did you mean 'clogging_input_filters'?
c->data_in_input_filters  = 0;
   ^
   clogging_input_filters
/usr/local2/apache2/include/httpd.h:1178:18: note: 'clogging_input_filters' 
declared here
unsigned int clogging_input_filters:1;
 ^
h2_conn.c:312:8: error: no member named 'data_in_output_filters' in 'struct 
conn_rec'
c->data_in_output_filters = 0;
~  ^
2 errors generated.

Re: NOTICE: Intent to T 2.4.36

2018-10-11 Thread Jim Jagielski
Gotcha. Thx.


Re: NOTICE: Intent to T 2.4.36

2018-10-11 Thread Jim Jagielski
I suggest you add

   'autoreconf -i'

as a prelim step.


Re: NOTICE: Intent to T 2.4.36

2018-10-11 Thread Jim Jagielski
% autoconf
configure.ac:41: error: possibly undefined macro: AM_INIT_AUTOMAKE
  If this token and others are legitimate, please use m4_pattern_allow.
  See the Autoconf documentation.
% ls
AUTHORS   DISCUSS   Makefile.am   README.md 
configure*mod-h2.xcodeproj/
COPYING   INSTALL   NEWS  autom4te.cache/   
configure.ac  mod_http2/
ChangeLog LICENSE   READMEconfig.logm4/ 
  test/
% ./configure --with-apxs=/usr/local2/apache2/bin/apxs
./configure: line 2332: syntax error near unexpected token `2.2.6'
./configure: line 2332: `LT_PREREQ(2.2.6)'
% autoconf --version
autoconf (GNU Autoconf) 2.69
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+/Autoconf: GNU GPL version 3 or later

Re: [VOTE] Release httpd-2.4.36

2018-10-10 Thread Jim Jagielski
+1:

   o macOS 10.13.6, Xcode 10, OpenSSL 1.1.1
   o CentOS 5&6, OpenSSL 1.0.2, 64bit

Will try to test against CentOS7 and Ubuntu 14.04LTS tomorrow

Thx for RMing!

> On Oct 10, 2018, at 3:18 PM, Daniel Ruggeri  wrote:
> 
> Hi, all;
>   Please find below the proposed release tarball and signatures:
> https://dist.apache.org/repos/dist/dev/httpd/
> 
> I would like to call a VOTE over the next few days to release this candidate 
> tarball as 2.4.36:
> [ ] +1: It's not just good, it's good enough!
> [ ] +0: Let's have a talk.
> [ ] -1: There's trouble in paradise. Here's what's wrong.
> 
> The computed digests of the tarball up for vote are:
> sha1: e40e7a879b84df860215b8a80f2a535534a1c4b4 *httpd-2.4.36.tar.gz
> sha256: ef788fb7c814acb2506a8b758a1a3f91f368f97bd4e6db16e98001f468e8e288 
> *httpd-2.4.36.tar.gz
> 
> -- 
> Daniel Ruggeri



Re: NOTICE: Intent to T 2.4.36

2018-10-10 Thread Jim Jagielski
> 
> Does the TLSv1.3 support need to be production ready?
> 
> TLSv1.3 is presumably an opt-in feature and as long as it doesn’t endanger 
> existing behaviours, I would have assumed it’s relatively safe to release 
> with caveats in the docs. 
> Of course, once there’s more take-up of TLSv1.3, then the test suite needs to 
> be useful. Getting real-world feedback about something completely new that 
> doesn’t endanger existing behaviours outside of TLSv1.3 is probably 
> worthwhile.

The issue is that such a major feature enhancement touches a lot of code. That 
can cause regressions.

Sometimes, some people try to reduce and restrict development and new features 
using that as an argument. I, and numerous others, have consistently disagreed 
with that as a convincing argument against adding stuff to 2.4.x. In this 
particular situation, the "usual suspect(s)" were actually very gung-ho on 
release, despite this being the exact kind of situation they would normally 
balk against. I was noting the discrepancy and wondering the reasoning...



Re: NOTICE: Intent to T 2.4.36

2018-10-10 Thread Jim Jagielski
FWIW, I am NOT proposing that. Nor would I have the right to do so.

> On Oct 10, 2018, at 3:50 PM, Daniel Ruggeri  wrote:
> 
> On 2018-10-10 14:01, William A Rowe Jr wrote:
>> On Wed, Oct 10, 2018 at 1:45 PM Jim Jagielski  wrote:
>>> I thought the whole intent for a quick 2.4.36 was for TLSv1.3
>>> support.
>>> If that's not ready for prime time, then why a release??
>> AIUI, it isn't that httpd isn't ready for release, or even httpd-test
>> framework.
>> Until all the upstream CPAN modules behave reasonably with openssl
>> 1.1.1
>> we will continue to see odd test results.
>> It was my hope we would push this out as 2.5.1-alpha, as now synced
>> with 2.4.x branch, and let the eager early adopters help us uncover
>> any
>> unforeseen issues. Think we have a handle on, and have addressed
>> the anticipated issues.
> 
> Right, my understanding is that this is more around the test suite and how it 
> does the testing rather than the project itself. If that's not the case, and 
> httpd itself isn't ready, I'm OK with aborting the release process.
> 
> -- 
> Daniel Ruggeri



Re: NOTICE: Intent to T 2.4.36

2018-10-10 Thread Jim Jagielski


> On Oct 10, 2018, at 3:37 PM, William A Rowe Jr  wrote:
> 
> On Wed, Oct 10, 2018, 14:28 Jim Jagielski  <mailto:j...@jagunet.com>> wrote:
> 
> 
>> On Oct 10, 2018, at 3:01 PM, William A Rowe Jr > <mailto:wr...@rowe-clan.net>> wrote:
>> 
>> On Wed, Oct 10, 2018 at 1:45 PM Jim Jagielski > <mailto:j...@jagunet.com>> wrote:
>> I thought the whole intent for a quick 2.4.36 was for TLSv1.3 support.
>> 
>> If that's not ready for prime time, then why a release??
>> 
>> AIUI, it isn't that httpd isn't ready for release, or even httpd-test 
>> framework.
>> Until all the upstream CPAN modules behave reasonably with openssl 1.1.1
>> we will continue to see odd test results.
> 
> The question is How Comfortable Are We That TLSv1.3 Support Is Production 
> Ready?
> 
> This release seems very, very rushed to me. It seems strange that for someone 
> who balks against releasing s/w that hasn't been sufficiently tested, or 
> could cause regressions, and that the sole reason for this particular release 
> is TLSv1.3 support which seems insufficiently tested, you are 
> uncharacteristic cool with all this.
> 
> You elided the other half of my answer, you might want to read the entire 
> comment.
> 
> If we can exercise the same discipline with 2.4.37 that we showed with 
> 2.4.35, then instead of producing a string of releases with a string of 
> regressions, we still come out ahead for all users.

You wrote:
   It was my hope we would push this out as 2.5.1-alpha, as now synced
   with 2.4.x branch, and let the eager early adopters help us uncover any
   unforeseen issues. Think we have a handle on, and have addressed
   the anticipated issues.

So "eager early adopters" are OK with modules *you* wish to push out, even if 
they aren't quite ready, but NOT OK with modules and features others want, even 
if they also agree that they 'have a handle on, and have addressed the 
anticipated issues'

In other words: would anyone else have suggested adding a major feature such as 
this, with somewhat questionable testing as well as it being the sole reason 
for said release, you would have complained and dismissed such explanations as 
'eager early adopters' as facetious. I am glad that this is no longer the case 
and you have Seen The Light! As long as we can show an attempt at testing, and 
convince ourselves we have a "handle on" anything that might pop up, and 
addressed any anticipated issues, we can continue adding new features as we 
have been and still come out ahead for all users. Again, this is what I and 
others have been pushing and promoting for years so I am again glad that you 
have finally agreed.

It's the inconsistency that is bothersome.

Re: NOTICE: Intent to T 2.4.36

2018-10-10 Thread Jim Jagielski



> On Oct 10, 2018, at 10:04 AM, Stefan Eissing  
> wrote:
> I have started to convert the existing h2 testsuite in 
> https://svn.apache.org/repos/asf/httpd/test/mod_h2/trunk from shell scripts 
> to pytest in the github repro. I have a pytest suite for mod_md also in its 
> github. 
> 
> My hope is to, one day, make those part of a httpd test suite, probably just 
> by combining the separate standalone ones. Then we could have 
> 'modules/ABC/test' as optional part of a module with a defined way to trigger 
> them.
> 

That would be great because it seems that almost no one is using it, or has 
been able to get that test suite to work. I know I haven't.



Re: NOTICE: Intent to T 2.4.36

2018-10-10 Thread Jim Jagielski


> On Oct 10, 2018, at 3:01 PM, William A Rowe Jr  wrote:
> 
> On Wed, Oct 10, 2018 at 1:45 PM Jim Jagielski  <mailto:j...@jagunet.com>> wrote:
> I thought the whole intent for a quick 2.4.36 was for TLSv1.3 support.
> 
> If that's not ready for prime time, then why a release??
> 
> AIUI, it isn't that httpd isn't ready for release, or even httpd-test 
> framework.
> Until all the upstream CPAN modules behave reasonably with openssl 1.1.1
> we will continue to see odd test results.

The question is How Comfortable Are We That TLSv1.3 Support Is Production Ready?

This release seems very, very rushed to me. It seems strange that for someone 
who balks against releasing s/w that hasn't been sufficiently tested, or could 
cause regressions, and that the sole reason for this particular release is 
TLSv1.3 support which seems insufficiently tested, you are uncharacteristic 
cool with all this.



Re: NOTICE: Intent to T 2.4.36

2018-10-10 Thread Jim Jagielski
I thought the whole intent for a quick 2.4.36 was for TLSv1.3 support.

If that's not ready for prime time, then why a release??

> On Oct 10, 2018, at 2:11 PM, Daniel Ruggeri  wrote:
> 
> On 2018-10-10 07:30, Joe Orton wrote:
>> On Tue, Oct 09, 2018 at 03:29:49PM -0500, Daniel Ruggeri wrote:
>>> Hi, all;
>>>   I ran through my usual testing routine, this time with OpenSSL 1.1.1, but
>>> found several test failures. In the past, these issues have been isolated to
>>> my environment so I just wanted to drop a line to see if anyone has run the
>>> test suite against 2.4.x lately and can corroborate this result? If not, I
>>> can debug my environment.
>> TLSv1.3 testing is still a mess with OpenSSL 1.1.1, sorry.  I have
>> updated the test suite just now to disable TLSv1.3 testing for most
>> people.  We need updates to Net::SSLeay (the latest upstream has the
>> patch) and IO::Socket::SSL, but the latter is not patched upstream, so I
>> can't make an accurate test for that yet.
>> At worst, forcibly testing with:
>>  ./t/TEST -sslproto 'all -TLSv1.2'
>> should now be possible.
>> (If using an existing check-out of the test suite don't forget to re-run
>> "make" before running ./t/TEST -conf to regenerate the config...)
>> Let me know if that's not made any difference for you.
>> I don't know why t/modules/http2.t is failing but I see that here too.
> 
> Thanks Joe and Bill.
> 
> Yep, when flipping back over to OpenSSL 1.1.0i, everything works A-OK. Even 
> the H2 failure irons itself out. It's a bummer to hear TLS 1.3 testing isn't 
> up to snuff with this being the major feature of the release.
> 
> I also just wiped the environment, recompiled everything from scratch (same 
> versions noted below) and reran the tests with the latest test framework and 
> see that the recent changes to the framework leave only the failing h2 test 
> (which doesn't happen w/ 1.1.0i). So... I think it was indeed localized to 
> the test framework.
> 
> I'm also happy to see the H2 EOS fix in, too!
> 
> So... I think I'm content with the results and am ready to T!
> 
>> Regards, Joe
>>> Test Summary Report
>>> ---
>>> t/modules/http2.t (Wstat: 0 Tests: 24 Failed: 0)
>>>  Parse errors: Bad plan.  You planned 52 tests but ran 24.
>>> t/security/CVE-2009-3555.t(Wstat: 0 Tests: 4 Failed: 2)
>>>  Failed tests:  3-4
>>> t/ssl/basicauth.t (Wstat: 0 Tests: 4 Failed: 2)
>>>  Failed tests:  2-3
>>> t/ssl/env.t   (Wstat: 0 Tests: 30 Failed: 15)
>>>  Failed tests:  16-30
>>> t/ssl/extlookup.t (Wstat: 0 Tests: 4 Failed: 4)
>>>  Failed tests:  1-4
>>> t/ssl/fakeauth.t  (Wstat: 0 Tests: 3 Failed: 2)
>>>  Failed tests:  2-3
>>> t/ssl/ocsp.t  (Wstat: 0 Tests: 3 Failed: 1)
>>>  Failed test:  3
>>> t/ssl/require.t   (Wstat: 0 Tests: 10 Failed: 3)
>>>  Failed tests:  2, 5, 9
>>> t/ssl/varlookup.t (Wstat: 0 Tests: 83 Failed: 83)
>>>  Failed tests:  1-83
>>> t/ssl/verify.t(Wstat: 0 Tests: 3 Failed: 1)
>>>  Failed test:  2
>>> Files=186, Tests=8857, 101 wallclock secs ( 1.86 usr  0.28 sys + 48.46 cusr
>>> 11.08 csys = 61.68 CPU)
>>> Versions at play were:
>>> system:
>>>  kernel:
>>>name: Linux
>>>release: 3.16.0-4-amd64
>>>version: #1 SMP Debian 3.16.51-3 (2017-12-13)
>>>machine: x86_64
>>>  libraries:
>>>openssl: "1.1.1"
>>>openldap: "2.4.46"
>>>apr: "1.6.5"
>>>apr-util: "1.6.1"
>>>iconv: "1.2.2"
>>>brotli: "1.0.6"
>>>nghttp2: "1.34.0"
>>>zlib: "1.2.11"
>>>pcre: "8.42"
>>>libxml2: "2.9.8"
>>>php: "5.6.38"
>>>lua: "5.3.5"
>>>curl: "7.61.1"
>>> Anything look obviously crazy/wrong?
>>> --
>>> Daniel Ruggeri
>>> On 2018-10-09 06:36, Daniel Ruggeri wrote:
>>> > Hi, all;
>>> >  Barring any major disagreement in the next several hours, I intend to
>>> > T our next version later today or early tomorrow.
>>> >
>>> > Hooray for TLS 1.3!
>>> > --
>>> > Daniel Ruggeri
> 
> -- 
> Daniel Ruggeri



Apache httpd 2.4.35 announcement on Twitter

2018-10-01 Thread Jim Jagielski
I didn't see any announcement about the 2.4.35 release on twitter... did I just 
miss it?

Using APR pools "better"

2018-09-26 Thread Jim Jagielski
At ApacheCon's welcoming event last night, Greg, Sander and I were chatting and 
Greg reminded us that the Subversion project "learned a lot about using APR 
pools" and it seems to me that a lot of that knowledge is likely missing in 
httpd-land. I also know that some of that has been backported back to APR 
itself, but I am wondering (as I am wont to do), if we couldn't do a better job 
here. I am sure that there are things in svn that could be easily and readily 
folded back into APR w/o breaking anything.

I know that some of that influenced Greg's PoCore work, but it would be really 
cool if someone in Subversion could maybe point out some of those improvements 
and "lessons learned" so that both APR and httpd could benefit.

Thx!

Re: Announce missing - in moderation?

2018-09-25 Thread Jim Jagielski
FWIW, I just saw a mod request for *an* announcement and approved it

> On Sep 25, 2018, at 12:19 PM, Private LIst Moderation 
>  wrote:
> 
> Hi Daniel,
> 
> I've looked in the moderation queue and did not find the announce@ moderation 
> email.
> 
> Craig
> 
>> On Sep 25, 2018, at 7:00 AM, Daniel Ruggeri > > wrote:
>> 
>> Infra points out it's easier to just resend than to dig out the message they 
>> found on the server. I've sent again - receiving these confirmations:
>> 
>> < 235 2.7.0 Authentication successful
>>> MAIL FROM:mailto:drugg...@apache.org>> SIZE=2919
>> < 250 2.1.0 Ok
>>> RCPT TO:mailto:annou...@httpd.apache.org>>
>> < 250 2.1.5 Ok
>>> DATA
>> < 354 End data with .
>> } [data not shown]
>> * We are completely uploaded and fine
>> < 250 2.0.0 Ok: queued as EB77F2332
>> 
>> < 235 2.7.0 Authentication successful
>>> MAIL FROM:mailto:drugg...@apache.org>> SIZE=874
>> < 250 2.1.0 Ok
>>> RCPT TO:mailto:annou...@httpd.apache.org>>
>> < 250 2.1.5 Ok
>>> DATA
>> < 354 End data with .
>> } [data not shown]
>> * We are completely uploaded and fine
>> < 250 2.0.0 Ok: queued as 9B4B1E1B
>> 
>> I've also added Craig here as he was unable to find the message sent to 
>> announce@a.o  - with luck, these won't vanish, but at 
>> least this time I have the message IDs...
>> -- 
>> Daniel Ruggeri
>> 
>> On 2018-09-24 16:59, Daniel Ruggeri wrote:
>>> Yes, I sent via curl (true story, you can send email with curl)
>>> directly to the relay service and authenticated with my ASF
>>> credentials. I had checked in with Infra here at ACNA and they saw
>>> *something* that looked like my message. I'll check in with them
>>> again.
>>> Thanks, folks
>>> --
>>> Daniel Ruggeri
>>> On September 24, 2018 3:07:00 PM EDT, William A Rowe Jr
>>> mailto:wr...@rowe-clan.net>> wrote:
 I'm seeing no announce@httpd moderation request. (I am not an
 annou...@apache.org  moderator.)
 Did you send from your @apache.org [1] avail-id through the ASF
 server? It would
 be rejected for non-apache and for mismatched SPF records.
 On Mon, Sep 24, 2018 at 9:16 AM Daniel Ruggeri >>> >
 wrote:
> Hi, all;
> I sent the announce message for 2.4.35, but haven't received it
> myself. I didn't get errors sending that I am aware of. Perhaps it
> is in moderation? If not, I can check in with infra to see if
> mail-relay.a.o ate it.
> Thanks
> --
> Daniel Ruggeri
>>> Links:
>>> --
>>> [1] http://apache.org 
>> 
> 
> Craig L Russell
> Secretary, Apache Software Foundation
> c...@apache.org  http://db.apache.org/jdo 
> 



Re: Announce missing - in moderation?

2018-09-24 Thread Jim Jagielski
me no see either

> On Sep 24, 2018, at 10:22 AM, .  wrote:
> 
> Confirming that I also didn't receive the announce email.
> 
> On Mon, Sep 24, 2018, 10:16 AM Daniel Ruggeri  > wrote:
> Hi, all;
>I sent the announce message for 2.4.35, but haven't received it myself. I 
> didn't get errors sending that I am aware of. Perhaps it is in moderation? If 
> not, I can check in with infra to see if mail-relay.a.o ate it.
> 
> Thanks
> -- 
> Daniel Ruggeri



Re: svn commit: r1841573 - in /httpd/httpd/branches/2.4.x: ./ CHANGES STATUS docs/manual/mod/mod_ssl.xml modules/ssl/mod_ssl.c modules/ssl/ssl_engine_config.c modules/ssl/ssl_engine_init.c modules/ssl

2018-09-21 Thread Jim Jagielski
*cheers*!!

> On Sep 21, 2018, at 8:14 AM, minf...@apache.org wrote:
> 
> Author: minfrin
> Date: Fri Sep 21 12:14:05 2018
> New Revision: 1841573
> 
> URL: http://svn.apache.org/viewvc?rev=1841573=rev
> Log:
> Add TLSv1.3 support to mod_ssl:
> trunk: http://svn.apache.org/r1839946
>   http://svn.apache.org/r1839920
>   http://svn.apache.org/r1833589
>   http://svn.apache.org/r1833588
>   http://svn.apache.org/r1828723
>   http://svn.apache.org/r1828720
>   http://svn.apache.org/r1828222
>   http://svn.apache.org/r1827992
>   http://svn.apache.org/r1827924
>   http://svn.apache.org/r1827912
>   http://svn.apache.org/r1828790
>   http://svn.apache.org/r1828791
>   http://svn.apache.org/r1828792
>   http://svn.apache.org/r1840585
>   http://svn.apache.org/r1840710
>   http://svn.apache.org/r1841218
> 2.4.x branch: svn merge ^/httpd/httpd/branches/tlsv1.3-for-2.4.x
> 
> Modified:
>httpd/httpd/branches/2.4.x/   (props changed)
>httpd/httpd/branches/2.4.x/CHANGES
>httpd/httpd/branches/2.4.x/STATUS
>httpd/httpd/branches/2.4.x/docs/manual/mod/mod_ssl.xml
>httpd/httpd/branches/2.4.x/modules/ssl/mod_ssl.c
>httpd/httpd/branches/2.4.x/modules/ssl/ssl_engine_config.c
>httpd/httpd/branches/2.4.x/modules/ssl/ssl_engine_init.c
>httpd/httpd/branches/2.4.x/modules/ssl/ssl_engine_kernel.c
>httpd/httpd/branches/2.4.x/modules/ssl/ssl_private.h
> 
> Propchange: httpd/httpd/branches/2.4.x/
> --
> --- svn:mergeinfo (original)
> +++ svn:mergeinfo Fri Sep 21 12:14:05 2018
> @@ -1,11 +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:1825504
> /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
> 

Re: trunk proxy_http failures

2018-09-19 Thread Jim Jagielski
Does folding 
http://home.apache.org/~ylavic/patches/2.4.x-mpms_async_objects_lifetime.patch
into 2.4.x make any difference??

> On Sep 19, 2018, at 10:10 AM, Stefan Eissing  
> wrote:
> 
> Hi,
> 
> the h2 test suite has tests with http/2 in the front and a standard 
> proxy_http to localhost. When running the test suite against trunk, the tests 
> run into a failed GET on a proxy. The request hangs 5 seconds and the fails 
> reading the status line, as seen below. The proxy is defined as:
> 
>
>BalancerMember "https://127.0.0.1:SUBST_PORT_HTTPS_SUBST; hcmethod=GET 
> hcuri=/
>
>...
>ProxyPass "/proxy" "balancer://http-local"
>ProxyPassReverse "/proxy" "balancer://http-local"
> 
> Typical log:
> [Wed Sep 19 14:02:58.038602 2018] [http2:trace1] [pid 35806:tid 
> 123145377832960] h2_task.c(675): [client 127.0.0.1:64231] h2_task(200-13): 
> start process_request
> [Wed Sep 19 14:02:58.038654 2018] [proxy:debug] [pid 35806:tid 
> 123145377832960] proxy_util.c(1326): AH10122: proxy: Entering byrequests for 
> BALANCER (balancer://https-local)
> [Wed Sep 19 14:02:58.038679 2018] [proxy:debug] [pid 35806:tid 
> 123145377832960] proxy_util.c(1418): AH10123: proxy: byrequests selected 
> worker "https://127.0.0.1:12346; : busy 0 : lbstatus 100
> [Wed Sep 19 14:02:58.038694 2018] [proxy:debug] [pid 35806:tid 
> 123145377832960] proxy_util.c(1971): AH00924: worker https://127.0.0.1:12346 
> shared already initialized
> [Wed Sep 19 14:02:58.038712 2018] [proxy:debug] [pid 35806:tid 
> 123145377832960] proxy_util.c(2028): AH00926: worker https://127.0.0.1:12346 
> local already initialized
> [Wed Sep 19 14:02:58.038736 2018] [proxy:debug] [pid 35806:tid 
> 123145377832960] mod_proxy.c(1258): [client 127.0.0.1:64231] AH01143: Running 
> scheme balancer handler (attempt 0)
> [Wed Sep 19 14:02:58.038756 2018] [proxy:debug] [pid 35806:tid 
> 123145377832960] proxy_util.c(2367): AH00942: HTTPS: has acquired connection 
> for (127.0.0.1)
> [Wed Sep 19 14:02:58.038775 2018] [proxy:debug] [pid 35806:tid 
> 123145377832960] proxy_util.c(2421): [client 127.0.0.1:64231] AH00944: 
> connecting https://127.0.0.1:12346/files/data-1m to 127.0.0.1:12346
> [Wed Sep 19 14:02:58.038790 2018] [proxy:debug] [pid 35806:tid 
> 123145377832960] proxy_util.c(2630): [client 127.0.0.1:64231] AH00947: 
> connected /files/data-1m to 127.0.0.1:12346
> [Wed Sep 19 14:03:03.041506 2018] [proxy_http:error] [pid 35806:tid 
> 123145377832960] (70014)End of file found: [client 127.0.0.1:64231] AH01102: 
> error reading status line from remote server 127.0.0.1:12346
> [Wed Sep 19 14:03:03.041541 2018] [proxy_http:debug] [pid 35806:tid 
> 123145377832960] mod_proxy_http.c(1386): [client 127.0.0.1:64231] AH01104: 
> Closing connection to client because reading from backend server 
> 127.0.0.1:12346 failed. Number of keepalives 1
> 
> What can I best do to further debug this?
> 
> Should I disable the balancer and see if the problem persists?
> 
> Help appreciated, thanks!
> 
> -Stefan



Re: svn commit: r1841078 - in /apr/apr/trunk: CHANGES apr.dsp atomic/unix/builtins64.c atomic/unix/mutex64.c atomic/win32/apr_atomic64.c include/apr_atomic.h include/arch/unix/apr_arch_atomic.h test/t

2018-09-18 Thread Jim Jagielski
Moved from httpd dev (which was moved to BCC)

> On Sep 17, 2018, at 2:54 PM, Yann Ylavic  wrote:
> 
> On Mon, Sep 17, 2018 at 5:52 PM Jim Jagielski  wrote:
>> 
>> Would like to also propose for apr-1.7...
> 
> How about 128bit? :p
> 
> There are __int128 (gcc) and _m128 (MSVC) and most 64bit intel/amd
> CPUs support cmpxchg16b.

The ‘__atomic’ builtins can be used with any integral scalar or pointer type 
that is 1, 2, 4, or 8 bytes in length. 16-byte integral types are also allowed 
if ‘__int128’ (see __int128 
<https://gcc.gnu.org/onlinedocs/gcc/_005f_005fint128.html#g_t_005f_005fint128>) 
is supported by the architecture.

This also implies that APR create a 128bit Int type, which we don't (yet).

Bumping to support 64bit was easy and logical.. bumping to 128 requires more 
legwork and is a bit more "intrusive" ;)

+1 to the theory though.

Fwd: svn commit: r1841078 - in /apr/apr/trunk: CHANGES apr.dsp atomic/unix/builtins64.c atomic/unix/mutex64.c atomic/win32/apr_atomic64.c include/apr_atomic.h include/arch/unix/apr_arch_atomic.h test/

2018-09-17 Thread Jim Jagielski
Would like to also propose for apr-1.7... 

> Begin forwarded message:
> 
> From: j...@apache.org
> Subject: svn commit: r1841078 - in /apr/apr/trunk: CHANGES apr.dsp 
> atomic/unix/builtins64.c atomic/unix/mutex64.c atomic/win32/apr_atomic64.c 
> include/apr_atomic.h include/arch/unix/apr_arch_atomic.h test/testatomic.c
> Date: September 17, 2018 at 11:50:19 AM EDT
> To: comm...@apr.apache.org
> Reply-To: d...@apr.apache.org
> 
> Author: jim
> Date: Mon Sep 17 15:50:19 2018
> New Revision: 1841078
> 
> URL: http://svn.apache.org/viewvc?rev=1841078=rev
> Log:
> Add in Atomics for 64bit ints
> 



Re: Making proxy "busy" atomic and implement a busy limit

2018-09-17 Thread Jim Jagielski
The reason, is that if we can add that to apr-1.7, we don't need to change the 
struct in httpd ;)

> On Sep 17, 2018, at 10:11 AM, Jim Jagielski  wrote:
> 
> Well, we do check all this via configure... if the platforms supports 64 
> "native" atomics then we could use those; if not, we could use the portable 
> versions as a backup (or simply return NOTIMPL).
> 
> I don't see how this is different from how we handle atomics currently, but I 
> could be mistaken.
> 
>> On Sep 17, 2018, at 10:03 AM, Nick Kew  wrote:
>> 
>> Apologies to Jim.  Sent this to him, meant for the dev list of course.
>> 
>>>> On 17 Sep 2018, at 14:18, Jim Jagielski  wrote:
>>>> 
>>>> FYI: Both clang and GCC support both __sync and __atomic which support 
>>>> 64bit ints. We could add that functionality to APR... 
>>> 
>>> We could indeed.
>>> 
>>> But does that not potentially leave a nasty gotcha?  Where a developer uses 
>>> it and expects
>>> atomic operations, and their application is subsequently built on a 
>>> platform that
>>> doesn't support those qualifiers.
>>> 
>>> With the obvious fallback it breaks silently.  With a more 
>>> sophisticated/heavyweight
>>> fallback, we should consider whether it's maintainable or likely to fall 
>>> into disrepair.
>>> 
>>> I wouldn't want to stop you, but it needs some thought.
>>> 
>>> -- 
>>> Nick Kew
>> 
> 



Re: Making proxy "busy" atomic and implement a busy limit

2018-09-17 Thread Jim Jagielski
FYI: Both clang and GCC support both __sync and __atomic which support 64bit 
ints. We could add that functionality to APR... 

> On Sep 17, 2018, at 8:57 AM, Jim Jagielski  wrote:
> 
> In principle, I agree w/ making these counters atomic... up to now, some 
> minor discrepancies from "real" has been accepted noise, but the more 
> sophisticated we get, the less we can accept such potential drift.
> 
> +1 to both.
> 
>> On Sep 17, 2018, at 8:44 AM, Rainer Jung  wrote:
>> 
>> I am thinking about making the proxy worker busy count atomic. Currently we 
>> use an apr_size_t in shared memory and increment/decrement simply using the 
>> C ++/-- operators. My (somewhat outdated) experience from mod_jk is, that 
>> this is not necessarily atomic and might lead to missing updates, letting 
>> the proxy worker busy count drift in any direction.
>> 
>> Since I am also thinking about implementing a busy limit (per proxy worker), 
>> the correctness of the proxy worker busy count would get much more 
>> important. I think such a configurable limit would be really useful, because 
>> it allows some (limited) form of resource management in a reverse proxy, 
>> allowing to define the maximum number of concurrency that is allowed for 
>> each worker. This will prevent the reverse proxy from getting disfunctional 
>> when some slow worker backend starts to consume more and more reverse proxy 
>> slots. Not in all cases can you counter such a scenario with ambigous 
>> response timeouts, which will also kill sporadic slow requests.
>> 
>> Note that apr atomics are 32 bit counters and current proxy worker busy 
>> counts might be 64 bit depending on platform. But real busy (concurrency) 
>> counters will hardly ever exceeed 32 bit limits.
>> 
>> Any comments on
>> 
>> - making proxy worker busy count atomic (using APR atomics)
>> 
>> - adding a feature to restrict the maximum busyness per proxy worker
>> 
>> Thanks and regards,
>> 
>> Rainer
> 



Re: Making proxy "busy" atomic and implement a busy limit

2018-09-17 Thread Jim Jagielski
In principle, I agree w/ making these counters atomic... up to now, some minor 
discrepancies from "real" has been accepted noise, but the more sophisticated 
we get, the less we can accept such potential drift.

+1 to both.

> On Sep 17, 2018, at 8:44 AM, Rainer Jung  wrote:
> 
> I am thinking about making the proxy worker busy count atomic. Currently we 
> use an apr_size_t in shared memory and increment/decrement simply using the C 
> ++/-- operators. My (somewhat outdated) experience from mod_jk is, that this 
> is not necessarily atomic and might lead to missing updates, letting the 
> proxy worker busy count drift in any direction.
> 
> Since I am also thinking about implementing a busy limit (per proxy worker), 
> the correctness of the proxy worker busy count would get much more important. 
> I think such a configurable limit would be really useful, because it allows 
> some (limited) form of resource management in a reverse proxy, allowing to 
> define the maximum number of concurrency that is allowed for each worker. 
> This will prevent the reverse proxy from getting disfunctional when some slow 
> worker backend starts to consume more and more reverse proxy slots. Not in 
> all cases can you counter such a scenario with ambigous response timeouts, 
> which will also kill sporadic slow requests.
> 
> Note that apr atomics are 32 bit counters and current proxy worker busy 
> counts might be 64 bit depending on platform. But real busy (concurrency) 
> counters will hardly ever exceeed 32 bit limits.
> 
> Any comments on
> 
> - making proxy worker busy count atomic (using APR atomics)
> 
> - adding a feature to restrict the maximum busyness per proxy worker
> 
> Thanks and regards,
> 
> Rainer



Re: 2.4.35 in Sept?

2018-09-12 Thread Jim Jagielski



> On Sep 12, 2018, at 4:14 PM, William A Rowe Jr  wrote:
> 
> Since we still have no schema to solve the project maintenance side of
> shipping source code

Sorry, but we have this thing called creating test tarballs and calling for a 
vote. I am sure you remember that.

The idea is that people actually take the time to download the tarballs, build 
a version of httpd for their use and then perform testing on said version such 
that they can vote on whether to release it or not. That testing entails such 
activities as running it through our test framework, putting it in a dev/prod 
environment to see how it works, etc... That is a schema that we have had 
for... let me see... years and decades.

What improvements do you have to suggest to improve upon this? Do you recommend 
a longer vote time? Do you recommend beta and/or release-candidates? Do you 
recommend that the 1st born of all voters be held in a camp until the release 
has "proven" itself to be up to your satisfaction ensuring that said voters 
have "skin in the game"?

It is better to light a single candle than to curse the darkness.



Re: 2.4.35 in Sept?

2018-09-12 Thread Jim Jagielski


> On Sep 12, 2018, at 4:14 PM, William A Rowe Jr  wrote:
> 
> On Tue, Sep 11, 2018 at 8:01 AM Jim Jagielski  <mailto:j...@jagunet.com>> wrote:
> If there is still interest, there are a handful of useful backports in STATUS 
> that could use review, testing and voting :-)
> 
> Unless the goal is to replace one set of regressions with a new set 
> of regressions, it's past due to tag 2.4.35 before "useful" returns as 
> the de facto criteria again on 2.4.x.
> 

Certainly that is up to the RM and the people reviewing, testing and voting on 
the backports...



Re: 2.4.x and 2.6.x ... next steps

2018-09-12 Thread Jim Jagielski



> On Sep 12, 2018, at 10:27 AM, Stefan Eissing  
> wrote:
> 
> I feel myself in agreement with Bill that trunk needs to be where 2.5.x is 
> born.
> 

It is. That should be clear in the proposal.

What should also be clear is that there is a LOT in trunk that should be in 
2.4.x and has nothing to do with 2.5/2.6/3.0/next-gen. So backporting that 
stuff HELPS midwifing 2.5/2.6!



Re: Cool Stuff In trunk: (Was: Re: 2.4.x and 2.6.x ... next steps)

2018-09-12 Thread Jim Jagielski
Thanks, this is useful.

At first blush, this looks like there is a crap-ton of stuff in trunk than can, 
and should, be quickly and easily backported to 2.4 asap!!

> On Sep 12, 2018, at 10:06 AM, William A Rowe Jr  wrote:
> 
> On Wed, Sep 12, 2018 at 7:49 AM Jim Jagielski  <mailto:j...@jagunet.com>> wrote:
> As I said before, the main assumption in my suggestion is that there are 
> things in trunk that "really should" be in some releasable version
> 
> Everything in trunk is now digested into three groups of commits, for 
> inspection. These don't include whitespace changes, so the resulting files 
> may be mis-indented and otherwise skewed, but we are looking for changes, not 
> insignificant formatting;
> 
> Just the docs (sources, and generated)
> http://svn.apache.org/viewvc?view=revision=1840682 
> <http://svn.apache.org/viewvc?view=revision=1840682>
> http://svn.apache.org/viewvc?view=revision=1840684 
> <http://svn.apache.org/viewvc?view=revision=1840684>
> 
> Just win32 generated build gunk (presuming vcproj and CMake are both winners, 
> there is a discussion to be had on .mak files before this gap is addressed)
> http://svn.apache.org/viewvc?view=revision=1840687 
> <http://svn.apache.org/viewvc?view=revision=1840687>
> 
> Everything else (all the interesting stuff)
> http://svn.apache.org/viewvc?view=revision=1840688 
> <http://svn.apache.org/viewvc?view=revision=1840688> 
> 
> I expect committers will be mostly interested in the last link above.
> 



Re: 2.4.x and 2.6.x ... next steps

2018-09-12 Thread Jim Jagielski



> On Sep 12, 2018, at 9:39 AM, William A Rowe Jr  wrote:
> 
> 
> So although others mentioned 2.4.x branch, this is not the origin of YOUR 
> proposal. Wow, that simplifies this discussion a lot (and hopefully, our new 
> committers who never even corresponded with some long absent colleagues now 
> see my concern with the dismissiveness against using trunk.) Sorry that I 
> misattributed that part of the discussion to your proposal.
> 
> Here is the problem I have with forking today. I expect you know I have no 
> problem with tagging 2.5.1-alpha any day of the week and putting 2.5 
> candidates up for release vote.
> 
> During the 'development' of 2.odd we have no need to fork, because all 
> API/ABI changes are permitted between 2.5.1 and 2.5.2. Our trunk needs to be 
> usable all the time, not just during this release prep. But, forking 
> introduces a mess of svn maintenance to no justified purpose.
> 
> And most of all, we need to trust our fellow committers. It is clear that 
> review before or after does not eliminate all errors. But 2.5 will not be GA 
> (2.6 will be.)
> 
> The straight line, avoiding a ton of excess backports, and keeping it simple 
> on the RM, is to either 1. Tag from the final, accepted 2.5.x svn commit rev 
> into 2.6.x branch, or 2. from trunk to 2.6.x branch if the RM believes the 
> changes are limited risk, and can be vetted during the release vote.
> 
> Forking 2.5.x says, outright, I don't trust my fellow committers with commit 
> bits to the alpha/beta development branch. That is also a bad signal to send 

Not at all. It sez "here is a safe space to continue to go wild and here is a 
place where there is an expected direct path to a releasable version"... no 
diff from when we had httpd-2.2, httpd-2.4 and trunk. We just have httpd-2.4, 
httpd-2.5 and trunk.

And again, ALL of this is predicated on the assumption that there is stuff in 
trunk (really useful and tested stuff) that cannot be backported to 2.4. 
Obviously, it is a lot easier, and takes a lot less time, to continue as we are 
and backport as we can; even some of the "impossible" stuff may actually be 
backportable with less effort than spinning 2.5/2.6. And, again personally, I 
think we are doing an extremely good job in balancing things between trunk and 
httpd-2.4, with most divergences either fluff or sandbox-type refactorings that 
may not pass muster when all is said and done.

Cool Stuff In trunk: (Was: Re: 2.4.x and 2.6.x ... next steps)

2018-09-12 Thread Jim Jagielski
As I said before, the main assumption in my suggestion is that there are things 
in trunk that "really should" be in some releasable version, stuff significant 
enough to warrant the work, but is "impossible" to be backported to 2.4.

If there are no real significant-but-impossible-to-backport features in trunk, 
then the proposal itself is moot.

So let's think about it: What is currently in trunk that is a pretty 
significant improvement? Then ask if it is directly backportable. Certainly the 
effort in backporting from trunk to 2.4.x is much less than the effort in 
spinning out 2.6.x and considering all things, that should be the primary flow.

Re: 2.4.x and 2.6.x ... next steps

2018-09-12 Thread Jim Jagielski
Ahh. I think I see the problem! For some reason Bill sees this as somehow
Jim's (my) fork. It's not. It's a  svn branch from HEAD of trunk, which contains
all the changes. That branch is the projects's branch not some personal
fork, whatever that means.

> On Sep 12, 2018, at 6:49 AM, William A Rowe Jr  wrote:
> 
> On Wed, Sep 12, 2018, 04:16 Daniel Gruno  <mailto:humbed...@apache.org>> wrote:
> On 09/12/2018 10:58 AM, Graham Leggett wrote:
> > On 12 Sep 2018, at 03:15, William A Rowe Jr  > <mailto:wr...@rowe-clan.net> 
> > <mailto:wr...@rowe-clan.net <mailto:wr...@rowe-clan.net>>> wrote:
> > 
> >> On Tue, Sep 11, 2018, 17:42 Graham Leggett  >> <mailto:minf...@sharp.fm> 
> >> <mailto:minf...@sharp.fm <mailto:minf...@sharp.fm>>> wrote:
> >>
> >> On 11 Sep 2018, at 20:35, Jim Jagielski  >> <mailto:j...@jagunet.com <mailto:j...@jagunet.com>>> wrote:
> >>
> >> > This is what I propose:
> >> >
> >> >  o Later on this week I svn cp trunk over to branches/2.5.x
> >>
> >>
> >> -1 ... Veto on the basis of project bylaws. Propose a revision for voting.
> > 
> > I've totally lost you. Jim describes creating a branch, how is this 
> > related to voting?
> 
> I am not Bill, but it is likely a reference to the fact that you can 
> veto code changes, not community/workflow changes. I see Jim's proposal 
> as the latter, so I'm not sure why the attempted veto. The codebase 
> itself isn't being changed from what I can gather, only the workflow is.
> 
> Yes. To be clear, the proposal to make 2.5 Jim's fork, discarding all 
> previously committed changes to 2.5 (and I suppose, renumbering trunk as 2.7) 
> is a change to the project development process at httpd.
> 
> As-it-stands, such a personal fork is vetoable. And flies in sharp contrast 
> to community over code, discarding the existing collaboration of 2.5.1-dev 
> trunk in favor of one participants agenda.
> 
> Note, sandboxes are encouraged, don't require any vote to start one, and 
> might lead to some compromise between points a and b.
> 
> I suggest above, propose a *process* revision to our /dev/ docs for a vote, 
> before proceeding to violate community norms on versioning. Sorry for the 
> confusion about what I was proposing to 'revise'.
> 
> As a project committee vote to change our operational process, that is a 
> simple majority vote, as Daniel observes, which would carve out space for a 
> zombie (never to be released) trunk,



Re: 2.4.x and 2.6.x ... next steps

2018-09-12 Thread Jim Jagielski



> On Sep 11, 2018, at 4:57 PM, Eric Covener  wrote:
> 
>> + clearly document the changes in 2.4 -> 2.5/2.6, to start building the
>> next https://httpd.apache.org/docs/current/upgrading.html.
> 
> as well as docs/manual/new_features_2.5.xml
> 
> I am not sure 2.6 has much to offer. But it's a bit of a
> chicken-and-egg problem I guess.

My thought was that the suspend stuff and async filters were
significant/useful enough and that they were un-backportable,
hence what I wrote in the last paragraph that that improvement
may be the only real diff between 2.4 and 2.6.


2.4.x and 2.6.x ... next steps

2018-09-11 Thread Jim Jagielski
I'd like for us to seriously consider the next steps
related to the future of httpd.

In trunk we have some stuff that can be easily, or, at
least, *somewhat* easily backported to 2.4.x, and I
personally think that we should do that. But we also
have some items which cannot be backported due to API/ABI
concerns, and some of these are pretty useful things.
And finally, we have some things in trunk that will likely
need to be majorly fixed or else scrapped.

The 1st thing we need to do is classify those things
within trunk. We then need to backport what we can,
and should, and then make progress on a 2.6.x release
(please note, I am using shorthand here... yes, I know
what we *really* do is a 2.5.x which then goes to 2.6.x
but I'm hopeful we all know what I mean).

This is what I propose:

  o Later on this week I svn cp trunk over to branches/2.5.x
  o That branch becomes the initial source for 2.6.x
  o trunk remains CTR, whereas branches/2.5.x becomes RTC
ala 2.4.x (ie: using STATUS and specific, targeted
backport requests).
  o Backports to 2.4.x only come from 2.5.x
  o We then release a 2nd alpha from branches/2.5.x
  o We get 2.5.x into a releasable stage, whereas we
svn mv branches/2.5.x to branches/2.6.x

A combination of trunk's STATUS and 2.4.x's STATUS will
become the STATUS for 2.5.x... see below for the why (but
basically that file will serve as the place where those
above "classifications" will be documented).

The main goal is that this creates a somewhat "stable"
2.5.x branch which can be polished but as well serve as
the source for backports. Additional development continues
on trunk w/o mussing up 2.5.x... but there is also a path
that stuff in trunk can end-up in 2.6.x. In also allows us
to remove "experiments" in the old trunk (and now 2.5.x)
which are broken or, at least, doesn't have enough support
to warrant being released (a glance thru 2.4.x's STATUS file
for backports which are stagnated, etc provide some clues
on what those could be... at the least, this will provide
incentive to address those concerns or revert those additions)

For me, the main push for this are some of the various async
improvements in trunk that, at least from what I can tell,
simply cannot be backported. It is possible that those improvements
will be the primary and almost-singular distinction between
2.4.x and 2.6.x after all is said and done, but who knows...

Thoughts? Comments?


Re: 2.4.35 in Sept?

2018-09-11 Thread Jim Jagielski
If there is still interest, there are a handful of useful backports in STATUS 
that could use review, testing and voting :-)

> On Aug 29, 2018, at 10:10 AM, Jim Jagielski  wrote:
> 
> Looking to maybe do an interim release in Sept...
> 
> Comments? Feedback?



Re: TLSv1.3 supprt for 2.4.x?

2018-09-03 Thread Jim Jagielski
+1! for backporting

> On Sep 3, 2018, at 5:17 AM, Stefan Eissing  
> wrote:
> 
> Dear SSL care takers and stake holders,
> 
> trunk has TLSv1.3 support for some time. I just now changed the 'all' 
> SSLProtocol selection, so that it does not include TLSv1.3. This means that 
> in order to enable it, admins must add an explicit '+TLSv1.3' to their config 
> (same for SSLProxyProtocl of course).
> 
> With this, the added support is really an opt-in and we could backport it to 
> 2.4.x, if we want. We have been burned with backporting SSL features just 
> recently (by my mistake), so I would understand that people feel a bit 
> reluctant here. On the other hand, there is certainly interest by users.
> 
> So, what is your opinion?
> 
> Cheers,
> 
> Stefan
> 
> PS. There are some combinations in renegotiation/client certs that are not 
> tested well. Therefore, '+TLSv1.3' should be tagged as 'experimental' or at 
> least with a heavy caveat for those setups. But I see no issue with using it 
> for plain-vanilla https: setups.



Re: Run httpd's testsuite

2018-09-03 Thread Jim Jagielski
The test framework itself is under:

https://svn.apache.org/viewvc/httpd/test/framework/trunk/

and is run using:

t/TEST

> On Sep 3, 2018, at 3:34 AM, Danesh Daroui  wrote:
> 
> Hi Jim!
> 
> Thanks for the tip, but how can I do that? Following the make file
> when "make check" is executed would be an option?
> 
> Regards,
> 
> Danesh
> 
> On Sun, Sep 2, 2018 at 9:25 PM Jim Jagielski  wrote:
>> 
>> FWIW, I've never run 'make check' but always run the test suite explicitly.
>> 
>>> On Sep 2, 2018, at 6:49 AM, Danesh Daroui  wrote:
>>> 
>>> Hi all,
>>> 
>>> I would like to be bale to run Apache https's testsuite. I have clones
>>> Apache-Test and configures the project with the given path and then
>>> built the httpd server, but when I execute "make cheek", all tests for
>>> "all.t" are skipped. The logs show that the test scripts runs the
>>> server with some isolated configurations on a specific port but it
>>> apparently cannot find "mod_perl.c" for instance. This is the last
>>> part of the log that I get when I run the test:
>>> 
>>> waiting 60 seconds for server to start: .
>>> waiting 60 seconds for server to start: ok (waited 0 secs)
>>> server localhost:8529 started
>>> [   info] adding source lib
>>> /home/danesh/open/github/Apache-Test/../Apache-Test/lib to @INC
>>> t/alltest/all.t . skipped: testing all.t
>>> t/alltest2/all.t  skipped: testing more than one all.t
>>> t/bad_coding.t .. ok
>>> t/cookies.t . skipped: cannot find module 'CGI',
>>> cannot find module 'CGI::Cookie'
>>> t/import.t .. ok
>>> t/log_watch.t ... ok
>>> t/log_watch_for_broken_lines.t .. ok
>>> t/more/all.t  skipped: cannot find module 'mod_perl.c'
>>> t/next_available_port.t . ok
>>> t/ping.t  ok
>>> t/redirect.t  ok
>>> t/request.t . ok
>>> t/sok.t . ok
>>> All tests successful.
>>> Files=13, Tests=91,  4 wallclock secs ( 0.05 usr  0.01 sys +  2.17
>>> cusr  0.56 csys =  2.79 CPU)
>>> Result: PASS
>>> [warning] server localhost:8529 shutdown
>>> 
>>> There are also some unit tests under "test" directory that they are
>>> all passed when I run the executable. I would like to know what is the
>>> difference between these two tests? Also I expected the tests that are
>>> triggered with "make check" to be much more extensive than some small
>>> tests that are run quickly. Something like night-run tests! Am I
>>> missing something?
>>> 
>>> Regards,
>>> 
>>> Danesh Daroui
>> 



Re: Run httpd's testsuite

2018-09-02 Thread Jim Jagielski
FWIW, I've never run 'make check' but always run the test suite explicitly. 

> On Sep 2, 2018, at 6:49 AM, Danesh Daroui  wrote:
> 
> Hi all,
> 
> I would like to be bale to run Apache https's testsuite. I have clones
> Apache-Test and configures the project with the given path and then
> built the httpd server, but when I execute "make cheek", all tests for
> "all.t" are skipped. The logs show that the test scripts runs the
> server with some isolated configurations on a specific port but it
> apparently cannot find "mod_perl.c" for instance. This is the last
> part of the log that I get when I run the test:
> 
> waiting 60 seconds for server to start: .
> waiting 60 seconds for server to start: ok (waited 0 secs)
> server localhost:8529 started
> [   info] adding source lib
> /home/danesh/open/github/Apache-Test/../Apache-Test/lib to @INC
> t/alltest/all.t . skipped: testing all.t
> t/alltest2/all.t  skipped: testing more than one all.t
> t/bad_coding.t .. ok
> t/cookies.t . skipped: cannot find module 'CGI',
> cannot find module 'CGI::Cookie'
> t/import.t .. ok
> t/log_watch.t ... ok
> t/log_watch_for_broken_lines.t .. ok
> t/more/all.t  skipped: cannot find module 'mod_perl.c'
> t/next_available_port.t . ok
> t/ping.t  ok
> t/redirect.t  ok
> t/request.t . ok
> t/sok.t . ok
> All tests successful.
> Files=13, Tests=91,  4 wallclock secs ( 0.05 usr  0.01 sys +  2.17
> cusr  0.56 csys =  2.79 CPU)
> Result: PASS
> [warning] server localhost:8529 shutdown
> 
> There are also some unit tests under "test" directory that they are
> all passed when I run the executable. I would like to know what is the
> difference between these two tests? Also I expected the tests that are
> triggered with "make check" to be much more extensive than some small
> tests that are run quickly. Something like night-run tests! Am I
> missing something?
> 
> Regards,
> 
> Danesh Daroui



2.4.35 in Sept?

2018-08-29 Thread Jim Jagielski
Looking to maybe do an interim release in Sept...

Comments? Feedback?


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

2018-08-29 Thread Jim Jagielski
We have before and, I think, we have provided no guarantee on how the status 
page "looks"... it is for that reason we provide the XML format alternative.

> On Aug 28, 2018, at 11:41 PM, rj...@apache.org wrote:
> 
> Author: rjung
> Date: Wed Aug 29 03:41:51 2018
> New Revision: 1839535
> 
> URL: http://svn.apache.org/viewvc?rev=1839535=rev
> Log:
> Add the remaining parts of my proxy-statusa and
> server-status proposals back to the list.
> 
> I have only applied the uncontroversial "auto"
> mode part of the accepted patches.
> 
> The "html" part is now back in STATUS (with
> adjusted smaller patches) to give some more
> time for feedback whether the HTML output
> format is allowed to change during a patch
> release.
> 
> 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=1839535=1839534=1839535=diff
> ==
> --- httpd/httpd/branches/2.4.x/STATUS (original)
> +++ httpd/httpd/branches/2.4.x/STATUS Wed Aug 29 03:41:51 2018
> @@ -209,7 +209,26 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK:
>   trunk patch: http://svn.apache.org/r1837056
>   2.4.x patch: https://home.apache.org/~jim/patches/response-204-304.patch
>   +1: jim, ylavic
> -   
> +
> +   *) mod_proxy: Improve the balancer member data shown
> +  in mod_status when "ProxyStatus" is "On":
> +  add "busy" count to html mode. The auto mode part
> +  has already been backported.
> +  This changes the HTML output format for the proxy-status
> +  but adds the very important busy metric.
> +  trunk: http://svn.apache.org/r1837588 (remaining parts)
> +  2.4.x patch: 
> https://home.apache.org/~rjung/patches/httpd-2.4.x-proxy-status-html-busy-r1837588-part2.patch
> +  +1: rjung, jim, ylavic
> +
> +   *) mod_status: Add cumulated response duration time
> +  in milliseconds to html mode. The auto mode part
> +  has already been backported.
> +  This changes the HTML output format for the server-status
> +  but adds the very useful request duration metric.
> +  trunk: http://svn.apache.org/r1837590 (remaining parts)
> +  2.4.x patch: 
> https://home.apache.org/~rjung/patches/httpd-2.4.x-server-status-html-duration-r1837590-part2.patch
> +  +1: rjung, jim, ylavic
> +
> PATCHES/ISSUES THAT ARE BEING WORKED
>   [ New entries should be added at the START of the list ]
> 
> 
> 



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

2018-08-28 Thread Jim Jagielski
+1

> On Aug 28, 2018, at 10:30 AM, Eric Covener  wrote:
> 
> On Tue, Aug 28, 2018 at 9:54 AM Yann Ylavic  wrote:
>> 
>> On Tue, Aug 7, 2018 at 4:19 PM  wrote:
>>> 
>>> Author: rjung
>>> Date: Tue Aug  7 14:19:31 2018
>>> New Revision: 1837599
>>> 
>>> URL: http://svn.apache.org/viewvc?rev=1837599=rev
>>> Log:
>>> Propose a few monitoring improvements.
>>> 
>>> 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=1837599=1837598=1837599=diff
>>> ==
>>> --- httpd/httpd/branches/2.4.x/STATUS (original)
>>> +++ httpd/httpd/branches/2.4.x/STATUS Tue Aug  7 14:19:31 2018
>>> @@ -200,6 +200,41 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK:
>>>   2.4.x patch: http://home.apache.org/~jim/patches/socache_redis.patch
>>>   +1: jim,
>>> 
>>> +   *) mod_proxy: Improve the balancer member data shown
>>> +  in mod_status when "ProxyStatus" is "On":
>>> +  add "busy" count and show byte counts in auto
>>> +  mode always in units of kilobytes.
>>> +  trunk: http://svn.apache.org/r1837588
>>> +  2.4.x patch: svn merge -c 1837588 ^/httpd/httpd/trunk .
>>> +   (adjust CHANGES)
>>> +  +1: rjung
>>> +
>>> +   *) mod_status: Complete the data shown for async
>>> +  MPMs in "auto" mode.  Added number of processes,
>>> +  number of stopping processes and number
>>> +  of busy and idle workers.
>>> +  trunk: http://svn.apache.org/r1837589
>>> +  2.4.x patch: svn merge -c 1837589 ^/httpd/httpd/trunk .
>>> +   (adjust CHANGES)
>>> +  +1: rjung
>>> +
>>> +   *) mod_status: Add cumulated response duration time
>>> +  in milliseconds.
>>> +  trunk: http://svn.apache.org/r1837590
>>> +  2.4.x patch: svn merge -c 1837590 ^/httpd/httpd/trunk .
>>> +   (adjust CHANGES and include/ap_mmn.h)
>>> +  +1: rjung
>>> +
>>> +   *) mod_status: Cumulate CPU time of exited child
>>> +  processes in the "cu" and "cs" values.
>>> +  Add CPU time of the parent process to the
>>> +  "c" and "s" values.
>>> +  trunk: http://svn.apache.org/r1837595
>>> +  2.4.x patch: svn merge -c 1837595 ^/httpd/httpd/trunk .
>>> +   (adjust CHANGES and include/ap_mmn.h)
>>> +  +1: rjung
>> 
>> Those changes look fine (and great) to me, I wanted to +1 but I'm
>> wondering if they really belong in 2.4.x since the output of
>> mod_status is changed in a way that could break existing parsers.
>> I don't know the "policy" here...
> 
> I think new keys in ?auto mode are OK.



Re: [Bug 62318] healthcheck

2018-08-24 Thread Jim Jagielski


> On Aug 24, 2018, at 1:18 PM, Eric Covener  wrote:
> 
> 
> I don't think it's hc execution time relatve to interval, it's hc
> execution time relative to AP_WD_TM_SLICE.  If it's much more than
> AP_WD_TM_SLICE they'll stack up while one is running.
> For a 1 second response you could queue up 10 in a second even if you
> only have an interval of as minute or hour.


Hmm... let me do some testing here... if that's the case, then it's borked
for sure.

Re: [Bug 62318] healthcheck

2018-08-24 Thread Jim Jagielski



> On Aug 24, 2018, at 12:53 PM, Christophe JAILLET 
>  wrote:
> 
> I've only found it in mod_proxy_balancer and, IIUC, the meaning is "slightly" 
> different from its use in hcheck! :)
> Looks like this 'updated' field was dedicated for recording the time a worker 
> has been added.
> 
> So, my understanding is that, either:
>- hcheck already changed the meaning of this field, and broke the API when 
> it has been introduced.
> or
>   - the API only says that 'updated' is "timestamp of last update", without 
> telling which kind of update! So why couldn't be used by hcheck to keep 
> record of the "timestamp of last update"... of its check?

It's the latter... recall that health check workers are totally different and 
separate from real workers.

> 
> I still think that moving when s->updated is updated (sic!) in hcheck should 
> be OK, and wouldn't be an API breakage for me.
> I don't thing that it can interfere in any way with mod_proxy_balancer, at 
> least with the actual code.
> And we should clarify what is the use of thee fields to avoid someelse to 
> 'steal' them.

Let's stop w/ the idea that the API is broken or stolen :)

But yeah, doing the update = now when started/queued makes sense,
assuming that we understand the issue.

Re: [Bug 62318] healthcheck

2018-08-24 Thread Jim Jagielski


> On Aug 24, 2018, at 12:05 PM, Eric Covener  wrote:
> 
> On Fri, Aug 24, 2018 at 11:57 AM Christophe JAILLET
> mailto:christophe.jail...@wanadoo.fr>> wrote:
>> 
>> Le 24/08/2018 à 16:40, Jim Jagielski a écrit :
>>> I was wondering if someone wanted to provide a sanity check
>>> on the above PR and what's "expected" by the health check code.
>>> 
>>> It would be very easy to adjust so that hcinterval was not
>>> the time between successive checks but the interval between
>>> the end of one and the start of another, but I'm not sure that
>>> is as useful. In other words, I think the current behavior
>>> is right (but think the docs need to be updated), but am
>>> willing to have my mind changed :)
>>> 
>> Hi Jim,
>> 
>> the current behavior is also what I would expect.
>> If I configure a check every 10s, I would expect 6 checks each minute,
>> even if the test itself takes time to perform.
> 
> 
> Bug describes something else IIUC.  Because the watchdog calls us 10
> times per second, it continuously sees that the worker hasn't been
> health checked within the desired interval and queues up a check, it
> doesn't know one is queued.

But that is only an issue, afaict, if the time taken to do the health check is
greater than the interval chosen... Or am I misunderstanding? That is,
if the interval is 200ms, and the health check takes 100ms, all is fine, we
get 5 checks a second. 

I guess what we could do is emit a warning if when a check is queued, we
already have one queued, or in process. This would some info to the sysadmin.
We could also track the time taken to perform a check and have that available
via mod_status as well. But these all assume that the underlying logic, and
how it's implemented, is sane.

Re: [Bug 62318] healthcheck

2018-08-24 Thread Jim Jagielski
Yes, but the updated field is used differently for the health check workers and
the "real" workers.

> On Aug 24, 2018, at 12:21 PM, Eric Covener  wrote:
> 
> On Fri, Aug 24, 2018 at 12:13 PM Christophe JAILLET
> mailto:christophe.jail...@wanadoo.fr>> wrote:
>> 
>> Le 24/08/2018 à 17:56, Christophe JAILLET a écrit :
>>> Le 24/08/2018 à 16:40, Jim Jagielski a écrit :
>>>> I was wondering if someone wanted to provide a sanity check
>>>> on the above PR and what's "expected" by the health check code.
>>>> 
>>>> It would be very easy to adjust so that hcinterval was not
>>>> the time between successive checks but the interval between
>>>> the end of one and the start of another, but I'm not sure that
>>>> is as useful. In other words, I think the current behavior
>>>> is right (but think the docs need to be updated), but am
>>>> willing to have my mind changed :)
>>>> 
>>> Hi Jim,
>>> 
>>> the current behavior is also what I would expect.
>>> If I configure a check every 10s, I would expect 6 checks each minute,
>>> even if the test itself takes time to perform.
>>> 
>>> 
>>> 
>>> Not related, but is there any use for 'hc_pre_config()'?
>>> We already have:
>>>   static int tpsize = HC_THREADPOOL_SIZE;
>>> 
>>> Having both looks redundant.
>>> 
>>> CJ
>>> 
>>> 
>> but shouldn't we
>>worker->s->update = now;
>> when the check is started (in hc_watchdog_callback()) instead of when it
>> is funished (at the end of hc_check())?
> 
> Looks like s->updated is not used elsewhere in HC but is used
> elsewhere in proxy modules and is in the API.
> I don't know if that calls for a 2nd timestamp or a just a bit for
> when checks are in progress.  Could be useful in
> the future to keep track of the addl information.



  1   2   3   4   5   6   7   8   9   10   >