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/
