Jetty-servlets GzipFilter不适用于Jetty 9.2.7.v20150116和Spring

Question

I'm using following xml in my web.xml -file to configure the GzipFilter to my Spring application which I'm running with Jetty. I would expect to see the resource size getting smaller when inspecting with developer tools in Chrome and also I would expect to see the "encoding" to have value "gzip" in response headers. However, none of these are visible.

However when examining with debugging tools in my IDE I noticed that the filter gets applied (I put the break point to GzipFilter) and also I noticed that the etag-headers have an -gzip extension in responses, when examining with developer tools. However the contents don't seem to be zipped.

I'm running out of ideas and would appreciate any help.

<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,application/json,image/svg+xml</param-value>
  </init-param>
</filter>
<filter-mapping>
  <filter-name>GzipFilter</filter-name>
  <url-pattern>/*</url-pattern>
</filter-mapping>

Edit: Adding request and response headers

 Request:
 GET ******* HTTP/1.1
 Host: localhost:8081
 Connection: keep-alive
 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6)       AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36
 Accept: */*
 Referer: http://localhost:8081/
 Accept-Encoding: gzip, deflate, sdch
 Accept-Language: en-US,en;q=0.8,fi;q=0.6
 Cookie: XSRF-TOKEN=******; JSESSIONID=*******

 Response:
 HTTP/1.1 200 OK
 Date: Mon, 29 Aug 2016 13:59:59 GMT
 Cache-Control: public
 Date: Mon, 29 Aug 2016 13:59:59 GMT
 Content-Type: application/javascript;charset=UTF-8
 Vary: Accept-Encoding, User-Agent
 ETag: "0f93db3b42f19c57f4a216dd80f63bae5--gzip"
 Server: Jetty(9.2.7.v20150116)
 Transfer-Encoding: chunked

Answer 1

The --gzip suffix on the ETag is used by the GzipFilter to know if the request processing actually went through a GzipFilter .

It's purpose is to break the ETag support in DefaultServlet if the request was once gzipped, and is now no longer gzipped.

Meaning this flow:

• Server configured with gzip
• Request to resource /foo.js
• DefaultServlet sends response to /foo.js with ETag: abcdef
• GzipFilter is configured to compressed application/javascript , so it compressed the response and alters the ETag to ETag: abcdef--gzip
• Some time later, the GzipFilter is reconfigured (different url-pattern, different mime-types, whatever)
• Same User-Agent requests resource /foo.js with ETag: abcdef--gzip , but this doesn't go through GzipFilter anymore, so the DefaultServlet will not recognize the ETag and serve the content afresh.

As for why your content isn't being compressed, its either due to the way you are setting the response.setContentType() or the size of the response body content.

First, you'll need to make sure that you always set response status codes, response headers, and (optionally) response buffer sizes before you access the response outputstream (or writer), as the .getOutputStream() and .getWriter() both use the values from the response object to set themselves up.

The GzipFilter also uses these values to know if the response should be compressed or not.

Next, the size of the response body content is important, as there is a lower limit to the the response size before the GzipFilter will get involved. (its actually inefficient to compress most content below the GzipFilter.minGzipSize )

In your version of Jetty, I believe the minGzipSize is 256 bytes.

As your pasted response headers is without a Content-Length and Transfer-Encoding: chunked , I cannot tell how big your response actually was.

Important upgrade note: GzipFilter in Jetty 9.3+ has been completely deprecated and results in a no-op if used. This is because the filter approach for Gzip compression is highly problematic when Servlet 3.1 and Async I/O are in use.

The Gzip support in Jetty 9.3+ has been moved outside of the Servlet spec and into a low level HttpOutput.Interceptor pattern that only compresses the content after a flush has occurred (either automatic internal or application specified).

To say this another way, the servlet buffers are not compressed as they are written from the application to the servlet buffers like in Jetty 9.2 and before. They are instead only compressed when they leave the servlet buffers and enter the network level writes.