[Catalyst-dev] nginx patch to Engine::FastCGI?

[Chris Carline]

On Thu, Oct 30, 2008 at 8:35 PM, J. Shirley <jshirley at gmail.com> wrote:
> I am working on a new nginx+fastcgi deployment, and this time the
> Catalyst app is not at "/" like my previous other deployments.  It
> seems that nginx doesn't quite jive with Catalyst out of the box in
> this case.
>
> I'm going to just describe the problem, as my solution is far from
> elegant, and hope that more Engine-centric folks can chime in with
> better ideas.
>
> nginx doesn't distinguish the request path any different than the
> subsequent path info (appended to the end of the path).  So,
> $env{SCRIPT_NAME} and $env{PATH_INFO} are effectively the same value.
> In the case of "/" this doesn't present any problem, but if your
> application is at a different path ("/myapp" for example) then it
> break.s
>
> The good thing is nginx allows for arbitrary variables to be set in
> the FastCGI config space, so you can explicitly set SCRIPT_NAME or
> PATH_INFO.  This doesn't help though with PATH_INFO always contains
> information for $c->req->base to be built though.
>
> The solution I came up with is to tell nginx to define the variables as such:
>
> fastcgi_param  SCRIPT_NAME        /ems/;
> fastcgi_param  PATH_INFO          $fastcgi_script_name; # Effectively
> /ems/{PATH_INFO}
>
> And then, in Engine::FastCGI I have this small patch, to remove the duplication:
>        if ( $env{SERVER_SOFTWARE} && $env{SERVER_SOFTWARE} =~ /nginx/ ) {
>            $env{PATH_INFO} =~ s/^$env{SCRIPT_NAME}//g;
>        }
>
> This is the only way I could get the base URI to be constructed
> properly.  I'm not that experienced with nginx, but I couldn't find
> anything at all in their documentation to help with it.
>
> Hopefully someone has some better thoughts on this...

I don't know if it's a better thought, but I subclassed the
prepare_path method of Engine::CGI in an Engine::FastCGI::WithParams
module that reads the values (for said environment variables) I need
from the application yaml if they exist... (updating the target engine
in the <app>_fastcgi.pl script is also required).

This also plays nicely with catalyst server and mod_perl deployments
as they use different engines.

It's a simple solution, but works well for my purposes (I'd rather
push this sort of thing through application config rather than env
vars tied to specific instances of my catalyst apps, as it means I can
use the same web server config to instantiate catalyst services for
everything).

I'm hoping for better thoughts too, but deadlines being what they are...