httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@gmail.com>
Subject Re: mod_proxy_fcgi issues
Date Sat, 06 Dec 2014 02:23:39 GMT
On Fri, Dec 5, 2014 at 7:45 AM, Jeff Trawick <trawick@gmail.com> wrote:

> On Thu, Dec 4, 2014 at 11:50 AM, Jeff Trawick <trawick@gmail.com> wrote:
>
>> On Thu, Dec 4, 2014 at 10:38 AM, Eric Covener <covener@gmail.com> wrote:
>>
>>> forked from apachecon thread
>>>
>>> On Thu, Dec 4, 2014 at 10:23 AM, Jeff Trawick <trawick@gmail.com> wrote:
>>> > On Thu, Dec 4, 2014 at 9:58 AM, Eric Covener <covener@gmail.com>
>>> wrote:
>>> >>
>>> >> On Tue, Dec 2, 2014 at 4:14 PM, Jim Riggs <apache-lists@riggs.me>
>>> wrote:
>>> >> > P.S. mod_proxy_balancer -> mod_proxy_fcgi -> php-fpm is really
fun
>>> and
>>> >> > interesting too! ;-)
>>> >>
>>> >> mod_proxy_fcgi seems to need a bit of work from what I have been
>>> >> seeing in bugzilla and IRC.  I hope to spend a little time on the code
>>> >> and doc, but not being an actual user of it I don't know how far I
>>> >> will really get before being distracted.
>>> >
>>> >
>>> > This is very important stuff IMO.
>>> >
>>> > I know we don't do the coordination thing around here, but if the work
>>> was
>>> > organized to some extent, perhaps 3-4 people could easily share the
>>> work???
>>> > (bite sized chunks of the development:  simple reproducers, doc, code,
>>> > review, whatever)
>>> >
>>> > Besides searching through Bugzilla and summarizing each mod_proxy_fcgi
>>> bug
>>> > and ranking by apparent severity, number of users involved in the bug
>>> > discussion, etc., what else should I put on a Wiki page?  E.g., do you
>>> have
>>> > an idea of what needs to be improved in the doc?
>>>
>>> I don't have much more than what amounts to the summary/initial poking
>>> around in the bugzillas.  I had the wiki thought too -- bullets there
>>> are much easie than trying to reabsorb the PRs each time.
>>>
>>> - examples need to account for php-fpm (how URLs and or paths are passed)
>>> - fixes for CGI variables in different configurations (sethandler vs.
>>> proxypass)
>>> -- fixup r->filename right before adding CGI vars, maybe directory walk
>>> -- path info calculation probably needs multiple modes.  Maybe expr
>>> based?
>>>
>>
>> FWIW, every time I see the PATH_INFO questions I recall the nginx
>> configuration (the script vars provided are those defined in the
>> configuration, with some expression support); we need general CGISetVar
>> <var> <expr> that sets or overrides script variables in common code (like
>> CGIPassAuth) so that it works with the many modules that interface with
>> scripts.
>>
>>
>>
>>> - further doc for worker matching stuff with ProxySet
>>> - provide a convenience/less verbose directive to configure SetHandler
>>> +  a backend worker
>>> -- doc SetHandler advantages
>>> - change compile-time diag stuff to trace8
>>> - need to port mod_proxy_http or mod_fcgid body spooling / content
>>> length passing
>>> - would be nice to have a non php-fpm fastcgi server to sanity check
>>> with so we don't end up with too many php-fpm-isms
>>> - figure out / make sure balancer examples work with php-fpm and/or
>>> setHandler
>>>
>>
>> And although mod_proxy_fcgi is  the usual suspect, some of these are
>> important issues with mod_proxy_scgi too.  (It is faster, and for some
>> deployments there's no natural preference for FastCGI over SCGI.)
>>
>> Thanks for all the notes; I'll write this stuff up today.
>>
>>
> Initial version at
> https://wiki.apache.org/httpd/Development/mod_proxy_fcgi
>
> I haven't integrated your list into the table yet
>

Now that's cleaned up.

I guess PATH_INFO is the issue that affects the most people; thoughts?

I guess expression-based support for overriding the default PATH_INFO
calculation is the basis for solving the widest variety of problems with
any of the variables, though I don't know if we'll have the right string
operations available (e.g., substring of dynamic length); thoughts?

Mime
View raw message