Well, while Lenny and Thiago supported this on a conceptual level I didn't get any additional use cases where gzip excluded paths would be a desired feature. Meanwhile, 1.39.0 Javamelody added a configuration option for turning off gzipping and I see Howard has already removed the contribution from ResponseCompressionAnalyzerImpl in 5.4. We can always add it back in if somebody finds a convincing use case for the feature.
Kalle On Fri, Jul 13, 2012 at 9:40 AM, Kalle Korhonen <[email protected]> wrote: > 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]
