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/

Reply via email to