I've resorted to returning a TextStreamResponse with "application/json" as the content type in order to bypass gzip compression.
2009/1/23 Patrick Moriarty <[email protected]>: > Looks like adding "application/json" to the configuration for > ResponseCompressionAnalyzer doesn't quite do it because it's compared > directly against "application/json;charset=UTF-8". > > I could add "application/json;charset=UTF-8" but I think > ResponseCompressionAnalyzer should probably ignore the charset and any > other parameters in isCompressable() > > Patrick > > > 2009/1/23 Patrick Moriarty <[email protected]>: >> Hi, >> >> Since the recent introduction of gzip compression returning a >> JSONObject from a mixin event method results in an empty responseText >> in Firefox. It seems there is some problem with Content-Type: >> application/json and Content-Encoding: gzip headers that prevents the >> response from being decompressed correctly by the browser. Has anyone >> come across this before? A Google search doesn't reveal much. >> >> For now I'm disabling compression for "application/json". Perhaps >> this should be the default behaviour? >> >> This seems to be the case with IE too. I attempted to check behaviour >> in Opera, but the response was not gzipped since the Accept-Encoding >> request header sent by Opera includes a space (eg. "deflate, gzip, >> ..." instead of "deflate,gzip,..."). >> IE6 also includes a space but places gzip at the beginning. Tapestry >> should probably trim the spce before comparing to "gzip" in >> ResponseCompressionAnalyzerImpl. >> >> Thanks, >> >> Patrick >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
