Re: [proposed] 2.4 Maintenance SIG

> On Jan 18, 2017, at 8:35 PM, Eric Covener wrote: > > On Wed, Jan 18, 2017 at 6:12 PM, William A Rowe Jr > wrote: >> I'm wondering if there is anyone interested in a regression-fix-only 2.4.26 >> that >> finally proves to be a workable upgrade for all

Re: Summary: Broken FastCGI with httpd

PM and httpd on what it wants/expects/needs regarding these env-vars. Yeah, SCRIPT_FILENAME seems core to this, I think. > On Jan 18, 2017, at 2:01 PM, Jacob Champion <champio...@gmail.com> wrote: > > On 01/18/2017 06:43 AM, Jim Jagielski wrote: >> Also, the fact that different method

Re: Summary: Broken FastCGI with httpd

Just some additional info (the perl script described might be useful, esp if we fold it into the test framework): https://bugs.php.net/bug.php?id=54152 > On Jan 18, 2017, at 9:47 AM, David Zuelke wrote: > >> On 17.01.2017, at 23:16, Jacob Champion

Re: Summary: Broken FastCGI with httpd

It seems to me that SCRIPT_FILENAME is the key w/ PHP-FPM, but I could be wrong. Also, the fact that different methods of invoking FCGI result in different vars, at 1st blush, doesn't seem "incorrect" assuming that each difference makes some sense, in a way. Finally, I think that instead of

Re: Async write completion broken in trunk?

> On Jan 18, 2017, at 8:25 AM, Luca Toscano <toscano.l...@gmail.com> wrote: > > > > 2017-01-18 14:00 GMT+01:00 Jim Jagielski <j...@jagunet.com>: > > > On Jan 18, 2017, at 7:50 AM, Graham Leggett <minf...@sharp.fm> wrote: > > > > On 17 Jan

Re: Async write completion broken in trunk?

> On Jan 18, 2017, at 8:14 AM, Graham Leggett <minf...@sharp.fm> wrote: > > On 18 Jan 2017, at 3:05 PM, Jim Jagielski <j...@jagunet.com> wrote: > >> Well, there's this, and it seems like there are issues w/ >> the current mutexing as well, causing weird

Re: Async write completion broken in trunk?

> On Jan 18, 2017, at 8:01 AM, Graham Leggett <minf...@sharp.fm> wrote: > > On 18 Jan 2017, at 3:00 PM, Jim Jagielski <j...@jagunet.com> wrote: > >> Somewhat on-topic but also off-topic as well, but it does seem >> that event on trunk is getting much mo

Re: Async write completion broken in trunk?

> On Jan 18, 2017, at 7:50 AM, Graham Leggett wrote: > > On 17 Jan 2017, at 7:40 PM, Luca Toscano wrote: > >> Since this email thread seems important, is there any update from anybody >> working on it? It would be great to open a bugzilla task

Re: JSON for mod_status

This is too awesome for words :) > On Jan 18, 2017, at 4:56 AM, Daniel Gruno <humbed...@apache.org> wrote: > > On 01/17/2017 07:33 PM, Jim Jagielski wrote: >> It all depends on what Bill decides regarding mod_bmx and if >> it is something we intent to backport to

Re: JSON for mod_status

, so I would require some sort of docs in addition to the actual code, of course. > On Jan 17, 2017, at 12:35 PM, Luca Toscano <toscano.l...@gmail.com> wrote: > > > > 2016-11-30 18:54 GMT+01:00 Jim Jagielski <j...@jagunet.com>: > I'm thinking about adding JSON sup

Re: mod_fcgi: Excessive memory usage when large files are uploaded

> On Jan 17, 2017, at 6:03 AM, Yann Ylavic wrote: > > On Tue, Jan 17, 2017 at 9:06 AM, Ivan Zahariev wrote: >> >> 1. Delete each bucket after sending it to the "ipc_handle". I've looked >> through >> the call tree and the *output_brigade is last used

Re: clang-analyzer?

> On Jan 9, 2017, at 4:48 AM, Graham Leggett wrote: > > On 08 Jan 2017, at 4:45 AM, Leif Hedstrom wrote: > >> I ran clang-analyzer against the HTTPD master branch, and it found 126 >> issues. Many of these are benign, but I was curious if the community has

Re: svn commit: r1776575 - in /httpd/httpd/trunk: docs/log-message-tags/next-number docs/manual/mod/mod_remoteip.xml modules/metadata/mod_remoteip.c

> On Jan 16, 2017, at 6:57 PM, Daniel Ruggeri wrote: > > For the most part, yes except the portions that make the header presence > optional (the HDR_MISSING case). Those were added as it came into the > code base to handle a use case I was working on. I've added some >

Re: FYI brotli

Besides, we had no problems supporting OpenSSL 0.9.6 for years :) If/when brotli 1.0.0 is released, we simply add support for that as well. No biggie. > On Jan 17, 2017, at 8:27 AM, Jim Jagielski <j...@jagunet.com> wrote: > > Actually, it works fine w/ Brotli 0.5.2 which i

Re: FYI brotli

Actually, it works fine w/ Brotli 0.5.2 which is what I have installed. > On Jan 16, 2017, at 3:28 PM, Evgeny Kotkov <evgeny.kot...@visualsvn.com> > wrote: > > Jim Jagielski <j...@jagunet.com> writes: > >> Functional patch avail... working on doccos. >

Re: FYI brotli

Functional patch avail... working on doccos. http://home.apache.org/~jim/patches/brotli-2.4.patch > On Jan 16, 2017, at 11:11 AM, Jim Jagielski <j...@jagunet.com> wrote: > > Just a head's up that I am working on the backport proposal/patch > for brotli for 2.4.x...

Re: svn commit: r1776575 - in /httpd/httpd/trunk: docs/log-message-tags/next-number docs/manual/mod/mod_remoteip.xml modules/metadata/mod_remoteip.c

Let me take a look... afaict, this is a copy of what was donated, which has been working for numerous people. But that doesn't mean it can't have bugs ;) > On Jan 16, 2017, at 7:20 AM, Ruediger Pluem wrote: > > Anyone? > > Regards > > Rüdiger > > On 01/10/2017 12:39 PM,

FYI brotli

Just a head's up that I am working on the backport proposal/patch for brotli for 2.4.x...

Re: Welcome Lucien Gentis and Luca Tascano to the HTTP Server PMC

Welcome to de mad-house! > On Jan 12, 2017, at 8:23 PM, Eric Covener wrote: > > HTTP Server committers Lucien Gentis and Luca Tascano were recently > elected to the HTTP Server Project Management Committee (PMC). > > A project management committee (PMC) is a committee of the

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

> On Jan 11, 2017, at 12:28 PM, Yann Ylavic <ylavic@gmail.com> wrote: > > On Wed, Jan 11, 2017 at 6:17 PM, Jim Jagielski <j...@jagunet.com> wrote: >> >>> On Jan 11, 2017, at 12:12 PM, Joe Orton <jor...@redhat.com> wrote: >>> >>&g

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

> On Jan 11, 2017, at 12:12 PM, Joe Orton <jor...@redhat.com> wrote: > > On Wed, Jan 11, 2017 at 11:08:29AM -0500, Jim Jagielski wrote: >> This is to address the following bug: >> >> https://bugzilla.redhat.com/show_bug.cgi?id=1410883 > > Thanks a lot J

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

imply that you can't reconfig watchdog on restarts which doesn't seem quite right... thoughts? > On Jan 11, 2017, at 11:00 AM, j...@apache.org wrote: > > Author: jim > Date: Wed Jan 11 16:00:37 2017 > New Revision: 1778319 > > URL: http://svn.apache.org/viewvc?rev=177

RemoteIPProxyProtocol

Once we backport to 2.4, it will be nigh-impossible to change the name... As we *sure* we want to call it RemoteIPProxyProtocol instead of just "regular" ProxyProtocol ? The latter just sounds and looks "more right" to me.

Re: proxy_fcgi directives or envvars?

It would be nice to avoid the overhead of getting the ENV. > On Jan 8, 2017, at 11:31 AM, Eric Covener wrote: > > We have an issue in proxy_fcgi in 2.4.21 and later that makes me think > we need to tell proxy_fcgi when it's talking to php-fpm vs. a generic > fastcgi

Re: [proposed] 2.4 Maintenance SIG

> On Jan 4, 2017, at 3:13 AM, Graham Leggett wrote: > > On 03 Jan 2017, at 10:47 PM, Jacob Champion wrote: > >> I don't feel that trunk is a dead branch, but I do think there is dead code >> in trunk. > > Can you give us an example of this dead code?

Re: The Version Bump fallacy [Was Re: Post 2.4.25]

> On Jan 3, 2017, at 8:04 PM, Noel Butler <noel.but...@ausics.net> wrote: > > On 03/01/2017 23:11, Jim Jagielski wrote: > >> Back in the "old days" we used to provide complimentary builds >> for some OSs... I'm not saying we go back and do that necessa

Re: [proposed] 2.4 Maintenance SIG

Bill, your Email client is messed-up again, as related to how it handles copy/pasted text in replies. > On Jan 3, 2017, at 9:07 AM, William A Rowe Jr wrote: > > On Jan 3, 2017 02:19, "Graham Leggett" wrote: > > > Can you clarify the problem you’re trying

Re: The Version Bump fallacy [Was Re: Post 2.4.25]

Back in the "old days" we used to provide complimentary builds for some OSs... I'm not saying we go back and do that necessarily, but maybe also providing easily consumable other formats when we do a release, as a "service" to the community might make a lot of sense.

Re: [proposed] 2.4 Maintenance SIG

> On Jan 2, 2017, at 7:11 PM, William A Rowe Jr wrote: > > So far, discussions are polarized on a single axis... > > East: Let's work on 3.0; whatever is going on in 2.4 won't distract me, I > won't spend time reviewing enhancements, because 3.0 is the goal. > > West:

Re: svn commit: r1776575 - in /httpd/httpd/trunk: docs/log-message-tags/next-number docs/manual/mod/mod_remoteip.xml modules/metadata/mod_remoteip.c

;) On Dec 30, 2016, at 9:41 AM, Daniel Ruggeri <drugg...@primary.net> wrote: > > > On 12/30/2016 8:28 AM, Jim Jagielski wrote: >> Kewl beans! > Indeed - the best beans to have! > >> Any issue if we rename the directive to just ProxyProtocolEnable? >>

Re: svn commit: r1776575 - in /httpd/httpd/trunk: docs/log-message-tags/next-number docs/manual/mod/mod_remoteip.xml modules/metadata/mod_remoteip.c

Kewl beans! Any issue if we rename the directive to just ProxyProtocolEnable? The "RemoteIP" prefix just seems weird :) Also, just as a head's up, I'm looking on adding PROXY support to the proxy module itself (that is, we *send* the PROXY line to backends) as a configurable option. So when that

Re: [users@httpd] Copyright notices in httpd source files

I didn't know you guys were working on it. Cool. I had been working the donation angle for awhile and finally got approval so wanted to get it in quick! :) > On Dec 29, 2016, at 3:56 AM, Nick Kew wrote: > > Cc: dev list. Looks like a catch? > > On Wed, 2016-12-28 at 17:44

Re: The Version Bump fallacy [Was Re: Post 2.4.25]

> On Dec 28, 2016, at 7:40 PM, Yehuda Katz wrote: > > On Wed, Dec 28, 2016 at 12:35 AM, William A Rowe Jr > wrote: > Our adoption is *broadly* based on the OS distributions > from vendors, not from people picking up our sources. > Yes - some integrate

Re: The Version Bump fallacy [Was Re: Post 2.4.25]

It wasn't the paste that was the problem, but the inability of other email clients to determine from your email what parts/sections are quoted from *previous* emails. > On Dec 28, 2016, at 5:49 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > > Hi Jim, > > Talk to Goog

Re: Post 2.4.25

> On Dec 28, 2016, at 6:28 PM, William A Rowe Jr wrote: > > > Because fixing r->uri is such a priority, trust that I'll be voting every 2.6 > candidate a -1 until it exists. I don't know why the original httpd founders > are so hung up on version number conservation,

Re: The Version Bump fallacy [Was Re: Post 2.4.25]

misses quote levels... > On Dec 28, 2016, at 1:34 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > > On Wed, Dec 28, 2016 at 9:13 AM, Jim Jagielski <j...@jagunet.com> wrote: > cPanel too... They are moving to EA4 which is Apache 2.4. > > If not moved yet, th

Re: svn commit: r1776076 - in /httpd/httpd/trunk: docs/manual/mod/mod_proxy_protocol.xml modules/filters/mod_proxy_protocol.c

I would simply add a note to the header of mod_remoteip > On Dec 28, 2016, at 12:23 PM, Daniel Ruggeri <drugg...@primary.net> wrote: > > > On 12/28/2016 7:49 AM, Jim Jagielski wrote: >> Sounds good... We could simply move the filter aspects over to >> mod

Re: The Version Bump fallacy [Was Re: Post 2.4.25]

cPanel too... They are moving to EA4 which is Apache 2.4. So the idea that supplemental (ie: 2.4.x->2.4.y) patches don't have the reach or range of larger ones (2.4.x->2.6/3.0) isn't quite accurate. IMO, people who are comfortable with "whatever the OS provides" aren't the ones we are talking

Re: [users@httpd] Web sockets & proxypass - No protocol handler was valid for the URL

+1 > On Dec 28, 2016, at 9:56 AM, Eric Covener wrote: > > On Wed, Dec 28, 2016 at 9:54 AM, Yann Ylavic wrote: >>> I guess we just got unlucky when this overlap was "fixed" before since >>> the order is not deterministic. I don't think we'll break anyone

Re: svn commit: r1776076 - in /httpd/httpd/trunk: docs/manual/mod/mod_proxy_protocol.xml modules/filters/mod_proxy_protocol.c

> On Dec 26, 2016, at 10:30 PM, Daniel Ruggeri <drugg...@primary.net> wrote: > > > On 12/26/2016 3:42 PM, j...@apache.org wrote: >> Author: jim >> Date: Mon Dec 26 21:42:26 2016 >> New Revision: 1776076 >> >> URL: http://svn.apache.o

Re: Post 2.4.25

> On Dec 24, 2016, at 8:54 AM, Eric Covener wrote: > > On Fri, Dec 23, 2016 at 3:28 PM, William A Rowe Jr > wrote: >> Next step is to actually end enhancements alltogether >> against 2.4 (we've done that some time ago, security >> issues

Re: Post 2.4.25

> On Dec 24, 2016, at 8:29 AM, Rich Bowen <rbo...@rcbowen.com> wrote: > > > > On 12/23/2016 03:52 PM, Jim Jagielski wrote: >> Personally, I don't think that backporting stuff to >> 2.4 prevents or disallows development on 2.6/3.0. In >> fact, I think it h

Re: Post 2.4.25

> On Dec 23, 2016, at 5:50 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > > Just a couple quick thoughts... > > On Dec 23, 2016 2:55 PM, "Jim Jagielski" <j...@jagunet.com> wrote: > > . We need to keep > 2.4 viable and worthwhile > &g

Re: Post 2.4.25

), William A Rowe Jr <wr...@rowe-clan.net> wrote: > Just a couple quick thoughts... > > On Dec 23, 2016 2:55 PM, "Jim Jagielski" <j...@jagunet.com> wrote: > > > As I have also stated, my personal belief is that > 2.4 is finally reaching some traction, and

Re: Post 2.4.25

3:28 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > > On Fri, Dec 23, 2016 at 2:20 PM, Jim Jagielski <j...@jagunet.com> wrote: > For me, it would be moving as much as we can from > trunk to 2.4 > > -1. To echo your frequent use of media to emphasize

Post 2.4.25

Now that we have 2.4.25 done, I'd like us to take the next few weeks thinking about how we'd like to see the next release shape up. For me, it would be moving as much as we can from trunk to 2.4, again, to enable current users to leverage and enjoy the goodness which is currently "stuck" in

Re: [DISCUSS] commit messages on backports

For the record, this is what I use: http://home.apache.org/~jim/code/svn.merge Most likely I will change it to have it accept $1 as the names of people to mark as "Reviewed by" via a simple cut/paste of the line from STATUS. > On Dec 23, 2016, at 8:36 AM, Eric Covener <c

Re: T of 2.4.24

> On Dec 23, 2016, at 2:32 AM, William A Rowe Jr wrote: > > > I hope you sort this out in your ombudsman role, because this is the > test of whether you understand ASF responsibilities, both legally, > and in the sense of our entire ecosystem, and the will of your specific

[RESULT] (Was: Re: [VOTE] Release Apache httpd 2.4.25 as GA)

half of Weds), so if someone wants to take on the announcing part, that would be great. I'll have limited cycles and external net access. > On Dec 16, 2016, at 1:29 PM, Jim Jagielski <j...@jagunet.com> wrote: > > At long, long last, the pre-release test tarballs for Apache httpd >

Re: [VOTE] Release Apache httpd 2.4.25 as GA

As a reminder, when Joe added those tests a few days ago, it was for: URL: http://svn.apache.org/viewvc?rev=1774010=rev Log: Add basic test case for mod_ext_filter & specific test for PR 60375. > On Dec 17, 2016, at 7:35 AM, Rainer Jung wrote: > > Am

Re: [VOTE] Release Apache httpd 2.4.25 as GA

+1: o CentOS5, x64 - event, worker o CentOS6, x64 - event, worker o CentOS7, x64 - event o macOS 10.12, x64 - event, worker No regressions (mod_ext_filter test failures aren't regressions) > On Dec 16, 2016, at 1:29 PM, Jim Jagielski <j...@jagunet.com> wrote: > > At

Re: [VOTE] Release Apache httpd 2.4.25 as GA

Those failures do not reflect a regression. > On Dec 16, 2016, at 3:11 PM, Jacob Champion <champio...@gmail.com> wrote: > > On 12/16/2016 10:29 AM, Jim Jagielski wrote: >> I'm calling a VOTE on releasing these as Apache httpd 2.4.25 GA. > > mod_ext_filter tests a

[VOTE] Release Apache httpd 2.4.25 as GA

At long, long last, the pre-release test tarballs for Apache httpd version 2.4.25 can be found at the usual place: http://httpd.apache.org/dev/dist/ I'm calling a VOTE on releasing these as Apache httpd 2.4.25 GA. [ ] +1: Good to go [ ] +0: meh [ ] -1: Danger Will Robinson. And why.

[REVOKED] Re: [VOTE] Release Apache httpd 2.4.24 as GA

This call is REVOKED! > On Dec 16, 2016, at 7:06 AM, Jim Jagielski <j...@jagunet.com> wrote: > > At long, long last, the pre-release test tarballs for Apache httpd > version 2.4.24 can be found at the usual place: > > http://httpd.apache.org/dev/dist/ > > I

Re: [VOTE] Release Apache httpd 2.4.24 as GA

Hmmm Weird that using the "official" macro test results in the error... Waiting to hear from other Win people. > On Dec 16, 2016, at 9:59 AM, Steffen <i...@apachelounge.com> wrote: > > Reverted that change, building and running now. > > On Friday 16/12/201

Re: [VOTE] Release Apache httpd 2.4.24 as GA

0): fatal error C1083: Cannot open include file: > 'sys/time.h': No such file or directory > > Steffen > > On Friday 16/12/2016 at 13:07, Jim Jagielski wrote: >> At long, long last, the pre-release test tarballs for Apache httpd >> version 2.4.24 can be found at the

[VOTE] Release Apache httpd 2.4.24 as GA

At long, long last, the pre-release test tarballs for Apache httpd version 2.4.24 can be found at the usual place: http://httpd.apache.org/dev/dist/ I'm calling a VOTE on releasing these as Apache httpd 2.4.24 GA. [ ] +1: Good to go [ ] +0: meh [ ] -1: Danger Will Robinson. And why.

Re: T of 2.4.24

I'll give it until tomorrow AM... If we have the 3, it'll be folded in. If not, I'm not going to delay. > On Dec 15, 2016, at 4:34 PM, Jim Jagielski <j...@jagunet.com> wrote: > > Done and done. > >> On Dec 15, 2016, at 4:30 PM, Jim Jagielski <j...@jagunet.

Re: T of 2.4.24

Done and done. > On Dec 15, 2016, at 4:30 PM, Jim Jagielski <j...@jagunet.com> wrote: > > Actually, it is: > >https://svn.apache.org/viewvc?view=revision=1772334 > > So I would like to see the enhancement in: > > >

Re: T of 2.4.24

. > On Dec 15, 2016, at 2:55 PM, Eric Covener <cove...@gmail.com> wrote: > > On Thu, Dec 15, 2016 at 2:09 PM, Eric Covener <cove...@gmail.com> wrote: >> On Thu, Dec 15, 2016 at 10:16 AM, Eric Covener <cove...@gmail.com> wrote: >>> On Thu, Dec 15, 2016 at 10:13

Re: svn commit: r1738464 - /httpd/httpd/trunk/server/mpm/event/event.c

Actually, it is. https://svn.apache.org/viewvc?view=revision=1772334 > On Dec 15, 2016, at 2:47 PM, Yann Ylavic wrote: > > On Thu, Dec 15, 2016 at 8:06 PM, Eric Covener wrote: >> I have been looking at this area a little bit from the perspective of

Re: T of 2.4.24

From what I can see, there are no show-stoppers and all my tests show no regressions... Let's shoot for a T this (east coast) evening... how does that sound? > On Dec 14, 2016, at 7:56 AM, Jim Jagielski <j...@jagunet.com> wrote: > > Looking at a T of 2.4.24 either the 15th or 16th...

Re: T of 2.4.24

Looking at a T of 2.4.24 either the 15th or 16th...

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

file descriptor: [client 127.0.0.1:63016] AH01468: ef_unified_filter() failed > On Dec 13, 2016, at 10:35 AM, Jim Jagielski <j...@jagunet.com> wrote: > > Confirming that 2.4.x HEAD fails as noted in PR 60375 > >> On Dec 13, 2016, at 10:14 AM, Jim Jagielski

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

Confirming that 2.4.x HEAD fails as noted in PR 60375 > On Dec 13, 2016, at 10:14 AM, Jim Jagielski <j...@jagunet.com> wrote: > > >> On Dec 13, 2016, at 8:33 AM, Jim Jagielski <j...@jagunet.com> wrote: >> >> This fails on all systems that have sed in

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

> On Dec 13, 2016, at 8:33 AM, Jim Jagielski <j...@jagunet.com> wrote: > > This fails on all systems that have sed in /usr/bin/sed > or someplace other than /bin :( > Hmmm... even w/ the change to /usr/bin/sed I'm getting test #1 failing: t/modules/ext_filter.t .. 1..23

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

Handled in: Committed revision 1774018. Committed revision 1774019. > On Dec 13, 2016, at 8:57 AM, Eric Covener wrote: > > On Tue, Dec 13, 2016 at 8:54 AM, Marion et Christophe JAILLET > wrote: >> Hi, >> >> >> >> I can't send a patch

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

This fails on all systems that have sed in /usr/bin/sed or someplace other than /bin :( > On Dec 13, 2016, at 8:20 AM, jor...@apache.org wrote: > > Author: jorton > Date: Tue Dec 13 13:20:32 2016 > New Revision: 1774010 > > URL: http://svn.apache.org/viewvc?rev=1774010=rev > Log: > Add basic

Re: svn commit: r1773761 - /httpd/httpd/trunk/modules/http/http_filters.c

Upon inspection it looks good... doing some further testing but so far, +1 Thx! > On Dec 12, 2016, at 11:18 AM, Yann Ylavic wrote: > > On Mon, Dec 12, 2016 at 3:32 PM, Eric Covener wrote: >> On Mon, Dec 12, 2016 at 6:25 AM, Yann Ylavic

Breakage on trunk head due to PCRE

./configure: line 6194: with_pcre: command not found checking for -pcre2-config... no checking for -pcre-config... no checking for pcre2-config... no checking for pcre-config... no configure: error: pcre(2)-config for libpcre not found. PCRE is required and available from http://pcre.org/ make:

Re: 2.6/3.0

> On Dec 9, 2016, at 5:24 PM, William A Rowe Jr wrote: > > > Instead, maybe we could backport all that stuff to 2.4, in a backwards > compatible fashion. That is, basically backport trunk to 2.4. This > would give us more runway to work on httpd-nextgen. > > That is very

Re: T of 2.4.24

> On Dec 12, 2016, at 1:26 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > > On Thu, Dec 8, 2016 at 8:55 AM, Jim Jagielski <j...@jagunet.com> wrote: > Things are looking good for a T of 2.4.24 sometime late > today. > > If you have any issues or concer

2.6/3.0

It may be weird talking about httpd 2.6/3.0 when we are stuck in a holding pattern for 2.4.24, but actually it's not a bad idea. Right now, there are quite a few improvements in trunk that should *really* be in a releasable version... Now we have some options on how to proceed, but my modus

Re: T of 2.4.24

> On Dec 9, 2016, at 12:20 AM, William A Rowe Jr wrote: > > On Thu, Dec 8, 2016 at 12:16 PM, William A Rowe Jr > wrote: > > @VP Legal, is this worth an escalation? You didn't see fit to respond today, > but I think this falls under the purview of

Re: T of 2.4.24

Scratch that... Instead, I plan on doing it on Monday, to provide some additional time for some things to get locked down and resolved. My apologies for those waiting for 2.4.24... > On Dec 8, 2016, at 9:55 AM, Jim Jagielski <j...@jagunet.com> wrote: > > Things are looki

Re: T of 2.4.24

AFAICT there is no consensus. But is this really a blocker? > On Dec 8, 2016, at 12:38 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > > On Thu, Dec 8, 2016 at 8:55 AM, Jim Jagielski <j...@jagunet.com> wrote: > Things are looking good for a T of 2.4.24 sometime l

T of 2.4.24

Things are looking good for a T of 2.4.24 sometime late today. If you have any issues or concerns, let me know asap.

Re: JSON for mod_status

> On Dec 1, 2016, at 2:16 PM, William A Rowe Jr wrote: > > > Note that mod_bmx_status entries focus on what most management > frameworks are looking for, so thus far, it doesn't deliver an entire > dataset per connection or worker thread. It certainly could, of course.

Re: JSON for mod_status

> On Dec 1, 2016, at 12:53 PM, William A Rowe Jr wrote: > > > Finally the query fn in mod_bmx_status performs the callback indicated > through its invocation to unspool the data in presentation format, which > lives back in mod_bmx and behaves identically for every bmx

Re: JSON for mod_status

lives in mod_bmx itself. > > > On Nov 30, 2016 14:35, "Jim Jagielski" <j...@jagunet.com> wrote: > One thing that I can't understand from an initial look > is how the whole hook thing is. In mod_status, we have a hook > that is run in mod_status and other modules us

Re: JSON for mod_status

One thing that I can't understand from an initial look is how the whole hook thing is. In mod_status, we have a hook that is run in mod_status and other modules use to supplement the mod_status output. With mod_bmx it looks like instead whatever "chunk" of data you want to make available, you put

Re: JSON for mod_status

One final note: The reason I brought all this up is that right now, using mod_status for actual automated status checking is downright painful. At ApacheCon, due to, I guess, me adding the mod_status hooks to the redis and memcache socache providers, people came up to me and asked when, if ever,

Re: [Vote] Considering mod_bmx for adoption by HTTP Server Project

> On Nov 30, 2016, at 2:59 PM, William A Rowe Jr wrote: > > > [X] Accept mod_bmx into the httpd trunk (for possible backport consideration) > Module sub-modules NEVER get the love and attention they need and warrant.

Re: JSON for mod_status

I'm not pushing back on mod_bmx at all... I just think that there is a better understanding here about "mod_status producing JSON" than what the changeover to mod_bmx would be. What I would push back on would be having 2 implementations, since that's just weird :) But if the BMX data format is

Re: JSON for mod_status

So the only concern is that you prefer XML over JSON??

Re: JSON for mod_status

> On Nov 30, 2016, at 2:31 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > > On Wed, Nov 30, 2016 at 1:27 PM, Jim Jagielski <j...@jagunet.com> wrote: > > > On Nov 30, 2016, at 1:56 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > > > >

Re: JSON for mod_status

> On Nov 30, 2016, at 1:56 PM, William A Rowe Jr wrote: > > > There's no way to anticipate the "right way" to map json > tables to presentation-level results. ??? Certainly that is the job of the xlate provider that would be used, wouldn't it. Or are you suggesting that

Re: JSON for mod_status

Any online examples of it running? It's been a SUPER long time since I looked at it. And I can't recall what the bean framework is or does... > On Nov 30, 2016, at 1:50 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > > On Wed, Nov 30, 2016 at 11:54 AM, Jim Jagielski <j...@

Re: JSON for mod_status

-11-30 at 12:54 -0500, Jim Jagielski wrote: >> I'm thinking about adding JSON support to mod_status... >> the "plain" version output really stinks and lacks parity >> w/ the info we provide via HTML, and it would be nice >> to produce a really easily parseable for

JSON for mod_status

I'm thinking about adding JSON support to mod_status... the "plain" version output really stinks and lacks parity w/ the info we provide via HTML, and it would be nice to produce a really easily parseable format. Thoughts...?

Re: apr-util 1.6 Netware got apr_redis.c and CW liked 99.9%

Thx again! Added in both APU-1.6 and APR-TRUNK > On Nov 22, 2016, at 4:53 AM, NormW wrote: > > G/E (Hope this doesn't ruin it) > >> Index: redis/apr_redis.c >> === >> --- redis/apr_redis.c(revision 1770630)

Re: NWGNUsocachmem needs to find mod_status.h

Done! Committed revision 1770828. Thx > On Nov 22, 2016, at 4:20 AM, NormW wrote: > > G/E, > See attached patch... > >> Index: modules/cache/NWGNUsocachmem >> === >> --- modules/cache/NWGNUsocachmem (revision

Time for 2.4.24!

We have a few items in STATUS that, imo, should be tested, voted-on and the committed to the httpd-2.4 branch in anticipation of a new release SOON! I'd like to have a T the end of next week, if possible so we can start off December (or be close to "starting it off") with a new release for the

Re: svn commit: r1768245 - /httpd/httpd/trunk/modules/cache/mod_socache_memcache.c

IMO, if you use and compute something 2x or more, it should be a var. YMMV > On Nov 18, 2016, at 4:04 PM, Christophe JAILLET > <christophe.jail...@wanadoo.fr> wrote: > > Le 05/11/2016 à 17:47, j...@apache.org a écrit : >> Author: jim >> Date: Sat Nov 5 16:47:43

Re: mod_socache_redis

Somehow things got out of sync. Should be fixed now. > On Nov 6, 2016, at 2:59 PM, Jacob Champion <champio...@gmail.com> wrote: > > On 11/06/2016 05:32 AM, Jim Jagielski wrote: >> This is weird... Are you using the stuff at the ASF?? >> The format wa

Re: svn commit: r1768245 - /httpd/httpd/trunk/modules/cache/mod_socache_memcache.c

Why? We trust the apr_memcache.c returns the correct response... No need to check the version of APR or APU since mod_socache_memcache.c works fine no matter what version is used. > On Nov 6, 2016, at 11:58 AM, William A Rowe Jr wrote: > > > On Sun, Nov 6, 2016 at 10:57

Re: mod_socache_redis

ank Ibell <hwib...@gmail.com> wrote: > > Hello Jim, > > I am trying to build trunk, but I am getting a compiler error. It seems the > structure apr_redis_stats_t is missing a rejected_connections field. I was > able to compile by adding the missing field to apr_redis_s

Re: mod_socache_redis

Is this Xcode8 or 7? I'm on OSX 10.11.6 and Xcode 7.3.1 > On Nov 6, 2016, at 1:11 AM, Hank Ibell <hwib...@gmail.com> wrote: > > Hello Jim, > > I am trying to build trunk, but I am getting a compiler error. It seems the > structure apr_redis_stats_t is missing a rejec

mod_socache_redis

Trunk now includes mod_socache_redis, which requires APR 1.6 and above. Please test it out and provide feedback :) I also added in the required mod_status hook info for mod_socache_memcache as well, so now it was also provide mod_status info. I plan to also submit that for backporting to 2.4 as

Re: svn commit: r1767482 - in /httpd/httpd/branches/2.4.x: ./ CHANGES STATUS modules/http/http_request.c server/request.c

Reverted. Thx! > On Nov 2, 2016, at 5:12 AM, Ruediger Pluem <rpl...@apache.org> wrote: > > > > On 11/01/2016 12:53 PM, j...@apache.org wrote: >> Author: jim >> Date: Tue Nov 1 11:53:57 2016 >> New Revision: 1767482 >> >> URL: http://svn

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