Re: [Catalyst] App Deployment - Apache, FastCGI, init.d
also, try daemontools - that shell script will shrink to about 3 lines, and managing it will be a cinch. It's in the cat calendar stuff somewhere. On 9/20/07, Hans Dieter Pearcey [EMAIL PROTECTED] wrote: On Wed, Sep 19, 2007 at 08:57:10PM -0500, Mitchell Jackson wrote: I've seen it mentioned on the list to use daemon tools with PAR ( http://www.catalystframework.org/calendar/2006/4 ) but that uses the built-in myapp_server.pl, running it's own web server, and I much prefer the apache/fastcgi approach, most especially because it leaves the work of serving static content to apache instead of the heavier application process. You misread. It uses myapp_server.pl only to make sure the PAR works properly. Keep reading and you'll see it uses myapp_fastcgi.pl. hdp. ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/ -- Daniel McBrearty email : danielmcbrearty at gmail.com http://www.engoi.com http://danmcb.vox.com http://danmcb.blogger.com find me on linkedin and facebook BTW : 0873928131 ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] Re: Problem using Static::Simple
On 19/09/2007, Will Hawes [EMAIL PROTECTED] wrote:
On 19/09/2007, Will Hawes [EMAIL PROTECTED] wrote:
Having upgraded all Catalyst modules to their latest versions today, I
think I'm seeing strangeness with Static::Simple. I've boiled it down to the
following:
1) $ catalyst.pl MyApp
2) Modify MyApp::Controller::Root::default() as follows:
sub default {
my( $self, $c ) = @_;
$c-response-status(404);
$c-response-body( 'not found' );
}
3) $ PATH_INFO=/static1 perl MyApp/script/myapp_cgi.pl
Content-Length: 9
Content-Type: text/html; charset=utf-8
Status: 404
not found
When accessing the app through Apache using Firefox with the
LiveHTTPHeaders extension, the response headers are reported as follows:
HTTP/1.x 404 OK
Date: Wed, 19 Sep 2007 17:48:48 GMT
Server: Apache/2.0.55 (Ubuntu) ...
X-Catalyst: 5.7010
Content-Length: 9
Keep-Alive: timeout=15, max=99
Connection: Keep-Alive
Content-Type: text/html; charset=utf-8
4) Modify myapp.yml as follows (the intention being to serve static
files from /var/www/static/*):
static:
dirs: [ 'static' ]
include_path: [ '/var/www' ]
5) $ PATH_INFO=/static1 perl MyApp/script/myapp_cgi.pl
Status: 404
Note that the Catalyst-generated Content-Length and Content-Type
response headers, as well as the response body, have disappeared. Accessing
the script via Firefox with LiveHTTPHeaders now shows the following:
HTTP/1.x 404 OK
Date: Wed, 19 Sep 2007 17:48:17 GMT
Server: Apache/2.0.55 (Ubuntu) ...
X-Catalyst: 5.7010
Keep-Alive: timeout=15, max=99
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/x-perl
Forgot to mention, these response headers cause Firefox to try to
download a PL file.
I'd have thought a request for /static1 should be ignored by
Static::Simple using the above config and that only URLs like /static/1
should be treated as pointing to static content.
Have I misunderstood something?
I've dug around for a while in Catalyst::Plugin::Static::Simple, here's what
I've found:
1) The unexpected matching of URLs like /static1 (as well as the expected
/static/1) seems to be because no trailing slash is used in the regular
expression that performs the match:
my $re = ( $dir =~ m{^qr/}xms ) ? eval $dir : qr/^${dir_re}/;
Perhaps this is by design, but adding the trailing slash to appears to fix
the problem while still allowing files to be served from the specified
static directories:
my $re = ( $dir =~ m{^qr/}xms ) ? eval $dir : qr/^${dir_re}\//;
I assume the trailing slash could be added to each item in dirs in my
config to achieve the same effect. I haven't tested that but even if there's
a good reason not to modify the regex, I think the behaviour should be
documented in ::Static::Simple.
2) When a non-existent static file is requested, Firefox tries to download a
PL file rather than displaying a 404 message. This appears to be because
::Static::Simple sets $c-res-status to 404, but does not set a content
type. This causes content-type to be auto-detected as text/x-perl, which
in turn makes Firefox want to download the file. Hacking ::Static::Simple to
set $c-res-content_type manually to text/html fixes the problem.
I can't see why the standard behaviour in either case above would be by
design. Are these valid problems I've highlighted and what do you think of
the suggested fixes?
___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] App Deployment - Apache, FastCGI, init.d
Mitchell Jackson wrote: Does anybody have a better init script than the one below for handling the fastcgi processes? I'm probably missing something obvious X.X I've been generating an init.d script with Catalyst::Helper::FastCGI::ExternalServer [1] for our Ubuntu servers without issue. -Brian [1] http://search.cpan.org/dist/Catalyst-Helper-FastCGI-ExternalServer/ ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] Catalyst::Controller::Rose::Simple
Hello list, I just uploaded on CPAN the module : http://search.cpan.org/dist/Catalyst-Controller-Rose-Simple/ that makes use of Rose::* easier ith Catalyst. It is version 0.01, so use with care and development environment use only. I know, documentation and tests are not very good... Feel free to ask me any question you want. Cheers, -- -- \^/-- ---/ O \----- -- | |/ \| Alexandre (Midnite) Jousset | -- ---|___|----- ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] Login via IP address?
I have a Cat app with the usual Session and Authentication
stuff running, though I'm using my own Authz stuff instead of
any of the built-in Roles tools. It's a typical setup with
regular users who can just view things, some users with
add/edit privs, and superusers who can create new users etc.
In a previous, non-Cat version of this app I had a function so
that people using the app from the main company location would
automatically be logged in as a generic regular user, and
only if they tried to do any adding/editing would get
redirected to a login page. I forgot about this and didn't
build it into the Cat version, and now I've learned that the
reason people continue to use the clunky old version instead
of my shiny fast featureful Cat app is that they're too lazy
to log in, so I'd like to add this.
The way it looked, more or less, in the old one was:
if ( !defined( $self-login_user() ) ) {
if ( $ENV{REMOTE_ADDR} =~ m/hairyIPaddressRegEx/ ) {
$self-login(generic);
$self-redirect( $self-{target_uri} );
} else {
# redirect to login page
}
}
What's the Right Way to do this in Cat?
Thanks.
Jesse, still not programming much lately
___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/
[Catalyst] Can't find my canary
I have a problem trying to use Catalyst::Plugin::FormCanary. There are 3 routines: sub setup checks to make sure session is up and running. It is. sub finalize_session successfully creates the canary keys and adds a hidden input tag to $c-response-body. I wrote output of $c-response-body to $c-log-debug, so I can see that at the command line. But when my page displays in the browser, view source shows that the hidden input tag is NOT there. I'm probably missing something very basic in what happens to $c-response-body, just not sure what. So when I (say) try to login, sub prepare_action can't find the canary. Bummer. Help? /dennis ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Catalyst::Controller::Rose::Simple
Hello Matt, Matt S Trout wrote: Feel free to ask me any question you want. Why haven't you submitted patches to the existing C-C-Rose? Any module called '-Simple' usually means there was an existing module that worked but I'm too lazy to patch it - please justify why that isn't the case here :) Well, I wasn't meaning that kind of question but hey, I said any question you want ;-)... Seriously, this is of course a good question, so here is my answer. I'm sure I haven't your experience but for me (and also for Peter Karman, C::C::Rose author), the suffix ::Simple (suggested by him) means Take all that [what already exists, i.e. Catalyst and Rose] and make it simpler to use together. In fact I don't even use its modules in mine since the goals are not the same and the functionalities don't overlap. The key point is that you can see it as the C::C::FormBuilder module reimplemented for Rose (and that was really the case). At first, on Peter's advice, I looked at C::C::Rose::* but I did not found anything relevant for what I was trying to do. I hope this answer your question. personal message I've seen you were coming to FPW2007 in Lyon, France. I'll also be there (presenting this module) so I'm looking forward to meet you IRL ;-) /personal message Regards, -- -- \^/-- ---/ O \----- -- | |/ \| Alexandre (Midnite) Jousset | -- ---|___|----- ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Can't find my canary
On Thu, 2007-09-20 at 08:43 -0700, Dennis Daupert wrote: I have a problem trying to use Catalyst::Plugin::FormCanary. Two things. First is, FormCanary is a hack. It would be better to let your form validation system handle canary injection and verification. FormCanary isn't going to work very well for AJAX. (Maybe I will add an API method $c-get_canary_html or something, but taking a bad idea even further might be ... bad :) However, if FormCanary's munging is appropriate for your application, wait a bit for me to release 0.02. It turns out that the body is now sent before finalize_session gets to inject the canary. I have fixed this locally but still have the verification test failing because C::P::S::S::Cookie is broken on all my machines. You can get my body fix from git, though, and see if that works on your machine. (git == git clone git://git.jrock.us/Catalyst-Plugin-FormCanary, or http://git.jrock.us if you want a tarball.) BTW, did the tests originally pass for you? If they did and the module doesn't work, I would be interested in hearing more about that. Regards, Jonathan Rockway ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] Encoding problem - ?fastcgi?
I got my all-singing all-dancing Catalyst app onto a proper server a few
days ago. It's all going much better than I thought it might, a couple of
friendly guinea-pigs, a fine crop of helpful comments, glitches getting
spotted fixed, a thriving TODO list ... and one problem which worries me -
I prefer bugs to be in my code, because then I can fix them and end of
story, but I don't think this is.
There is a point where I send data out as a variety of other mime-types.
This is either text, in a small range of iso-8859 encodings (I work in utf8
internally, of course, so this is encoded specifically). or binary,
generated from that text as a temporary file by external programs and read
in from that. This is output with, eg,
$c-res-content_type('application/pdf');
$c-res-body($data);
Developing testing this on my machine at home, this works as it should. On
the remote server, I can view the files directly, and they're as they should
be; I can request the data through :3000 from script/appname_server.pl, and
again, it's correct; but hand it out through script/appname_fastcgi.pl +
mod_fastcgi/apache and it's broken; each single byte with the high bit set
is replaced by a 0xC3 0xsomethingelse pair - it's been recoded into utf8,
with values that assume it was Latin 1 to start with (regardless of anything
I put in the Content-Type). Workaround is to replace the code above with a
redirect to the temporary file, which then goes out through Static::Simple
and arrives uncorrupted.
The data leaves my code with the utf8 flag unset, and is handled properly by
C::P::Unicode. So I think it must be in the fastcgi conversation ? Has
anybody else seen this, or have any ideas ? I can't see any changes in
C::E::FastCGI.pm that offer any Clue, and I'm really not sure where to go
next.
System at home, where it doesn't happen, is Apache/2.0.54 with Catalyst
modules from, I think, last January or thereabout (the new Debian stable
caught me by suprise, bringing the home box up to date is going to be a big
job I have other things I'd rather be doing). Remote system, where it
does happen, is Apache/2.2.3 with cpan upgrade a few days ago. mod_fastcgi
is the same on both (2.4.2)
The site is
http://livetunebook.qualmograph.org.uk
just in case anybody wants a look. Traditional tunes.
--
Richard Robinson
The whole plan hinged upon the natural curiosity of potatoes - S. Lem
___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Catalyst::Controller::Rose::Simple
Alexandre Jousset wrote on 9/20/07 11:41 AM: Hello Matt, Matt S Trout wrote: Feel free to ask me any question you want. Why haven't you submitted patches to the existing C-C-Rose? Any module called '-Simple' usually means there was an existing module that worked but I'm too lazy to patch it - please justify why that isn't the case here :) Well, I wasn't meaning that kind of question but hey, I said any question you want ;-)... Seriously, this is of course a good question, so here is my answer. I'm sure I haven't your experience but for me (and also for Peter Karman, C::C::Rose author), the suffix ::Simple (suggested by him) means Take all that [what already exists, i.e. Catalyst and Rose] and make it simpler to use together. Alexandre, Actually, I had suggested you use ::Simple because in your original email to me, (a) you had indicated you intended to use C::C::Rose, but with an API similar to the FormBuilder philosophy, and (b) you had a working title of C::C::Rose::FormManager, which I thought would be misleading, since all the existing C::C::Rose::* classes also manage forms. As you indicate below, you don't use any of the C::C::Rose code, design or philosophy, so sharing the namespace seems misleading at the very least. So I'd prefer it if you used a difference namespace altogether. I believe the latest best practice recommendation is to use the CatalystX top-level space. Perhaps something like CatalystX::RHTMLOManager or similar. In fact I don't even use its modules in mine since the goals are not the same and the functionalities don't overlap. The key point is that you can see it as the C::C::FormBuilder module reimplemented for Rose (and that was really the case). At first, on Peter's advice, I looked at C::C::Rose::* but I did not found anything relevant for what I was trying to do. I'd like to encourage you in your efforts at making the Rose projects easier to use with Catalyst. Since you've got a different approach to what easy means than I do, starting with a namespace that clearly delineates your project from mine seems to be in your best interest. pek -- Peter Karman . http://peknet.com/ . [EMAIL PROTECTED] ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
