On Fri, Dec 5, 2014 at 7:45 AM, Jeff Trawick <[email protected]> wrote:
> On Thu, Dec 4, 2014 at 11:50 AM, Jeff Trawick <[email protected]> wrote: > >> On Thu, Dec 4, 2014 at 10:38 AM, Eric Covener <[email protected]> wrote: >> >>> forked from apachecon thread >>> >>> On Thu, Dec 4, 2014 at 10:23 AM, Jeff Trawick <[email protected]> wrote: >>> > On Thu, Dec 4, 2014 at 9:58 AM, Eric Covener <[email protected]> >>> wrote: >>> >> >>> >> On Tue, Dec 2, 2014 at 4:14 PM, Jim Riggs <[email protected]> >>> 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?
