I think this would be interesting :) +0 > From: Jens Lorenz [mailto:[EMAIL PROTECTED]] > From: "Stefano Mazzocchi" <[EMAIL PROTECTED]> > > > Well, IMHO there are still some cases where a GZIPSerializer might > > > be useful. But thanks to you Luca and Stefano for opening my eyes > > > for the world outside Cocoon. > > > > You are welcome. > > > > Anyway, I believe that a HTML-gzipping-serializer is a bad idea because > > is mixes concerns: GZIP compression is a property of the transport layer > > and should be transparent. > > > > As for lack of caching: I also think that Cocoon should stop caching its > > generated resources and just try to be more proxy friendly. But that is > > another story. > > To summarize this issue ... I tested the CompressionFilter coming as > example with Tomcat and it works just fine. No need to hack into Cocoon > and doesn't serve incomplete gzip files. > Also it automatically detects accept-encoding of the browser and only > compresses, if compression is supported by the http client. > > For production environments, it's probably a good idea to extend this > example to compress only html and text files. No much sense in compressing > gif and jpg files, besides wasting cpu cycles ... > > If anyone is interested, I would prepare a patch to the CompressionFilter > coming with tomcat and to cocoons web.xml, with the filter commented out, > so that only these comments need to be removed, in order to get compressed > output from cocoon/tomcat. > > > Jens > > -- > > jens.lorenz at interface-projects dot de > > interface:projects GmbH \\|// > Tolkewitzer Strasse 49 (o o) > 01277 Dresden ~~~~oOOo~(_)~oOOo~~~~ > Germany > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
