Thanks,
I looked into sources now and I see how it works now. I was under assumption
that production mode also controls the compressing, well it is not.
I was experimenting a bit with headers and also by looking at the source
code of the isGZipSupported() method I can see that some rare cases are
>From GZipFilter implements HttpServletRequestFilter {
private final ResponseCompressionAnalyzer analyzer;
public boolean service(HttpServletRequest request, HttpServletResponse
response, HttpServletRequestHandler handler)
throws IOException
{
HttpServletResponse newRespon
So, the header takes precedence over production mode setting and the
tapestry.gzip-compression-enabled?
Is this really the case?
-borut
2011/9/12 Steve Eynon
>
> http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/services/ResponseCompressionAnalyzer.html
>
> Looks like it has been
http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/services/ResponseCompressionAnalyzer.html
Looks like it has been doing since T5.1.
Steve.
On 12 September 2011 21:14, Borut Bolčina wrote:
> Hi,
>
> at the moment the only way to configure T5 response compression is via
> tapestry
Hi,
at the moment the only way to configure T5 response compression is via
tapestry.gzip-compression-enabled.
Should the configuration extend to support checking Accept-Encoding request
header?
-borut
