Ive stepped through the GzipFilter, and things look to be processed through
the Gzip compression, but only my welcome.html page is returned as gzipped
- all the .css and .js resources do not have a gzip Content-Encoding set on
them.
Just to clarify, did you really mean "text/application" instead of
"text/css" and "application/javascript" ?
N
On Fri, Nov 30, 2012 at 3:45 AM, Martin Grigorov <mgrigo...@apache.org>wrote:
> Hi,
>
> The gzip filter should be before Wicket filter. This way it has the chance
> to manipulate the response generated by Wicket.
> Wicket just calls httpServletResponse.setContentType("text/application")
> and httpServletResponse.write(someStringWithJS).
> GZipFilter's job is to change the content type and gzip the JS string.
> I recommend you to put a breakpoint in GZipFilter and see what happens.
>
>
> On Thu, Nov 29, 2012 at 8:30 PM, Nick Pratt <nbpr...@gmail.com> wrote:
>
> > Ive enabled Gzip compression via the Jetty filter for my application
> (Jetty
> > v6 and v8).
> > Based on Chrome Dev Tools and Firebug in Firefox, my .js and .css files
> are
> > not being compressed (browser states in the request that it will take
> gzip
> > response), although text/html is, and Im trying to understand why.
> >
> > Ive got the mimeTypes configured in the GzipFilter servlet, minGzipSize
> > defaults to 0 bytes.
> >
> > In Wicket 6, is there anything going on with the resources that would
> > prevent Jetty's GzipFilter from working?
> >
> > Ive tried placing the filter both before and after the WicketFilter.
> >
> > Chrome's PageSpeed analyzer also thinks most of my larger JS files are
> not
> > compressed (Ive been looking at the Response headers)
> >
> > Any thoughts?
> >
> > N
> >
>
>
>
> --
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com <http://jweekend.com/>
>
