Re: Summary: Broken FastCGI with httpd

On 02/05/2017 05:10 AM, Jim Jagielski wrote: Not seeing anything fpm_main.c... Line 1144 in my copy (attached). It's an example of an Apache-specific fixup that only runs if apache_was_here is *false*. --Jacob if (!apache_was_here && env_path_translated != NULL && env_redirect_url !=

Re: Summary: Broken FastCGI with httpd

> On Jan 30, 2017, at 4:21 PM, Jacob Champion 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 paths related to 'apache_was_here' > >

Re: Summary: Broken FastCGI with httpd

On 01/30/2017 01:21 PM, Jim Jagielski wrote: Plus, other than the "additional" way of detecting apache_was_here, that file has been very stable with no real changes: https://github.com/php/php-src/commits/master/sapi/fpm/fpm/fpm_main.c since

Re: Summary: Broken FastCGI with httpd

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 paths related to 'apache_was_here' No, apache_was_here is only *new* Apache. There are other fixups that trigger on other

Re: Summary: Broken FastCGI with httpd

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

Re: Summary: Broken FastCGI with httpd

> On Jan 30, 2017, at 4:04 PM, Jacob Champion 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 was to send FCGI data such that PHP-FPM doesn't use *any* >>

Re: Summary: Broken FastCGI with httpd

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 was to send FCGI data such that PHP-FPM doesn't use *any* Apache-related fixups. In other words, httpd sends "what it should" and PHP-FPM "uses what it receives"

Re: Summary: Broken FastCGI with httpd

On Sat, Jan 28, 2017 at 10:22 AM, Jim Jagielski wrote: > >> On Jan 27, 2017, at 1:36 PM, Jacob Champion 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

Re: Summary: Broken FastCGI with httpd

> On Jan 27, 2017, at 1:36 PM, Jacob Champion 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... >> and the Apache path only kicks in

Re: Summary: Broken FastCGI with httpd

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... and the Apache path only kicks in if it sees the proxy:balancer or proxy:fcgi prefix. Unfortunately there are at least

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 wrote: > > > > 2017-01-27 13:56 GMT+01:00 Jim Jagielski : > > > On Jan 26, 2017, at 6:13

Re: Summary: Broken FastCGI with httpd

2017-01-27 13:56 GMT+01:00 Jim Jagielski : > > > 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

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 01/26/2017 10:59 AM, Jim Jagielski wrote: We can easily handle generic FCGI expectations via the script that Eric referred to... what's harder is that PHP does it's own adjustments of what we send. Right, there are tests for our CGI compliance in general (PR 51517) and then there are

Re: Summary: Broken FastCGI with httpd

On 26.01.2017, at 18:03, Jim Jagielski wrote: > > 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 > > >

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

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. That way we're all on the same page as to the things that need to be fixed. --Jacob

Re: Summary: Broken FastCGI with httpd

On 01/25/2017 09:30 PM, Eric Covener wrote: But since it's a 2.4.23 regression for fpm, I am looking for the minimum change, because there are just too many potential fastcgi servers we could be contacting. Right, I agree. In fact I'd almost be fine with just reverting my patch and the query

Re: Summary: Broken FastCGI with httpd

On Thu, Jan 26, 2017 at 12:03 PM, Jim Jagielski wrote: > 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 >

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

Yeah... that was something brought up earlier... leveraging ap_expr with access to things like r->path_info, etc directly. Right now, we don't have that mechanism, although we could likely leverage mod_lua maybe to hook in after subprocess_env has been populated and then adjust as needed. > On

Re: Summary: Broken FastCGI with httpd

On Thu, Jan 26, 2017 at 7:56 AM, Eric Covener wrote: > > Dunno if the evaluation is late enough though. You need to see the > output of the ap_add_* which to me implied you'd need an > expression-aware FCIG directive that is really evaluated right where > we'd do the override.

Re: Summary: Broken FastCGI with httpd

On Thu, Jan 26, 2017 at 7:49 AM, Jim Jagielski wrote: > 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

Re: Summary: Broken FastCGI with httpd

On Thu, Jan 26, 2017 at 4:07 AM, David Zuelke wrote: > > RewriteRule ^ index.php [L], GET /ohai: > > $_SERVER['SCRIPT_NAME'] /index.php > $_SERVER['REQUEST_URI'] /ohai > $_SERVER['REDIRECT_URL']/ohai > $_SERVER['SCRIPT_FILENAME'] /app/index.php > > Last case is

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

Is this via AddType/Action? > On Jan 25, 2017, at 11:37 PM, Eric Covener wrote: > > Seems like w/ the update it's still a bogus PATH_INFO that fpm is correcting > > 'PATH_INFO' => '/foo.php/bar/baz/', > > I'm using this as the target from one of the old bug

Re: Summary: Broken FastCGI with httpd

On 26.01.2017, at 06:16, Eric Covener wrote: > > On Wed, Jan 25, 2017 at 6:12 PM, David Zuelke wrote: >>> AddType application/x-php7-fpm .php >>> Action application/x-php7-fpm /php7-fpm virtual >>> >>>SetHandler proxy:fcgi://localhost:9000 >>> >>>

Re: Summary: Broken FastCGI with httpd

I'm testing your recent config and the config from https://github.com/apache/httpd/commit/cab0bfbb2645bb8f689535e5e2834e2dbc23f5a5#commitcomment-20393588 w/ htaccess that makes index.php act like a front controller. Lately I look at the output of the fakefpm.pl script I posted above, but was

Re: Summary: Broken FastCGI with httpd

On Wed, Jan 25, 2017 at 6:12 PM, David Zuelke wrote: >> 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 looks like... >> can you

Re: Summary: Broken FastCGI with httpd

Seems like w/ the update it's still a bogus PATH_INFO that fpm is correcting 'PATH_INFO' => '/foo.php/bar/baz/', I'm using this as the target from one of the old bug reports. #!/usr/bin/perl use FCGI; use Socket; use FCGI::ProcManager; use Data::Dumper; $num_args = $#ARGV + 1; if

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

On 25.01.2017, at 20:12, Jim Jagielski wrote: > > 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 > >

Re: Summary: Broken FastCGI with httpd

On 01/25/2017 12:21 PM, Jim Jagielski wrote: 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. I argue that this is a bug. It's made other PHP fixes difficult. See [1], about halfway through the message.

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 wrote: > > On 24.01.2017, at 01:24, Jim Jagielski wrote: >> >> >>> On Jan 23, 2017, at 4:35 PM, Jacob Champion wrote:

Re: Summary: Broken FastCGI with httpd

On 24.01.2017, at 01:24, Jim Jagielski wrote: > > >> 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*

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

Re: Summary: Broken FastCGI with httpd

On 01/23/2017 09:05 AM, Jim Jagielski wrote: OK, I was thinking something like this, which tries to "compartmentalize" it to where we actually create the CGI vars... Anyone able to test? This patch doesn't seem to change anything in my limited tests so far. Comments inline: diff --git

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

On 19.01.2017, at 19:00, Jacob Champion wrote: > > On 01/18/2017 01:00 PM, Jim Jagielski wrote: >> After all, it's easier for the FCGI server to know the SCRIPT_NAME >> than httpd to "guess"... > > I think the recent breakage calls this assumption into question. The server

Re: Summary: Broken FastCGI with httpd

On 01/18/2017 01:00 PM, Jim Jagielski wrote: After all, it's easier for the FCGI server to know the SCRIPT_NAME than httpd to "guess"... I think the recent breakage calls this assumption into question. The server admin knows exactly where the scripts are in the use cases we're currently

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: Summary: Broken FastCGI with httpd

The thing is that when we are proxying back, some of those values can't make sense, since, for example, there is no "real" path on the httpd server that maps to the actual request file I think the original idea was to simply send the full URL to the FCGI server, to let it parse things out for

Re: Summary: Broken FastCGI with httpd

On 01/18/2017 06:47 AM, David Zuelke wrote: Thanks for picking this up! And thank you for driving this on the PHP side! --Jacob

Re: Summary: Broken FastCGI with httpd

On 01/17/2017 11:46 PM, Stefan Eissing wrote: Would it make sense to narrow down the setups to a few blessed ones that become part of our tests? I think so. Problem is that I don't, myself, know what is actually in use out there. I keep learning about new ways to invoke CGI every month, it

Re: Summary: Broken FastCGI with httpd

On 01/18/2017 06:56 AM, Eric Covener wrote: Unfortunately we might need our own directives for the overrides here to get them to run after the normal vars are calculated and only when we're in the proxy_fcgi handler. See https://bz.apache.org/bugzilla/show_bug.cgi?id=28903 for an older

Re: Summary: Broken FastCGI with httpd

On 01/18/2017 06:43 AM, Jim Jagielski wrote: 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. They don't make sense. For example, mod_proxy_fcgi can be set up in a

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

On Wed, Jan 18, 2017 at 9:47 AM, David Zuelke wrote: > There's one more caveat around SCRIPT_FILENAME, I think: it might not be the > same for httpd and the FCGI backend if they're running on separate machines! I think this goes to the notion of overriding these variables w/

Re: Summary: Broken FastCGI with httpd

> On 17.01.2017, at 23:16, Jacob Champion wrote: > > (This conversation is currently spread over Bugzilla, IRC, GitHub, and > php-internals. Here's my attempt at summarizing it for all of you. If you > have no interest in CGI or FastCGI, stop reading now.) Thanks for

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: Summary: Broken FastCGI with httpd

Thanks for the nice summary, Jacob. I find the topic of cgi in our server surprisingly complex. Sometimes mod_http2 stumbles on "details" like conn->id to identify requests that Seemed a Good Idea at the time. Would it make sense to narrow down the setups to a few blessed ones that become