[Catalyst] Capture page on server?
Sorry, bit of a newbie question: is there any way that I can run an action but capture the results (server-side) to a file? Doing so client side is easy (eg wget) but I want to keep the page text on the server and to automate the page generation/save. -- Regards, Martin ([EMAIL PROTECTED]) IT: http://methodsupport.com Personal: http://thereisnoend.org ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Capture page on server?
On 23 Jun 2008, at 21:45, Martin Ellison wrote: Sorry, bit of a newbie question: is there any way that I can run an action but capture the results (server-side) to a file? Doing so client side is easy (eg wget) but I want to keep the page text on the server and to automate the page generation/save. From Catalyst::View::TT: render($c, $template, \%args) Renders the given template and returns output, or a Template::Exception object upon error. ... so: my $var = $c-render($template, \%args); my $file = '/what/ever.html'; print $FH, , $file; ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Capture page on server?
* On Mon, Jun 23 2008, Martin Ellison wrote: Sorry, bit of a newbie question: is there any way that I can run an action but capture the results (server-side) to a file? Doing so client side is easy (eg wget) but I want to keep the page text on the server and to automate the page generation/save. If you want to log the output of every request, you probably want to wrap finalize and save the file after it runs. If you want to run an arbitrary request against your application and see the result, you want the Subrequest plugin. It would be better for your app to not depend upon your app, though. Calling a method is simpler, faster, and cleaner than running an entire request and capturing the result, so try to structure your app in such a way as to allow that. Regards, Jonathan Rockway -- print just = another = perl = hacker = if $,=$ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Capture page on server?
I actually want to save a static copy of the front page to improve load times. My fastcgi process sometimes disappears (I'm on shared hosting and I think they auto-cancel stale processes), and it takes a while for the process to be restarted, which impacts the first page load. Subsequent pages are faster but it's the first page that makes the impression on the user. The static plugin does not work, because that requires fastcgi to be running, and my app is too small for me to set up squid. So I want to redirect the front page to a static page, but regenerate the static page, and also force the app to do something (so the server can restart the fastcgi process before the user requests any other page). 2008/6/23 Jonathan Rockway [EMAIL PROTECTED]: * On Mon, Jun 23 2008, Martin Ellison wrote: Sorry, bit of a newbie question: is there any way that I can run an action but capture the results (server-side) to a file? Doing so client side is easy (eg wget) but I want to keep the page text on the server and to automate the page generation/save. If you want to log the output of every request, you probably want to wrap finalize and save the file after it runs. If you want to run an arbitrary request against your application and see the result, you want the Subrequest plugin. It would be better for your app to not depend upon your app, though. Calling a method is simpler, faster, and cleaner than running an entire request and capturing the result, so try to structure your app in such a way as to allow that. Regards, Jonathan Rockway -- print just = another = perl = hacker = if $,=$ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/ -- Regards, Martin ([EMAIL PROTECTED]) IT: http://methodsupport.com Personal: http://thereisnoend.org ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Capture page on server?
ok, that works thanks (as does the server side wget). 2008/6/23 Kieren Diment [EMAIL PROTECTED]: On 23 Jun 2008, at 21:45, Martin Ellison wrote: Sorry, bit of a newbie question: is there any way that I can run an action but capture the results (server-side) to a file? Doing so client side is easy (eg wget) but I want to keep the page text on the server and to automate the page generation/save. From Catalyst::View::TT: render($c, $template, \%args) Renders the given template and returns output, or a Template::Exception object upon error. ... so: my $var = $c-render($template, \%args); my $file = '/what/ever.html'; print $FH, , $file; ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/ -- Regards, Martin ([EMAIL PROTECTED]) IT: http://methodsupport.com Personal: http://thereisnoend.org ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Capture page on server?
On Tue, Jun 24, 2008 at 12:23:05AM +0800, Martin Ellison wrote: I actually want to save a static copy of the front page to improve load times. My fastcgi process sometimes disappears (I'm on shared hosting and Will setting the TTCACHE help at all? -- Chisel Wright e: [EMAIL PROTECTED] w: http://www.herlpacker.co.uk/ Don't cha wish your boyfriend was geek like me? ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] [Fwd: [rt-users] Security vulnerability in RT 3.0 and up]
H. Is this something Catalyst needs to worry about? --[Lance] -- GPG Fingerprint: 409B A409 A38D 92BF 15D9 6EEE 9A82 F2AC 69AC 07B9 CACert.org Assurer ---BeginMessage--- All versions of RT from 3.0.0 to 3.6.6 (including some, but not all RT 3.7 development releases) are vulnerable to a potential remote denial of service attack which could exhaust virtual memory or consume all available CPU resources. After a detailed analysis, we believe that an attacker would need to be a 'Privileged' RT user in order to perform an attack. We recommend that you install version 1.19 or newer of the Perl module Devel::StackTrace from CPAN, which will close the vulnerability. Two methods for doing this are: * Using the CPAN shell - as root, run the following: # cpan Devel::StackTrace * Download and install the package by hand - as root, run the following: # wget http://www.cpan.org/authors/id/D/DR/DROLSKY/Devel-StackTrace-1.1901.tar.gz # tar xvzf Devel-StackTrace-1.1901.tar.gz # cd Devel-StackTrace-1.1901 # perl Makefile.PL # make # make test # make install Installing this newer version of the module is a complete fix, and will close the vulnerability. However, we suggest that you upgrade to RT 3.6.7, released last Monday, which provides additional safeguards against this type of attack. We wish to thank Rune Hammersland [EMAIL PROTECTED] for bringing this issue to our attention in a diligent and professional manner, and to Dave Rolsky [EMAIL PROTECTED] for working with us to resolve the issue in the libraries that RT uses. If you need help resolving this issue locally, we will provide significantly discounted pricing for single-incident support. Please contact us at [EMAIL PROTECTED] for more information. signature.asc Description: This is a digitally signed message part ___ RT-Announce mailing list [EMAIL PROTECTED] http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-announce ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com---End Message--- ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Capture page on server?
Martin Ellison wrote:
I actually want to save a static copy of the front page to improve load
times. My fastcgi process sometimes disappears (I'm on shared hosting
and I think they auto-cancel stale processes), and it takes a while for
the process to be restarted, which impacts the first page load.
Subsequent pages are faster but it's the first page that makes the
impression on the user. The static plugin does not work, because that
requires fastcgi to be running, and my app is too small for me to set up
squid.
So I want to redirect the front page to a static page, but regenerate
the static page, and also force the app to do something (so the server
can restart the fastcgi process before the user requests any other page).
We do exactly this for our app and it's a lifesaver when hit with a
Slashdotting. Our app is 99% read / 1% write so using a lightweight
HTTP server (Lighttpd, NginX, etc) in front of the FastCGI Catalyst
app makes for amazing scalability.
To do this, we have something like this in our Root controller:
sub render : ActionClass('RenderView') {}
sub end : Private {
my ( $self, $c ) = @_;
$c-forward('render');
if ($c-stash-{save_response_as}) {
File::Slurp::write_file(
$c-stash-{save_response_as},
{ atomic = 1, buf_ref = \$c-res-body }
);
}
}
Then you can use some -f style rules in apache or lighttpd to serve
the file if it exists. On the (relatively) rare occasion of a write
request we simple delete the files from the cache.
Hope that helps!
- Brian
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Capture page on server?
Bill Moseley [EMAIL PROTECTED] writes: On Mon, Jun 23, 2008 at 07:10:31PM +0200, Matthias Zeichmann wrote: On Mon, Jun 23, 2008 at 18:23, Martin Ellison [EMAIL PROTECTED] wrote: I actually want to save a static copy of the front page to improve load times. did you look into http://search.cpan.org/dist/Catalyst-Plugin-Cache/lib/Catalyst/Plugin/Cache.pm ? Or even: http://search.cpan.org/~agrundma/Catalyst-Plugin-PageCache-0.18/ I doubt these plugins will help Martin since he's trying to fix the problem that his FCGI backend process has been torn down. On this subject though, PageCache is a really useful low-work high-return way to do some simple page caching from Catalyst. It has built-in support for only caching unauth'd pages, caches based on wildcards, all kinds of useful stuff. But there is one caveat I ran into when playing with it. If you're doing Content-Encoding negotiation in Catalyst (with C::P::Compress::Gzip, for example), the PageCache doesn't know about it and will cache either the gzip'd or plain version depending on which is first hit, then serve that out indiscriminately to all clients. As an example, hit a cachable page with your web browser (which supports gzip), then try to fetch the same (cached) page with curl or something; you'll get the gzip'd stream of gibberish. If you're doing Content-Encoding negotiation in your webserver, which is probably better (and with a patch or 1.5 trunk lighttpd now supports this with mod_deflate), you don't have to worry about this. I've been mulling over whether there's any reasonable way to fix things to deal with this, but it amounts to any kind of content negotiation needing to run very early (as part of dispatch?) and somehow publishing that information to the rest of the pipeline. In the case of PageCache, it would simply need to incorporate any negotiated content information into the cache key. This sort of runs the whole gamut from Accept, Accept-Language, Accept-Encoding, etc. If negotiations required explicit controller code, you could make the case that we should just augment cache_page to accept some kind of cache key seed so that the controller could run some very minimal code, then call cache_page with like seed = 'json' or whatever. Unfortunately, people like their negotiation code to be transparent, like the compression or the cool auto-negotiation that the REST stuff does (which IIRC will output json, xml, yaml, whatever transparently to the controller code). /rdj ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] Re: Capture page on server?
* Ryan D Johnson [EMAIL PROTECTED] [2008-06-23 20:40]: I've been mulling over whether there's any reasonable way to fix things to deal with this, but it amounts to any kind of content negotiation needing to run very early (as part of dispatch?) and somehow publishing that information to the rest of the pipeline. Yes, http://tools.ietf.org/html/rfc2616#section-14.44 HTTP. If you are a web app developer, it is your job to learn it, love it, live it, breathe it. At the very least, study RFC 2616 once to know what’s in there. Most people who try to “solve” some problem with their web app architecture a) do so because they are ignorant of all the facilities of HTTP and b) end up inventing a worse wheel than what HTTP itself provides. The simplicity of HTTP is deceptive; it conceals the deep deliberation that went into choosing *this* form of simplicity vs some other one. (Oh, and this is not a personal comment to you, Ryan – I mean the “you”s above in the general sense.) Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Re: Capture page on server?
Aristotle Pagaltzis [EMAIL PROTECTED] writes: * Ryan D Johnson [EMAIL PROTECTED] [2008-06-23 20:40]: I've been mulling over whether there's any reasonable way to fix things to deal with this, but it amounts to any kind of content negotiation needing to run very early (as part of dispatch?) and somehow publishing that information to the rest of the pipeline. HTTP. I'm not 100% sure if I followed your point. I think it was well-behaved servers should be setting the Vary response header when content is negotiated based on a request header, and well-behaved caches should pay attention to it. Here's where I show ignorance of the Catalyst plugin model. For example, C::P::PageCache and C::P::Compress::Gzip both hook into finalize -- PageCache to cache the data, Gzip to compress the data. Is the calling order for those two guaranteed somehow by NEXT? If I include PageCache *last* (or *first*?) in the plugin load order, will that guarantee that all the other plugins have done their work? If so, it might make sense for PageCache to pay attention to the Vary header. I imagine that the cache save and lookup code will get significantly more complex, though. /rdj ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Re: Capture page on server?
On Mon, Jun 23, 2008 at 3:40 PM, Aristotle Pagaltzis [EMAIL PROTECTED] wrote: If so, it might make sense for PageCache to pay attention to the Vary header. I imagine that the cache save and lookup code will get significantly more complex, though. Not a whole lot – it needs to incorporate those request headers into a compound key. I was thinking more of the lookup than the storage. Perhaps it's as straightforward as associating a set of headers with a given URI so that you can remember which ones need to be used to generate the lookup key. But what if two responses for the same URI yield a different Vary header? Etc. It's starting to sound more like search than lookup. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
