Re: Jetty Gzip Compression

2013-10-23 Thread Martin Grigorov
See https://issues.apache.org/jira/browse/WICKET-5392


On Fri, Nov 30, 2012 at 5:11 PM, Martin Grigorov mgrigo...@apache.orgwrote:

 Try with wget/curl client instead.
 I meant text/javascript ..


 On Fri, Nov 30, 2012 at 4:08 PM, Nick Pratt nbpr...@gmail.com wrote:

 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/
 




 --
 Martin Grigorov
 jWeekend
 Training, Consulting, Development
 http://jWeekend.com http://jweekend.com/




Re: Jetty Gzip Compression

2012-11-30 Thread Martin Grigorov
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/


Re: Jetty Gzip Compression

2012-11-30 Thread Nick Pratt
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.orgwrote:

 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/



Re: Jetty Gzip Compression

2012-11-30 Thread Martin Grigorov
Try with wget/curl client instead.
I meant text/javascript ..


On Fri, Nov 30, 2012 at 4:08 PM, Nick Pratt nbpr...@gmail.com wrote:

 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/
 




-- 
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com http://jweekend.com/