2.4.38

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

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

Re: Load balancing and load determination

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 an

Re: __attribute__

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

__attribute__

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

> 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

Re: Load balancing and load determination

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.

Load balancing and load determination

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

Re: SetHandler balancer-manager question.

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,

Re: Test framework regressions - spelling and usertrack

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

Re: Test framework regressions - spelling and usertrack

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

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

Test framework regressions - spelling and usertrack

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

Re: [VOTE] Release httpd-2.4.37

+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/ >

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

> 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

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

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

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

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

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

-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

Re: [VOTE] Release httpd-2.4.36

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

Re: [VOTE] Release httpd-2.4.36

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 chan

Re: [VOTE] Release httpd-2.4.36

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

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

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

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

v/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:

Re: [VOTE] Release httpd-2.4.36

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

Re: [VOTE] Release httpd-2.4.36

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

Re: NOTICE: Intent to T 2.4.36

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

Re: NOTICE: Intent to T 2.4.36

Gotcha. Thx.

Re: NOTICE: Intent to T 2.4.36

I suggest you add 'autoreconf -i' as a prelim step.

Re: NOTICE: Intent to T 2.4.36

% 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*

Re: [VOTE] Release httpd-2.4.36

+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

Re: NOTICE: Intent to T 2.4.36

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

Re: NOTICE: Intent to T 2.4.36

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 quic

Re: NOTICE: Intent to T 2.4.36

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

Re: NOTICE: Intent to T 2.4.36

> 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

Re: NOTICE: Intent to T 2.4.36

> 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, the

Apache httpd 2.4.35 announcement on Twitter

I didn't see any announcement about the 2.4.35 release on twitter... did I just miss it?

Using APR pools "better"

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

Re: Announce missing - in moderation?

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

Re: Announce missing - in moderation?

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

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

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

Re: trunk proxy_http failures

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.

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

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

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/

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

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

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

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 fro

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

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

Re: 2.4.35 in Sept?

> 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

Re: 2.4.35 in Sept?

> 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

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

> 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

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

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

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

> 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

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

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

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

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 20

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

> 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

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

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

Re: 2.4.35 in Sept?

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?

+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

Re: Run httpd's testsuite

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 >

Re: Run httpd's testsuite

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

2.4.35 in Sept?

Looking to maybe do an interim release in Sept... Comments? Feedback?

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

d/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 > -

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

/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) >>&

Re: [Bug 62318] healthcheck

> 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

Re: [Bug 62318] healthcheck

> 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

Re: [Bug 62318] healthcheck

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

Re: [Bug 62318] healthcheck

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

Re: [Bug 62318] healthcheck

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

Re: svn commit: r818825 - in /httpd/httpd/trunk: include/ modules/examples/ modules/experimental/ modules/session/ server/ server/mpm/event/ server/mpm/prefork/ server/mpm/worker/

> > I was tempted to start using it for a private struct instead of adding > more vhost.c-only garbage to the server_rec itself. > Was that the idea? > Yes... from what I can recall, it was intended to be a space that modules could w/o mucking around with extending the server_rec

Re: Event is broken in trunk (Was: Re: t/apache/getfile.t)

even more so w/ r1837823 :) thx > On Aug 10, 2018, at 12:19 PM, Yann Ylavic wrote: > > On Fri, Aug 10, 2018 at 3:40 PM, Jim Jagielski wrote: >> Looks like some looping (full error log at: >> http://home.apache.org/~jim/test/error_log) > > Better with r1837822?

Re: svn commit: r1837823 - /httpd/httpd/trunk/server/request.c

+1... > On Aug 10, 2018, at 12:24 PM, yla...@apache.org wrote: > > Author: ylavic > Date: Fri Aug 10 16:24:15 2018 > New Revision: 1837823 > > URL: http://svn.apache.org/viewvc?rev=1837823=rev > Log: > ap_request_core_filter() can check whether the next filter should yield. > > Itself won't

Re: Event is broken in trunk (Was: Re: t/apache/getfile.t)

Looks like some looping (full error log at: http://home.apache.org/~jim/test/error_log) [Fri Aug 10 13:36:09.607977 2018] [core:trace8] [pid 43559:tid 123145562525696] util_filter.c(935): [client 127.0.0.1:63911] brigade contains: bytes: 0, non-file bytes: 0, eor buckets: 1, morphing buckets

Re: Event is broken in trunk (Was: Re: t/apache/getfile.t)

I've just been able to test on macOS lately. Will work on getting you the requested error info. Thx > On Aug 10, 2018, at 9:15 AM, Yann Ylavic wrote: > > On Thu, Aug 9, 2018 at 10:10 PM, Jim Jagielski wrote: >> I had to go all the way back to r1835846 to get trunk stable again

Re: Event is broken in trunk (Was: Re: t/apache/getfile.t)

Yeppers... looks like: core: axe data_in_in/output_filter from conn_rec. was done prematurely and/or not completely. Yann, can you fix this? I'm having a hard time groking your thought process in the restructuring here. > On Aug 9, 2018, at 4:10 PM, Jim Jagielski wrote: > > I

Re: Event is broken in trunk (Was: Re: t/apache/getfile.t)

I had to go all the way back to r1835846 to get trunk stable again... r1836239 is the start of the breakage... :< > On Aug 9, 2018, at 3:59 PM, Jim Jagielski wrote: > > I've confirmed that this does NOT happen w/ worker or prefork, so it's > definitely something broken with t

Event is broken in trunk (Was: Re: t/apache/getfile.t)

I've confirmed that this does NOT happen w/ worker or prefork, so it's definitely something broken with the recent churn on the Event MPM. No doubt, stuff done over the last 2-3 weeks have broken Event.

Re: t/apache/getfile.t

USE_PERLIO USE_PERL_ATOF Built under darwin Compiled at Jul 6 2017 13:25:29 %ENV: PERL5LIB="/Users/jim/perl5/lib/perl5" PERL_LOCAL_LIB_ROOT="/Users/jim/perl5" PERL_MB_OPT="--install_base "/Users/jim/perl5"" PERL_MM_OPT="INSTALL_BASE=/User

t/apache/getfile.t

Anyone having issues w/ the above test hanging after test 182? On the 2.4.x branch it runs thru to completion, but on trunk (macOS), stalls after 182: ... #lwp request: #GET http://localhost:8529/getfiles-perl-pod/perlxstypemap.pod HTTP/1.1 #User-Agent: libwww-perl/6.26 #

Re: Specific regressions to promptly address for 2.4.35?

> On Aug 9, 2018, at 12:11 AM, William A Rowe Jr wrote: > > > You didn't seriously expect me to rise to that bait? No, I wasn't planning to > bring you a rock It's not a rock... if you expect people to review patches, certainly those patches should be available someplace, right? I'm not

Re: [PATCH] [BZ 62567] Re: automation and test cases

I've never used the cmake style for building (but I know that CLion, which is cmake-based, barfs on trunk and thus is useless as an IDE for httpd), but I'll give it a whirl. Thx for the reminder > On Aug 7, 2018, at 5:40 AM, Michal Karm wrote: > > On 08/07/2018 11:08 AM, Stefan Eissing wrote:

Re: Specific regressions to promptly address for 2.4.35?

> On Aug 7, 2018, at 11:21 AM, William A Rowe Jr wrote: > > > Specific regressions as requested by Jim, posted on users@ and dev@ > which are showstoppers to upgrading for some; > > - Non-HTTP responses from mod_ratelimit with delayed content (cgi, proxy) > * Breaki

Re: Wherefor 2.4.36?

> On Aug 6, 2018, at 1:37 PM, William A Rowe Jr wrote: > > Is anyone else disappointed in the number of regressions in 2.4.35? > Could you point them out?

Re: svn commit: r1837225 - in /httpd/httpd/trunk: CHANGES include/scoreboard.h modules/echo/mod_echo.c modules/experimental/mod_noloris.c modules/generators/mod_status.c modules/lua/lua_request.c serv

> On Aug 2, 2018, at 1:28 AM, Christophe JAILLET > wrote: > > Le 01/08/2018 à 13:27, j...@apache.org <mailto:j...@apache.org> a écrit : >> Author: jim >> Date: Wed Aug 1 11:27:28 2018 >> New Revision: 1837225 >> >> URL: http://svn.apache.o

Re: svn commit: r1836150 - /httpd/site/trunk/content/security/vulnerabilities-httpd.xml

It looks like these were missed in CHANGES. I will update and push. > On Jul 18, 2018, at 3:54 AM, m...@apache.org wrote: > > Author: mjc > Date: Wed Jul 18 07:54:13 2018 > New Revision: 1836150 > > URL: http://svn.apache.org/viewvc?rev=1836150=rev > Log: > add 2.3.34 vulns that were fixed > >

[ANNOUNCEMENT] Apache HTTP Server 2.4.34 Released

Apache HTTP Server 2.4.34 Released July 16, 2018 The Apache Software Foundation and the Apache HTTP Server Project are pleased to announce the release of version 2.4.34 of the Apache HTTP Server ("Apache"). This version of Apache is our latest GA release of the new generation 2.4.x

Re: [CLOSED] [VOTE] Release Apache httpd 2.4.34 as GA

I'm looking to ANNOUNCE and RELEASE today, around noonish EDT...

[CLOSED] Re: [VOTE] Release Apache httpd 2.4.34 as GA

The polls are closed and with more than the required 3 +1 (binding) votes and no -1s, the VOTE passes! Thx to all! > On Jul 10, 2018, at 10:03 AM, Jim Jagielski wrote: > > The pre-release test tarballs for Apache httpd > version 2.4.34 can be found at the usual place: >

Re: [VOTE] Release Apache httpd 2.4.34 as GA

Just a quick FYI that the vote closes in ~2hr from "now"... so get those tests done and cast your vote! TIA! > On Jul 10, 2018, at 10:03 AM, Jim Jagielski wrote: > > The pre-release test tarballs for Apache httpd > version 2.4.34 can be found at the usual

Re: [VOTE] Release Apache httpd 2.4.34 as GA

Also Ubuntu 16.04 LTS (64bit) (as well as 15.10, which is EOL) > On Jul 10, 2018, at 11:12 AM, Jim Jagielski wrote: > > +1 for: > > o CentOS5, 64bit > o CentOS6, 64bit > o CentOS7, 64bit > o macOS 10.13.5, Xcode9 > >> On Jul 10, 2018, at 10:03 AM, Jim

Re: [VOTE] Release Apache httpd 2.4.34 as GA

+1 for: o CentOS5, 64bit o CentOS6, 64bit o CentOS7, 64bit o macOS 10.13.5, Xcode9 > On Jul 10, 2018, at 10:03 AM, Jim Jagielski wrote: > > The pre-release test tarballs for Apache httpd > version 2.4.34 can be found at the usual place: > > http://httpd.a

Re: Time for 2.4.34?

ic >> Gesendet: Donnerstag, 5. Juli 2018 21:34 >> An: httpd-dev >> Betreff: Re: Time for 2.4.34? >> >> On Thu, Jul 5, 2018 at 9:11 PM, Yann Ylavic >> wrote: >>> On Thu, Jul 5, 2018 at 5:43 PM, Jim Jagielski wrote: >>>> Seems to me that

Time for 2.4.34?

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

Re: svn commit: r1834671 - in /httpd/httpd/branches/2.4.x: CHANGES docs/manual/mod/mod_md.xml modules/md/md_crypt.c modules/md/md_json.c modules/md/md_version.h modules/md/mod_md.c modules/md/mod_md_c

> On Jul 2, 2018, at 1:40 PM, Christophe Jaillet > wrote: > > Le 02/07/2018 à 17:36, William A Rowe Jr a écrit : >> On Mon, Jul 2, 2018 at 8:25 AM, Stefan Eissing > > wrote: >>I thought experimental == CTR, but if this is separate then I‘ll go >>

Re: mod_cache: Broken Expires from back end and CacheStoreExpired

I can't fault the logic... +1 for the patch. > On Jun 19, 2018, at 6:47 AM, Rainer Jung wrote: > > I have a situation where I have a caching Apache in front of a back end. The > backend sends a response header "Expires: -1" and mod_cache unconditionally > refuses to cache the response with

mod_socache_redis

I just realized that we never backported this to 2.4.x... looking over the list, I can't see any real reason why? Anyone upset if I propose it for backport?

Re: 2.4.34 release

I've held off on a T due to the showstoppers in STATUS... We shouldn't release until they are closed. > On May 29, 2018, at 12:13 PM, Daniel Ruggeri wrote: > > I'm game for doing a T today and running the vote through Sunday (since I'm > out of town starting tomorrow) if we're ready. > >

Re: slotmem + balancer

> On May 20, 2018, at 4:59 PM, Yann Ylavic wrote: > > > Now we are back to 2.4.29 code, r1822341 is in again, and I committed > additional changes (minimal hopefully) to address the issues reported > in PR 62308 (and PR 62044 still). My own testing, based on the tests >

Re: slotmem + balancer

> On May 12, 2018, at 10:23 AM, Mark Blackman wrote: > > I think you will find it difficult to re-work effectively unless you can > identify representative test cases possibly including a segfault. > > For me the most important characteristics of the fix were (a) to more

Re: svn commit: r1831396 - /httpd/httpd/trunk/modules/proxy/mod_proxy_balancer.c

> On May 11, 2018, at 5:44 AM, yla...@apache.org wrote: > > +rv = storage->attach(>bslot, conf->id, , , p); > if (!conf->bslot) { > -ap_log_error(APLOG_MARK, APLOG_EMERG, 0, s, APLOGNO(01205) > "slotmem_attach failed"); > +

Re: slotmem + balancer

I am under the impression is that we should likely restore mod_slotmem_shm back to its "orig" condition, either: o http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/slotmem/mod_slotmem_shm.c?view=markup=1822341 o

Re: svn commit: r1830800 - in /httpd/httpd/trunk: CHANGES modules/slotmem/mod_slotmem_shm.c

I seem to be having issues with this patch via this scenario: o Using the balancer-manager, make changes. o Do a grace restart some times. o Make more changes. o Now shutdown. o Now restart. The changes are erased... It looks like maybe something to do with the generation number... ??

<    1   2   3   4   5   6   7   8   9   10   >