Using contentType and response size as a criteria for determining whether or not to apply gzipping makes a lot of sense when handling Tapestry responses. However, we just integrated javamelody (https://code.google.com/p/javamelody/) that's implemented as a filter and does its own gzipping. You could argue that javamelody should provide that as a configurable option but currently doesn't. Luckily it was easy enough to override ResponseCompressionAnalyzer and use it's deprecated and currently unused contribution as a collection of paths that should be excluded from gzipping by T5. Just wondering if others think this is too much of an edge case to support or if we should put it back in the core and reuse the contribution for excluded paths? Are there any other valid reasons to disable gzipping on case-by-case basis than existing resource specific compression and the size of a response?
Kalle --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
