Mailing List Archive

On Thu, Oct 30, 2008 at 8:35 PM, J. Shirley <jshirley@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...

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev

Re: nginx patch to Engine::FastCGI? [ In reply to ]

Oct 31, 2008, 12:52 PM

Post #3 of 16 (17522 views)

On Thu, Oct 30, 2008 at 6:16 PM, Chris Carline <chris@carline.org> wrote:
> On Thu, Oct 30, 2008 at 8:35 PM, J. Shirley <jshirley@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...
>

I see your point on this, but it's a slightly different issue. The
issue isn't one of changing or overriding configuration, it's about
just base functionality ($c->req->base) that should work out of the
box. In my opinion nginx is going to be one of the most common
deployment platforms, for many reasons, and it would be harmful to
Catalyst to not work out of the box with it.

If there was a way to get the anchor part of the confg and do the
variable substitution there, I would much prefer that and just have a
cookbook entry. That isn't quite possible, though.

I'm not too worried about minor patches for upstream servers, as
lighttpd requires a slight tweak to work properly with Engine::FastCGI
too.

-J

--
J. Shirley :: jshirley@gmail.com :: Killing two stones with one bird...
http://www.coldhardcode.com/

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev

Re: nginx patch to Engine::FastCGI? [ In reply to ]

Oct 31, 2008, 4:26 PM

Post #4 of 16 (17523 views)

On 31 Oct 2008, at 19:52, J. Shirley wrote:

>
> I'm not too worried about minor patches for upstream servers, as
> lighttpd requires a slight tweak to work properly with Engine::FastCGI
> too.
>

It does? As far as I'm aware i've not patched anything in cat to get
my app running under lighty with fastcgi...

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev

Re: nginx patch to Engine::FastCGI? [ In reply to ]

Oct 31, 2008, 4:28 PM

Post #5 of 16 (17510 views)

Re: nginx patch to Engine::FastCGI? [ In reply to ]

Oct 31, 2008, 4:42 PM

Post #6 of 16 (17528 views)

On Fri, Oct 31, 2008 at 4:26 PM, Ash Berlin <ash_cpan@firemirror.com> wrote:
>
> On 31 Oct 2008, at 19:52, J. Shirley wrote:
>
>>
>> I'm not too worried about minor patches for upstream servers, as
>> lighttpd requires a slight tweak to work properly with Engine::FastCGI
>> too.
>>
>
> It does? As far as I'm aware i've not patched anything in cat to get my app
> running under lighty with fastcgi...
>

Look at Catalyst::Engine::FastCGI:
# If we're running under Lighttpd, swap PATH_INFO and SCRIPT_NAME
# http://lists.rawmode.org/pipermail/catalyst/2006-June/008361.html
# Thanks to Mark Blythe for this fix
if ( $env{SERVER_SOFTWARE} && $env{SERVER_SOFTWARE} =~ /lighttpd/ ) {
$env{PATH_INFO} ||= delete $env{SCRIPT_NAME};
}

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev

Re: nginx patch to Engine::FastCGI? [ In reply to ]

Oct 31, 2008, 4:55 PM

Post #7 of 16 (17507 views)

On 31 Oct 2008, at 23:42, J. Shirley wrote:

> On Fri, Oct 31, 2008 at 4:26 PM, Ash Berlin
> <ash_cpan@firemirror.com> wrote:
>>
>> On 31 Oct 2008, at 19:52, J. Shirley wrote:
>>
>>>
>>> I'm not too worried about minor patches for upstream servers, as
>>> lighttpd requires a slight tweak to work properly with
>>> Engine::FastCGI
>>> too.
>>>
>>
>> It does? As far as I'm aware i've not patched anything in cat to
>> get my app
>> running under lighty with fastcgi...
>>
>
> Look at Catalyst::Engine::FastCGI:
> # If we're running under Lighttpd, swap PATH_INFO and
> SCRIPT_NAME
> # http://lists.rawmode.org/pipermail/catalyst/2006-June/008361.html
> # Thanks to Mark Blythe for this fix
> if ( $env{SERVER_SOFTWARE} && $env{SERVER_SOFTWARE} =~ /
> lighttpd/ ) {
> $env{PATH_INFO} ||= delete $env{SCRIPT_NAME};
> }

Ah - the difference between requires and required. As in its already
in the server, and I took your message to mean further user
interaction was needed. So yeah, looks like we need something similar
for nginx. However I think the lighty solution doesn't need any
special config. (I could be wrong here as I've not attempted non-root
lighty+fcgi ever)

-ash

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev

Re: nginx patch to Engine::FastCGI? [ In reply to ]

Oct 31, 2008, 5:09 PM

Post #8 of 16 (17515 views)

On Fri, Oct 31, 2008 at 4:55 PM, Ash Berlin <ash_cpan@firemirror.com> wrote:
>
> On 31 Oct 2008, at 23:42, J. Shirley wrote:
>
>> On Fri, Oct 31, 2008 at 4:26 PM, Ash Berlin <ash_cpan@firemirror.com>
>> wrote:
>>>
>>> On 31 Oct 2008, at 19:52, J. Shirley wrote:
>>>
>>>>
>>>> I'm not too worried about minor patches for upstream servers, as
>>>> lighttpd requires a slight tweak to work properly with Engine::FastCGI
>>>> too.
>>>>
>>>
>>> It does? As far as I'm aware i've not patched anything in cat to get my
>>> app
>>> running under lighty with fastcgi...
>>>
>>
>> Look at Catalyst::Engine::FastCGI:
>> # If we're running under Lighttpd, swap PATH_INFO and SCRIPT_NAME
>> # http://lists.rawmode.org/pipermail/catalyst/2006-June/008361.html
>> # Thanks to Mark Blythe for this fix
>> if ( $env{SERVER_SOFTWARE} && $env{SERVER_SOFTWARE} =~ /lighttpd/ )
>> {
>> $env{PATH_INFO} ||= delete $env{SCRIPT_NAME};
>> }
>
> Ah - the difference between requires and required. As in its already in the
> server, and I took your message to mean further user interaction was needed.
> So yeah, looks like we need something similar for nginx. However I think the
> lighty solution doesn't need any special config. (I could be wrong here as
> I've not attempted non-root lighty+fcgi ever)
>
> -ash
>

nginx already requires special configuration to "work" (it doesn't
populate PATH_INFO at all) so you still have to follow a recipe. It's
very trivial, though, and I don't think it would confuse anybody.

I just really hate the "Lets s/// envvars!" approach...

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev

Re: nginx patch to Engine::FastCGI? [ In reply to ]

syber.rus at gmail

Oct 31, 2008, 5:42 PM

Post #9 of 16 (17527 views)

The main difference is that nginx is 2x faster and 10x more powerful :)
i advice you to play with it ;)

2008/11/1 Ash Berlin <ash_cpan@firemirror.com>

>
> On 31 Oct 2008, at 23:42, J. Shirley wrote:
>
> On Fri, Oct 31, 2008 at 4:26 PM, Ash Berlin <ash_cpan@firemirror.com>
>> wrote:
>>
>>>
>>> On 31 Oct 2008, at 19:52, J. Shirley wrote:
>>>
>>>
>>>> I'm not too worried about minor patches for upstream servers, as
>>>> lighttpd requires a slight tweak to work properly with Engine::FastCGI
>>>> too.
>>>>
>>>>
>>> It does? As far as I'm aware i've not patched anything in cat to get my
>>> app
>>> running under lighty with fastcgi...
>>>
>>>
>> Look at Catalyst::Engine::FastCGI:
>> # If we're running under Lighttpd, swap PATH_INFO and SCRIPT_NAME
>> # http://lists.rawmode.org/pipermail/catalyst/2006-June/008361.html
>> # Thanks to Mark Blythe for this fix
>> if ( $env{SERVER_SOFTWARE} && $env{SERVER_SOFTWARE} =~ /lighttpd/ )
>> {
>> $env{PATH_INFO} ||= delete $env{SCRIPT_NAME};
>> }
>>
>
> Ah - the difference between requires and required. As in its already in the
> server, and I took your message to mean further user interaction was needed.
> So yeah, looks like we need something similar for nginx. However I think the
> lighty solution doesn't need any special config. (I could be wrong here as
> I've not attempted non-root lighty+fcgi ever)
>
> -ash
>
>
> _______________________________________________
> Catalyst-dev mailing list
> Catalyst-dev@lists.scsys.co.uk
> http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev
>

Re: nginx patch to Engine::FastCGI? [ In reply to ]

Oct 31, 2008, 5:59 PM

Post #10 of 16 (17516 views)

On 1 Nov 2008, at 00:42, Oleg Pronin wrote:

> The main difference is that nginx is 2x faster and 10x more powerful
> [than lighttpd] :)
> i advice you to play with it ;)
>
>

Gah top quoting :)

How much faster can you get at shunting off requests to the fastcgi?
And given my site is so low traffic it doesn't matter + It Aint Broke.

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev

Re: nginx patch to Engine::FastCGI? [ In reply to ]

Oct 31, 2008, 8:03 PM

Post #11 of 16 (17518 views)

On Fri, Oct 31, 2008 at 5:59 PM, Ash Berlin <ash_cpan@firemirror.com> wrote:
>
> On 1 Nov 2008, at 00:42, Oleg Pronin wrote:
>
>> The main difference is that nginx is 2x faster and 10x more powerful [than
>> lighttpd] :)
>> i advice you to play with it ;)
>>
>>
>
> Gah top quoting :)
>
> How much faster can you get at shunting off requests to the fastcgi? And
> given my site is so low traffic it doesn't matter + It Aint Broke.
>

I really really really don't want this thread to be hijacked into a
war of the fastcgi frontends. Having said that, *I* think nginx is
awesome and cool and spectacular and beautiful and sechs.

Which is why I'm motivated to get full functionality of it + Catalyst,
which is the thread... so, can any core devs chime in, perhaps andyg
specifically?

Thanks,
-J

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev

Re: nginx patch to Engine::FastCGI? [ In reply to ]

Nov 1, 2008, 7:34 AM

Post #12 of 16 (17490 views)

On 1 Nov 2008, at 03:03, J. Shirley wrote:

> On Fri, Oct 31, 2008 at 5:59 PM, Ash Berlin
> <ash_cpan@firemirror.com> wrote:
>>
>> On 1 Nov 2008, at 00:42, Oleg Pronin wrote:
>>
>>> The main difference is that nginx is 2x faster and 10x more
>>> powerful [than
>>> lighttpd] :)
>>> i advice you to play with it ;)
>>>
>>>
>>
>> Gah top quoting :)
>>
>> How much faster can you get at shunting off requests to the
>> fastcgi? And
>> given my site is so low traffic it doesn't matter + It Aint Broke.
>>
>
> I really really really don't want this thread to be hijacked into a
> war of the fastcgi frontends. Having said that, *I* think nginx is
> awesome and cool and spectacular and beautiful and sechs.

Me either - wasn't my intent.

>
>
> Which is why I'm motivated to get full functionality of it + Catalyst,
> which is the thread... so, can any core devs chime in, perhaps andyg
> specifically?
>
> Thanks,
> -J

Okay, so what are there to get the info needed from nginx to the
fastcgi engine? Is there any way other than to use env vars? i.e. is
the best plan of attack to patch Engine::FastCGI similarly to what's
needed for lighttpd and add some docs somewhere saying 'to run under
non-root nginx do this'?

-ash

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev

Re: nginx patch to Engine::FastCGI? [ In reply to ]

andy at hybridized

Nov 1, 2008, 7:50 AM

Post #13 of 16 (17481 views)

>> Which is why I'm motivated to get full functionality of it +
>> Catalyst,
>> which is the thread... so, can any core devs chime in, perhaps andyg
>> specifically?
>>
>> Thanks,
>> -J
>
> Okay, so what are there to get the info needed from nginx to the
> fastcgi engine? Is there any way other than to use env vars? i.e. is
> the best plan of attack to patch Engine::FastCGI similarly to what's
> needed for lighttpd and add some docs somewhere saying 'to run under
> non-root nginx do this'?

I've never used nginx so I'll leave it up to you guys to come up with
the best solution. If we have to patch the FastCGI engine like we did
for lighttpd it doesn't bother me too much. Have you checked what the
Rails guys (or others) do for this situation? Let's make sure some
obscure config option hasn't been missed first.

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev

Re: nginx patch to Engine::FastCGI? [ In reply to ]

Nov 1, 2008, 8:24 AM

Post #14 of 16 (17499 views)

On Sat, Nov 1, 2008 at 7:50 AM, Andy Grundman <andy@hybridized.org> wrote:
>>> Which is why I'm motivated to get full functionality of it + Catalyst,
>>> which is the thread... so, can any core devs chime in, perhaps andyg
>>> specifically?
>>>
>>> Thanks,
>>> -J
>>
>> Okay, so what are there to get the info needed from nginx to the fastcgi
>> engine? Is there any way other than to use env vars? i.e. is the best plan
>> of attack to patch Engine::FastCGI similarly to what's needed for lighttpd
>> and add some docs somewhere saying 'to run under non-root nginx do this'?
>
>
> I've never used nginx so I'll leave it up to you guys to come up with the
> best solution. If we have to patch the FastCGI engine like we did for
> lighttpd it doesn't bother me too much. Have you checked what the Rails
> guys (or others) do for this situation? Let's make sure some obscure config
> option hasn't been missed first.
>
>

Frustratingly, all the examples I've managed to find are about running
the app at "/". The much more common option is using mongrel, in
which case nginx simply acts as a proxy and FastCGI isn't in the
picture.

Looking at how PHP handles things is also a fools errand, since it is
file based and SCRIPT_NAME points to the executing script.

(Speaking of mongrel, it seems roughly similar to ::Prefork -- has
anybody done any comparisons?)

Sounds like a hacky patch is the way forward :( I could possibly
submit a patch to nginx, but I figure that could be more work...

Thanks,
-J

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev

Re: nginx patch to Engine::FastCGI? [ In reply to ]

pagaltzis at gmx

Nov 2, 2008, 5:08 AM

Post #15 of 16 (17481 views)

* J. Shirley <jshirley@gmail.com> [2008-11-01 16:30]:
> (Speaking of mongrel, it seems roughly similar to ::Prefork --
> has anybody done any comparisons?)

Thatâ€™s what it is. I have no idea about Mongrelâ€™s performance,
since Iâ€™ve never used Rails in anger, but it appears that Mongrel
is written in C in large part. If someone who has the means to
run a few tests easily finds that itâ€™s significantly faster than
C:E:HTTP::Prefork or any other Perl option it might be possible
to port Mongrel to Perl as an XS Perl module without too much
work just by rewrapping the C parts.

Oh yeah, and thereâ€™s an HTTP server implementation in AxKit2, and
of course the new kid on the block, Mojoâ€¦

> I could possibly submit a patch to nginx, but I figure that
> could be more work...

It is also the approach that would benefit everyone, though
(other frameworks besides Catalyst, be they Perl or in other
languages)â€¦

Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev

Re: Re: nginx patch to Engine::FastCGI? [ In reply to ]

Nov 2, 2008, 6:24 AM

Post #16 of 16 (17490 views)