Re: svn commit: r1674661 - in /httpd/httpd/branches/2.4.x: ./ CHANGES STATUS modules/proxy/mod_proxy_wstunnel.c

> On Mar 2, 2017, at 5:58 AM, jean-frederic clere wrote: > >> >> +upgrade = apr_table_get(r->headers_in, "Upgrade"); >> +if (!upgrade || strcasecmp(upgrade, "WebSocket") != 0) { >> +ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r, APLOGNO(02900) >> +

Re: svn commit: r1784990 - in /httpd/httpd/branches/2.4.x: ./ modules/lua/

I think it's also safe to adjust to keep the "Looking for" 5.1 -> 5.2 to also add 5.3 explicitly > On Mar 1, 2017, at 1:36 PM, Jacob Champion <champio...@gmail.com> wrote: > > On 03/01/2017 09:44 AM, Jim Jagielski wrote: >> Hmmm... WFM under macOS and fedo

Re: svn commit: r1784990 - in /httpd/httpd/branches/2.4.x: ./ modules/lua/

Hmmm... WFM under macOS and fedora and centos. > On Mar 1, 2017, at 12:21 PM, Jacob Champion wrote: > > On 03/01/2017 08:54 AM, j...@apache.org wrote: >> Author: jim >> Date: Wed Mar 1 16:54:35 2017 >> New Revision: 1784990 >> >> URL:

Re: svn commit: r1784915 - in /httpd/httpd/branches/2.4.x/docs/manual: upgrading.html.en upgrading.xml.fr upgrading.xml.meta

Oops! Sorry, didn't see the full commit. My mistake. All good! Thx! > On Mar 1, 2017, at 9:11 AM, Luca Toscano <toscano.l...@gmail.com> wrote: > > Hi Jim, > > 2017-03-01 15:02 GMT+01:00 Jim Jagielski <j...@jagunet.com>: > > > On Mar 1, 2017,

Re: svn commit: r1784915 - in /httpd/httpd/branches/2.4.x/docs/manual: upgrading.html.en upgrading.xml.fr upgrading.xml.meta

> On Mar 1, 2017, at 6:43 AM, elu...@apache.org wrote: > > > Location "/server-status" > SetHandler server-status > -Require 127.0.0.1 > +Require local > /Location > Isn't 'localhost' the canonical term?

SHA-256

I think we should start, in addition to "signing" w/ md5 and sha-1, using sha-256 as well. Sound OK?

Re: Expr's lists evaluated in a string context (was: [users@httpd] mod_lua and subprocess_env)

Would it be possible that people are using it that way for exactly that purpose? I am wondering about this causing some regression for external users. > On Feb 22, 2017, at 10:51 AM, Yann Ylavic wrote: > >> On Tue, Feb 21, 2017 at 6:32 PM, Yann Ylavic

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

> On Feb 20, 2017, at 3:54 PM, Ruediger Pluem wrote: > > > > On 02/20/2017 02:38 PM, yla...@apache.org wrote: >> Author: ylavic >> Date: Mon Feb 20 13:38:03 2017 >> New Revision: 1783755 >> >> URL: http://svn.apache.org/viewvc?rev=1783755=rev >> Log: >> mpm_event: use a

Re: APR pools, mutexes and thread safe allocations

Fair enuff... sounds like thread safe pools aren't something people are interested in, so I won't worry about it :) thx for the discussion!

Re: APR pools, mutexes and thread safe allocations

> > It could be done, but who would use it that way? > I think the non-thread safety of pools requires that each person/developer implement their own locking esp around areas where they might not even understand that there is cross-thread issues. Thinking about 1.6 and especially apr 2.0, it

Re: APR pools, mutexes and thread safe allocations

> On Feb 20, 2017, at 10:58 AM, Yann Ylavic wrote: > > > So as Brane says, if one sets a mutex to the allocator of a pool > because (s)he wants pool_create/destroy() to be thread-safe, it does > not necessarily wants the same for palloc() and friends (e.g. the pool > is

Re: APR pools, mutexes and thread safe allocations

apr_pool_create_ex_debug(), yes. > On Feb 20, 2017, at 11:00 AM, Yann Ylavic <ylavic@gmail.com> wrote: > > Well, this is for debug mode only I guess. > > On Mon, Feb 20, 2017 at 4:59 PM, Jim Jagielski <j...@jagunet.com> wrote: >> Please READ a

Re: APR pools, mutexes and thread safe allocations

> On Feb 20, 2017, at 10:26 AM, Branko Čibej wrote: > > > APR pools were designed with the assumption that separate threads will > always use separate pools whenever concurrent allocations are possible. > This assumption happens to fit pretty well with the >

Re: APR pools, mutexes and thread safe allocations

Please READ apr_pools.c... Search for '->mutex' > On Feb 20, 2017, at 10:58 AM, Yann Ylavic <ylavic@gmail.com> wrote: > > On Mon, Feb 20, 2017 at 4:43 PM, Jim Jagielski <j...@apache.org> wrote: >> You are confusing pool mutexes with allocator mutexes... &

Re: APR pools, mutexes and thread safe allocations

You are confusing pool mutexes with allocator mutexes... > On Feb 20, 2017, at 10:26 AM, Branko Čibej <br...@apache.org> wrote: > > On 20.02.2017 16:08, Jim Jagielski wrote: >> Again, this would ONLY happen if the underlying allocator has >> a mutex! > >

Re: APR pools, mutexes and thread safe allocations

I mean, of course, "has a *mutex*" > On Feb 20, 2017, at 10:39 AM, Jim Jagielski <j...@jagunet.com> wrote: > > Again, I am only talking about those in which the allocator > has a pool... The allocator. Via apr_allocator_mutex_set(). > >> On Feb 20

Re: APR pools, mutexes and thread safe allocations

Again, I am only talking about those in which the allocator has a pool... The allocator. Via apr_allocator_mutex_set(). > On Feb 20, 2017, at 10:26 AM, Branko Čibej <br...@apache.org> wrote: > > On 20.02.2017 16:08, Jim Jagielski wrote: >> Again, this would ONLY hap

Re: APR pools, mutexes and thread safe allocations

Not with apr_palloc() or anything that calls apr_palloc (eg apr_pcalloc, et.al...) > On Feb 20, 2017, at 10:15 AM, Stefan Eissing <stefan.eiss...@greenbytes.de> > wrote: > >> >> Am 20.02.2017 um 16:08 schrieb Jim Jagielski <j...@jagunet.com>: >

APR pools, mutexes and thread safe allocations

Again, this would ONLY happen if the underlying allocator has a mutex! > On Feb 20, 2017, at 10:06 AM, Branko Čibej <br...@apache.org> wrote: > > On 20.02.2017 15:55, Jim Jagielski wrote: >>> On Feb 20, 2017, at 9:51 AM, Stefan Eissing <stefan.eiss...@greenbytes.d

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

> On Feb 20, 2017, at 9:51 AM, Stefan Eissing <stefan.eiss...@greenbytes.de> > wrote: > >> >> Am 20.02.2017 um 15:16 schrieb Jim Jagielski <j...@jagunet.com>: >> >> The below got me thinking... >> >> Right now, the pool allocator mute

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

The below got me thinking... Right now, the pool allocator mutex is only used when, well, allocator_alloc() is called, which means that sometimes apr_palloc(), for example, can be thread-safeish and sometimes not, depending on whether or not the active node has enough space. For 1.6 and later,

Re: FYI brotli

Just a FYI that it looks like a 0.6.x version of the lib will be released v. soon with all that is needed for the module to work and compile as-is... 1.0.0 will be released a little bit later which will simply deprecate/remove the OLD API, which we don't use anyway... That is, the lib change from

Re: svn commit: r1783413 - in /httpd/httpd/branches/2.4.x: ./ STATUS server/mpm/event/event.c

CHANGES is usually for PR listing and significant user-land changes and not necessarily and full listing of all fixes... That's what the commit logs are for :) > On Feb 17, 2017, at 1:49 PM, Marion & Christophe JAILLET > wrote: > > No CHANGES entry? > > CJ > >

Re: Topic for discussion... 2.4.26

, if I understood how that branch would > be applied. > > > On Feb 16, 2017 11:25 AM, "Jim Jagielski" <j...@jagunet.com> wrote: > Would be nice, I think, to start discussion on a T of 2.4.26 and > to open the doors to who wants to RM. Note, that if *nobody* > offers to RM, I will... and no matter what, I offer to help > whoever wishes to RM.

Re: FYI brotli

Whatever... nginx will have it 1st anyway. And once again we fail our users by having a nickel holding up a dollar. > On Feb 16, 2017, at 2:48 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > > On Thu, Feb 16, 2017 at 12:47 PM, Jim Jagielski <j...@jagunet.com> wrote: &g

Re: FYI brotli

> On Feb 16, 2017, at 1:15 PM, William A Rowe Jr wrote: > > > I concur with Evgeny Kotkov that an ABI stable dependency is appropriate > before adding this to httpd 2.4.x - so far as I've read none have suggested > this as an experimental addition to 2.4. > I do. We

Topic for discussion... 2.4.26

Would be nice, I think, to start discussion on a T of 2.4.26 and to open the doors to who wants to RM. Note, that if *nobody* offers to RM, I will... and no matter what, I offer to help whoever wishes to RM.

Re: svn commit: r1782875 [1/3] - in /httpd/httpd/trunk: ./ modules/http2/

> On Feb 15, 2017, at 7:07 AM, Yann Ylavic wrote: > > On Mon, Feb 13, 2017 at 10:00 PM, wrote: >> Author: icing >> Date: Mon Feb 13 21:00:30 2017 >> New Revision: 1782875 >> >> URL: http://svn.apache.org/viewvc?rev=1782875=rev >> Log: >> On the trunk:

Re: svn commit: r1782419 - /httpd/httpd/trunk/modules/proxy/mod_proxy_fcgi.c

ener <cove...@gmail.com> wrote: > > On Fri, Feb 10, 2017 at 10:31 AM, Jim Jagielski <j...@jagunet.com> wrote: >> related to this and >> >>http://svn.apache.org/viewvc?rev=1782482=rev >> >> what exactly are we defining as the difference between unsett

Re: svn commit: r1782419 - /httpd/httpd/trunk/modules/proxy/mod_proxy_fcgi.c

related to this and http://svn.apache.org/viewvc?rev=1782482=rev what exactly are we defining as the difference between unsetting an envar and setting it as "empty"?

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

> On Feb 8, 2017, at 4:09 PM, Jacob Champion <champio...@gmail.com> wrote: > > On 02/08/2017 12:31 PM, Jim Jagielski wrote: >> Have you even TRIED it? > > Yes, with the latest trunk, a config of > > >SetHandler "proxy:fcgi://localhost:1010

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

Have you even TRIED it? I have. With PHP-FPM as well as that Perl script FPM. All works as expected. > On Feb 8, 2017, at 3:27 PM, Jacob Champion <champio...@gmail.com> wrote: > > On 02/08/2017 12:10 PM, Jim Jagielski wrote: >> Doesn't the below make it work without ch

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

> On Feb 8, 2017, at 2:49 PM, Jacob Champion <champio...@gmail.com> wrote: > > On 02/08/2017 11:32 AM, Jim Jagielski wrote: >> It does it automatically requiring no config-file changes >> to the end user. > > Anyone picking up the SCRIPT_FILENAME change (wh

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

> On Feb 8, 2017, at 1:08 PM, Jacob Champion wrote: > > On 02/08/2017 07:52 AM, Eric Covener wrote: >> My concern is that nobody ever reported this config as broken and >> there's no telling what any on-by-default change here can break. > > +1. > > Maybe a different way

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

Just to be clear, I simply *tested* against that config... the patch is not designed to do anything with it. It was basically to ensure that it introduced no regressions.

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

> On Feb 8, 2017, at 10:52 AM, Eric Covener <cove...@gmail.com> wrote: > > On Wed, Feb 8, 2017 at 10:45 AM, Jim Jagielski <j...@jagunet.com> wrote: >> Which ones? You mean the special case one? >> >> Would it be better if we did that *before* calling &g

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

Which ones? You mean the special case one? Would it be better if we did that *before* calling the fix_cgivars(). What is there makes the following config pair work as-is: AddType application/x-php7-fpm .php Action application/x-php7-fpm /fpm virtual SetHandler

Re: proxy test failures between 2.4 and trunk

I am back w/ cycles so ping me if I can help. > On Feb 8, 2017, at 8:47 AM, Eric Covener <cove...@gmail.com> wrote: > > I owe a backport in this one, jorton added the test to demonstrate an > issue reported. Will move it along today. > > On Wed, Feb 8, 2017 at 8

proxy test failures between 2.4 and trunk

Just a FYI that there is a test failure in t/modules/proxy.t in 2.4-HEAD which is not present in trunk... # testing : reverse Location-proxy to index.html # expected: 200 # received: '404' not ok 3 # testing : reverse Location-proxied body # expected: qr/^welcome to / # received: ' # # 404 Not

Re: Summary: Broken FastCGI with httpd

> On Jan 30, 2017, at 4:21 PM, Jacob Champion <champio...@gmail.com> wrote: > > On 01/30/2017 01:17 PM, Jim Jagielski wrote: >> Looking over fpm_main, Apache is detected iff PHP sees the proxy:balancer >> and/or >> proxy:fcgi prefix. Looking at the logic

Re: Summary: Broken FastCGI with httpd

> On Jan 30, 2017, at 4:17 PM, Jim Jagielski <j...@jagunet.com> wrote: > >> >> On Jan 30, 2017, at 4:04 PM, Jacob Champion <champio...@gmail.com> wrote: >> >> On 01/28/2017 07:22 AM, Jim Jagielski wrote: >>> In your scenario does "old

Re: Summary: Broken FastCGI with httpd

> On Jan 30, 2017, at 4:04 PM, Jacob Champion <champio...@gmail.com> wrote: > > On 01/28/2017 07:22 AM, Jim Jagielski wrote: >> In your scenario does "old mode" == "old" Apache or non Apache? > > "Old" Apache. > >> My idea w

Re: Summary: Broken FastCGI with httpd

> On Jan 27, 2017, at 1:36 PM, Jacob Champion <champio...@gmail.com> wrote: > > On 01/27/2017 04:56 AM, Jim Jagielski wrote: >> Let me relook over fpm-main... from what I saw, there are only 2 >> logic paths: one if Apache and the other for everybody-else... >&g

Re: [proposed] 2.4 Maintenance SIG

https://www.youtube.com/watch?v=jKGjOE_7bYI

Re: Summary: Broken FastCGI with httpd

Ahh... thanks! Yeah, it looks like other than removing the prefix (and host:port), it does nothing more Apache-wise. > On Jan 27, 2017, at 8:28 AM, Luca Toscano <toscano.l...@gmail.com> wrote: > > > > 2017-01-27 13:56 GMT+01:00 Jim Jagielski <j...@jagunet.com>: >

Re: Summary: Broken FastCGI with httpd

> On Jan 26, 2017, at 6:13 PM, Jacob Champion wrote: > > > +1 (just not for 2.4.26, per my OP in the thread -- there is no way I can > find around the current PHP-FPM "fixups" without compatibility-breaking > behavior). > Let me relook over fpm-main... from what I

Re: Summary: Broken FastCGI with httpd

> On Jan 26, 2017, at 1:38 PM, Jacob Champion wrote: > > On 01/26/2017 09:49 AM, Eric Covener wrote: >> Do you have a scenario that sends a bad var in 2.4 that is corrected >> by the recent trunk changes? > > I just need to start adding test cases to the suite, I think.

Re: Summary: Broken FastCGI with httpd

As of HEAD on trunk, configs with the below seem to work as expected: AddType application/x-php7-fpm .php Action application/x-php7-fpm /fpm virtual SetHandler proxy:fcgi://localhost:9001 -- SetHandler "proxy:fcgi://localhost:9001 What other scenarios

Re: Summary: Broken FastCGI with httpd

ded. > On Jan 26, 2017, at 7:56 AM, Eric Covener <cove...@gmail.com> wrote: > > On Thu, Jan 26, 2017 at 7:49 AM, Jim Jagielski <j...@jagunet.com> wrote: >> It seems that in many, many cases, we just to "adjust" a handful of >> the ennvars populated by ap_add

Re: Summary: Broken FastCGI with httpd

It seems that in many, many cases, we just to "adjust" a handful of the ennvars populated by ap_add_cgi_vars()... Right now, with my patch, we are doing it directly and explicitly in mod_proxy_fcgi. No doubt there are other places that need such special treatment as well. One possibility would be

Re: Summary: Broken FastCGI with httpd

The long and short is that if we can get SCRIPT_NAME right, the rest is cake... > On Jan 26, 2017, at 4:07 AM, David Zuelke wrote: > > On 26.01.2017, at 06:16, Eric Covener wrote: >> >> On Wed, Jan 25, 2017 at 6:12 PM, David Zuelke wrote:

Re: Summary: Broken FastCGI with httpd

) >= 0 ) { > $proc_manager->pm_pre_dispatch(); > print("Content-type: text/plain\r\n\r\n"); > print Dumper(\%req_params); > } > } > FCGI::CloseSocket($socket); > > On Wed, Jan 25, 2017 at 11:31 PM, Jim Jagielski <j...@jagunet.com> wrote: >> OK... I just committed something that in the AddType/Action >> setup has reasonable values w/ php-fpm70 > > > > -- > Eric Covener > cove...@gmail.com

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

This was tested with: AddType application/x-php7-fpm .php Action application/x-php7-fpm /php7-fpm virtual SetHandler proxy:fcgi://localhost:9000 What setup are you looking at? Can you provide your config. I'm testing to see if we even need the dconf->backend_type anymore... That

Re: Summary: Broken FastCGI with httpd

OK... I just committed something that in the AddType/Action setup has reasonable values w/ php-fpm70

Re: Summary: Broken FastCGI with httpd

OK, got it working and just saw that in these cases, proxy_fcgi_canon() isn't even called... which throws that whole idea out of the water.

Re: Summary: Broken FastCGI with httpd

Can you provide to me a pgp-fpm.conf that you use... Basically, I want to create an environ that exactly uses the AddType application/x-php7-fpm .php Action application/x-php7-fpm /php7-fpm virtual SetHandler proxy:fcgi://localhost:9000 setup. This shows what the httpd conf

Re: Summary: Broken FastCGI with httpd

The idea was to key in on the extension specified in the AddType line. > On Jan 24, 2017, at 8:43 AM, David Zuelke <d...@heroku.com> wrote: > > On 24.01.2017, at 01:24, Jim Jagielski <j...@jagunet.com> wrote: >> >> >>> On Jan 23, 2017, at 4:35 PM, J

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

++1. I know that Daniel is out of pocket for a little bit so I'l give it a coupla more days before I "restore" to the original filter code... > On Jan 24, 2017, at 3:46 AM, Ruediger Pluem <rpl...@apache.org> wrote: > > > > On 01/17/2017 02:48 PM, Jim Jagielski

Re: Summary: Broken FastCGI with httpd

> On Jan 23, 2017, at 4:35 PM, Jacob Champion wrote: > > > What situations lead to CONTENT_TYPE being set to a PATH_INFO delimiter? I'm > not sure what this is supposed to do. > The *idea* was to look for ".php" in the actual URL for example :)

[no subject]

Yeah, this was fast and dirty and really a concept... I'm in Arlington VA for the next coupla of days and won't be able to get another look until later. Basically, the idea was to trigger when FCGI is in place... Maybe notes is better than subprocess_env for that special knowledge.

Re: Summary: Broken FastCGI with httpd

OK, I was thinking something like this, which tries to "compartmentalize" it to where we actually create the CGI vars... Anyone able to test? diff --git a/modules/mappers/mod_actions.c b/modules/mappers/mod_actions.c index 2a67a2742..efe22f814 100644 --- a/modules/mappers/mod_actions.c +++

Re: svn commit: r1779525 - /httpd/httpd/trunk/modules/http2/h2_mplx.c

> On Jan 19, 2017, at 4:00 PM, Ruediger Pluem wrote: > > > > On 01/19/2017 09:38 PM, ic...@apache.org wrote: >> Author: icing >> Date: Thu Jan 19 20:38:50 2017 >> New Revision: 1779525 >> >> URL: http://svn.apache.org/viewvc?rev=1779525=rev >> Log: >> On the trunk: >> >>

Re: Reset out x.minor.z definition of 'minor' at httpd?

> On Jan 20, 2017, at 3:36 PM, Jim Jagielski <j...@jagunet.com> wrote: > > > If I really was the dictator Bill tries to insinuate that I am, > I would simply branch 2.5 *right now* off of trunk. In fact, I'd announce 2.5-alpha "immediately" as what's in trunk.

Re: Reset out x.minor.z definition of 'minor' at httpd?

> On Jan 20, 2017, at 3:37 PM, Graham Leggett wrote: > > > We’ve had a significant amount of progress, a trunk that is so stable that > almost all fixes and features can be backported to v2.4 without any fear of > incompatibility, and the “fighting” is limited to very few

Re: [Bug 60071] Child httpd processes crash with Segmentation fault when enabling more than 1 healthcheck

Cool! Yann, I see this as a show-stopper for 2.4.26... Do you agree? Would you like to propose this (and the 2 other commits) for backport to close this bug. Thx! > On Jan 20, 2017, at 2:21 AM, bugzi...@apache.org wrote: > > https://bz.apache.org/bugzilla/show_bug.cgi?id=60071 > > --- Comment

Re: Reset out x.minor.z definition of 'minor' at httpd?

> On Jan 20, 2017, at 12:47 PM, David Zuelke wrote: > > > I'd actually like to question the whole practice of porting features back to > older branches. I think that's the core reason why trunk is in total > disarray, and why no substantial releases have been made. There is

Re: Reset out x.minor.z definition of 'minor' at httpd?

> On Jan 20, 2017, at 9:26 AM, William A Rowe Jr wrote: > > > Just so we are all in agreement, 2.4 has been neither conservative nor > maintenance in any conventional sense, for the past four years. Instead > we have users relying on the stable 2.2 release which we will

Re: Alternate versioning proposal: patch line releases

> On Jan 20, 2017, at 10:43 AM, Eric Covener wrote: > > On Fri, Jan 20, 2017 at 9:53 AM, William A Rowe Jr > wrote: >> Many if not most developers disagree with you, most developers agree that >> adding features and enhancements is disruptive. 2.4.x

Re: Reset out x.minor.z definition of 'minor' at httpd?

Bill wrote: >I think one of our disconnects with 2.4 -> 2.6 is that in any other framework, >there would be > no ABI breakage in 2.6. That breakage would be deferred to and shipped as > 3.0. Huh? For just one single, simple example, what about APR?? Are we going to now redefine the

Re: Alternate versioning proposal: patch line releases

I can even imagine a world where that makes sense...

Re: [proposed] 2.4 Maintenance SIG

There is no such thing as "Jim's Releases" or "Bill's Releases". The PMC votes on them and the release is an action of the PMC. It's a PMC release. As for why I do it: It's a chore. Mostly "thankless" due to the drama one needs to endure and the fact that you will be assured that at least someone

Re: [proposed] 2.4 Maintenance SIG

> On Jan 19, 2017, at 3:12 PM, Jacob Champion wrote: > > I don't agree with everything Bill is saying here, but to be fair to him: if > people are backporting new features and higher-risk changes to 2.4.x at the > same time an RM is trying to coordinate a bugfix-only

Re: Summary: Broken FastCGI with httpd

> On Jan 19, 2017, at 1:08 PM, David Zuelke wrote: > > Yeah, not much interest yet, sorry :( Jim, I think you have a php.net > account; are you also on that mailing list and can chime in? > It's been awhile... certainly before the Github switch. Don't *think* I'm on the

Re: Summary: Broken FastCGI with httpd

Let me mull this over... basically, we want/need to be able to read into the AddType directive the MIME type and the suffix and then look for the 1st occurance of a "file" with that suffix in the URL path and *assume* that is the actual SCRIPT_NAME. Being aware that this is virtual via the Action

Re: Summary: Broken FastCGI with httpd

> On Jan 19, 2017, at 1:00 PM, Jacob Champion wrote: > >> Would it make sense, mostly from a PHP point-of-view, to send >> something like SCRIPT_FILENAME_RAW (or even >> APACHE_SCRIPT_FILENAME)... Or does that simply complicate an already >> fuzzy and nebulous situation? >

Re: Summary: Broken FastCGI with httpd

Would it make sense, mostly from a PHP point-of-view, to send something like SCRIPT_FILENAME_RAW (or even APACHE_SCRIPT_FILENAME)... Or does that simply complicate an already fuzzy and nebulous situation? Is [1] being used as the canonical place for this discussion w/ the PHP Group? 1.

Re: [proposed] 2.4 Maintenance SIG

You seem to be ignoring the times when bug-fixes, and regression-fix-only patches themselves have resulted in regressions. Or when bug-fixes themselves devolve into grand-scale refactoring which greatly introduce the very real probability of regressions. Handling regressions seems independent

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

This is to address the following bug: https://bugzilla.redhat.com/show_bug.cgi?id=1410883 The only reason why I can see why the orig idea to use s->process->pool was to make watchdog run independent of any restarts of httpd itself... that is, a truly independent watchdog. But that would imply

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.

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