Re: A little nit

> On 3 Aug 2017, at 08:30, Jim Jagielski <j...@jagunet.com> wrote: > > It's just GUI magic... Basically, it will internally take '1.1' and > convert it to 11, 1.0 to 10, etc... If that's the case, I would recommend going 2 decimal places (1.1 = 100, 1.25 = 125, etc.) to allow

Fwd: [Bug 61376] httpd segfault after receiving graceful/restart signals

FYI > Begin forwarded message: > > From: bugzi...@apache.org > Subject: [Bug 61376] httpd segfault after receiving graceful/restart signals > Date: August 2, 2017 at 6:42:34 PM EDT > To: b...@httpd.apache.org > Reply-To: "Apache HTTPD Bugs Notification List" > Message-Id:

Re: A little nit

It's just GUI magic... Basically, it will internally take '1.1' and convert it to 11, 1.0 to 10, etc... No struct or field changes. > On Aug 2, 2017, at 3:39 PM, Jim Riggs <apache-li...@riggs.me> wrote: > >> On 2 Aug 2017, at 12:33, Jim Jagielski <j...@jagunet.com> wrot

Re: A little nit

> On 2 Aug 2017, at 12:33, Jim Jagielski <j...@jagunet.com> wrote: > > I'll be adding some code to allow for lbfactors to be > single decimal numbers (like 1.1, 2.5, etc...)... People > have asked "How do I change it so that machine B is like 10% > preferred" a

A little nit

I'll be adding some code to allow for lbfactors to be single decimal numbers (like 1.1, 2.5, etc...)... People have asked "How do I change it so that machine B is like 10% preferred" and I mention that "Well, you could make one a 10 and the other an 11" but that confuses people. :/

Re: svn commit: r1802336 - /httpd/httpd/trunk/docs/manual/mod/mod_proxy_fcgi.xml

> On Jul 19, 2017, at 12:44 PM, Luca Toscano wrote: > > What does reuse=on do more other than forcing a worker to reuse the same > socket? > Reuse also activates the IP address cache...

Re: svn commit: r1802336 - /httpd/httpd/trunk/docs/manual/mod/mod_proxy_fcgi.xml

; On Jul 19, 2017, at 4:26 AM, Luca Toscano <toscano.l...@gmail.com> wrote: > > Hi Jim, > > 2017-07-18 23:00 GMT+02:00 <j...@apache.org>: > Author: jim > Date: Tue Jul 18 21:00:14 2017 > New Revision: 1802336 > > URL: http://svn.apache.org/viewvc?rev=1802336=rev

Re: mod_proxy_fcgi and flush

Agreed. r->pool for the win. > On Jul 14, 2017, at 5:38 AM, Plüm, Rüdiger, Vodafone Group > wrote: > > > > Von: Luca Toscano [mailto:toscano.l...@gmail.com] > Gesendet: Freitag, 14. Juli 2017 11:30 > An: Apache HTTP Server Development List

Re: 2.4.27

> On 11 Jul 2017, at 11:46, James Cloos <cl...@jhcloos.com> wrote: > >>>>>> "JJ" == Jim Jagielski <j...@jagunet.com> writes: > > JJ> *) mod_http2: disable and give warning when mpm_prefork is encountered. > The server will > JJ>

Re: An ask for eyes on proposal

+1 for Whitelisting... > On Jul 10, 2017, at 12:02 PM, William A Rowe Jr wrote: > > Based on the fact that Jim's advanced this for consideration for 2.4.28, > any further feedback on the following proposal to make RemoteIPProxyProtocol > directive into a whitelist (to

[ANNOUNCEMENT] Apache HTTP Server 2.4.27 Released

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

PROXY protocol support

Now that 2.4.27 is (almost) out, there are some other patches in STATUS that would be good to finalize, including in particular, the support for the HAproxy PROXY protocol support. To help, I've gone ahead and created an updated, merge-clean patch as well as created tests for it in the Perl

Re: rfc1123 aka Proxy balancer://127

Personally, I think we simply document that balancer names must start w/ a character. > On Jul 10, 2017, at 2:56 AM, jean-frederic clere wrote: > > Hi, > > According rfc1123 the configuration: > ProxyPass "/" "balancer://127" > >BalancerMember ajp://tomcat1:8009 >

[RESULT] Was: Re: [VOTE] Release Apache httpd 2.4.27 as GA

With sufficient +1 (binding) votes and no -1 votes, and after the required 72 waiting period, I call this vote CLOSED and the vote PASSES. Will move the artifacts over so that mirrors can pick them up in prep for an announcement tomorrow.

Re: [VOTE] Release httpd-2.2.34

> On Jul 6, 2017, at 3:33 PM, William A Rowe Jr wrote: > > > +/-1 > [ ] Release 2.2.34 as legacy GA +1: macOS 10.12.5 > > +/-1 > [ ] Retire the 2.2.x branch from any further maintenance. +1

Re: httpd 2.4.26 with apr 1.6 ExtFilterDefine

2.4.26/27 doesn't *require* APR/APU 1.6.x, but there are some features that depend on it. If it's a bug in apr 1.6.x, then it's not a httpd bug specifically... imo at least. any further detail on how the below is actually borken?? What happens? > On Jul 7, 2017, at 7:41 AM, Steffen

Re: [VOTE] Release Apache httpd 2.4.27 as GA

+1: o CentOS 6.9, 64bit o CentOS 7.3, 64bit o Ubuntu 15.10, 64bit > On Jul 6, 2017, at 1:45 PM, Jim Jagielski <j...@jagunet.com> wrote: > > The pre-release test tarballs for Apache httpd > version 2.4.27 can be found at the usual place: > > http://httpd.apach

Re: mod_proxy_fcgi and flush

works 4 me... :/ > On Jul 6, 2017, at 2:08 PM, Helmut K. C. Tessarek > wrote: > > One of the comments on the documentation page of mod_proxy_fcgi > (http://httpd.apache.org/docs/2.4/mod/mod_proxy_fcgi.html) mentions an > issue with flush: > > There is just no flush

Re: [VOTE] Release Apache httpd 2.4.27 as GA

+1 on macOS 10.12.5 and Xcode 8.3.3. More tests to come ;) > On Jul 6, 2017, at 1:45 PM, Jim Jagielski <j...@jagunet.com> wrote: > > The pre-release test tarballs for Apache httpd > version 2.4.27 can be found at the usual place: > > http://httpd.apache.org/de

[VOTE] Release Apache httpd 2.4.27 as GA

The pre-release test tarballs for Apache httpd version 2.4.27 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.27 GA. [ ] +1: Good to go [ ] +0: meh [ ] -1: Danger Will Robinson. And why. Vote will last the

T of 2.4.27 count down

Okey dokey... looks like we are now no longer on hold... I expect to T around 1:30pm eastern, or so. > On Jul 6, 2017, at 11:13 AM, Jim Jagielski <j...@jagunet.com> wrote: > > Due to the questions around lua and apr_table and the > change regarding http2 and prefork, doing a T

Re: 2.4.27

> On Jul 6, 2017, at 11:15 AM, Stefan Eissing > wrote: > > Hej, > > I tried to gather some discussion about this. Should have polled this mailing > list. You can read most of it here: https://github.com/icing/mod_h2/issues/142 > > tl;dr > > I had several

2.4.27 T ... holding off

Due to the questions around lua and apr_table and the change regarding http2 and prefork, doing a T of 2.4.27 right now does not seem prudent. I am holding off until we determine what to do about both "issues"

Re: svn commit: r1800835 - in /httpd/httpd/branches/2.4.x: ./ CHANGES modules/lua/README modules/lua/config.m4 modules/lua/lua_apr.c modules/lua/lua_config.c modules/lua/lua_request.c modules/lua/mod_

From IRC: [10:09:37] I've personally never used apr_table like described by jchampion_ [10:09:46] and I don't believe it's documented? [10:10:15] if you want to set a header, you'd use r.headers_out['foo'] = 'bar' [10:10:42] so tbh I'd be in favor of just scrapping that bit [10:10:54]

Re: svn commit: r1800835 - in /httpd/httpd/branches/2.4.x: ./ CHANGES modules/lua/README modules/lua/config.m4 modules/lua/lua_apr.c modules/lua/lua_config.c modules/lua/lua_request.c modules/lua/mod_

/modules/lua.t at line 53 fail #13 # Failed test 52 in t/modules/lua.t at line 72 Failed 3/52 subtests (less 24 skipped subtests: 25 okay) > On Jul 6, 2017, at 8:16 AM, Jim Jagielski <j...@jagunet.com> wrote: > > The biggest issue, for me, is that currently the > test

Re: svn commit: r1800835 - in /httpd/httpd/branches/2.4.x: ./ CHANGES modules/lua/README modules/lua/config.m4 modules/lua/lua_apr.c modules/lua/lua_config.c modules/lua/lua_request.c modules/lua/mod_

The biggest issue, for me, is that currently the test framework returns loads of errors on mod_lua; either we "fix" mod_lua or we "fix" the tests but having it the way it is now is kinda wonky :-)

Re: perl test framework

Ok... was just making sure it wasn't just me having issues with more modern Perls.

Re: 2.4.27

file. PR 61240. [Ruediger Pluem] *) mod_proxy_fcgi: Revert to 2.4.20 FCGI behavior for the default ProxyFCGIBackendType, fixing a regression with PHP-FPM. PR 61202. [Jacob Champion, Jim Jagielski] *) core: Avoid duplicate HEAD in Allow header. This is a regression in 2.4.24

Re: perl test framework

> On Jul 5, 2017, at 8:39 AM, Rainer Jung wrote: > > Solaris: self-compiled 5.22.0 I have found that 5.20.x works best for me... I have also found that doing a universal CPAN update generally causes various framework tests to fail[1]; usually the 1st hint of troubles

perl test framework

I am curious... what versions of Perl are people using when running the Perl test framework? It seems that, at least to me, it is quite picky regarding versions, at least on macOS.

2.4.27

Anyone opposed to a quick T and release of 2.4.27 within the next week?

Re: FastCGI env-vars

There is one (I hope!) final question... There seems to be conflicting interpretations on whether PATH_INFO should, or should NOT, include any QUERY_STRING info or "extra stuff" after the actual path itself... Right now, we don't.

FastCGI env-vars

In any case, I think HEAD of the perl test framework is finally in shape to test and catch expectations regarding how we handle FCGI env-vars, both in "generic" situations as well as how php-fpm sees/expects them. At least, the current rev "passes" all tests based on my assumptions on what those

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

> On Jun 30, 2017, at 11:43 AM, Eric Covener wrote: > > On Fri, Jun 30, 2017 at 11:10 AM, William A Rowe Jr > wrote: >> Thousands of bugs pass through STATUS, what makes yours special? > > It fixes a regression in the last release, I think it's close

Re: svn commit: r1800306 - in /httpd/httpd/trunk: CHANGES modules/mappers/mod_actions.c modules/proxy/mod_proxy_fcgi.c

acob Champion <champio...@gmail.com> wrote: > > On 06/30/2017 05:32 AM, Jim Jagielski wrote: >> I still think that the below has value and should not be/have-been >> reverted. > > I'm not arguing that it doesn't have value in theory, but IMO it doesn't > belong in 2.

Re: svn commit: r1800306 - in /httpd/httpd/trunk: CHANGES modules/mappers/mod_actions.c modules/proxy/mod_proxy_fcgi.c

I still think that the below has value and should not be/have-been reverted. Anyone opposed to me re-adding it to trunk and removing it from the backport proposal? > On Jun 29, 2017, at 1:43 PM, jchamp...@apache.org wrote: > > Modified: httpd/httpd/trunk/modules/mappers/mod_actions.c > URL: >

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

> On Jun 28, 2017, at 6:46 AM, Eric Covener <cove...@gmail.com> wrote: > > On Wed, Jun 28, 2017 at 5:50 AM, Jim Jagielski <j...@jagunet.com> wrote: >> Is there someplace a set of examples on This Is What PHP and PHP-FPM >> Expect These Value

Re: [VOTE] Release httpd-2.2.33

I would also suggest to reroll: I'll test the reroll on my systems here.

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

Is there someplace a set of examples on This Is What PHP and PHP-FPM Expect These Values To Be? Like a whole slew of: For request: /blag/futo/gtyj.php?qur=kjr SCRIPT_NAME: Should be /gtyj.php PATH_INFO Should be /blag/futo PATH_TRANSLATED Should be

Re: svn commit: r1799689 - in /httpd/test/framework/trunk/t: conf/proxy.conf.in htdocs/modules/proxy/fcgi/ htdocs/modules/proxy/fcgi/index.php modules/proxy_fcgi.t

This is cool. Thx. It's inline with what I was hoping to do. I'm curious though Since we never actually *run* php-fpm on the PHP script, we never see what PHP actually determines are these parameters, right? > On Jun 23, 2017, at 1:50 PM, jchamp...@apache.org wrote: > > Author: jchampion >

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

Over this weekend I may try to extend the current fcgi testing to include php-fpm... we should not, imo, fold in any patches until we can test each applicable use case and avoid regressions. Hacking on the test will keep my mind off of things... > On Jun 23, 2017, at 7:52 AM, Jim Jagielski

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

AddType application/x-php7-fpm .php Action application/x-php7-fpm /fpm virtual SetHandler proxy:fcgi://localhost:9001 SetHandler "proxy:fcgi://localhost:9001

Re: Timeouts and other time-related granularity

Recommendations on how to do it better welcomed!

Re: Timeouts and other time-related granularity

It would be useful to mark those directives supporting the "extended time format" as such, but we don't have that format documented anyplace... As someone who has limited docs-sense, what is the best way to do that. Should we create some entry somewhere in our manual that specifies that format

Re: Timeouts and other time-related granularity

Last I checked, these already are. > On Jun 21, 2017, at 9:36 AM, Stefan Eissing <stefan.eiss...@greenbytes.de> > wrote: > > s->timeout > s->keep_alive_timeout > > ? > >> Am 21.06.2017 um 15:34 schrieb Jim Jagielski <j...@jagunet.com>: >

Re: Timeouts and other time-related granularity

I've started making some of the more obvious changes to support sub-single-second values for various modules... 1st was the watchdog and hcheck modules. It does seem like "everyplace" we have timeouts, we should take full advantage of the finer granularity we store anyway. Looking at reqtimeout

Re: WatchdogInterval

Hmmm... has to do with wd_interval_set handling. No idea why the "error" isn't reported but that's what it is. > On Jun 21, 2017, at 8:19 AM, Jim Jagielski <j...@jagunet.com> wrote: > > This is weird... At least on my system, if I set WatchdogInterval > to *anything*

WatchdogInterval

This is weird... At least on my system, if I set WatchdogInterval to *anything*, httpd will refuse to start up. Even if I set it to the default. It's like the mere existence of the directive in the config file is enough to stop it. WTF?

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

% cat fcgi.pl #!/usr/bin/env perl use FCGI; use Socket; use FCGI::ProcManager; use Data::Dumper; $num_args = $#ARGV + 1; if ($num_args != 1) { print "\nUsage: fcgi.pl \n"; exit 1; } $proc_manager = FCGI::ProcManager->new( {n_processes => 1} ); $socket = FCGI::OpenSocket( $ARGV[0], 10 );

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

Ahh... the tests from the orig bug report > On Jun 20, 2017, at 2:39 PM, Jacob Champion wrote: > > SCRIPT_NAME

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

> On Jun 20, 2017, at 1:18 PM, Jacob Champion <champio...@gmail.com> wrote: > > On 06/20/2017 10:12 AM, Jim Jagielski wrote: >> All this is, IMO, moot until we have a *patch*. > > Agreed. See my other fork of this thread for my questions on that. > >> Right

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

Last I checked, it's in the test framework... > On Jun 20, 2017, at 1:42 PM, Jacob Champion <champio...@gmail.com> wrote: > > On 06/20/2017 09:47 AM, Jacob Champion wrote: >> I think. Still trying to context switch back three months. > > Jim, do you have a good te

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

> On Jun 20, 2017, at 1:03 PM, Jacob Champion wrote: > > On 06/20/2017 10:00 AM, William A Rowe Jr wrote: >> You must presume it is in the wild, and shortening the exposure >> by a matter of days isn't significant. > > My point is that we should fix it ASAP. Days vs. more

Re: Timeouts and other time-related granularity

We already have a format which is used by a few directives via ap_timeout_parameter_parse() If desired, we could extend that for the fractional stuff. > On Jun 20, 2017, at 9:12 AM, Stefan Eissing <stefan.eiss...@greenbytes.de> > wrote: > > >> Am 20.06.2017 um 14:56

Timeouts and other time-related granularity

Most of our time-related directives accept seconds as their parameters, but I'm thinking that allowing milliseconds is likely a better option... From what I can see, most of what would be interesting/useful to change are stored as interval/apr_time anyway, so there would be no real API/struct

CVE-2017-7659: mod_http2 null pointer dereference

CVE-2017-7659: mod_http2 null pointer dereference Severity: Important Vendor: The Apache Software Foundation Versions Affected: httpd 2.4.24 (unreleased) httpd 2.4.25 Description: A maliciously constructed HTTP/2 request could cause mod_http2 to dereference a NULL pointer and crash the server

[ANNOUNCE] Apache HTTP Server 2.4.26 Released

Apache HTTP Server 2.4.26 Released June 19, 2017 The Apache Software Foundation and the Apache HTTP Server Project are pleased to announce the release of version 2.4.26 of the Apache HTTP Server ("Apache"). This version of Apache is our latest GA release of the

[RESULT] Re: [VOTE] Release Apache httpd 2.4.26 as GA

With more than the 3 +1 (binding) votes, and no -1, this vote PASSES. I anticipate a Release Announcement on Monday. Will move the artifacts for mirror grab. Thx to all testers and all contributors! > On Jun 13, 2017, at 1:33 PM, Jim Jagielski <j...@jagunet.com> wrote: > > The p

Re: [VOTE] Release Apache httpd 2.4.26 as GA

+1: o macOS 10.12.5 / Xcode 8.3.3 o CentOS 6, 64bit

Re: svn commit: r20021 - /dev/httpd/

Thanks! Fixed. > On Jun 13, 2017, at 2:12 PM, Jim Riggs <apache-li...@riggs.me> wrote: > > I don't know that it really matters, but this guy is in there twice (in each > CHANGES doc), once with the PR # and once without: > >> + *) mod_proxy: Allow the per-request env

Re: svn commit: r20021 - /dev/httpd/

I don't know that it really matters, but this guy is in there twice (in each CHANGES doc), once with the PR # and once without: > + *) mod_proxy: Allow the per-request environment variable "no-proxy" to > + be used as an alternative to ProxyPass /path !. This is primarily > + to set

[VOTE] Release Apache httpd 2.4.26 as GA

The pre-release test tarballs for Apache httpd version 2.4.26 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.26 GA. [ ] +1: Good to go [ ] +0: meh [ ] -1: Danger Will Robinson. And why. Vote will last the

Re: The drive for 2.4.26

There was a delay in doing the T due to an issue that was being investigated. This looks resolved now. With that, I plan on doing a T& today at ~1:30pm (Eastern) unless someone else wishes to RM.

Re: svn commit: r1798472 - /httpd/httpd/branches/2.4.x/CHANGES

That's right. It's that specific module. > On Jun 12, 2017, at 10:18 AM, Eric Covener <cove...@gmail.com> wrote: > > I thought we were leaving proxy_http2 experimental? > > On Mon, Jun 12, 2017 at 10:13 AM, <j...@apache.org> wrote: >> Author: jim >>

Re: The drive for 2.4.26

Still looking at a T today... I will RM unless someone else would like to do so!

Re: An ask for eyes on proposal

Is expansion of the syntax something that could be folded in for 2.4.27? > On Jun 8, 2017, at 2:51 PM, William A Rowe Jr wrote: > > [Again, using all the words] > > On Thu, Jun 8, 2017 at 12:30 PM, Daniel Ruggeri wrote: >> Hi, all; >> With the

Re: The drive for 2.4.26

Perfect... I propose a T on Monday... comments? > On Jun 6, 2017, at 5:23 AM, Stefan Eissing > wrote: > > Backported. Will also release v1.10.6 on github shortly. > >> Am 06.06.2017 um 10:53 schrieb Stefan Eissing : >> >>> >>> Am

Re: Ideas from ApacheCon

Will do! THX! > On Jun 2, 2017, at 9:46 AM, Jim Riggs <apache-li...@riggs.me> wrote: > >> On 2 Jun 2017, at 07:20, Jim Jagielski <j...@jagunet.com> wrote: >> >>> On Jun 1, 2017, at 1:29 PM, Jim Riggs <apache-li...@riggs.me> wrote: >>> &

Re: Ideas from ApacheCon

> On 2 Jun 2017, at 07:20, Jim Jagielski <j...@jagunet.com> wrote: > >> On Jun 1, 2017, at 1:29 PM, Jim Riggs <apache-li...@riggs.me> wrote: >> >> Regardless, even worst case, we are looking at what, iterating 6 pointers >> instead of 3 or 10 instead

Re: Ideas from ApacheCon

On Jun 1, 2017, at 1:29 PM, Jim Riggs <apache-li...@riggs.me> wrote:Regardless, even worst case, we are looking at what, iterating 6 pointers instead of 3 or 10 instead of 5? We probably have some lower hanging fruit across the request lifecycle code to increase performance than savin

Re: Ideas from ApacheCon

> On Jun 1, 2017, at 1:29 PM, Jim Riggs <apache-li...@riggs.me> wrote: > > > Regardless, even worst case, we are looking at what, iterating 6 pointers > instead of 3 or 10 instead of 5? We probably have some lower hanging fruit > across the request lifecycle code to i

Re: Ideas from ApacheCon

> On Jun 1, 2017, at 1:29 PM, Jim Riggs <apache-li...@riggs.me> wrote: > > > Regardless, even worst case, we are looking at what, iterating 6 pointers > instead of 3 or 10 instead of 5? We probably have some lower hanging fruit > across the request lifecycle code to i

Re: HTTP/2 and no-longer "experimental"

It sounds like there is some consensus that http/2 be no longer tagged as experimental is that it be moved to RTC. I also sounds like we wish to keep mod_proxy_http2 as experimental however (and CTR).

Implement hot spares in mod_proxy_balancer [was Re: Ideas from ApacheCon]

> On 1 Jun 2017, at 17:15, Yann Ylavic <ylavic@gmail.com> wrote: > > On Thu, Jun 1, 2017 at 10:48 PM, Jim Riggs <apache-li...@riggs.me> wrote: >>> On 1 Jun 2017, at 15:25, Yann Ylavic <ylavic@gmail.com> wrote: >>> >>> On Thu, Jun

Re: Ideas from ApacheCon

> On 1 Jun 2017, at 15:25, Yann Ylavic <ylavic@gmail.com> wrote: > > On Thu, Jun 1, 2017 at 10:22 PM, Yann Ylavic <ylavic@gmail.com> wrote: >> On Thu, Jun 1, 2017 at 7:29 PM, Jim Riggs <apache-li...@riggs.me> wrote: >>>> On 1 Jun 2017, at

Re: Ideas from ApacheCon

> On 1 Jun 2017, at 07:55, Jim Jagielski <j...@jagunet.com> wrote: > > I really like where this is going... I just have a few questions: > > 1. The style, esp with array usage is different; eg APR_ARRAY_PUSH > and APR_ARRAY_IDX... any particular reason w

Re: Ideas from ApacheCon

thru the full list of workers one time, and then go thru the list of avail works and spares right after that. Assume that all workers are available; doesn't it mean we go thru that last 2x? > On May 31, 2017, at 1:44 PM, Jim Riggs <apache-li...@riggs.me> wrote: > >&

Re: HTTP/2 and no-longer "experimental"

> On Jun 1, 2017, at 4:40 AM, Stefan Eissing > wrote: > > What could a change of "experimental" do? > > - A. It could address the FUD. Which I assume is important for market shares. > And for people who have done serious investments (successful ones) in httpd >

Re: Ideas from ApacheCon

> On 23 May 2017, at 09:16, Jim Riggs <apache-li...@riggs.me> wrote: > >> On 18 May 2017, at 13:22, Rainer Jung <rainer.j...@kippdata.de> wrote: >> >> Am 18.05.2017 um 19:46 schrieb Jim Jagielski: >>> Based on feedback from various sessions: >&g

Broken OCSP Stapling

This was mentioned in today's Bulletproof TLS newsletter (https://www.feistyduck.com/bulletproof-tls-newsletter/issue_28_lets_encrypt_downtime.html): https://blog.hboeck.de/archives/886-The-Problem-with-OCSP-Stapling-and-Must-Staple-and-why-Certificate-Revocation-is-still-broken.html It

HTTP/2 and no-longer "experimental"

There was discussion some time ago about dropping the "experimental" tag from our HTTP/2 implementation. It is causing loads of people to not use it, as well as allowing for the perpetuation of FUD that httpd really doesn't support HTTP/2. I'd like for 2.4.26 to be the release that removes that

Re: The drive for 2.4.26

I think we should wait on a T to resolve this issue... > On May 30, 2017, at 9:12 AM, Stefan Eissing > wrote: > > I have one report of a CPU busy loop that seems to only happen on the last 3 > changes in mod_http2. Steffen is currently testing if a feature

r1792092 (Was: Re: The drive for 2.4.26)

Eric just noted that one viable backport hasn't been proposed yet... Jean-Frederic, can you confirm that r1792092 is something you'd like to see in 2.4.x? Other than the field addition to the struct, the change looks v. self-contained.

Re: The drive for 2.4.26

It looks like all the "easy and safe" backports have been submitted and then committed. I am hesitant to stir things up anymore and think that this week is our luck week for a T of 2.4.26. Comments? Feedback?

Re: The drive for 2.4.26

Until a proposal in in STATUS (and apologies if it is), its suitability for 2.4.x is a big unknown. > On May 24, 2017, at 12:42 PM, Luca Toscano <toscano.l...@gmail.com> wrote: > > > > 2017-05-22 16:35 GMT+02:00 Jim Jagielski <j...@jagunet.com>: > I think we are *

Re: Ideas from ApacheCon

> On 18 May 2017, at 12:46, Jim Jagielski <j...@jagunet.com> wrote: > > Based on feedback from various sessions: > > o A new-kind of "hot standby" in mod_proxy which kicks >in whenever a worker moves out of the pool (ie, doesn't >wait until al

Re: Ideas from ApacheCon

> On 18 May 2017, at 13:22, Rainer Jung <rainer.j...@kippdata.de> wrote: > > Am 18.05.2017 um 19:46 schrieb Jim Jagielski: >> Based on feedback from various sessions: >> >> o A new-kind of "hot standby" in mod_proxy which kicks >> in whe

Re: Ideas from ApacheCon

> On 22 May 2017, at 06:45, Jim Jagielski <j...@jagunet.com> wrote: > > I'll let Jim Riggs answer that...it came up during his mod_cache > talk. >> On May 18, 2017, at 2:25 PM, Eric Covener <cove...@gmail.com> wrote: >> >> On Thu, May 18, 2017 at 2:2

Re: The drive for 2.4.26

I think we are *really* close! What say we try for a T sometime this week? Who wants to RM? If no one does, I will.

Re: Ideas from ApacheCon

I'll let Jim Riggs answer that...it came up during his mod_cache talk. > On May 18, 2017, at 2:25 PM, Eric Covener <cove...@gmail.com> wrote: > > On Thu, May 18, 2017 at 2:22 PM, Rainer Jung <rainer.j...@kippdata.de> wrote: >>> o Look into AAA and mod_cache; eg:

Ideas from ApacheCon

Based on feedback from various sessions: o A new-kind of "hot standby" in mod_proxy which kicks in whenever a worker moves out of the pool (ie, doesn't wait until all workers are out)... ala a redundant hard drive. o Look into AAA and mod_cache; eg: "bolt in at the end" o

ACNA Miami: Who? When?

So, who all will be in Miami? From what I've seen on Sched and messages here: Yes : jimjag, rich, jfc, ruggeri, me No : rowe, covener There are several other ACNA regulars who have been quiet around here lately. Anyone else coming in? I'll be there Sunday evening through Friday morning. I

Re: Change from ad-hoc/historical security process to ASF process?

+1... Lets do it. BTW, I would adjust #16 to include: Add the CVE to the CHANGES file. That way, it's still documented in CHANGES, just after the release is spun out, show it shows up in the next release's CHANGES. > On May 5, 2017, at 8:39 AM, Eric Covener wrote: > >

Re: mod_brotli in 2.4.x is missing a few Makefile changes

OK, thx for clearing that up. Cheers! > On Apr 28, 2017, at 9:50 AM, Jan Ehrhardt <php...@ehrhardt.nl> wrote: > > Jim Jagielski in gmane.comp.apache.devel (Fri, 28 Apr 2017 09:29:01 > -0400): >> Are these issues with *building* the brotli library during >&g

Re: mod_brotli in 2.4.x is missing a few Makefile changes

This just clicked for me... Are these issues with *building* the brotli library during the configure/make of httpd? Why, exactly, are we doing this if this is, in fact, what we are doing? Just curious why we are taking this dependency on directly. > On Apr 28, 2017, at 9:19 AM, Jan Ehrhardt

Re: The drive for 2.4.26

It would be cool to have 2.4.26 released by ApacheCon, or even by OSCON. There are, last I checked, 2 showstoppers on list for 2.4.26... Anyway we could address them and shoot for a T maybe next Weds?

Re: backport proposals

ulo CHANGES) >> ie: >> http://home.apache.org/~ylavic/patches/httpd2.4-hcheck-after-r1779573.patch >> FULL hcheck patch: >> http://home.apache.org/~jim/patches/httpd2.4-hcheck.patch >> http://svn.apache.org/r1789387 >>

Re: mod_brotli in 2.4.x is missing a few Makefile changes

BTW, there are also deltas for config.m4 in modules/filters mainly around mod_brotli. At present what is in 2.4 seems to work fine, but should we consider backporting config.m4 as well?

Re: mod_brotli in 2.4.x is missing a few Makefile changes

Thanks! Are these the full diffs for Makefile? > On Apr 26, 2017, at 10:50 AM, Gregg Smith <g...@gknw.net> wrote: > > > On 4/26/2017 4:51 AM, Jim Jagielski wrote: >> >>> On Apr 25, 2017, at 4:34 PM, Evgeny Kotkov <evgeny.kot...@visualsvn.com> >>

Re: HTTP Server Hackathon/BOFs in Miami?

I have never been productive at Hackathons. The discussion is great and all that, but as far as the actual coding is concerned, I am too accustomed to having a certain environment when coding, including my desktop cpu, full keyboard and monitor. I just can't do serious coding/hacking on a laptop.

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