I'm trying to setup Jetty to serve compressed html content. In web.xml I setup GzipFilter and mapped it to /* but this doesn't seem to work. Here's the filter configuration:
<filter>
<filter-name>GZipFi开发者_运维技巧lter</filter-name>
<display-name>Jetty's GZip Filter</display-name>
<description>Filter that zips all the content on-the-fly</description>
<filter-class>org.mortbay.servlet.GzipFilter</filter-class>
<init-param>
<param-name>mimeTypes</param-name>
<param-value>text/html</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>GZipFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
I'm just starting to use Jetty, so the solution might be ridiculously simple. If you can link me to documentation that might help me, that would be great too.
GZIP Compression
GZIP Compression can be used to reduce the amount of data being sent "over the wire". Compression is applied as a transport encoding. This can greatly improve webapplication performance, however it can also consume more CPU and some content (eg images) cannot be well compressed.
Static Content
The Jetty Default Servlet can serve precompressed static content as a transport encoding and avoid the expense of on-the-fly compression. If the "gzip" init parameter is set to true, then Jetty will look for compressed static resources. So if a request for "foo.txt" is received and the file "foo.txt.gz" exists, then it will be served as "foo.txt" with a gzip transport encoding.
GzipFilter
The Jetty Gzip Filter is a compression filter that can be applied to almost any dynamic resource (servlet). It fixes many of the bugs in commonly available compression filters (eg handles all ways that content length may be set) and has been testing with Jetty continuations and suspending requests.
Some user-agents may be excluded from compression, so as to avoid some common browser bugs (yes this means IE!).
refer from jetty doc: http://docs.codehaus.org/display/JETTY/GZIP+Compression
you can look Gzipfilter source code,here is a lot of useful comments : http://download.eclipse.org/jetty/stable-7/xref/org/eclipse/jetty/servlets/GzipFilter.html
I'm gonna answer this too, since I've had a huge headake trying to make this work, and I finally did it. Also, I'm not a major expert in the fine details of HTTP so I'll give a non-professional answer.
First, here's how I checked if my GZipFilter was working or not. Started Firefox, made sure I had the Firebug addon, started the Firebug addon, went to the "Net" tab. Then I accessed the URL which should return a GZipped response. Here's what Firebug shows:
The "Size" column shows the size of the response. If you hover over the "Size" column label with your mouse, it will tell you that if the response is compressed, then it will display the compressed size of the response.
This all was done with the GZip filter enabled in Jetty. I then removed the GZip filter declaration from my web.xml, restarted Jetty and repeated the test. This time around the response had the exact same size as before, which clearly indicated that the GZip compression was not working.
After multiple trial and errors, what I did is look in Firebug at the "Request Headers" section to see the value for the "Accept" header. I've noticed that here this had values such as "application/xml" and "text/xml", but the way I had configured my GZIp filter's init param "mimeTypes" only contained "text/xml" (and was missing "application/xml"). It was configured like so:
<filter>
<filter-name>GzipFilter</filter-name>
<filter-class>org.eclipse.jetty.servlets.GzipFilter</filter-class>
<init-param>
<param-name>mimeTypes</param-name>
<param-value>text/html,text/plain,text/xml,application/xhtml+xml,text/css,application/javascript,image/svg+xml,application/json,application/xml; charset=UTF-8</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>GzipFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
After adding the "application/xml" value to the list like so:
<filter>
<filter-name>GzipFilter</filter-name>
<filter-class>org.eclipse.jetty.servlets.GzipFilter</filter-class>
<init-param>
<param-name>mimeTypes</param-name>
<param-value>text/html,text/plain,text/xml,application/xhtml+xml,application/xml,text/css,application/javascript,image/svg+xml,application/json,application/xml; charset=UTF-8</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>GzipFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
I redid my previous test, and sure enough now the reported size of the response was much smaller:
Also notice that now, the reported Response Headers contain an extra field called "Content-Encoding" with a value of "gzip".
So basically the idea is to check what kind of values you send in your Request "Accept" header and make sure that all those values are configured in the GZip filter's "mimeTypes" init param.
Sometimes using Gzipfilter has some problems, depending on how you are handling buffers and flushing. As such, using org.eclipse.jetty.servlets.IncludableGzipFilter (which actually an extends GzipFilter) may solve your problems.
On jetty 9.3:
edit jetty.conf and include the xml file "jetty-gzip.xml"
edit start.ini and add "--module=servlets"
edit jetty-gzip.xml and configure the mime-types you want.
Restart jetty and test again.
What was the error? Are you getting classpath problems or something else? If classpath, you need to make sure the gzipfilter class is available to the jetty runtime or it will die.
Are you sending the request with the "Content-Encoding: gzip" request header?
精彩评论