[Catalyst] Capture page on server?

[Ryan D Johnson]

Bill Moseley <moseley at hank.org> writes:

> On Mon, Jun 23, 2008 at 07:10:31PM +0200, Matthias Zeichmann wrote:
>> On Mon, Jun 23, 2008 at 18:23, Martin Ellison <m.e at acm.org> 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