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

Jacob Champion in gmane.comp.apache.devel (Tue, 20 Jun 2017 09:07:44 -0700): >On 02/08/2017 07:56 PM, Eric Covener wrote: >> Assuming there's some alternate path that actually does change >> SCRIPT_NAME by default, we a) don't have any complaint about >> SCRIPT_NAME and b) have the SetEnv thing.

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

On 06/20/2017 01:35 PM, Jacob Champion wrote: What requests and server config did you use with this test setup? Here's why I'm asking: if I were to propose the attached patch for backport, what is the test case that *should* fail but doesn't? (proxy_fcgi.t passes, no problem.) And once we

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

On 06/20/2017 12:23 PM, Jim Jagielski wrote: % cat fcgi.pl #!/usr/bin/env perl What requests and server config did you use with this test setup? --Jacob

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

On 06/20/2017 11:48 AM, Jim Jagielski wrote: Ahh... the tests from the orig bug report There have been several reports. I'm hoping to get the test case you were using to test the new `if (fpm ...` logic in mod_proxy_fcgi. Even if it was just a manual test; I just want to get it recorded in

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

On 06/20/2017 10:55 AM, Jim Jagielski wrote: It's already in the wild. We do not guarantee bug compatibility. That's our judgment call based on adoption, expected user disruption, time in the wild, etc. The purpose of my Showstopper was to revert to known-good behavior. That didn't happen,

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 06/20/2017 10:55 AM, Jim Jagielski wrote: Last I checked, it's in the test framework... Quick grep for "SCRIPT_NAME" in the tests doesn't turn up anything; can you point me to it? --Jacob

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

On Tue, Jun 20, 2017 at 1:32 PM, William A Rowe Jr wrote: > On Tue, Jun 20, 2017 at 12:12 PM, Jim Jagielski wrote: >> >>> On Jun 20, 2017, at 1:03 PM, Jacob Champion wrote: >>> >>> On 06/20/2017 10:00 AM, William A Rowe Jr wrote:

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

On Tue, Jun 20, 2017 at 12:12 PM, Jim Jagielski wrote: > >> 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

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

As a general FYI: cPanel can’t release 2.4.26 until this is patched / fixed. We were bitten *hard* by the SCRIPT_URI breakage a while back, and this is going to put a blocker on our release. — Jacob Perkins Product Owner cPanel Inc. jacob.perk...@cpanel.net

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

> On Jun 20, 2017, at 1:18 PM, Jacob Champion 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 now there >> is a work-around,

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 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 test case for the current FPM

Re: svn commit: r1799356 - in /httpd/httpd/branches/2.2.x: ./ server/scoreboard.c

On Jun 20, 2017 12:00, "Jacob Champion" wrote: On 06/20/2017 09:47 AM, wr...@apache.org wrote: > Log: > Make the range test legible > Hmm, out of curiosity, is the legibility you mention from the parenthesization change or the switch to greater-than-or-equal for one side?

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

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 test case for the current FPM logic so we don't break that with a fix? --Jacob

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

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 now there is a work-around, which, again IMO, reduces the "need" to release something "now"... the only question is whether

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: svn commit: r1782209 - /httpd/httpd/branches/2.4.x/STATUS

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 days may not be significant, but days vs. months is definitely significant when it

Re: svn commit: r1799356 - in /httpd/httpd/branches/2.2.x: ./ server/scoreboard.c

On 06/20/2017 09:47 AM, wr...@apache.org wrote: Log: Make the range test legible Hmm, out of curiosity, is the legibility you mention from the parenthesization change or the switch to greater-than-or-equal for one side? I kind of like reading code that has all less-than comparisons, instead

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

On Tue, Jun 20, 2017 at 11:17 AM, Jacob Champion wrote: > On 06/20/2017 09:16 AM, William A Rowe Jr wrote: >> >> It's released into the wild, what is done is done. > > > Of course. But having it in the wild for three days is different than having > it in the wild for six

Re: [PATCH 2.2] fix ap_get_scoreboard_*

Joe, I compromised on your fix and retained parens for legibility, following the pattern of the other fix. Committed as r1799356, thanks On Mon, Jun 19, 2017 at 7:08 AM, Joe Orton wrote: > The limit checking is broken in 2.2's ap_get_scoreboard_*. This was > fixed in 2.4 in

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

On 06/20/2017 09:07 AM, Jacob Champion wrote: Can we do a quick fixup and reroll before it's too late? And... what *is* the fixup? It looks like the logic here -- where we start at the end of SCRIPT_NAME (or the beginning of PATH_INFO) and work backwards -- is designed to stop at the first

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

On 06/20/2017 09:16 AM, William A Rowe Jr wrote: It's released into the wild, what is done is done. Of course. But having it in the wild for three days is different than having it in the wild for six months. --Jacob

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

On Tue, Jun 20, 2017 at 11:15 AM, Jacob Champion wrote: > On 06/20/2017 09:14 AM, William A Rowe Jr wrote: >> >> Would encourage us to wait at least a couple more days for >> other, unrelated regression reports to filter in while fixing this >> defect. But there is nothing

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

On 06/20/2017 09:14 AM, William A Rowe Jr wrote: Would encourage us to wait at least a couple more days for other, unrelated regression reports to filter in while fixing this defect. But there is nothing stopping a 2.4.27 in rapid succession, we simply don't retroactively "retract" releases.

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

On Tue, Jun 20, 2017 at 11:07 AM, Jacob Champion wrote: > On 02/08/2017 07:56 PM, Eric Covener wrote: >> >> Assuming there's some alternate path that actually does change >> SCRIPT_NAME by default, we a) don't have any complaint about >> SCRIPT_NAME and b) have the SetEnv

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

On 02/08/2017 07:56 PM, Eric Covener wrote: Assuming there's some alternate path that actually does change SCRIPT_NAME by default, we a) don't have any complaint about SCRIPT_NAME and b) have the SetEnv thing. If we want more options, maybe we can stash this older SCRIPT_NAME into a new

Re: ocsp stapling improvements

> Am 20.06.2017 um 17:43 schrieb William A Rowe Jr : > > On Tue, Jun 20, 2017 at 6:39 AM, Stefan Eissing > wrote: >> >>> Am 12.06.2017 um 21:35 schrieb Ruediger Pluem : >>> 2. Persist responses (is this just a

Re: ocsp stapling improvements

On Tue, Jun 20, 2017 at 6:39 AM, Stefan Eissing wrote: > >> Am 12.06.2017 um 21:35 schrieb Ruediger Pluem : >> >>> 2. Persist responses (is this just a config/default issue?) >> >> This could become tricky given the various so cache implementations

Re: ocsp stapling improvements

> Am 20.06.2017 um 17:19 schrieb Hanno Böck : > > On Tue, 20 Jun 2017 13:39:56 +0200 > Stefan Eissing wrote: > >> Can we push the burden of getting a OCSP response to the client, even >> for must-staple certificates? > > No, you can't. > The

Re: ocsp stapling improvements

On Tue, 20 Jun 2017 13:39:56 +0200 Stefan Eissing wrote: > Can we push the burden of getting a OCSP response to the client, even > for must-staple certificates? No, you can't. The whole point is that must staple enforces stapling. This has a bit to do with the

Re: ocsp stapling improvements

> Am 20.06.2017 um 14:35 schrieb Plüm, Rüdiger, Vodafone Group > : > > It might cause I/O overhead compared with socache_shmcb, but it might be a > good solution > for those who want to have persisted OCSP responses. Other people might > priorize > a distributed

Re: Timeouts and other time-related granularity

I live and learn - hopefully. > Am 20.06.2017 um 15:32 schrieb Plüm, Rüdiger, Vodafone Group > : > > > >> -Ursprüngliche Nachricht- >> Von: Stefan Eissing [mailto:stefan.eiss...@greenbytes.de] >> Gesendet: Dienstag, 20. Juni 2017 15:13 >> An:

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 > wrote: > > >> Am 20.06.2017 um 14:56 schrieb Jim Jagielski

RE: Timeouts and other time-related granularity

> "2:20:33.1h" is 140 minutes, 33 seconds and 100ms. This one seems very backwards to me, as leading zeros could change the meaning. Ex. 0:1:15h vs 1:15h. If allowing combination units like that (personally, it seems overkill), I think it would be much safer to require an explicit

AW: Timeouts and other time-related granularity

> -Ursprüngliche Nachricht- > Von: Stefan Eissing [mailto:stefan.eiss...@greenbytes.de] > Gesendet: Dienstag, 20. Juni 2017 15:13 > An: dev@httpd.apache.org > Betreff: Re: Timeouts and other time-related granularity > > > > Am 20.06.2017 um 14:56 schrieb Jim Jagielski

Re: Timeouts and other time-related granularity

> Am 20.06.2017 um 14:56 schrieb Jim Jagielski : > > 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

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

AW: ocsp stapling improvements

> -Ursprüngliche Nachricht- > Von: Stefan Eissing [mailto:stefan.eiss...@greenbytes.de] > Gesendet: Dienstag, 20. Juni 2017 13:40 > An: dev@httpd.apache.org > Betreff: Re: ocsp stapling improvements > > > > Am 12.06.2017 um 21:35 schrieb Ruediger Pluem : > > > > I

Re: ocsp stapling improvements

> Am 12.06.2017 um 21:35 schrieb Ruediger Pluem : > > I guess the core mistake we do today is that we expire the entries in the > cache > after SSLStaplingStandardCacheTimeout. But we should keep them in the cache > as long as > they are valid (so either whats in the next

Re: ocsp stapling improvements

> Am 13.06.2017 um 00:48 schrieb Hanno Böck : > > What I think needs also be handled: > * There's > https://bz.apache.org/bugzilla/show_bug.cgi?id=59049 > which indicates that faulty responses from the OCSP server may bring > the server into a faulty state from which it